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 and
I suggest you to deal with it (sic!)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
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.
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 expressions to
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 people
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
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?
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
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
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
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
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
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.
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*=*traditional semicolon presentation*, but
not vice versa. I suggested plugin for JOSM that will present
in 2011, but have never seen this
being documented for all those keys...
regards
m.
On Wed, Jan 21, 2015 at 10:23 AM, Никита acr...@gmail.com wrote:
Java has regular expressions as well [1], I know they are not for the
every day user, but this problem also holds
of this:
route_ref:De_Lijn=1;2;3;4;5;6;7;8;9;284;285;310;315;316;317;333;334;335;337;351;352;358;370;371;372;373;374;380;395;520;524;525;537;586;597
Polyglot
2015-01-21 11:08 GMT+01:00 Никита acr...@gmail.com:
traffic_calming = table; choker in Russia?
This is not specific to Russia actually
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=nodenode=5830795i=0:
traffic_calming = table; choker in Russia?
This is not specific to Russia actually. Not many
the worst way to do this. With complicating things
with REGEX.
2015-01-21 11:42 GMT+03:00 Nadjita tagg...@mark.reidel.info:
On 21.01.2015 09:06, Никита wrote:
If you trying to parse name=school *with any regex *to map it as
amenity=school* *you are wrong. OSM is not for you.
If you trying
Никита, 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 in Java. STOP your
...@remote.org:
Hi,
On 01/21/2015 12:07 PM, Никита wrote:
*route_ref:De_Lijn:8=yes*
*route_ref:De_Lijn:9=yes*
*route_ref:De_Lijn:284=yes*
I want to see bolded keys in database directly
No. Relations have been invented specifically to avoid this.
Conceputally, the value space should
\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:
ref ~
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
://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 Friedrich Volkmann b...@volki.at:
On 21.01.2015 02:51, Никита wrote:
payment=efectivo;visa;mastercard;american␣express
payment
Friedrich Volkmann b...@volki.at:
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 never teach your ugly hacks to to OSM users.
Probably because these are for developers, not for users
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
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
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
, Никита wrote:
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
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 from you but
you seem to not care about the response in the first place.
Do you really want to tag
:00 Никита acr...@gmail.com:
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=playground
http://www.realkidfriendly.com/wp-content/uploads/2010/07/161
)
Игровая зона для детей (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 dieterdre...@gmail.com:
2014-12-19 12:12 GMT+01:00 Никита acr...@gmail.com:
IMO, kids_area=* is prefered when you have bigger
, 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 Koppenhoefer dieterdre...@gmail.com:
2014-12-19 13:07 GMT+01:00 Никита acr...@gmail.com:
leisure=playground (usually
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 imagic@gmail.com:
2014-12-19 13:59 GMT+01:00 Martin
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)
:
2014-12-19 12:12 GMT+01:00 Никита acr...@gmail.com:
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
I think
about leisure=playground
deprecation! It's easy!
2014-12-19 21:06 GMT+04:00 moltonel 3x Combo molto...@gmail.com:
On 19/12/2014, Никита acr...@gmail.com 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
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 -
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 erjo...@gmail.com:
Hi Dmitry
I did a quick sruvey of some fast food restuarants the local Ikea, I
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 Никита acr...@gmail.com:
Probably we should define kids_area as:
leisure=playground
playground:indoor=yes
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
We have highly inconsistent content at wiki (feature pages
http://wiki.openstreetmap.org/wiki/Category:Features). Inconsistency is
not limited to landuse=wood/natural=forest. Another example is
landuse=meadow (Landuse http://wiki.openstreetmap.org/wiki/Landuse,
Vegetation
I'm sorry, wrong list. See t...@openstreetmap.org.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
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
Do you mean spersonal name/s proper noun?
2014-09-29 14:21 GMT+04:00 Никита acr...@gmail.com:
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
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
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
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
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:
=movable have application in routing software (user
preferences).
2014-08-10 13:43 GMT+04:00 Richard Z. ricoz@gmail.com:
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 the German
Smale colin.sm...@xs4all.nl
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. Also, bridge=humpback does not
imply covered=yes by default. It does
/Road_signs_in_the_United_Kingdom
[2] http://www.autopath.co.uk/
On 2014-08-10 15:34, Никита wrote:
I'm fine with this tag being used in UK. But I care about it's
definition. If this tag will be interesting only in some territory,
why not to define this tag specific to UK? You didn't answer how we
. --colin [1]
http://wiki.openstreetmap.org/wiki/Road_signs_in_the_United_Kingdom [2]
http://www.autopath.co.uk/ On 2014-08-10 15:34, Никита wrote:
I'm fine with this tag being used in UK. But I care about it's definition.
If this tag will be interesting only in some territory, why
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
of countries have term more specific terms than kindergarten.
2014-07-23 12:17 GMT+04:00 Martin Koppenhoefer dieterdre...@gmail.com:
Am 23/lug/2014 um 07:13 schrieb Никита acr...@gmail.com:
Here is list of terms linked at en:Kindergarten page (not necessary same
thing as kindergarten in Germany
with kindergartens of some
developed country. It will definetly clarify age_group.
2014-07-22 20:58 GMT+04:00 Martin Koppenhoefer dieterdre...@gmail.com:
2014-07-22 18:31 GMT+02:00 Никита acr...@gmail.com:
Hello everyone! Target minage (age_group) should be different from legal
minage (current tag
or playgroups
2014-07-23 4:21 GMT+04:00 Serge Wroclawski emac...@gmail.com:
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 care?
- Serge
On Mon, Jul 21, 2014 at 12:13 AM, Никита acr...@gmail.com
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:
57 matches
Mail list logo
