Re: [Tagging] new page for tree_lined=*

> 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

Re: [Tagging] new page for tree_lined=*

> 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

Re: [Tagging] JOSM's "suspicious" path data warnings

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

Re: [Tagging] My ban by user Woodpeck = Frederik Ramm

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

Re: [Tagging] My ban by user Woodpeck = Frederik Ramm

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

Re: [Tagging] Do we still need cycleway=opposite_lane? (Was: Do we still need cycleway=opposite?)

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

Re: [Tagging] Do we still need cycleway=opposite_lane? (Was: Do we still need cycleway=opposite?)

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

Re: [Tagging] Do we still need cycleway=opposite_lane? (Was: Do we still need cycleway=opposite?)

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

Re: [Tagging] Do we still need cycleway={opposite, opposite_lane}?

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

Re: [Tagging] Do we still need cycleway=opposite_lane? (Was: Do we still need cycleway=opposite?)

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

Re: [Tagging] Green lanes (OT)

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 

Re: [Tagging] Do we still need cycleway=opposite?

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

Re: [Tagging] Do we still need cycleway=opposite?

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

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.

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

+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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

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

Re: [Tagging] Wild changes to wiki pages changing the cycleway tagging scheme

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

Re: [Tagging] tree rows vs individual trees

> 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

Re: [Tagging] When was the deprecation of location=kiosk for power=substation discussed?

> 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

Re: [Tagging] Still RFC — Drop stop positions and platforms

> 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. >

Re: [Tagging] Still RFC — Drop stop positions and platforms

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.

Re: [Tagging] Still RFC — Drop stop positions and platforms

> 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

Re: [Tagging] Still RFC — Drop stop positions and platforms

> 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,

Re: [Tagging] Still RFC — Drop stop positions and platforms

"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

Re: [Tagging] Still RFC — Drop stop positions and platforms

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

> 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

Re: [Tagging] Still RFC — Drop stop positions and platforms

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

Re: [Tagging] Still RFC — Drop stop positions and platforms

> 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: > >

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> 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

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> 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

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> Gesendet: Dienstag, 16. Januar 2018 um 14:50 Uhr > Von: "Mateusz Konieczny" <matkoni...@gmail.com> > An: "Christian Müller" <cmu...@gmx.de> > Cc: tagging@openstreetmap.org > Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as extra

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> 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

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> 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

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> Gesendet: Dienstag, 16. Januar 2018 um 14:50 Uhr > Von: "Mateusz Konieczny" <matkoni...@gmail.com> > An: "Christian Müller" <cmu...@gmx.de> > Cc: tagging@openstreetmap.org > Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as ext

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> 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

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> Gesendet: Dienstag, 16. Januar 2018 um 13:06 Uhr > Von: "Mateusz Konieczny" <matkoni...@gmail.com> > An: "Christian Müller" <cmu...@gmx.de> > Cc: tagging@openstreetmap.org > Betreff: Re: [Tagging] Sidewalks and cycleways as tags vs as ext

Re: [Tagging] Sidewalks and cycleways as tags vs as extra lines

> 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

Re: [Tagging] tower types, cooling towers etc.

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

Re: [Tagging] Simplify building:part areas

> 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

Re: [Tagging] Simplify building:part areas

> 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

Re: [Tagging] simple 3D buildings, proposed redefinition of building:levels

> 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: > > -

Re: [Tagging] how to map simple buildings

> 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:

Re: [Tagging] how to map simple buildings

> 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 >

Re: [Tagging] how to map simple buildings

> 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

Re: [Tagging] how to map simple buildings

> 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

Re: [Tagging] how to map simple buildings

> 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,

Re: [Tagging] how to map simple buildings

> 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

Re: [Tagging] how to map simple buildings

> Gesendet: Donnerstag, 02. März 2017 um 17:19 Uhr > Von: "Martin Koppenhoefer" <dieterdre...@gmail.com> > An: "Christian Müller" <cmu...@gmx.de> > Cc: "Tag discussion, strategy and related tools" <tagging@openstreetmap.org> > Betreff

Re: [Tagging] how to map simple buildings

> 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

Re: [Tagging] how to map simple buildings

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

Re: [Tagging] how to map simple buildings

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

Re: [Tagging] Tagging of topographic areas with a name

Il giorno 18/ago/2013, alle ore 17:54, Christian Müller cmu...@gmx.de 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 boundaries of territories