> 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
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
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
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
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
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
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*
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
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
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
__
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
;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
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
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
ersonal favourite) on that footway
leading through the turnstile.
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
; 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
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
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
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
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://
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
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
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
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
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
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
Roy Wallace wrote:
> But I agree with Tobias also - we should first create a "good
> concept for modelling the lanes themselves". Tobias, could you link to
> the latest/most promising proposal, if there is one?
If we already had a superior proposal, this would be a lot easier.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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://
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
_
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
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
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
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
__
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
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
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
___
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 bicycles might
not be usable for strollers, for example.
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
_
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
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
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
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
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
e already *is* a consensus to use
"yes" for this.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
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
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
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
to distinguish between plausible
possibilities and irrelevant hypothetical constructs?
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
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
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
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
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
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
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
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
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
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
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
rers,
which should be avoided.
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
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
/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
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,
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
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
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
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
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
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
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
do this
by manually positioning a label, either.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
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
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
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
everyone agree that these are
simply documentation errors and should be corrected?
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
http://wiki.openstreetmap.org/wiki/Proposed_features/Scope_for_access_tags
Intention: solve some tagging problems related to restrictions
(restrictions on wet roads, restrictions only for some vehicle types,
direction-dependent restrictions).
Tobias Knerr
. Probably we should just
relabel that to "poll" or something and make clear that it isn't binding
in any way. It's merely a quick indicator whether consensus has been
reached and a way of getting some more discussion started.
Tobias Knerr
__
to state that a maxspeed is valid only on wet roads (example 1) or only
for hgv traffic.
Please add your opinion to the poll and discuss related ideas as well as
problems with the concept on the talk page.
Tobias Knerr
___
talk mailing list
talk@openstr
hange to the data, but the (unpublished) tools creating
the images, thus nothing of use would be contributed back to the "free
world" with ODbL.
I don't think explaining that data is more useful for us than images
will help (I've already tried that), beca
really help to explain why we should allow those
non-free ones to be created in the first place.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
because I found this aspect of the statement especially
interesting. Most probably overly generalizing, misleading and/or simply
wrong. ;-)
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
provements suggested during
the original proposal's RFC and poll processes have made it into the
extension.
With this way of tagging, we'd probably be able to represent almost all
maxspeed and access restrictions.
See the proposal page for examples. C
boxes. If the OSM meaning is indeed based on
some external definition of the term, then exactly that definition
should be linked in the descriptive text.
Tobias Knerr
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
can perfectly
handle all situations and there is no significant difference in mapping
effort either. So why don't we restrict the via role to ways (except
maybe for the popular single-via-node case)?
Tobias Knerr
PS: I'm perfectly aware that there is no authoritative documentation,
that I ca
1 - 100 of 368 matches
Mail list logo
