Re: [Tagging] Feature Proposal - RFC - police=*

Am 15. März 2019 07:55:31 MEZ schrieb Joseph Eisenberg : >Please don’t change the established meaning of amenity=police; it >should >keep meaning “a public police station”. > >Most database users are only going to be interested in public police >stations, that’s why we’ve gotten by for over 10 y

Re: [Tagging] Mapping deforestation wikipage

> > > “The idea is to have mapathon in > > different time, when new imagery are > > available and after check what > > changed searching in the database > In this case you only need to map the area of woodland or forest now, and it’s no problem to leave other landuse and natural areas unmapped. B

Re: [Tagging] Feature Proposal - RFC - police=*

Mar 15, 2019, 7:37 AM by grimpeu...@gmail.com: > > > Am 15. März 2019 00:19:22 MEZ schrieb althio <> althio.fo...@gmail.com > > >: > >Martin Koppenhoefer <> dieterdre...@gmail.com > >> > wrote: > >>> > If this seems viable, I would

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

Taginfo shows it is not the preferred method 979<3562 https://taginfo.openstreetmap.org/tags/cycleway%3Aleft%3Aoneway=-1 https://taginfo.openstreetmap.org/tags/cycleway%3Aleft=opposite_lane *=opposite_lane is/was well understood as far as I know (I am regularly "teaching" OSM using the bicycle

Re: [Tagging] Mapping deforestation wikipage

sent from a phone > On 15. Mar 2019, at 08:32, Joseph Eisenberg > wrote: > > But you should plan to keep your own copy of the database to compare with and > edit in the future. the OSM db contains all the history as well, not just the current state. What you often cannot tell from the dat

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

sent from a phone > On 15. Mar 2019, at 09:23, Charles MILLET wrote: > > Why using two tags when one works well, when the value opposite_lane exists > and the interpretation is the same? why using a specific tag if everything can be expressed with standard tags? There are arguments for both

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

It was introduce in may 2018 when opposite_lane was already well used and described in the wiki. I don't see any process of validation but correct me if I am wrong. I feel the wiki modification to introduce cycleway:left=lane + cycleway:left:oneway=-1 has been forced through. Charles On 15/03

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

In absolute yes but be carefull: Some editors (like StreetComplete since some weeks or iD) might push one or the other schema without the user knowing which one is used in the background and sometimes without rationale why this one and not the other one on editor side (they implement ONE, they d

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

Whatever the preferred tagging method, both are used and both should be documented in the wiki. At least for the sake of data users and definition of used tags. The edit of the wiki looks suspicious. On Fri, Mar 15, 2019, 09:25 Charles MILLET wrote: > Taginfo shows it is not the preferred metho

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

Yes, one of main points of StreetComplete is to allow editing without knowing how objects are tagged, similarly iD. It means that to count "how many people decided to use tag XYZ" all iD users and all StreetComplete users count as say 4 people because not each mapper is deciding on its own but it

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

I am not comfortable with the definition of standard tag in this case. Isn't the tag or name space "oneway" made to define that a lane is oneway or not ? In this case using cycleway:left means by default it is oneway. So the name space ":oneway" is used to describe the direction. Correct me i

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

Mateusz Konieczny wrote: > Yes, one of main points of StreetComplete is to allow editing > without knowing how objects are tagged, similarly iD. > > It means that to count "how many people decided to use tag > XYZ" all iD users and all StreetComplete users count as say > 4 people because not ea

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

Am Fr., 15. März 2019 um 09:59 Uhr schrieb Charles MILLET < charlesmil...@free.fr>: > I am not comfortable with the definition of standard tag in this case. > > Isn't the tag or name space "oneway" made to define that a lane is > oneway or not ? In this case using cycleway:left means by default it

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

Mar 15, 2019, 10:03 AM by rich...@systemed.net: > Mateusz Konieczny wrote: > >> Yes, one of main points of StreetComplete is to allow editing >> without knowing how objects are tagged, similarly iD. >> >> It means that to count "how many people decided to use tag >> XYZ" all iD users and all

Re: [Tagging] Feature Proposal - RFC - police=*

Agreed - don't change the meaning. If additional information is required - and I'm not sure why - then additional police=* tag is a good alternate to the Amenity tag. TonyS On 15/03/2019 06:55, Joseph Eisenberg wrote: Please don’t change the established meaning of amenity=police; it should ke

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

On 15/3/19 10:12 am, althio wrote: Discussed: maybe there https://lists.openstreetmap.org/pipermail/tagging/2018-May/036164.html Decided : I don't know Even for the tagging list that is one rambling thread. After pushing through a lengthy discussion on how to count the number of lanes, how OS

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

On 15/3/19 11:35 am, Hubert87 wrote: > "cycleway:left:oneway=-1" as the currently preferred method and have been mapping/tagging like this for a while now. What makes you think that? cycleway:left:oneway=-1 => 979 cycleway:right:oneway=-1 => 19 oneway:bicycle=no => 70400 and looking at ht

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

Am Fr., 15. März 2019 um 11:15 Uhr schrieb Andrew Davidson < thesw...@gmail.com>: > On 15/3/19 11:35 am, Hubert87 wrote: > > > > > "cycleway:left:oneway=-1" > > > > as the currently preferred method and have been mapping/tagging like > > this for a while now. > > What makes you think that? > > cy

Re: [Tagging] Superroutes - good, bad or ugly?

I wonder why we need a separate type=superroute if everything what can be done with superroutes can also be done with normal routes. Example: http://hiking.waymarkedtrails.org/?l#route?id=371740 is a normal hiking route, more than 10k km long, with 7 child relations that have child relations ag

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

On 2019-03-14 23:57, Martin Koppenhoefer wrote: > There are indications that at least 2 other secret groups operating in osm > are suspicious about the plans for a new group and are planning to covf Another tasteless and vile joke. Not that I was expecting anything better from you, Martin: tastl

Re: [Tagging] Superroutes - good, bad or ugly?

Le 15.03.19 à 12:27, Hufkratzer a écrit : > is that a good/sufficient reason to define a new relation type? imho nearly no routing tools (nor foot nor bus) is currently able to use a relation type=route with relations as child. so that's a good reason to create/improve a doc if superrelation is n

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

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 not

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

Sergio, and others who might be reading this and thinking it is "normal", On 15.03.19 12:41, Sergio Manzi wrote: > Another tasteless and vile joke. It is ok to say that, even though I'd hope it is rarely necessary. But it is definitely not ok to say > Not that I was expecting anything better f

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 meant

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] Superroutes - good, bad or ugly?

On Fri, Mar 15, 2019 at 12:07:50PM +, marc marc wrote: > Le 15.03.19 à 12:27, Hufkratzer a écrit : > > is that a good/sufficient reason to define a new relation type? > > imho nearly no routing tools (nor foot nor bus) is currently able > to use a relation type=route with relations as child. >

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] Superroutes - good, bad or ugly?

marc marc wrote: > imho nearly no routing tools (nor foot nor bus) is currently > able to use a relation type=route with relations as child. cycle.travel can. I don't particularly care what's decided, but I would like it to be consistent (which right now it certainly isn't), and personally I don

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 bee

Re: [Tagging] Superroutes - good, bad or ugly?

I like Sarah's proposal too, especially for walking routes. I'm not sure it would work for complex PT routes, where routability is involved. One issue: a route relation can be a route on it's own AND part of a longer route (or node network), on any level of the hierarchy. segment=yes would not cov

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 u

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 o

Re: [Tagging] Superroutes - good, bad or ugly?

sent from a phone > On 15. Mar 2019, at 14:43, Peter Elderson wrote: > > I like Sarah's proposal too, especially for walking routes. I'm not sure it > would work for complex PT routes, where routability is involved. how can we state that a route is complete and also a segment of another ro

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

As the one who in a way triggered this discussion originally, a discussion that has been abandoned without conclusion, I want to say that I had very much preferred that the discussion be restarted *before *a one-sided wiki change. If two different methods are in use, we should document both, outlin

Re: [Tagging] Superroutes - good, bad or ugly?

I can see *a lot* of shared routes in my area because most of the buses heavily use a star topography (everything must take you to a central station) as opposed to a hybrid mesh/star topography (everywhere has access to a service to a central station, but there are circular routes to allow quic

Re: [Tagging] Superroutes - good, bad or ugly?

I have actually done that, a "stub" containing one nwn hiking path which also acts as the NL part of an iwn route. It was the only way to get the tagging of names, international names, colours and osmc:symbols right. On waymarkedtrails it works like a charm, but I'm less sure about OsmAnd. Fr gr

Re: [Tagging] Superroutes - good, bad or ugly?

Good analysis Seirra, I would not "reuse" route=road in other route=* relations though. route=bicycle might share segments with route=foot/walking/hiking, but I'd keep everything related to bus/trolley_bus and coach together in terms of sharing of subroutes not mix it with other route types. For

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

On 15/03/2019 11:41, Sergio Manzi wrote: ... I see this as the last straw ... (just to add to what Frederik has said) Can I recommend that all mailing lists work much better with an effective killfile at the client side?  That way you don't need to read anything by people who you don't think

Re: [Tagging] Superroutes - good, bad or ugly?

Am Fr., 15. März 2019 um 16:01 Uhr schrieb Jo : > For public transport the biggest benefit will be ease of maintenance. > +1, it will also be "lighter" in a way: the superroute relations = actual bus routes, will have much slower increase of versions, it will only be the segment relations who in

Re: [Tagging] Superroutes - good, bad or ugly?

This seems to boil down to: You can put any sequence of connected ways in a package (shared route segment) and use that package in any route to replace these ways themselves. You would need to allow all types of route relations to contain ways and shared segment relations. I'm not sure if you wou

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

Mar 15, 2019, 2:57 PM by cmu...@gmx.de: > 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 cyclew

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

Am Fr., 15. März 2019 um 16:36 Uhr schrieb Mateusz Konieczny < matkoni...@tutanota.com>: > > Where are the wiki edits in 2017 of 2018 of the > wiki, documenting the results of the mailing > list discussions back then? > > In general, people unfortunately rarely > document mailing list discussions

[Tagging] make a summary and/or "propage" mailing concensus in the wiki

Le 15.03.19 à 16:34, Mateusz Konieczny a écrit : > people unfortunately rarely > document mailing list discussions on wiki, > even in cases of a clear consensus. > What is quite weird, given that editing wiki has > usually much greater impact on tag usage > than commenting on mailing list. I agree

Re: [Tagging] Feature Proposal - RFC - police=*

Am 15. März 2019 09:17:31 MEZ schrieb Mateusz Konieczny : >Mar 15, 2019, 7:37 AM by grimpeu...@gmail.com: > >> >> >> Am 15. März 2019 00:19:22 MEZ schrieb althio <> >althio.fo...@gmail.com > >: >> >Martin Koppenhoefer <> dieterdre...@gmail.com >

Re: [Tagging] Feature Proposal - RFC - police=*

On Fri, 15 Mar 2019 at 09:19, Mateusz Konieczny wrote: > >> amenity=police would be reduced to indicate that the tag is used for all >> police facilities > > I am against changing meaning of an established tag (even if it has some > mistaggings). +1 On Fri, 15 Mar 2019 at 17:17, Jan S wrote:

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

Missed the earlier discussion. I also always regarded cycleway=opposite, opposite_track, opposite_lane, opposite_share_busway etc. as the old deprecated method and oneway:bicycle=no + normal cycleway tag as the one that superceded it. Same with cycleway:right=dual_lane/dual_track being superced

Re: [Tagging] Feature Proposal - RFC - police=*

Le 15.03.19 à 17:16, Jan S a écrit : > I sense dissent here about the future use of amenity=police. Would it be a > possible solution to keep amenity=police for public-facing police stations > only, that's the current meaning. > but invite mappers on the wiki to nevertheless add police=station

Re: [Tagging] Superroutes - good, bad or ugly?

+1 Sarah would you be willing to write a proposal for this? Cheers pangoSE Sarah Hoffmann skrev: (15 mars 2019 14:03:28 CET) >On Fri, Mar 15, 2019 at 12:07:50PM +, marc marc wrote: >> Le 15.03.19 à 12:27, Hufkratzer a écrit : >> > is that a good/sufficient reason to define a new relation type

Re: [Tagging] Superroutes - good, bad or ugly?

oh the idea is that [G] has type=route, but no route=* because it may be used in any form of route (with some 'common sense' of course); route does not apply until [C] so route=road would not get reused. there is actually a small error, [D/E] is the same and stays exclusively within public tran

Re: [Tagging] Superroutes - good, bad or ugly?

On Fri, Mar 15, 2019 at 9:05 AM Sarah Hoffmann wrote: > The disadvantage of all these proposals is that it is impossible > to figure out if a relation is a route or only part of a superroute > without looking at the parent. At the risk of beating a dead horse, mightn't this be an argument in favo

Re: [Tagging] Superroutes - good, bad or ugly?

yeah roughly so. in terms of mapping, no. as relations are on somewhat of a 'meta' level though, I considered it mostly due to the fact people seem to feel some sort of tag is needed. I (personally) wondered whether the use of type=route would require the use of a route tag no matter what (or I

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

Re: [Tagging] Superroutes - good, bad or ugly?

key: almost tagging should occur here | data may be reused in parent | data may be reused in parent and any 'adjacent' (with the same letter) parent // /public transport network///[A]/ / /route_master=public transport /[B] /route variant/ [C] _combined stop/way relation

Re: [Tagging] Superroutes - good, bad or ugly?

When I start mapping a bus line, I have several route relations which contain all the stops for each variation in itinerary. When I add the ways, it would be nice to reuse subroute relations for the parts where ways are shared between lines. When I come back later and I want to compare whether th

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

Hi again, lets ignore the cycleway:left:oneway=-1 for a moment and just consider cycleway:left=lane vs cycleway:left=opposite_lane. To me the main difference is, that cycleway:left=opposite_lane can only be used when the carriageway itself is a one way street (legally speaking). because of

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

sent from a phone > On 15. Mar 2019, at 19:42, Hubert87 wrote: > > Also, have you considered, how you would tag a dual-cycleway on the left-hand > side of a one way carriageway?(eg cycleway:left=? + cycleway:left:oneway=no) https://taginfo.openstreetmap.org/keys/cycleway%3Aleft%3Alanes Che

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 ed

Re: [Tagging] Superroutes - good, bad or ugly?

The just-a-chain-of-ways relation doesn't have to be shared. It's shareable, but the sharing really is of no consequence. I think software needs a tag to control the selection for the purpose it serves, OR allow any route relation without a type within all route types it supports. I would indeed

Re: [Tagging] Superroutes - good, bad or ugly?

I can understand your concern. I did actually consider mentioning something about skipping stops.. but I forgot to, I spent a good few hours on the original, so I guess my thoughts got easily distracted. I'll make an example based on the real data to help illustrate the idea, but I'll also incl

Re: [Tagging] Superroutes - good, bad or ugly?

maybe we can have roles to state whether the tags of the referenced object should apply to the relation or if only the geometry matters. These superroutes could be also useful for admin relations Cheers, Martin ___ Tagging mailing list Tagging@openst

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

Interesting. But I actually miss wrote. I meant a two-way cycleway. Also, but OT, lanes-count should only be used for double tracked vehicles afaik. In contrast to the *:lanes=*|*|* scheme. Am 15.03.2019 um 19:55 schrieb Martin Koppenhoefer: sent from a phone On 15. Mar 2019, at 19:42, H

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

sent from a phone > On 15. Mar 2019, at 20:20, Hubert87 wrote: > > Also, but OT, lanes-count should only be used for double tracked vehicles > afaik. In contrast to the *:lanes=*|*|* scheme. You have to distinguish lanes count on roads from that on cycle infrastructure. Admittedly, they ar

Re: [Tagging] Feature Proposal - RFC - police=*

Woudn’t it be possibel to do an Automated edit where we add fixme:Police to all amenity Police this shoud Speed up the Adoption and allow for the Elimination of the amenity=Police. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openst

Re: [Tagging] Superroutes - good, bad or ugly?

hmm... I'm not quite sure on what would be best. I do see your point in the case of just splitting very long ways there, they would not be 'shared' at all. to the best of my knowledge type=* is intended to exclusively define the relation. in all circumstances that we have discussed, it still jo

Re: [Tagging] Superroutes - good, bad or ugly?

hmm maybe. version 4 will include a detailed example, once that is available feel free what would be missing for that purpose On 3/15/19 7:19 PM, Martin Koppenhoefer wrote: maybe we can have roles to state whether the tags of the referenced object should apply to the relation or if only the ge

Re: [Tagging] Feature Proposal - RFC - police=*

Mar 15, 2019, 8:25 PM by ferdi98...@gmail.com: > > Woudn’t  it be possibel to do an Automated edit where we add fixme:Police to > all amenity Police this shoud Speed up the Adoption and allow for the > Elimination of the amenity=Police. > > In theory yes. See https://wiki.openstreetmap.org/wik

Re: [Tagging] Superroutes - good, bad or ugly?

key: /almost all tagging should occur here/ | _data may be reused in parent_ | *data may be reused in parent and any 'adjacent' (with the same letter) parent* /public transport network///[A] /route_master=public transport /[B] /route variant/ [C] _combined stop/way relat

Re: [Tagging] Feature Proposal - RFC - police=*

I don't see why people would care that much about a tag that could be seen as a sub-tag at first (look at all the chain of tag that we have like : man_made=street_cabinet + street_cabinet=power + power=substation + substation=minor_distribution). So someone don't like the "amenity=police" + police=

Re: [Tagging] Superroutes - good, bad or ugly?

Looks good. Vr gr Peter Elderson Op vr 15 mrt. 2019 om 21:05 schreef seirra blake < sophietheopos...@yandex.com>: > key: *almost all tagging should occur here* | *data may be reused in > parent* | *data may be reused in parent and any 'adjacent' (with the same > letter) parent* > > *public tran

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

On Sat, 16 Mar 2019 at 01:36, Mateusz Konieczny wrote: > In general, people unfortunately rarely > document mailing list discussions on wiki, > even in cases of a clear consensus. > What is quite weird, given that editing wiki has > usually much greater impact on tag usage > than commenting on ma

Re: [Tagging] Feature Proposal - RFC - police=*

On Sat, 16 Mar 2019 at 02:17, Jan S wrote: > > Would it be a possible solution to keep amenity=police for public-facing > police stations only, but invite mappers on the wiki to nevertheless add > police=station, so that in the future the majority of police stations will > hopefully also carry th