Michael Barabanov wrote:
Seems like double work to me. Ross's suggestion may just work. If
there're no objections, I'll update the wiki.
Please not, this is a crude hack. Why not use the opening_hours syntax?
This should be standard.
hours=6:00-9:00,15:00-19:00
Sebastian
___
On 16 August 2010 21:08, André Riedel wrote:
> 2010/8/16 Tom Chance :
> > Basically I have deprecated "power_type=photovoltaic" and
> > "power_type=solar-thermal", which combine two bits of information (source
> of
> > energy, and type of energy generated). This also allows for adequate
> tagging
On Tue, 17 Aug 2010, Cartinus wrote:
> Concluding less than six hours after your initial post to this mailinglist
> that nobody has a problem with what you propose is: youthfull exuberance ?
> impatience ? It is certainly is not the way to go.
6 hours isn't one rotation of the earth, and certainl
On 17 August 2010 17:44, Sebastian Klein wrote:
> Michael Barabanov wrote:
>>
>> Seems like double work to me. Ross's suggestion may just work. If
>> there're no objections, I'll update the wiki.
>
> Please not, this is a crude hack. Why not use the opening_hours syntax? This
> should be standar
On Tue, 17 Aug 2010 18:04:21 +1000
John Smith wrote:
> On 17 August 2010 17:44, Sebastian Klein wrote:
> > Michael Barabanov wrote:
> >>
> >> Seems like double work to me. Ross's suggestion may just work. If
> >> there're no objections, I'll update the wiki.
> >
> > Please not, this is a crude
John Smith wrote:
On 17 August 2010 17:44, Sebastian Klein wrote:
Michael Barabanov wrote:
Seems like double work to me. Ross's suggestion may just work. If
there're no objections, I'll update the wiki.
Please not, this is a crude hack. Why not use the opening_hours syntax? This
should be s
2010/8/17 Craig Wallace :
> Though from what you describe, it sounds more like its just one shop - ie
> all operated by the same company, and with just one set of checkouts etc -
> but just calling itself a "farmers market"?
> In which case, I would suggest tagging it as shop=greengrocer (if its mo
Ross Scanlon wrote:
And also a semi-colon ; between the times as per the rest of multiple values
for one key.
No, quoting [1]:
>
a break on days separated by "," · ( e.g.> Mo,We,Fr )
a break on hours separated by "," · ( e.g.> 08:30-14:00,16:30-20:00 )
different hours on different days
2010/8/17 Michael Barabanov :
> Seems like double work to me. Ross's suggestion may just work. If there're
> no objections, I'll update the wiki.
There is already a proposal for this kind of stuff, which would be
possible to apply here as well:
http://wiki.openstreetmap.org/wiki/Proposed_featur
On 17 August 2010 18:52, M∡rtin Koppenhoefer wrote:
> 2010/8/17 Michael Barabanov :
>> Seems like double work to me. Ross's suggestion may just work. If there're
>> no objections, I'll update the wiki.
>
>
> There is already a proposal for this kind of stuff, which would be
> possible to apply h
Following discussion here and on the wiki I have changed "power_type" to
"power_output":
http://wiki.openstreetmap.org/wiki/Proposed_features/power_type
I have also introduced a new tag proposal, "power_method":
http://wiki.openstreetmap.org/wiki/Proposed_features/power_method
This resolves ambig
Just to help summarise, with these proposals we end up with:
power=generator (the starting point)
power_rating (to specify the watts generated)
http://wiki.openstreetmap.org/wiki/Key:power_rating
power_source (to specify the fuel type / energy source)
http://wiki.openstreetmap.org/wiki/Key:power
On Tue, 17 Aug 2010, Tom Chance wrote:
> Just to help summarise, with these proposals we end up with:
>
> power=generator (the starting point)
>
> power_rating (to specify the watts generated)
> http://wiki.openstreetmap.org/wiki/Key:power_rating
>
> power_source (to specify the fuel type / ener
On 17/08/2010 12:59, Tom Chance wrote:
Just to help summarise, with these proposals we end up with:
power=generator (the starting point)
power_rating (to specify the watts generated)
http://wiki.openstreetmap.org/wiki/Key:power_rating
power_source (to specify the fuel type / energy source)
htt
On 17/08/2010 05:29, John Smith wrote:
On 17 August 2010 13:14, Michael Barabanov wrote:
I agree. But I'm not in the mood to start a voting process on changing
hour_on to access:time.
We keep getting told this is a do-ocracy, so if you find something
more useful, just do it? :)
2010/8/17 John Smith :
> You were the one complaining about amenity=school being widely used so
> we should sub-tag it, I don't think we should do any of the above for
> similar reasons, leave the restriction stuff alone and dump
> dates/times into their own key pair.
>
> restriction=no_right_turn
On 17 August 2010 12:12, Liz wrote:
> On Tue, 17 Aug 2010, Tom Chance wrote:
> > Just to help summarise, with these proposals we end up with:
> >
> > power=generator (the starting point)
> >
> > power_rating (to specify the watts generated)
> > http://wiki.openstreetmap.org/wiki/Key:power_rating
On 17 August 2010 12:56, Vincent Pottier wrote:
> On 17/08/2010 12:59, Tom Chance wrote:
>
>> Just to help summarise, with these proposals we end up with:
>>
>> power=generator (the starting point)
>>
>> power_rating (to specify the watts generated)
>> http://wiki.openstreetmap.org/wiki/Key:power
On 17 August 2010 22:27, M∡rtin Koppenhoefer wrote:
> If a restriction is valid only for some time, I would like to see this
> in one tag and not in 2 for several reasons:
I think you are over engineering, in any case my previous point still
stands, there is no less than 3 completely different wa
M∡rtin Koppenhoefer wrote:
2010/8/17 John Smith :
You were the one complaining about amenity=school being widely used so
we should sub-tag it, I don't think we should do any of the above for
similar reasons, leave the restriction stuff alone and dump
dates/times into their own key pair.
restric
2010/8/17 John Smith :
> On 17 August 2010 23:44, M∡rtin Koppenhoefer wrote:
>> Oops, so sorry, I wasn't aware that there is already a time syntax in
>> the restrictions relation :(
>
> I your suggestion conflicts with the restriction=* values, so any
> existing software may handle the extension s
2010/8/17 Sebastian Klein :
> I don't really like the Extended_conditions_for_access_tags proposal for
> reasons mentioned in the above sites and their talk pages. Basically it
> violates (or gives up) the principle that keys are simple atomic identifiers
> that you can query without regexes and th
On 17 August 2010 23:58, M∡rtin Koppenhoefer wrote:
> I'm pulling this back to the list, because otherwise it is not useful
> for the rest of the comunity, and because I think that you don't mind.
I mentioned to several posters that this should be on the tagging list.
> amenity=school is widely
On 18 August 2010 00:00, M∡rtin Koppenhoefer wrote:
> 2010/8/17 Sebastian Klein :
>> I don't really like the Extended_conditions_for_access_tags proposal for
>> reasons mentioned in the above sites and their talk pages. Basically it
>> violates (or gives up) the principle that keys are simple atom
2010/8/17 John Smith :
> I'm not talking about hour_on, I'm talking specifically about your suggestion:
>
>> restriction=[6:00-9:00;15:00-18:00]only_right_turn
>
> Which breaks restriction=*
IMHO it doesn't. It is justified that a restriction that is valid
_only 6-9 or 15-18_ doesn't look the sam
On 18 August 2010 00:03, M∡rtin Koppenhoefer wrote:
> 2010/8/17 John Smith :
>> I'm not talking about hour_on, I'm talking specifically about your
>> suggestion:
>>
>>> restriction=[6:00-9:00;15:00-18:00]only_right_turn
>>
>> Which breaks restriction=*
>
>
> IMHO it doesn't. It is justified that
2010/8/17 John Smith :
> Your suggestion would require a regex, the time information should be
> in it's own key to prevent this.
I'm not a programmer but I think that some substring-parsing would be
sufficient (do you mean this?). For the evaluation of the term you
will in all cases need a rege
On 18 August 2010 00:06, M∡rtin Koppenhoefer wrote:
> I'm not a programmer but I think that some substring-parsing would be
substring/regex is essentially the same end result.
> sufficient (do you mean this?). For the evaluation of the term you
> will in all cases need a regex (to see if the dat
2010/8/17 John Smith :
> On 18 August 2010 00:03, M∡rtin Koppenhoefer wrote:
>> 2010/8/17 John Smith :
>>> I'm not talking about hour_on, I'm talking specifically about your
>>> suggestion:
>>>
restriction=[6:00-9:00;15:00-18:00]only_right_turn
>>>
>>> Which breaks restriction=*
>>
>>
>> IMH
On 18 August 2010 00:08, M∡rtin Koppenhoefer wrote:
> It is much more elegant on the other hand not to have to create
> separate restrictions for all times, but deal in one restriction with
> it. The more these things are in use, the more apps will be able to
> understand them. Currently many apps
2010/8/17 Tom Chance :
> Just to help summarise, with these proposals we end up with:
>
> power=generator (the starting point)
Please do not mix the "power"-tag for generating electricity with
other sources of energy like steam, vacuum, heat and so on.
http://wiki.openstreetmap.org/wiki/Key:power
2010/8/17 John Smith :
> That's the point, if you are looking for a limited set of values you
> can do a complete match, you don't need to try and do anything as
> complex or resource intensive as a regular expression *UNLESS* you
> know explicitly that key would need to be parsed in that manner, s
Why do you think no software parses keys with semi-colon seperated values?
eg amenity=fuel;cafe
Because it takes too many resources to search every amenity=* value
for possible values with multiple tags, instead we tag them separate
or some kind of sub-tag...
2010/8/17 André Riedel :
>> power=generator (the starting point)
>
> Please do not mix the "power"-tag for generating electricity with
> other sources of energy like steam, vacuum, heat and so on.
why not? Isn't that all power?
cheers,
Martin
___
Tagg
On 17 August 2010 15:25, M∡rtin Koppenhoefer wrote:
> 2010/8/17 André Riedel :
> >> power=generator (the starting point)
> >
> > Please do not mix the "power"-tag for generating electricity with
> > other sources of energy like steam, vacuum, heat and so on.
>
> why not? Isn't that all power?
>
>
> >> amenity=school
> >> school=dance
>
> -1, IMHO no. A dancing school, boxing school, ski school, etc. are
> IMHO not in the same category than general-education schools. They
> might be classified in one category, but that is IMHO not school.
I agree!! The term "training" here is much more sui
On 18 August 2010 01:06, Surly_ru wrote:
> I agree!! The term "training" here is much more suitable than "school".
> My recommendation is "amenity=training + training=dance".
-1
The whole point of all the was to avoid adding any more amenity=* tags
unnecessarily, it's already an overly abused du
> > My recommendation is "amenity=training + training=dance".
>
> -1
>
> The whole point of all the was to avoid adding any more amenity=* tags
> unnecessarily
OK! Let's discard "amenity". Only "training=dance" is good too.
My suggestion is not about "amenity". It is about changing "school" to
On 18 August 2010 01:15, Vladimir Pokvalitov wrote:
> OK! Let's discard "amenity". Only "training=dance" is good too.
>
> My suggestion is not about "amenity". It is about changing "school" to
> "training".
Wouldn't that be a little counter initiative since they are called
dance schools, driving
> Wouldn't that be a little counter initiative since they are called
> dance schools, driving school, etc ?
These short-term training courses for adults are very different from
educational schools for children, despite of their name. So let's don't mix
them.
I know that there are some bike lanes on the left side, but is there
any real benefit to tagging cycleway:right=lane rather than
cycleway=lane when you have a bike lane on the right side of a one-way
street? How about on the right side of a dual carriageway?
___
On Mon, 16 Aug 2010 00:03:17 -0700, Alan Mintz wrote:
> For Forest Highways (generally major paved roads): ref=FH nn (e.g.
> name=Angeles Crest Highway + ref=FH 61). For Forest Roads/Routes/Truck
> Trails: ref=FR yDxx (e.g. name=Upper Monroe Road + ref=FR 2N16)
> For Forest Trails: ref=FT yDxx (e.
On Tue, Aug 17, 2010 at 5:19 AM, Paul Johnson wrote:
> On Mon, 16 Aug 2010 00:03:17 -0700, Alan Mintz wrote:
>
>> For Forest Highways (generally major paved roads): ref=FH nn (e.g.
>> name=Angeles Crest Highway + ref=FH 61). For Forest Roads/Routes/Truck
>> Trails: ref=FR yDxx (e.g. name=Upper Mon
At 2010-08-17 02:19, Paul Johnson wrote:
On Mon, 16 Aug 2010 00:03:17 -0700, Alan Mintz wrote:
> For Forest Highways (generally major paved roads): ref=FH nn (e.g.
> name=Angeles Crest Highway + ref=FH 61). For Forest Roads/Routes/Truck
> Trails: ref=FR yDxx (e.g. name=Upper Monroe Road + ref=FR
On Tue, 17 Aug 2010, Tom Chance wrote:
> > I note that too many tags are one-offs with no consideration of where
> > they fit
> > in an organised set of tags.
>
> I've no idea what you mean. Could you explain?
Example "I need a tag for this item I'm standing next to. I'll call it
amenity="
On Wed, 18 Aug 2010, André Riedel wrote:
> Please do not mix the "power"-tag for generating electricity with
> other sources of energy like steam, vacuum, heat and so on.
could you please explain what the problem will be if this tag "power" is
extended as proposed?
__
At 2010-08-17 12:08, Nathan Edgars II wrote:
I know that there are some bike lanes on the left side, but is there
any real benefit to tagging cycleway:right=lane rather than
cycleway=lane when you have a bike lane on the right side of a one-way
street?
Assuming you meant to add "in a place wher
At 2010-08-16 18:30, Michael Barabanov wrote:
How would one tag a turn
restriction
(http://wiki.openstreetmap.org/wiki/Turn_restrictions)
which is active say 6-9AM and 3-6PM every day? hour_on/hour_off seem to
only be sufficient for one time interval.
Currently, I use:
hour_on=06:00;15:00
hour_o
On 17/08/2010 17:28, Surly_ru wrote:
Wouldn't that be a little counter initiative since they are called
dance schools, driving school, etc ?
These short-term training courses for adults are very different from
educational schools for children, despite of their name. So let's don't mix
them
On 17.08.10 17:11, John Smith wrote:
> The whole point of all the was to avoid adding any more amenity=* tags
> unnecessarily, it's already an overly abused dumping ground and makes
> it difficult for doing generic icons for POIs...
I can't follow your argument here. A dancing school (or is ist c
On 18 August 2010 01:28, Surly_ru wrote:
>> Wouldn't that be a little counter initiative since they are called
>> dance schools, driving school, etc ?
>
> These short-term training courses for adults are very different from
> educational schools for children, despite of their name. So let's don't
On 18 August 2010 08:25, Andreas Labres wrote:
> I can't follow your argument here. A dancing school (or is ist called dance
> school? in which part of the English world?) is an amenity, is it not?
The term amenity, if used in the vaguest form, can almost mean anything.
> And you do want a gener
On 18 August 2010 07:19, Alan Mintz wrote:
> NAFAIK, if I understand you correctly. That's what semi-colons are for. In
Which nothing seems to bother to parse... OSM data is already
computationally expensive just parsing simple key pairs...
___
Tagging
> Incorrect. A sharrow is used on a designated bicycle route
[in Paul Johnson's part of the world]
> to indicate what part of a shared lane bicyclists should use
> [Stephen Hope] has never
>seen them anywhere except on a route
Let's make an effort to keep tagging schemes globally applicable, and
On Mon, Aug 16, 2010 at 7:30 AM, John Smith wrote:
> I'm not sure this is the best way to do things, what do others think?
>
> http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:shop&oldid=517645&diff=next
I think I'd prefer shop=no personally, in an effort to reduce all the
sy
On 18 August 2010 11:41, Steve Bennett wrote:
> On Tue, Aug 17, 2010 at 9:30 PM, John Smith wrote:
>> shop=rental
>> rental:car=yes/no
>> rental:bike=yes/no
>> rental:truck=yes/no
>> rental:van=yes/no
>> rental:bus=yes/no
>
> I don't like this because this:
>
> shop=rental
Which is why I added a
On Wed, Aug 18, 2010 at 11:58 AM, John Smith wrote:
> Which is why I added a bunch of tags after describing what it does rent...
Which only a few diehards are ever going to tag. Ease of use for
taggers is a major consideration. More tags=more powerful information,
but less usability.
>
>> means
On Tue, 17 Aug 2010 13:44:58 -0700, Alan Mintz wrote:
> At 2010-08-17 02:19, Paul Johnson wrote:
>>On Mon, 16 Aug 2010 00:03:17 -0700, Alan Mintz wrote:
>>
>> > For Forest Highways (generally major paved roads): ref=FH nn (e.g.
>> > name=Angeles Crest Highway + ref=FH 61). For Forest
>> > Roads/Ro
On 18 August 2010 12:04, Steve Bennett wrote:
> Which only a few diehards are ever going to tag. Ease of use for
> taggers is a major consideration. More tags=more powerful information,
> but less usability.
There is a lot of amenity=fast_food places tagged, I wonder how many
tag the cuisine prop
At 2010-08-17 14:33, Paul Johnson wrote:
On Tue, 17 Aug 2010 13:44:58 -0700, Alan Mintz wrote:
> At 2010-08-17 02:19, Paul Johnson wrote:
>>On Mon, 16 Aug 2010 00:03:17 -0700, Alan Mintz wrote:
>>
>> > For Forest Highways (generally major paved roads): ref=FH nn (e.g.
>> > name=Angeles Crest Hig
On Tue, Aug 17, 2010 at 9:35 PM, Steve Bennett wrote:
> Any arguments against cycleway=sharrow?
Yes, a cycleway should be mainly/exclusively for bicycles.
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/taggin
On Wed, Aug 18, 2010 at 1:02 PM, Anthony wrote:
> On Tue, Aug 17, 2010 at 9:35 PM, Steve Bennett wrote:
>> Any arguments against cycleway=sharrow?
>
> Yes, a cycleway should be mainly/exclusively for bicycles.
Hmm, I guess we're interpreting "cycleway=x" differently.
You: "This is a cycleway, m
In established practise, cycleway=lane means "this way is a road which has a
bicycle lane" not "this way is mainly for bicycles". However I see the point
that the lane _itself_ is generally mainly for bicycles.
We don't have the chevron arrows in Australia but we do have bicycle symbols
painted
On Tuesday, August 17, 2010 08:55:48 pm, Alan Mintz wrote:
> As I said somewhere earlier, this seems to vary by region and forest. The
> tagging I mentioned is used in all southern and central California
> USFS-oversight forests and the ones I was able to quickly check just now in
> northern CA.
64 matches
Mail list logo
