Am Donnerstag, 30. Mai 2013, 05:22:27 schrieb Tac Tacelosky:
> postgres also has ILIKE, which does case-insensitive searches, so
> that's working for the moment.
Unfortunately, ILIKE will not use any indexing (unless your pattern starts with
some characters that are not affected by capitalization
postgres also has ILIKE, which does case-insensitive searches, so
that's working for the moment.
The biggest challenge I'm having with the current editors is the
learning curve for the tags, specifically which keys to use. But yes,
I've spent some time in there, and am trying to adopt their appro
On 5/29/13 6:42 PM, Richard Welty wrote:
On 5/29/13 6:01 PM, Tac Tacelosky wrote:
I see "amenity:Restaurant" and "amenity:restaurant" are both returned
from the api. And I just discovered that postgres does case-sensitive
LIKE's. Sigh.
now fixing this is actually a reasonable thing to do in a
On Wed, May 29, 2013 at 7:33 PM, Tac Tacelosky wrote:
> I'm looking at a picture of a restaurant, and asking the user what
> type of establishment it is. Because I'm not yet weighing tags, the
> user has choices like "donut" and "donuts", and has no idea which to
> pick. I'm working on a way now
I'm looking at a picture of a restaurant, and asking the user what
type of establishment it is. Because I'm not yet weighing tags, the
user has choices like "donut" and "donuts", and has no idea which to
pick. I'm working on a way now to at least present the most likely
tag (based on taginfo).
T
On Wed, May 29, 2013 at 6:01 PM, Tac Tacelosky wrote:
> I see "amenity:Restaurant" and "amenity:restaurant" are both returned
> from the api. And I just discovered that postgres does case-sensitive
> LIKE's. Sigh.
Those are the kinds of things that bots come along and fix (much like
they do in
On 5/29/13 6:01 PM, Tac Tacelosky wrote:
I see "amenity:Restaurant" and "amenity:restaurant" are both returned
from the api. And I just discovered that postgres does case-sensitive
LIKE's. Sigh.
now fixing this is actually a reasonable thing to do in a bulk edit,
because many data consumers li
I see "amenity:Restaurant" and "amenity:restaurant" are both returned
from the api. And I just discovered that postgres does case-sensitive
LIKE's. Sigh.
Tac
On Wed, May 29, 2013 at 5:35 PM, Martin Koppenhoefer
wrote:
>
>
>
>
> On 29/mag/2013, at 18:01, Eugene Alvin Villar wrote:
>
>> True, b
On 29/mag/2013, at 18:01, Eugene Alvin Villar wrote:
> True, but then we have the key drive_through=* which follows the "usual"
> syntax:
it's two different things, the underscore replaces a space (two words) the dash
connects two words to one
cheers,
Martin
_
On Wed, May 29, 2013 at 11:33 PM, Martin Koppenhoefer <
dieterdre...@gmail.com> wrote:
>
>
>
>
> On 29/mag/2013, at 16:47, Eugene Alvin Villar wrote:
>
> Usually, but there exists exceptions such as service=drive-through instead
> of the expected service=drive_through or even service=drivethrough
On 29/mag/2013, at 16:47, Eugene Alvin Villar wrote:
> Usually, but there exists exceptions such as service=drive-through instead of
> the expected service=drive_through or even service=drivethrough:
> http://wiki.openstreetmap.org/wiki/Tag:service=drive-through
in this case the spelling
On Wed, May 29, 2013 at 7:07 AM, Serge Wroclawski wrote:
> In addition to above, though, you may want to consider that Subway is
> a chain restaurant, so you may want to consider
>
> brand=Subway instead of name=Subway
>
My preference is on name=Subway. Both are correct as the name of the store
On Wed, May 29, 2013 at 7:18 AM, Greg Troxel wrote:
>
> Tac Tacelosky writes:
>
> > Are there any punctuation restrictions on tags? In particular, commas
> > could be problematic for storing a list of tags as a single string.
>
> I am not clear on a formal grammer, but it seems clear that tag n
Thanks, that's helpful. I'm working on a UI where people type what
they see, and the system translates that to the appropriate tags. The
brand tag is particularly useful in this context, and one I wasn't
even aware of, so thanks for pointing it out.
Tac
On Wed, May 29, 2013 at 8:08 AM, Serge Wr
On Tue, May 28, 2013 at 11:26 PM, Paul Johnson wrote:
> Well, I guess we need to back up. When is a name not a name to you?
I don't always use brand, but when I'm tagging a store or restaurant
that I know is part of a large megachain, then I do:
http://wiki.openstreetmap.org/wiki/Key:brand
It
2013/5/29 Tac Tacelosky
>
>
> name=Subway
> amenity=fast_food
> cuisine=sandwiches
>
>
for the kind of Subway I know of, I'd definitely use this one, they are far
from being "restaurants". I would tag brand=Subway and the operator from
the receipt (e.g. if you ate there).
Cheers,
Martin
On Tue, May 28, 2013 at 8:13 PM, Serge Wroclawski wrote:
> I'm sorry but I don't understand this comment at all.
>
> Are you saying that because of the brand tag, that there would some
> consequence? This is a matter of the data consumer, such as the
> renderer, knowing what to do with the tag.
>
>
> When I write software to get the label of an object, I always use
> brand or operator over name.
>
> How does this work for something like a school, where the name is the
individual school's name, but the school district is the operator?
Brad
___
Tag
On Tue, May 28, 2013 at 8:29 PM, Paul Johnson wrote:
>
> On May 28, 2013 6:08 PM, "Serge Wroclawski" wrote:
>
>> brand=Subway instead of name=Subway
>
> Very, very few Subway locations have names other than Subway. Not really
> sure that's a valid complaint except in particularly well-branded ed
On May 28, 2013 6:08 PM, "Serge Wroclawski" wrote:
> brand=Subway instead of name=Subway
Very, very few Subway locations have names other than Subway. Not really
sure that's a valid complaint except in particularly well-branded edge
cases (like Batman's Subway, which is in Batman Fuels (Shell)
On Tue, May 28, 2013 at 6:43 PM, Tac Tacelosky wrote:
> Yeah, tag keys should follow that, but not key values. I'm sure there
> are values with single and double quotes, commas and semi-colons.
>
> Does OSM support any sort of multi-tag structure, like
> "cuisine:japanese" AND "cuisine:thai"?
>
Tac Tacelosky writes:
> Yeah, tag keys should follow that, but not key values. I'm sure there
> are values with single and double quotes, commas and semi-colons.
Sorry, I meant tag values that are essentially keywords, such as
amenity=fast_food. Basically the values for amenity should not onl
Yeah, tag keys should follow that, but not key values. I'm sure there
are values with single and double quotes, commas and semi-colons.
Does OSM support any sort of multi-tag structure, like
"cuisine:japanese" AND "cuisine:thai"?
Tac
On Tue, May 28, 2013 at 7:18 PM, Greg Troxel wrote:
>
> Tac
Hehe. As a former Panera employee I would say that the food is indeed
shipped in bulk in factory fashion. (frozen gallon bag of soup anyone?) ;-)
For me Panera would be fast_food or cafe, depending on the mappers
inclination.
On May 28, 2013 7:22 PM, "Greg Troxel" wrote:
>
> "Brian Wolford // HO
"Brian Wolford // HOT" writes:
> I often differentiate fast_food as "counter service" and restaurant as "sit
> down with a menu and order from a waiter" service.
I basically agree, but there's also an intermediate "order at counter,
have someone bring it to you". But the key point (here I'm ve
On 5/28/13 7:04 PM, Paul Johnson wrote:
I'd go with the amenity=fast_food bit, too. Restaurants are a little
higher class, Waffle House would be an edge case but I'd be inclined to
call that a restaurant (even if it tends to be faster than McDo's).
my rule of thumb is table service vs counter s
Tac Tacelosky writes:
> Are there any punctuation restrictions on tags? In particular, commas
> could be problematic for storing a list of tags as a single string.
I am not clear on a formal grammer, but it seems clear that tag names
and non-numeric tag values should be limited to a-z, 0-9, an
I often differentiate fast_food as "counter service" and restaurant as "sit
down with a menu and order from a waiter" service.
On Tue, May 28, 2013 at 7:04 PM, Paul Johnson wrote:
> I'd go with the amenity=fast_food bit, too. Restaurants are a little
> higher class, Waffle House would be an ed
This discussion is best for t...@openstreetmap.org or for
help.osm.org, but I'll bite.
On Tue, May 28, 2013 at 6:52 PM, Richard Welty wrote:
>> name=Subway
>> amenity=fast_food
>> cuisine=sandwiches
This is what the wiki would suggest, what the JOSM presets say, and
what the renderer will accep
Thanks. I'm actually using taginfo to prepopulate a dropdown form,
but not displaying the frequencies, which I guess I need to do.
I also see things like
amenity=restaurant;bar
which makes sense, but I doubt is "right".
Are there any punctuation restrictions on tags? In particular, commas
cou
I'd go with the amenity=fast_food bit, too. Restaurants are a little
higher class, Waffle House would be an edge case but I'd be inclined to
call that a restaurant (even if it tends to be faster than McDo's).
On Tue, May 28, 2013 at 5:52 PM, Richard Welty wrote:
> On 5/28/13 6:19 PM, Tac Tacelo
On Tue, May 28, 2013 at 5:52 PM, Richard Welty wrote:
> On 5/28/13 6:19 PM, Tac Tacelosky wrote:
>
>> name=Subway
>> amenity=restaurant
>> cuisine=fast_food
>>
>> OR
>>
>> name=Subway
>> amenity=fast_food
>> cuisine=sandwiches
>>
>> the second one is what you would get with a JOSM
> preset so tha
On 5/28/13 6:19 PM, Tac Tacelosky wrote:
name=Subway
amenity=restaurant
cuisine=fast_food
OR
name=Subway
amenity=fast_food
cuisine=sandwiches
the second one is what you would get with a JOSM
preset so that's the way i've always entered them.
the JOSM preset does give sandwich, not sandwiches
On Tue, May 28, 2013 at 3:19 PM, Tac Tacelosky wrote:
> name=Subway
> amenity=restaurant
> cuisine=fast_food
>
> This would be my pick.
>
> On a related note, are the underscores necessary? I'd rather say "Fast
> Food"
>
Me too, but the tag is fast_food. Otherwise you just create another tag
th
name=Subway
amenity=restaurant
cuisine=fast_food
OR
name=Subway
amenity=fast_food
cuisine=sandwiches
On a related note, are the underscores necessary? I'd rather say "Fast Food"
Thx,
Tac
___
Tagging mailing list
Tagging@openstreetmap.org
http://li
35 matches
Mail list logo
