ave written "just ignore the naggers with
their legalities and trace away". It's only insignificantly more subtle
the way he phrases it.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
utomated editing to have a "bot
flag". This information is then used to add "B"s next to Bot edits in
history/watchlist/... and for a "Hide bots" filter in these lists.
Instead of making this a property of an account, we could also implement
bot flags for individual
clearly demonstrates that
simpler-than-Potlatch editing is possible.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
established tag, but
any tag that /isn't/ highway=* (or anything else already in use) should
work.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
erpretation.
Generally, the more implicit assumptions you associate with a tag, the
more probable it is that someone's implicit assumptions are different
from yours. That's why a "largely meaningless object" like path has a
certain appeal.
Tobias Knerr
___
.g. http://wiki.openstreetmap.org/wiki/Node
And yes, the effect is limited to the OSMWiki.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
ly normalisation might easily lead to mandating
the solution that would, after some experimentation, have turned out to
be the inferior choice.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
a problem when you incorrectly represent
reality in order to produce a certain rendering.
When there are different representations (such as long segments and
short segments) that represent reality equally well, choosing the one
that is easier for applications isn't a problem at all, but rather
Dave F. wrote
> Tobias Knerr wrote:
>> In order to truly show what's possible, we would need to completely
>> redesign that front page into a "featured products" catalogue [...]
> It doesn't have to be completely redesigned, just a link saying:
>
> &q
ve the purpose of presenting OSM
products. Instead, it presents OSM data *itself* - with features such as
changeset list, data layer, XML export, etc.. And for that purpose, we
don't need "closed" rendering styles.
Tobias Knerr
___
ta
do this
by manually positioning a label, either.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
pected?
Another problem with your approach is that it only works in renderers
designed with the intention to display /everything/. I'd expect good
rendering styles to be limited to a selected subset of the available
information.
Tobias Knerr
___
talk m
sers. In order to do this, we'd need
permission to distribute it under both licenses, but a user can of
course decide to only publish modifications under one of the two licenses.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
address
until then, each object will have been touched by a larger number of
contributors, and of course there will be a larger amount of data in the
database overall).
So unfortunately, we need to decide soon - and in absence of reliable
empirical data available, onl
cally
important, the fork would be at a disadvantage.
I'm not sure about attribution, either. Wouldn't the fork have to
attribute OSM as well, making attribution significantly less convenient?
Tobias Knerr
___
legal-talk maili
ew objects if they add completely
new information. It's not really possible for an automated process to do
anything else.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Steve,
SteveC wrote:
>> How is insulting people going to help things?
>
> By letting them know FUD and BS will be shot down.
I understand that most statements you are responding to seem stupid,
unnecessary or inappropriate to you. You might even think that those who
posted them should really kno
f data, just one. Unfortunately, there is the
technical requirement to provide two strings - key and value. A "thingy"
key (could be "type" or "poi" or whatever just as well as "amenity") is
a method to work around this.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Ben Laenen wrote:
> Tobias Knerr wrote:
>> There is a concept that covers all of these and uses oneway:bicycle:
>> http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_fo
>> r_access_tags
>>
>> The bicycle:oneway structure, to my knowledge,
/wiki/Proposed_features/Extended_conditions_for_access_tags
The bicycle:oneway variant, to my knowledge, hasn't been part of a
solution that can be used to express all of these cases yet and is
mostly just there as a solution for this single situation (opposite
traffic
over the world?
It makes a difference for possible approaches like using
highway=Fahrradweg (or DE:cycleway or any other value that isn't exactly
"cycleway") for German cycleways, as that would still be "one meaning
per tag".
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
lity to road
network attributes - either software (using a traffic laws DB) or humans
(mapping more than just what's on the ground).
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
rers,
which should be avoided.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Martin Koppenhoefer schrieb:
> 2009/11/25 Tobias Knerr
>
>> Jean-Marc Liotier wrote:
>>> Ævar Arnfjörð Bjarmason's diary entry last week (http://j.mp/8ESP8o)
>>> stired my interest. Using a few examples, he showed how mapping
>>> everything as an
ot even a GPS).
Actually, I don't believe most mappers will be able and willing to
produce data that is more precise than what can represented with width
tag + lane info any time soon.
Of course, if you *want* to map areas in addition to li
l only modify the visible part of your signature,
that is, the part after the "|". And it will convert all special
characters, such as "[", "]" and "|".
By the way: The wiki doesn't distinguish between the pagenames
User:username and User:Username anyw
t; [...]
The additional node e is necessary. If there is a barrier on a node that
is part of the c-d road, that barrier does block traffic on c-d.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
he street and mark the trees on the left, and
> you are going to go the other way down the street and mark the trees on the
> right.
As with all left/right tags (as well as forward/backward, up/down,
oneway, incline, etc.), this would certainly r
ike these.
The idea was that maybe the common key approach could be some kind of
compromise. As I said, though, I don't believe that an attempt to
establish an alternative to disused=yes could be successful.
Tobias Knerr
___
talk mailing list
talk@op
they can be ignored unless there are important
reasons for breaking that rule.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
urse, in order to make mapping convenient, it's sometimes necessary
to break that concept (with access tags, for example), and probably we
won't be able to get rid of
disused/abandoned/construction/planned/proposed/etc anymore.
Unfortunately, peopl
Russ Nelson:
> Tobias Knerr writes:
> > Frederik Ramm:
> > > (5) Never ever invent a tag that you don't have a concrete use for.
> >
> > "Never plan ahead, always wait until there are thousands of existing
> > tags that make creating a better
t what a certain tag means - we'd still need a way
to handle those situations: voting, councils, dictators, whatever.
> 5) If you disagree with the definition of the key or value, then
> create a new key or value with a different name,
This can potentially lead to some conflicts when t
to distinguish between plausible
possibilities and irrelevant hypothetical constructs?
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
p;zoom=18&directions=51.243609690021025,6.787233352661133,51.2442275913119,6.786621809005737&travel=car&styleId=1
that probably was influenced by this restriction relation:
http://www.openstreetmap.org/browse/relation/183709
(There are some other links with examples in this thread, which are all
related to onl
estriction to it now, but is is necessary or not? Should
> the wiki be updated?
Imo: Yes, it is necessary (other tools such as JOSM expect it, too), and
the examples should be updated to reflect this.
Tobias Knerr
___
talk mailing l
Tagging the general direction of a way as incline=up/down:
http://wiki.openstreetmap.org/wiki/Proposed_features/incline_up_down
Vote-Start: 2009-10-03
Vote-End: 2009-10-17
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/list
e already *is* a consensus to use
"yes" for this.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
o be addr:housenumber=25f. The number of houses represented by
an interpolation way doesn't have anything to do with the number of
nodes in the way.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
wikipedia=*
tags. It might cause problems later, but the other solutions have
apparent flaws right now.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
ry barely usable due to "big edit" spam
it's probably the most useful provider of watchfeeds.
Here's the link:
http://www.itoworld.com/static/osmmapper
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Gary68 wrote:
> is there a function available now to find out how many users are
> watching a certain page?
I don't know a way to access that information right now. Maybe someone
can adapt this Wikipedia tool
http://toolserver.org/~mzmcbride/cgi-bin/watcher.py
for the OSM wiki?
T
only
accepting data that does). 3% doesn't sound that impressive, btw. Is
that before or after performing interpolation?
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
it is not
appropriate for steps with bicycle ramps. Otherwise, we'd need to tag a
lot of pedestrian streets/areas where pushing bicycles is legal (while
cycling is not) with bicycle=yes. Of course, this would be misleading.
I prefer ramp:bicycle=yes.
Tobias Knerr
_
r bicycles might
not be usable for strollers, for example.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
t
documentation, especially if they have written "proposal" over it and no
one has touched the page for almost two years.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
r can ignore addr:street on interpolation ways - with
documentation and tools (such as JOSM presets) supporting consistent
tagging you will be able to extract most data this way. Unless, of
course, enough people prevent consistent tagging by denying its possibility.
Tobias Knerr
___
without that
tag (I've implemented it for the GraphView plugin, for example), so the
tag obviously wouldn't add or improve information.
Mappers shouldn't do the job of a software preprocessor.
Tobias Knerr
___
talk mailing list
talk@openstreetm
tle details that
could well have been expressed by an additional tag. There is hardly a
good reason for most applications - and for most mappers - to
differentiate, so this doesn't warrant a different top-level tag.
Is there still some chance t
d even if we were to agree now that adding the tags to the
interpolation way is better, we shouldn't change the original proposal
page but modify current documentation instead (e.g.
http://wiki.openstreetmap.org/wiki/Key:addr ).
Tobias Knerr
__
David Earl wrote:
> On 08/09/2009 13:16, Tobias Knerr wrote:
>> Liz wrote:
>>> It's actually quite easy in JOSM
>>> you mass select them and add the tag
>> If mass selecting is possible, the changeset would have been the better
>> place, imo. Tags on
asy in JOSM
> you mass select them and add the tag
If mass selecting is possible, the changeset would have been the better
place, imo. Tags on individual objects do only make sense if you need to
add different source information for each object (or maybe even each
tag). And that's as m
ke gmane.org, so those numbers are off.
Even if the number of subscribers is slightly flawed, it would still be
able to show *relative* list size (talk_a is six times larger than
talk_b) and growth (we now have 50 % more subscribers) - if we assume
that the percentage of gateway users does
services are not really
intended for the public (at least if they need them and don't just
experiment with them) and we are only about data. If that's still the
case, recommending the use of these services to the public doesn't seem
like a good idea.
Tobias Knerr
_
Proposal that suggests to use highway=conveyor for conveyors that
transport persons, namely escalators and travelators (moving walkways).
http://wiki.openstreetmap.org/wiki/Proposed_features/Conveyor
___
talk mailing list
talk@openstreetmap.org
http://
e.
So except for truly lane-based stop signs, I think that expressing stop
signs using lane-based methods would be a bad idea - as they are
direction based, not lane based, in reality.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.or
r, a node modelling the
direction-dependent objects is part of a single way, so directions
(forward/backward) can be based on the direction of that way.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
hway key to store the
highway value "trunk", this is possible even with API 0.6.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
specific than
> :forward ... It would be nice to have an explicit
> description of how all the different tags can be evaluated.
I'm going to put together a comprehensive description of how I think
access evaluation w.r.t. conditional tagging could work as soon as I
have the time. I hope tha
n and
inconsistent uses...
> A (transport mode) category is simply a group of transport modes and/or
> other categories that are sometimes treated similarly regarding road
> access (by law).
Ok, thanks, I now understand what you mean. I thought it had something
to do with the access v
reset makers and translators will also take care not
to choose misleading descriptions.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
e placed on single ways rather than intersections, it would be
possible. Is there a reason why you didn't choose this approach?
(I do not have an opinion yet, I'm just interested in arguments for the
different options.)
Tobias Knerr
___
t
g that
seemingly obvious "steps" preset.
Personally, I still think adding that little incline=up tag would be
worth the effort...
Tobias Knerr
PS: How about adopting inline quoting for your mails to the list?
___
talk mailing list
t
goods conveyors? If there isn't any, then how can a reason
not be "good enough" to do it?
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Stephen Hope wrote:
> 2009/8/23 Tobias Knerr :
>> I believe the best way to solve this is to create a new top-level (that
>> is, highway) value for all variants of conveyor transport.
> [...]
> Is this intended to be only for human transport? I know of some quite
> len
t;category" and "(transport) mode" confuses me, especially as
they both seem to be things that can be a key.
I know from experience that it is hard to find good terms for these
concepts, but maybe you can help me a bit to understand it.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
tions that don't know
about this kind of feature would use it wrong anyway (e.g. route in the
wrong direction).
Would that solution work?
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
geometry
Allowing only separate ways would take away the choices #3 and #4 and
limit #2 to the sort of tags we already use (i.e. no proper ordering, no
sub-tags for lanes).
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Proposal for tagging the general direction of a way as incline=up/down:
http://wiki.openstreetmap.org/wiki/Proposed_features/incline_up_down
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
ly work):
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Advanced_footway_and_cycleway#Expanding_this_proposal_to_include_multi-lane_tagging
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
dd the lanes as numbered tags (e.g. "right1:", "left3:"), then we
should refer to these numbers. If we do something completely different,
then the lane turn restrictions need to adapt to that.
Tobias Knerr
___
talk mailing list
talk@ope
d specifically intended for bicycles, so it
isn't more of a cycleway than any ordinary road.
Of course, a cyclemap should still make sure to visibly indicate whether
an oneway rule applies to bicycles.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
hem.
> I'm not a programmer but it seems to me that you're missing same
> parenthesis
Assuming AND binds more strongly than OR, the query seems correct.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
e path vs. *way distinction that originally wasn't there
at all. (Things like paved surface, urban vs. rural, intentionally
maintained etc.) This is definitely *not* what I voted for.
Tobias Knerr
___
talk mailing list
talk@openstre
at this is a bad idea per se, but it requires
* good, universally applicable definitions for these separate tags
* exhaustive and complex editor support (having to look up and add a
whole bunch of tags for each road isn't an usable concept)
* clever rendering rules that can take
he wiki as a recommendation if you want. Of course,
this would require that barrier=turnstile was properly documented in the
first place.
Apparently, it still isn't. (It's mentioned on Key:barrier, but is not
part of the table and doesn't have an own page either.) Does anyone
object
ale of the task!
It's just that we have failed to create that definition so far. The task
would become rather easy if we didn't have to deal with differing
legislations at all.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://
nally use the same tags.
So I'm actually not sure whether country-specific defaults are the ideal
solution. Country-specific values /might/ be the better choice.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
the lack of a central communcaition channel is a
problem of its own.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
; routers) not beeing able to return if e.g. the stile is closed.
I don't think that this "trapping" situation is relevant in realistic
cases (i.e. a few metres of way tagged like that) - it will even be
below GPS accuracy.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
ion or a relation if you expect it
to be used in rendering, but I'd definitely recommend to also use a tag
like the one I suggested on the way to allow a more generic evaluation
for routing/navigation.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
direction, vehicle, time, etc.) is needed anyway,
it can be used to solve this as well.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
ersonal favourite) on that footway
leading through the turnstile.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
voice their opinion. It's everybody's right to refuse
participation. But I don't think it's good style to use the problems
resulting from that refusal as a proof that that process cannot work.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
entation / neighbors are using now. While path may have been
"approved" by a minority, it's also a minority who is complaining about
it now. If applications and editors consistently used path, then most of
your 1 wouldn't spend a second thought on it.
To
;s the difference between your suggestion and the current
situation, except that you want to limit participation to people at SOTM?
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
upid decision.
Do you have some examples for bad decisions that were produced by wiki
voting?
"path" isn't a good example because most of the chaos actually stems
from people using the pre-ochlocracy foot-/cycle-/bridleway without
having a common defini
aybe "in those parts of the world where streets are not perfectly
straight, it is of no use and even dangerous in the hands of newbies"
should be extrapolated to "it should not be included by default but
provided by a plugin/option"?
Tobias Knerr
__
of stile.
barrier=turnstile is clearly the better solution. This really cannot be
described by any of the existing barrier values. (Otherwise, I'd of
course suggest a sub-tag.) After all, renderers can still use the same
icon for different tags if the developers don't consider the distin
access=yes with a vehicle
condition, imo). So /keeping/ keys key-ish might not quite work...
Btw, it's nice to finally get some ideas about the conditional tagging
issue. I only wonder why people didn't provide this sort of feedback
when I explicitly requested it for for my p
ues was recently brought up on the talk page of
the "Extended conditions for access tags" proposal, btw:
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Extended_conditions_for_access_tags#Move_parameters_from_key_to_value
However, I'm still wondering if someone has any *practical*
x27;t think *=emergency is necessarily a bad idea, it's just not what
is currently documented.)
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
ays need to deal with substrings of either key or value string.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
way to tag
conditions. Then we can discuss the lane problem again. ;)
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
ts ("[ ]") have been suggested on talk-de as an
alternative to using colons.
Please state your opinion in the poll on the proposal's wiki page:
Which syntax do you prefer?
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
s_tags
it would be
access[forward] = destination
(or access:forward = destination, depending on what syntax people like
better)
Of course that's way direction dependent.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.ope
> Both foot and cycle routes take a long way around (car goes even further
> thought an 'access=bus' section).
"access=bus"? That tag doesn't match the usual vehicletype=usageright
structure, so why would you expect it
mbles the
route relations (also in that there can be more than one architect),
thus there is a case for relations.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
y the traffic zone proposal
(DE:rural etc.) that are based on national categories.
As stated above, I'd certainly expect that it would be easier for
#989431 to tag "DE:rural" info than to tag maxspeed:hgv/goods, minspeed
etc. (unless #989431 is a professional hgv driver employed by that
ying ("Rural UK")
* all additional rules coming from signs etc.
I don't need to know what the defaults are! If there is a sign, I add
the restriction. It might or might not overwrite any defaults, Why
should a mapper care?
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
201 - 300 of 330 matches
Mail list logo