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

> Insulting people will get you nowhere at all. Well there over hundred messages and some people don't dare to study topic, I was repeating my messages multiple times already. > If you want to be able to perform index searches, then import the data in tables with fields allowing you to do so. That

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

"I suggest you to deal with it" (sic!) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

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

> You know that it's always a trade-off, right? Exactly. Regex advocates are ponies in DB design. > disk usage/IO Index lookup for "color:green:lightgreen"=yes is fast. full table scan just to compute regex for each value is not Or wait do you have an custom DB for OSM tailored both for regexes a

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

> in order to catch them all you need color:*green*=yes, a (simple) regular expression I don't need any regex. STOP. color:green=yes color:green:lightgreen=yes "color:green"="yes" query is dead simple. > Even with your schema you will not be able to avoid that people will need regular expression

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

> in order to catch them all you need color:*green*=yes, a (simple) regular expression. No, I don't. I use tags color:green=yes color:green:lightgreen=yes And will search for "color:green"=yes while I wait for native multivalue tags. > Even with your schema you will not be able to avoid that peo

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

Well not perfect solution at the moment, but least I don't need to teach somebody regexes: "color:green"=yes | "color:lightgreen"=yes | "color: bluegreen"=yes | ... "But how this is different from regexes?" you would say. 1. There no regexes at all 2. There should be pages about http://wiki.opens

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

> That object is not part of the result set. Maybe he meant how to find out that an item is missing from the list? Well I don't see how that becomes any easier by moving the values over to the keys. "color:green"!=* in overpass should return values without information about green color or "color:gr

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

> 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. > name=* > name#2=* > name#3=* There no point in using indexes in key. You need s

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

> So the data in OSM is still "color=purple;orange;green" This data will be untranslated for iD users. It is freetext without selectbox and prone to errors. *You have to know tags* *when you use this approach*. http://wiki.openstreetmap.org/wiki/Key:mtb:scale:imba is not displayed directly as mtb:

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

Agree, there no regexes at first. But is it possible to query this tagging scheme? Lets say you have color[1]=purple color[2]=orange color[3]=green How do you query for green in overpass? In JOSM? And what if for another object you will have different set of tags with different order? color[1]=bl

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

Or wait, I actually misunderstood you, my point is still valid. Did you mean color[1]=yellow? color[2]=red? But again, how do you query then? Query for red? color[*]=red? Regexes again. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.ope

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

> key[1]=value1 key[2]=value2 > and returning to the semicolon mode on the output again. That would probably help avoid too much regexping. I see your point, but sadly this is not solution. I was always mentioning xxx:yyy scheme as *semantic subkeys*, there no semantic in: key[1] - what does 1 mea

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

I cannot understand your example without illustration. > Hide the internals from the end-users. We can easily hide *something*:japanese=yes *something*:korean=yes under single field *something*=**, but not vice versa. I suggested plugin for JOSM that will present multiple subkeys as text field or

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

> Using a xxx:yyy schema also requires checkboxes besides every existing value in JOSM presets. So I don't see how it is any easier for new mappers or preset creators. Problem in multiple values in value part in *key=value.* How iD should parse cuisine=mexican;japanese? This work repeated every t

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

> opening_hours:Mo-We 08:00-17:00 = yes > opening_hours:Th-Fr 08:00-21:00 = yes > would in my opinion lead to an inordinate number of subkeys. If you were reading other people messages you would probably notice that opening_hours=* tag was mentioned as minor exception to general rule *not to use

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

> Presets are a problem [1],[2] and it is not easy to present tag list with more than 50 tags per object. This is irrelevant to multivalued keys or multiple subkeys problem actually. You need to organize 50 variants under some checkboxes or select lists. It will be hard regardless if we decide to

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

Propaganda. Propaganda. Propaganda. > But it's harder to get all tags in category. How would you get all the payment methods, not the exact 'ellectrico'? Why normal person need to know about all payments methods if he/she only have mastercard/ellectrico/coins? You probably never use data at all.

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

> > \b means word boundary (any character that starts or ends a word, such as > space, colon, semicolon, etc) > However, word boundaries can be slow and are not recommended if you need to > search large areas (e.g. whole world, germany or similar). > In this case, we could use something like: >

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

right http://taginfo.openstreetmap.org/search?q=lanes Can somebody continue this list of exceptions? 2015-01-21 15:23 GMT+03:00 Frederik Ramm : > Hi, > > On 01/21/2015 12:07 PM, Никита wrote: > > *route_ref:De_Lijn:8=yes* > > *route_ref:De_Lijn:9=yes* > > *route_ref:

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

00 jgpacker : > Getting all places with japanese and chinese cuisine around the globe in > Overpass: http://overpass-turbo.eu/s/7b2 > > 2015-01-21 8:09 GMT-02:00 Никита [via GIS] <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=5830795&i=0>>: > >>

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

hey > do have their use. > > I wouldn't want to have to add: > > route_ref:318=yes > route_ref:616=yes > > > or > > route_ref:BE:De_Lijn:1=yes > route_ref:BE:De_Lijn:2=yes > ... > instead of this: > > > route_ref:De_Lijn=1;2;3;4;5;6;7;8;9;

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

aren't they documented > in the wiki ? I only joined the project in 2011, but have never seen this > being documented for all those keys... > > regards > > m. > > On Wed, Jan 21, 2015 at 10:23 AM, Никита wrote: > >> > Java has regular expressions as well [1

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

;re insulting the one person who was supporting you? Please No I didn't. Quote them. PS. Well I'm sorry for my tone if it was looking unacceptable in some messages. 2015-01-21 12:00 GMT+03:00 Dan S : > Now you're insulting the one person who was supporting you? Please >

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

ppening, we have to work around. And obviously you choose the worst way to do this. With complicating things with REGEX. 2015-01-21 11:42 GMT+03:00 Nadjita : > On 21.01.2015 09:06, Никита wrote: > > > If you trying to parse name=school *with any regex *to map it as > > amenity=sc

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

> Никита, you really need to accept regexe is a widely used technology and one you really are not going to stamp out. You missing the point. I do aware of POSIX standard. I do aware of perl quirks and overengineered regex syntax. JOSM uses Java. There no "command line wiht perl"

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

title=Key:payment:coins&redirect=no 2015-01-21 9:39 GMT+03:00 Friedrich Volkmann : > On 21.01.2015 03:59, Никита wrote: > > You don't know regexes and theory behind them. [...] There always pattern > > that will broke your regex. > > E.g.? > > > You will neve

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

se? Do you too busy with your regexes? What are you talking about? http://taginfo.openstreetmap.org/keys/payment%3Acoins#values http://taginfo.openstreetmap.org/tags/payment%3Acoins=yes - 26 37395.32% http://taginfo.openstreetmap.org/tags/payment%3Acoins=no 1 142 4.13% 2015-01-21 6:13 GMT+03:00

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

> Friedrich Volkmann Ad hominem. Wow. You are so low. >, by making assumptions instead of asking those who know. This is called data analys. Statistics. Numbers. There nobody to ask if users prefer one method over another. >The resulting tagging rules are actually a burden for both mappers and

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

Wow. Quality of discussion here. > I even find the second example more difficult to visualize. It's just worse than the first in every respect payment=efectivo;visa;mastercard;american␣express payment=mastercard;visa;efectivo Now try to find *efectivo *with your regexes. If you want to tell me

Re: [Tagging] AddrN

> I'm trying to understand is why This is actaully hard question to answer in terms of OSM right now. Why does building exists? Why countries exists? We don't have answers for them, but we map them regardless. All I can say is that most cities in Russia use odd/even system as desribed here ("Europ

Re: [Tagging] Feature Proposal - RFC - Cluster

You should include tag this meaning "enable/disable inheritance (propagation) of tags to all its memebers". This is main difference between Relation:street and Relation:associatedStreet. Sometimes you need this feature, but sometimes not. 1. inherit tags from parent relation 2. don't 3. unspecified

Re: [Tagging] Distinction between amenity=restaurant and fast_food

> does it serve food? does it serve alcohol? how fast is food available after ordering? is it table service with waiters? is it counter service with tables? is takeout available? is there drive thru takeout? is there a restroom amenity? is there a playground amenity? This schema is quite meaningfu

Re: [Tagging] Mapping of kids areas

ation at once! Make proposal about leisure=playground deprecation! It's easy! 2014-12-19 21:06 GMT+04:00 moltonel 3x Combo : > > On 19/12/2014, Никита wrote: > >> just tag the amenity with playground=yes. > > > > That doesn't work. We have a 20 km^2 airport

Re: [Tagging] Mapping of kids areas

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

Re: [Tagging] Mapping of kids areas

> We are in a geographical database and the relative position (inside=part of /OR/ outside) of elements are known. This is not how hotels\motels or playground\childenarea works. Hotels are hotels, regardless of your position. The only part that relies on geo functions in my definition is "get open

Re: [Tagging] Mapping of kids areas

> we are talking about "part of" I think we can use this in definition, but lets wait for Dmitry. Here is my point: Definition: (required, must be tagged) kids_area=* - used for areas dedicated for kids within bigger facilities (restaurants, fast_foods, hotels, hospitals, airports, shops) (requir

Re: [Tagging] Mapping of kids areas

> is near mall and other not. -1 to you. You failed to understand proposal/discussion. There a lot more differences beside simply indoor/outdoor criteria. Please read discussion from start. 2014-12-19 17:06 GMT+04:00 Martin Vonwald : > > > > 2014-12-19 13:59 GMT+01:00 Martin Koppenhoefer : >> >>

Re: [Tagging] Mapping of kids areas

я комната"(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 cannot resolve/refine or define leisure=playground, this task is too heavyweight and out of this proposal. 2014-12-19 16:17 GMT+04:00 Martin K

Re: [Tagging] Mapping of kids areas

; (leisure=playground) "Игровая зона для детей" (amenity=kids_area) Just try to google these words and you will see real difference between two. 2014-12-19 15:30 GMT+04:00 Martin Koppenhoefer : > > > 2014-12-19 12:12 GMT+01:00 Никита : >> >> IMO, kids_area=* is prefe

Re: [Tagging] Mapping of kids areas

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 opening_hours=10-20 2014-12-19 15:06 GMT+04:00 Martin Koppenhoefer : > > > 2014-12-19 8:27 GMT+01:

Re: [Tagging] Mapping of kids areas

proposal > > ...and then you proceed to talk something below that entirely contradicts > what you said above?!? > > On Fri, 19 Dec 2014, Никита wrote: > > > > Why not? > > Is your questions serious? > > I answered to what I thought that was a serious question

Re: [Tagging] Mapping of kids areas

don't care about exact tables and their locations or geometries. We need answers to simple questions "Where should I leave my child?". We don't care about playground:pencil=yes tagging, it is useless for any purpose. 2014-12-19 14:03 GMT+04:00 Ilpo Järvinen : > > O

Re: [Tagging] Mapping of kids areas

> leisure=playground > playground:supervised=yes/no > playground:outdoor=yes/no > playground:indoor=yes/no kids_area=* is not about these 4 tags. kids_area=* is disjoint to leisure=playgrounds. Please read proposal. http://www.imenno.ru/wp-content/uploads/2013/08/HD_08.jpg-940x626.jpg - leisure=p

Re: [Tagging] Mapping of kids areas

> but some people at least are starting to use amenity=childcare. Please don't link to tags without proposals they are meaningless without actual data/definition. No reason to discuss them here. kids_area=* is clearly defined as more advanced leisure=playground in the proposal. I will use this ta

Re: [Tagging] Mapping of kids areas

> Yes we can, see playground=* as approved, e.g. playground=swing Most likely because you have no idea what objects will be mapped with new tag kids_area=*. Well please show, show me these tags then: playground=pcroom playground=tv playground=activitytable playground=activitytable playground=globe

Re: [Tagging] Mapping of kids areas

=kids_area may have not only tvs not other expensive equipment. We cannot map equipment, this is insane to maintain, but we can classify between leisure=playground and kids_area=*. 2014-12-17 13:32 GMT+04:00 Никита : > > Probably we should define kids_area as: > leisu

Re: [Tagging] Mapping of kids areas

Probably we should define kids_area as: leisure=playground playground:indoor=yes playground:supervised=yes - "supervised by parents, not by somebody else" 2014-12-17 12:49 GMT+04:00 Erik Johansson : > > Hi Dmitry > > I did a quick sruvey of some fast food restuarants the local Ikea, I know > they

Re: [Tagging] Landuse vs Vegetation vs Landcover proposed cleanup at wiki

I'm sorry, wrong list. See t...@openstreetmap.org. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Landuse vs Vegetation vs Landcover proposed cleanup at wiki

We have highly inconsistent content at wiki (feature pages ). Inconsistency is not limited to landuse=wood/natural=forest. Another example is landuse=meadow (Landuse , Vegetation

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

Dave, no, my intention was to describe them similar to maxspeed=DE:, maxspeed=IT: values, not tags. But as Lukas Sommer said > In Japan, the name belongs to the _traffic signal_, and _not_ to the junction. But since only Japan is different there no need to use prefixed values with different meaning

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

> Thailand has official signs naming the junctions/intersections. These names are also used when you give directions. As Imagic suggested, it not best way to use different tags for close meanings, single tag will be better option: junction=th:junction_area junction=jp:junction_area junction=kr:junc

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

> Do you mean personal name proper noun? 2014-09-29 14:21 GMT+04:00 Никита : > > a lot of people in Thailand will be mad at you then... > Well, yes, Thailand also, but this tag will be truly meaningful for > limited number of countries. I think we should reflect that. >

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

> a lot of people in Thailand will be mad at you then... Well, yes, Thailand also, but this tag will be truly meaningful for limited number of countries. I think we should reflect that. > Having named junctions is quite common. Do you mean personal name? There very-very few named junctions in Russ

Re: [Tagging] Feature Proposal - Voting - Tagging for complex junctions or traffic signals that are named

Not enough examples, I cannot vote yes right now. Can you please provide examples how to draw area for more complicated junctions? For 3, 4 or 5 roads? Example with roundabout (should we include inside area)? For junction with 2 or many roundabouts (how we should include all these small areas betwe

Re: [Tagging] bridge=humpback ?

lar truck can pass a particular > bridge is not easy to put into simple tags. It can be rather complex, which > is why products like [2 <http://www.autopath.co.uk/>] exist. --colin [1] > http://wiki.openstreetmap.org/wiki/Road_signs_in_the_United_Kingdom [2] > http://www.autopath.co.uk/ O

Re: [Tagging] bridge=humpback ?

cular bridge is not easy to put into > > simple tags. It can be rather complex, which is why products like [2] > exist. > > > > --colin > > > > [1] http://wiki.openstreetmap.org/wiki/Road_signs_in_the_United_Kingdom > > > > [2] http://www.autopath.co.uk/ > > > > &g

Re: [Tagging] bridge=humpback ?

0 août 2014 12:41:22 UTC+02:00, Colin Smale > wrote: > >> On 2014-08-10 12:13, Никита wrote: >> >> I.e they define this tag as subtype of >>> http://en.wikipedia.org/wiki/Arch_bridge [5]. I don't see any real >>> application/use to bridge=humpback. Al

Re: [Tagging] bridge=humpback ?

ridge=movable have application in routing software (user preferences). 2014-08-10 13:43 GMT+04:00 Richard Z. : > On Sun, Aug 10, 2014 at 01:04:20PM +0400, Никита wrote: > > I don't think so. Can you please define meaning of bridge=humpback? > > it was at least among the values of t

Re: [Tagging] bridge=humpback ?

I don't think so. Can you please define meaning of bridge=humpback? PS. Tag covered=yes was proposed to mark "covered" ways. For example covered bridges. http://wiki.openstreetmap.org/wiki/Proposed_features/covered, from examples section: http://www.travelbygps.com/special/covered/covered_bridge.J

Re: [Tagging] Climbing access path

I understand access=customers, it is okay tag for this case. But what does customers=climbers mean? How do you distinguish climbers from others?.. http://taginfo.openstreetmap.org/keys/customers#values says there 25 instances with 4 values, but what exactly do they mean? If customers=climbers mean

Re: [Tagging] Feature Proposal - RFC - Tag:building=kindergarten, accept and document usage of this tag

an half of countries have term more specific terms than kindergarten. 2014-07-23 12:17 GMT+04:00 Martin Koppenhoefer : > > > > Am 23/lug/2014 um 07:13 schrieb Никита : > > > > Here is list of terms linked at en:Kindergarten page (not necessary same > thing as kindergarten

Re: [Tagging] Feature Proposal - RFC - Tag:building=kindergarten, accept and document usage of this tag

at least link it with more modern analogue United Kingdom nursery schools or playgroups 2014-07-23 4:21 GMT+04:00 Serge Wroclawski : > Maybe this is a US-centric view, but in the US, a kindergarten is a > grade of school. > > In other parts of the world, does kindergarten mean day car

Re: [Tagging] min_age vs. minage

kindergartens of some developed country. It will definetly clarify age_group. 2014-07-22 20:58 GMT+04:00 Martin Koppenhoefer : > > 2014-07-22 18:31 GMT+02:00 Никита : > > Hello everyone! Target minage (age_group) should be different from legal >> minage (current tag min_age). >

Re: [Tagging] min_age vs. minage

Hello everyone! Target minage (age_group) should be different from legal minage (current tag min_age). I have reason and explanation for this. I have found age_group (not legal age, but something like target_age) tag, but right now is only proposal and defined only for 4 amenity

[Tagging] Feature Proposal - RFC - Tag:building=kindergarten, accept and document usage of this tag

Hello! This is second time I send email. First was rejected for some reason. Tag:building=kindergarten - accept and document de-facto usage of this tag. Proposal page: http://wiki.openstreetmap.org/wiki/Proposed_features/building%3Dkindergarten Tag description page: http://wiki.openstreetmap.org