Re: [Tagging] mast / tower / communication_tower (again)
Looking at the definition on the wikiproject telecom https://wiki.openstreetmap.org/wiki/WikiProject_Telecoms (in the part "Antennas / Masts / Towers", there is a section to indicate how to tag the mast, tower ...: >From my understandings, the three (four) cases are currently : - a vertical structure supported by anchors for a mast; - a free-standing structure for a tower (it can be a tower of 10 meters or 150 meters !); - and the communication_tower is only a sub-category of a tower, for the ones with an height > 100 meters (i suppose it is an historic method to get big tower rendered differently without knowing the height exactly - for the towers that are a clear landscape reference). (- And for antenna (alone) on buildings, there is "telecom=antenna".) Probably most of the mast are only accessible via ladder, and most of the big tower have a platform (i don't know if all of them does), but does it really matter ? The question i could see is : do we really need the communication_tower tag or should it be a secondary tag of the tower itself (like tower_type=*) ? I think it is useful to distinguish them somehow as it is useful as a landmark on the map, but am i alone to think that ? Le dim. 30 sept. 2018 à 18:04, SelfishSeahorse a écrit : > On Sun, 30 Sep 2018 at 17:24, SelfishSeahorse > wrote: > > > > On Sun, 30 Sep 2018 at 14:45, Martin Koppenhoefer > > wrote: > > > > > > > To solve the contradiction we need to get rid of one of the two > definitions. > > > > > > they could be combined: if it is intended to be accessed by people > (not only for maintenance) and is not guyed it is a tower, otherwise it > would be a mast. > > > > I think it's better to stick to either a common or a technical > > definition. OSM-specific definitions are prone to create confusion and > > tagging mistakes. > > PS: Except if this appears to be a common definition. > > ___ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] mast / tower / communication_tower (again)
On Sun, 30 Sep 2018 at 17:24, SelfishSeahorse wrote: > > On Sun, 30 Sep 2018 at 14:45, Martin Koppenhoefer > wrote: > > > > > To solve the contradiction we need to get rid of one of the two > > > definitions. > > > > they could be combined: if it is intended to be accessed by people (not > > only for maintenance) and is not guyed it is a tower, otherwise it would be > > a mast. > > I think it's better to stick to either a common or a technical > definition. OSM-specific definitions are prone to create confusion and > tagging mistakes. PS: Except if this appears to be a common definition. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] mast / tower / communication_tower (again)
sent from a phone > On 30. Sep 2018, at 17:24, SelfishSeahorse wrote: > > I think it's better to stick to either a common or a technical > definition. it doesn’t have to be the British definition of terms, has it? Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Traffic sign direction tagging..
On 28/09/18 22:58, Philip Barnes wrote: > > > On 28 September 2018 22:14:03 BST, Simon Poole wrote: >> >> >> Am 28.09.2018 um 18:07 schrieb Bryan Housel: I actually mentioned the issue in Milano. Essentially `traffic_sign`, `traffic_sign:forward` and `traffic_sign:backward` need to be treated as "object" tags as >> things are now. >>> Let’s just do `traffic_sign=*` and consider the others an unfortunate >>> mistake that can go away. >> There are a total of 37'000 forward / backward variants that would have >> to be migrated to traffic_sign + a suitable sub tag, not an awful lot >> in the grand scheme of things, but needs to be done. > > Not all give ways have a sign, some are just give way markings painted on the > road. As far as the law is concerned, that is also a traffic sign, diagram 1003A in TSRGD 2016 (see http://www.legislation.gov.uk/uksi/2016/362/schedule/9/made ). Failure to give way is a criminal offence contrary to s. 36 RTA 1988. > > Phil (trigpoint) > -- Robert Skedgell (rskedgell) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] mast / tower / communication_tower (again)
On Sun, 30 Sep 2018 at 19:34, Martin Koppenhoefer wrote: > > > I think it's better to stick to either a common or a technical > > definition. > > > it doesn’t have to be the British definition of terms, has it? It would already be helpful if there actually were a common definition to distinguish masts from towers. By the way, i've written a message to the person who added the definition to the wiki that 'a tower is accessible and provides platforms, whereas a mast only offers ladder steps to climb it' [1] and asked him where this definition comes from and what 'accessible' exactly means (a ladder also provides access). [1]: https://wiki.openstreetmap.org/w/index.php?title=Tag:man_made%3Dmast=next=795248 Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] mast / tower / communication_tower (again)
sent from a phone > On 30. Sep 2018, at 20:19, SelfishSeahorse wrote: > > a tower is accessible and provides > platforms, whereas a mast only offers ladder steps to climb it' [1] > and asked him where this definition comes from and what 'accessible' > exactly means (a ladder also provides access). while a ladder is clearly intended for access, there is a difference to a staircase or elevator, I guess you can also see it? I agree the wiki definitions / wording can be improved. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] mast / tower / communication_tower (again)
> only one in the Western Hemisphere, > I presume you're thinking of Toronto's CN Tower, but the Space Needle in Seattle though listed as an Observation Tower has a transmitter spike on top, so serves the same dual purposes as Fernsehturms in Germany, as TV transmitter and tourist trap. There are a goodly number of smaller hilltop closed, cylindrical concrete microwave towers in USA, with protected interior stairs, built initially for a survivable phone and classified networks, by AT and WHCA. Concrete, tower, for antennae. But no public observation gallery. -- Bill Ricker bill.n1...@gmail.com https://www.linkedin.com/in/n1vux ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] mast / tower / communication_tower (again)
On Sun, 30 Sep 2018 20:19:58 +0200 SelfishSeahorse wrote: > On Sun, 30 Sep 2018 at 19:34, Martin Koppenhoefer > wrote: > > > > > I think it's better to stick to either a common or a technical > > > definition. > > > > > > it doesn’t have to be the British definition of terms, has it? > > It would already be helpful if there actually were a common definition > to distinguish masts from towers. > > By the way, i've written a message to the person who added the > definition to the wiki that 'a tower is accessible and provides > platforms, whereas a mast only offers ladder steps to climb it' [1] > and asked him where this definition comes from and what 'accessible' > exactly means (a ladder also provides access). I suspect it comes from observing European-style radio towers (for example, Fernsehturm Berlin[1]). The confusion comes from the fact that these are virtually unknown outside of Europe and Asia -- there's only one in the Western Hemisphere, and none in Africa. [1]: https://en.wikipedia.org/wiki/Fernsehturm_Berlin -- Mark ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] mast / tower / communication_tower (again)
sent from a phone > On 1. Oct 2018, at 06:07, Mark Wagner wrote: > > I suspect it comes from observing European-style radio towers (for > example, Fernsehturm Berlin[1]). For the record: the mother of all these towers with a shaft in reinforced concrete is actually in Stuttgart: https://en.m.wikipedia.org/wiki/Fernsehturm_Stuttgart Cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Tagging a named river bend
Fine for me. Yves Le 30 septembre 2018 06:19:21 GMT+02:00, Dave Swarthout a écrit : >Correct. I will split the river way at either end of the bend and apply >the section tags to that piece only. The river continues to have its >own >name tag while the bend has only the tags needed to identify it as a >section with special characteristics, and also a name > >On Sun, Sep 30, 2018 at 10:33 AM Joseph Eisenberg < >joseph.eisenb...@gmail.com> wrote: > >> I think this is a good solution for your situation; tagging bends and >> reaches. It should work for other types of waterways too. >> >> I assume in this example you will be splitting the way >(waterway=river) at >> the beginning and end of the bend? So there are no overlapping or >duplicate >> ways. >> On Sun, Sep 30, 2018 at 11:28 AM Dave Swarthout > >> wrote: >> >>> Unfortunately, this topic has gotten split into two threads making >it >>> difficult to follow. In trying to summarize, let's not be overly >concerned >>> with rendering issues or whether this scheme can be fully modeled on >OSM. >>> We can deal with rapids, hazards, etc., using existing tagging or >develop >>> new tagging schemes later. That goes for discussions about using >relations >>> to model "overlaps". I'm trying to tag a river feature, a named bend >in the >>> waterway. Can we decide about the scenario we're currently working >with? >>> >>> This example uses the colon ":" as a separator for different parts >of the >>> keys rather than mixing it with the underscore character "_". >>> >>> > waterway=river >>> > name=Tanana River >>> > waterway:section=bend >>> > waterway:section:name=Harper Bend >>> >>> Pros and cons (subject to the limitations I mentioned)? >>> >>> On Sun, Sep 30, 2018 at 6:09 AM Joseph Eisenberg < >>> joseph.eisenb...@gmail.com> wrote: >>> Re: "I would not discard the idea of using some kind of relation >for this (type=route is not suitable, or is it?). It is the most >flexible way to tag as it allows for overlapping entities and avoids duplication >of ways." In theory, it would be great to be able to build up a long river >from many nested relations, but it doesn't seem to work now. Imagine a long river that passes through different language >regions, and therefore has a different name near the headwaters, in the middle, >and near the sea. Each short bend, reach, or rapid (in a whitewater river) >would be a way, perhaps 1/2 to 2km long. Then each named section of the >river would be made up of several of these ways. And the three long parts of >the waterway with a different name*(eg name:de= then name:fr= then >name:nl=, from mountains to sea) would be a relation made up of the shorter >relations. Unfortunately, because "super"-relations are not handled well in >the editors or any applications, this would be hard to maintain and >hard for database users. I actually tried doing this for a river in New >Guinea that changes names between mountains and lowlands, by making a >"super"-relation that continued a couple of sub-relations, but JOSM complains and it >doesn't seem to render. If we ever manage to add "area" as a database primitive, we should consider adding "multipolygon" as an area made up of constituent >polygons and ways, and "linestring" or something, as a longer way made up of >shorter ways, if such a thing is possible. (When I used to be able to edit roads on Google Maps, the API >seemed to be able to recognize that a short segment of a street was part of >the longer street, and suggested editing the whole longer way (or >relation?) when I would select the short segment. ) -Joseph On Sat, Sep 29, 2018 at 10:55 PM Martin Koppenhoefer < dieterdre...@gmail.com> wrote: > > > sent from a phone > > > On 28. Sep 2018, at 02:39, Dave Swarthout > > wrote: > > > > I keep coming back to Martin's place=river_bend. Adding a >name=Harper > Bend along with that tag would solve the problem in a >straightforward > manner, would not be confused with the specialized whitewater >tagging > schemes and would be relatively easy to implement. A look at >Taginfo tells > me that the "place" key has been misused quite a bit but I think > place=river_bend would be a logical and easily understood new use >of the > key. > > > this works best if you want to focus on the fact it is a bend. If >we > want something more generic like “section” that could maybe even >be applied > to named sections of other linear features like city walls / >walls, etc. > > I would not discard the idea of using some kind of relation for >this > (type=route is not suitable, or is it?). It is the most flexible >way to tag > as it allows for overlapping entities and avoids duplication of >ways. If > overlapping is not required, an
Re: [Tagging] My "weirdly unnatural aversion to relations"
On 30.09.2018 05:00, Bryan Housel wrote: > From my own perspective as the main developer on the main editor for > OSM, This is way too exaggerated. While iD is most visible, most data is created not by iD. And it is not always possible to advice novice user to use iD. For example iD only supports new "Russian water tagging scheme" (everything blue is natural=water), so if a country had made a decision to stick with original "standard OSM water scheme" (with landuse=reservoir|basin|etc waterway=riverbank) it is impossible to use iD as it does not support standard OSM water scheme. Note that Russian water scheme never reached the standard water scheme in popularity even with iD pushing for it. Same goes with "contact:*" scheme and probably a number of other tagging schemes. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] My "weirdly unnatural aversion to relations"
On Sunday 30 September 2018, Tomas Straupis wrote: > "Russian water > tagging scheme" (everything blue is natural=water) Note this is a completely wrong characterization of the water=* tagging scheme that is playing on nationalistic sentiments. You should not do that. water=river is not more popular among Russian mappers than it is in other parts of the world: https://taginfo.openstreetmap.org/tags/waterway=riverbank#map https://taginfo.openstreetmap.org/tags/water=river#map That ID through its presets for waterbodies - to put it in a friendly way - does not much support consistent differentiation of standing and flowing water is one thing - but this is not directly related to the different tagging schemes and it has nothing to do with anything Russian. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] My "weirdly unnatural aversion to relations"
2018-09-30, sk, 17:09 Christoph Hormann rašė: > Note this is a completely wrong characterization of the water=* tagging > scheme that is playing on nationalistic sentiments. You should not do > that. Sorry, had no intention to insult anybody. This alternative scheme _originated from Russia_ when standard water schema was already used all around in full toolchain - thus the name. -- Tomas ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] mast / tower / communication_tower (again)
On Sun, 30 Sep 2018 at 14:45, Martin Koppenhoefer wrote: > > > To solve the contradiction we need to get rid of one of the two definitions. > > they could be combined: if it is intended to be accessed by people (not only > for maintenance) and is not guyed it is a tower, otherwise it would be a mast. I think it's better to stick to either a common or a technical definition. OSM-specific definitions are prone to create confusion and tagging mistakes. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] mast / tower / communication_tower (again)
On Sun, 30 Sep 2018 at 03:13, Graeme Fitzpatrick wrote: > > https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmast says that > > "In structural engineering, mast is a vertical structure, supported by > external guys and anchors. > > This is the only existing definite feature that could be used to > differentiate masts and towers." > > but then shows an photo example of a "mast" with no guys. Thanks for pointing to that definition -- i wasn't aware of it. The confusion on the wiki seems to come from the fact that 'the terms "mast" and "tower" are often used interchangeably', as noted on Wikipedia: https://en.wikipedia.org/wiki/Radio_masts_and_towers#Mast_or_tower? That is, we have two contradictory definitions on the wiki: the engineering definition according to which a tower is freestanding and mast guyed, and the other definition according to which 'a tower is accessible and provides platforms, whereas a mast only offers ladder steps to climb it'. (Where does this latter definition come from?) To solve the contradiction we need to get rid of one of the two definitions. Regards Markus ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] mast / tower / communication_tower (again)
sent from a phone > On 30. Sep 2018, at 14:39, SelfishSeahorse wrote: > > To solve the contradiction we need to get rid of one of the two definitions. they could be combined: if it is intended to be accessed by people (not only for maintenance) and is not guyed it is a tower, otherwise it would be a mast. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] My "weirdly unnatural aversion to relations"
Hi, On 30.09.2018 05:00, Bryan Housel wrote: > From my own perspective as the main developer on the main editor for > OSM, ... fsvo "main editor" ;) > I’m willing to bet a black hat > could design and upload a relation that would destroy OSM.. Or at least, > crash every piece of software in the stack that we rely on: mapnik, > osmium, and any editor that tries to touch it. Relation 7066589 came close. (And no, you won't be able to access its history through the web site, it will time out.) See https://github.com/openstreetmap/osm2pgsql/issues/713 for background - osm2pgsql had to be patched as a result. > Anyway, I’m not totally against them, but every one of them is different > and I can't spend weeks or months supporting every kind of relation or > public transport schema people dream up unless it’s super critical for > building a useful map (like turn restrictions). The idea that turn restrictions are "super critical" but public transport relations are not is valid, but subjective; I hope that, as the ID editor matures, it will attract a healthy and diverse team of main developers so that decisions about what is important and what isn't are not a single person's any more! Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Traffic sign direction tagging..
On Sun, Sep 30, 2018 at 2:23 AM Graeme Fitzpatrick wrote: [relations] > > Maybe because people don't understand how to use them properly (I know I > don't?), so they're scared of them? > I thought I was the only one. :) Some very simple, easily found, instructions / guidelines would be handy. > I've only used a couple of types so far. You're right, the instructions are scattered around the different type of relation and so not easily found. They're also not (generally) written with the newbie in mind, so not easily understood. But the problem is that the different types of OSM relation, like your real-life relations, are all different, do different things and behave somewhat differently. What you're asking for is similar to the job interview question "Describe yourself in a single word" (my answer is "indescribable") except it's closer "Describe all your relatives in a single word" (my answer is "related"). Oh, and never forget that this is OSM. So you'll find one person saying that relations of type A, B and C are not only valid but also vital whilst any other type of relation is an abomination and another person saying types A, B and C are unnecessary abominations and all other types are valid and essential. For example, super relations solve several distinct problems and are, at the same time, an unnecessary abomination with no conceivable use cases (I thought of a nifty use for them that would be useful to me but they are so despised by so many people I'm scared of even mentioning it). Right now I can't think of a way of improving the documentation in the way you (and I) would like because the relation types differ so much. All that comes to mind is a page saying that "relations relate things" with a list of the different types and a one-line description. -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
