> On 15. Aug 2020, at 12:43, Martin Koppenhoefer wrote:
> > On 15. Aug 2020, at 07:32, Volker Schmidt wrote:
> >
> > I do see these issues with adding sidewalks and cycle paths, where we have
> > a similar choice between mapping as separate objects or as road property.
>
> it is often perceived
> On Fri, 14 Aug 2020 at 14:33, Paul Allen via Tagging
> mailto:tagging@openstreetmap.org]> wrote:
> Is there a serious need (other than, say, one person's dissertation) to
> perform
> database queries to find objects that are tree-lined? I can see the need to
> find the nearest car park with d
I however consider a path to be a generic, almost unbound to physical properties, entity allowing an object to travel from a to b in urban or rural space. The main point here is, that 'path' _can_ be defined as an unpaved, one man width little way, but it does by no means have this meaning in any
The intriguing question is:
Does use of OSM in commercial products make
OSM a commercial product? IMHO it does not.
This would blow any license like PD, BSD, etc.:
Just because companies /use/ what's available
on an open basis, doesn't change the status of
the objects used. The OSM foundation
Shameless plug:
At least in Germany copyright does have limits, so an individual
may use/recite/remix parts of a copyrighted work or database, in
particular for non-commercial and scientific use - just as it is
popular to cite and quote parts of scientific publications in
others. See in particula
Again, please note the context this has
been orginally written in.
It dealt with the suggestion of
cycleway:left:direction=forward
There was no intention of importing
other objects of discussion, like you
and others did.
Greetings
> 03/20/19, 11:57, Paul Johnson wrote:
>
> > Suggesting for
I do, for the reasons and in the context given,
but please go ahead and throw that context away.
Regards,
cmuelle8
> On 03/20/19, 07:27, althio wrote:
>
> "rather bad thing"?!? Who says? Source?
___
Tagging mailing list
Tagging@openstreetmap.org
ht
Suggesting forward and backward as tag
values is a rather bad thing, as these
are values for route relation roles.
For example, if a physical way as part
of a route relation is travelled along
the direction of the osm way (as given
by its node order) it may be assigned
the role "forward" and this
OSM is a thing of beauty and a job forever.
If the distant goal changed from sticking to
ground truth, we may also accept fake islands
and fantasy cities again, instead of consequently
removing them.
And no, even if I wanted to replace them all,
I could not, for lack of resources and because
of p
What is the "normal traffic flow" of a two-way road?
After all, opposite_lane made it to be used in combination
with these as well - despite the fact that [1] documents
combination with oneways exclusively. (And because of that
[1] presumably spares details on right/left-handedness of
traffic sys
This seems reasonable but probably takes years to implement.
Considering how tagging changes moved, or rather not moved,
in the past, the projection into the future is that it will
at best be yet another tagging scheme (YATS) needing to co-
exist with the ones already present.
Regards,
cmuelle8
Yes, all of them, rationale:
For cycleway=opposite_track or cycleway=opposite_lane
you won't know which track or lane it refers to (or if
it refers to both), if two lanes or tracks accompany
the road.
cycleway=opposite (in the sense that no lane is marked
and no track exists, but cycling a oneway
I support discouraging both opposite* values.
Re-using oneway semantics is easy. oneway is an established
tag with established interpretation - if its meaning is not
reshaped in an obscure way it is reusable in all its namespace
variants with confidence and no frills.
I'm also in favour of a bet
This is not or at best conditionally true.
oneway:bicycle=no tells you /nothing more/ than that bicycles
can pass in both directions of a oneway, but it does not tell
you /where/ in the street or /how/, nor about the degree of
safety doing so, i.e. if a lane is marked.
cycleway:[left|right|both|n
What are you gonna do with the *=track cases then?
Imho your approach would mean to generally discourage
cycleway*=* and generally represent cycleway tracks
using a separate geometry.
In the case where cycleway tracks are separated merely
by a curb, this may be unsatisfactory as well. If the
geom
First use of cycleway:left=opposite_lane appears
to be one in Böblingen near Stuttgart in November
2009 [1]. About one year later it was applied to
a geometry in the center of Paris [2].
Traces of cycleway:left:oneway=* date back to late
2010, north of Edinburgh [3], about two months after
the ed
Let's do some research how "cycleway:left=opposite_lane"
entered the Bicycle wiki documentation. The relevant edit
was made in June 2013 [1].
Before that, Bicycle documentation has lived 5 years
from its incarnation without recommending opposite_lane
in combination with cycleway:left or cycleway:
oneway:bicycle=no is indifferent to a specific lane object,
it only means that a specific mode of transportation has
an exemption from the value tagged using oneway=*
In fact, oneway:bicycle=no refers most prominently to oneways
that do not have a marked cycleway lane at all, e.g. case S1
in the o
I'm objecting right now and heavily so.
There are lots of mappers not continuously
reading the mailing list or that are active
in other forums, so I do not have to regret
that I have not been there in 2017 or 2018.
cycleway:right= and cycleway:left= tags
are way older. And no-one thought about
u
Oh, and how exactly do you explain, that it never
ever appeared in the tag description for cycleway:left
and cycleway:right ?
Even on Bicycle wiki page, these were _red_ links,
while all the other stuff had neatly been linked
to existing and valid tag descriptions.
The meaning of it has never bee
The oneway attribute, unaffixed or not, reflects the direction
a way may _legally_ be used in. You're free to ignore it, but
may have to deal with consequences by law enforcement personnel.
Because in OSM each way has an inherent direction given by the
order of its node list (let it be D), it is
It also means that this software in turn
could dictate what the wiki has to document.
There are lots of people around deriving tag
meaning based on taginfo data. If the wiki
doc is not in sync with their findings, it
is tempting to document the state empirically
observable.
In some cases, spare
+1 for your rationale by not being blinded by sheer numbers.
(if we are to go by the numbers there, we are stuck with the
oldest and most established tags ever, regardless of their
shortcomings)
-1 for your suspicion. If you cannot live with a wiki being
changed, then use paper. Wikis were meant
This is not true, the namespace method has been
employed at least since May 2008, but propably
even before that date on which it was documented:
https://wiki.openstreetmap.org/wiki/Namespace
*:oneway is just an employment of this method,
documentation of a full key may be present, but
this is not
The answer to your question is simple. The conretion
of opposite_lane depends on the traffic system you're
in, but cycleway:left and cycleway:right are globally
used tags, not limited to a specific jurisdiction.
In particular, :left and :right suffixes _do not_
depend on the traffic system in use,
> On 9. Feb 2019, at 22:46, Martin Koppenhoefer wrote:
>
> > On 9. Feb 2019, at 15:23, Tom Pfeifer wrote:
> >
> > IMHO this violates the one object - one OSM element principle.
>
>
> IMHO it doesn’t. One tag describes a tree row, the other individual trees. It
> doesn’t matter that it is the
> 2018-04-26 03:23 PDT -07:00 François Lacombe :
>
> location=kiosk raises terminology questions and prevent to give
> the actual location of the cabinet when a substation is in it.
> That's why using man_made=street_cabinet is more consistent with
> local distribution substations not installed in
> Sent: Sat, 7 Apr 2018 22:51:40 +0100
> From: ael
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
>
> > If I'm not mistaken, the dictionary is referring the platform *on* the
> > bus [^1], not to the bus stop.
>
> As a native English speake
I'd go with function. If sth. is tagged public_transport=platform
then within the scope of public transport this sth. /functions/ as a
platform.
It does not make sense to view this as a structure or "structure only"
tag, since it is not very specific about the physical realization.
I.e. material,
> Gesendet: Freitag, 30. März 2018 um 11:29 Uhr
> Von: "Selfish Seahorse"
> An: "Tag discussion, strategy and related tools"
> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
>
> In my opinion, it's never too late to look for alternatives.
+1, if it is an alternative. Read:
> Gesendet: Freitag, 30. März 2018 um 11:06 Uhr
> Von: "Selfish Seahorse"
> An: "Tag discussion, strategy and related tools"
> Betreff: Re: [Tagging] Still RFC — Drop stop positions and platforms
>
> I wouldn't call a sidewalk a platform, especially because the waiting
> area on the sidewalk ofte
"wild" platform - the opposite of a built, dedicated platform structure
An example for both:
wild - a road with a grass strip and a PT post stuck in the ground,
people have to use the grass strip; over time it may have an "upgrade"
using fine gravel to compensate for the dirt revealed by
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dplatform
does have a legacy banner, but contrary
https://wiki.openstreetmap.org/wiki/DE:Tag:public_transport%3Dplatform
writes that legacy tags should co-exist (like in forever)
even if PTv2 tags are present.
If few people read the wiki, then th
> Sent: Thu, 29 Mar 2018 19:55:34 +0200
> From: "Selfish Seahorse"
> To: "Tag discussion, strategy and related tools"
> Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
>
> Or, very often, because there's a sidewalk and, therefore, no need for
> a platform.
In this case it i
> Sent: Wed, 28 Mar 2018 22:20:21 +0200
> From: "Michael Reichert"
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] Still RFC — Drop stop positions and platforms
>
> - If someone writes such a complicated proposal, he should ask the
> authors of map styles (if he isn't someone himself) fo
Mapping public transport in detail was in part started to aid impaired people and people with diminished mobility. The stop_position is an attempt to tell for large/long platforms at which subarea of the platform you can expect a public service vehicle to have an entrance (regardless of its lengt
> Sent: Wed, 28 Mar 2018 16:53:28 +0300
> From: "Ilya Zverev"
> To: tagging@openstreetmap.org
> Subject: [Tagging] Still RFC — Drop stop positions and platforms
>
> Hi folks,
>
> A while ago I've made a proposal to deprecate some public_transport=* tags:
>
> https://wiki.openstreetmap.org/wiki/P
> Gesendet: Dienstag, 16. Januar 2018 um 22:13 Uhr
> Von: "Fernando Trebien"
> An: "Tag discussion, strategy and related tools"
> Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines
>
> For simplicity, I think it should be no big problem changing the wiki
> to suggest using c
> Gesendet: Dienstag, 16. Januar 2018 um 15:55 Uhr
> Von: "Marc Gemis"
> An: "Tag discussion, strategy and related tools"
> Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines
>
> adding e.g. surface=paving_stones to the cycleway and
> cycleway=paving_stones to the main road
> Gesendet: Dienstag, 16. Januar 2018 um 14:50 Uhr
> Von: "Mateusz Konieczny"
> An: "Christian Müller"
> Cc: tagging@openstreetmap.org
> Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines
>
> Also, I am curious whatever you think th
> Gesendet: Dienstag, 16. Januar 2018 um 14:24 Uhr
> Von: "Volker Schmidt"
> An: "Tag discussion, strategy and related tools"
> Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines
>
> Filtering out separate cycleways that accompany roads would be plain wrong.
> A bicycle rou
> Gesendet: Dienstag, 16. Januar 2018 um 14:10 Uhr
> Von: "Marc Gemis"
> An: "Tag discussion, strategy and related tools"
> Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines
>
> There is a rule One Feature, One Object in OSM. [1]
> It seems to me that anything besides a tag
> Gesendet: Dienstag, 16. Januar 2018 um 14:50 Uhr
> Von: "Mateusz Konieczny"
> An: "Christian Müller"
> Cc: tagging@openstreetmap.org
> Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines
>
> On Tue, 16 Jan 2018 14:32:27 +01
> Gesendet: Dienstag, 16. Januar 2018 um 14:00 Uhr
> Von: "Andy Townsend"
> An: tagging@openstreetmap.org
> Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines
>
> "replacing" sidewalk=* with e.g. sidewalk:left=* is not a good idea
> since there are 1,186,931 existing objects
> Gesendet: Dienstag, 16. Januar 2018 um 13:06 Uhr
> Von: "Mateusz Konieczny"
> An: "Christian Müller"
> Cc: tagging@openstreetmap.org
> Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines
>
> On Tue, 16 Jan 2018 11:17:31 +0100
>
> Gesendet: Montag, 15. Januar 2018 um 15:47 Uhr
> Von: "Fernando Trebien"
> An: "Tag discussion, strategy and related tools"
> Betreff: [Tagging] Sidewalks and cycleways as tags vs as extra lines and
> StreetComplete
>
> The wiki also says that, when mapping a parallel cycleway as a
> parallel
On Thu, Nov 9, 2017 at 4:35 PM, Martin Koppenhoefer
wrote:
> I just noticed that the tagman_made=cooling_tower is deprecated.
> The template says the reason is on the deprecated features list, but actually
> there is no reasoning there.
+1. People are moving forward too fast without documentin
> Sent: Fri, 18 Aug 2017 20:06:29 +0100
> From: "Javier Sánchez Portero"
> To: "Tag discussion, strategy and related tools"
> Subject: Re: [Tagging] Simplify building:part areas
>
> Josm validation will raises a warning for duplicated ways (way1 and way2).
> If I use the open ways + MP relations
> Sent: Fri, 18 Aug 2017 09:47:04 +0100
> From: "Javier Sánchez Portero"
> To: "Tag discussion, strategy and related tools"
> Subject: Re: [Tagging] Simplify building:part areas
>
> Thank you. This clarifies me a lot because I had not thought to use both
> building=* and building:part=* in the f
Hi,
in the realm of Germany's celebration of the luther year,
people are gathering coordinates to luther roses here:
https://www.google.com/maps/d/viewer?mid=1KNy1ApGlFxvNHEfBY1O_6994JE4
General info:
https://en.wikipedia.org/wiki/Luther_rose
https://de.wikipedia.org/wiki/Lutherrose
A quick s
> Gesendet: Mittwoch, 08. März 2017 um 18:32 Uhr
> Von: "Martin Koppenhoefer"
> An: "Tag discussion, strategy and related tools"
> Betreff: [Tagging] simple 3D buildings, proposed redefinition of
> building:levels
>
> NEW:
>
> - building:min_level unchanged
>
> - building:levels=amount of
> Gesendet: Sonntag, 05. März 2017 um 20:22 Uhr
> Von: "Peter Barth"
> An: "Tag discussion, strategy and related tools"
> Betreff: Re: [Tagging] how to map simple buildings
>
> Mappers even screw up simple multipolygons all the time.
Addendum: It's not mappers to blame, but partial data, i.e. ob
> Gesendet: Sonntag, 05. März 2017 um 20:22 Uhr
> Von: "Peter Barth"
> An: "Tag discussion, strategy and related tools"
> Betreff: Re: [Tagging] how to map simple buildings
>
>
> you're probably more than 10 years late with that and there had
> been many to suggest great new database schemata, gr
> Gesendet: Samstag, 04. März 2017 um 21:21 Uhr
> Von: "Tobias Knerr"
> An: tagging@openstreetmap.org
> Betreff: Re: [Tagging] how to map simple buildings
>
> And probably a few more. None of these requires relations.
I'm sure there is a lot of stuff in OSM where you could
trade code against a re
> Gesendet: Samstag, 04. März 2017 um 10:17 Uhr
> Von: "Martin Koppenhoefer"
> An: "Tag discussion, strategy and related tools"
> Betreff: Re: [Tagging] how to map simple buildings
>
> So no, the building relations to group building:parts are not strictly
> redundant, but the reason they are "ne
> Gesendet: Freitag, 03. März 2017 um 20:04 Uhr
> Von: "Tobias Knerr"
> An: "Tag discussion, strategy and related tools"
> Betreff: Re: [Tagging] how to map simple buildings
>
> The type=building relation is unnecessary [..]
It may be redundant, but it's far from useless. Also, I've
noticed tha
> Gesendet: Freitag, 03. März 2017 um 03:36 Uhr
> Von: "Kevin Kenny"
> An: "Tag discussion, strategy and related tools"
> Betreff: Re: [Tagging] how to map simple buildings
>
> I'm hijacking the thread a bit here
You do not, this list is claimed to be open to everyone.
> there's a fairly subs
> Gesendet: Donnerstag, 02. März 2017 um 17:19 Uhr
> Von: "Martin Koppenhoefer"
> An: "Christian Müller"
> Cc: "Tag discussion, strategy and related tools"
> Betreff: Re: [Tagging] how to map simple buildings
>
> do I understand you
> Gesendet: Donnerstag, 02. März 2017 um 14:09 Uhr
> Von: "Martin Koppenhoefer"
> An: "Tag discussion, strategy and related tools"
> Betreff: [Tagging] how to map simple buildings
>
> I have just started mapping according to the simple building scheme
> and have some questions to the more experi
Also note that there are some implications in 2d mapnik rendering.
With the building outline we define and the mapnik rules that were
set upto render everything highway=* _above_ anything else, the
renderer _will_ overlap a building outline with a pedestrian area.
Esp. when (highway=pedestrian ar
I usually go for a mixture of 1.1. and 1.3., i.e.
- use building:part for the architectural blocks the building is made of,
with building:min_height / building:min_level where appropiate
- use type=multipolygon building=*, stuff the usual building tags into that,
this will be rendered by
>Il giorno 18/ago/2013, alle ore 17:54, "Christian Müller" ha
>scritto:
>> The term boundary does not make any implication on it's width.
> it has no width at all, it is a line
-1. It may be _represented_ by a line, as declared by an entity. Even though
the bo
>On 16.08.2013 19:05, Masi Master wrote:
>> Hmm, I'm not sure that boundary is the right tag. Isn't it a border, and
>> not an area?
> Boundaries describe an area but you are right that they are not really
> boundaries, especially if the border lines are not clearly defined
The term boundary doe
63 matches
Mail list logo