[Tagging] FYI: Change to destination details proposal: destination:sign was replaced by destination:symbol

Hi! I updated my proposal about additional destination details [1] and replaced the key destination:sign by destination:symbol, because the word "sign" seems to be too ambiguous. I'll update my tagging to reflect those change. Best regards, Martin [1] https://wiki.openstreetmap.org/wiki/Propose

Re: [Tagging] Feature proposal - Power transmission refinement - RFC 2

François Lacombe wrote: >I spent a little more time this week on the power transmission proposal. >https://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement > Finally, the two values minor_line and minor_cable, due to the arbitrary > voltage threshold which may be differ

Re: [Tagging] Feature proposal - Power transmission refinement - RFC 2

Hi Alv, I'm sorry this particular point disappoint you and be such a disagreement reason. Our views aren't the same regarding power line model and they do have been well explained on wiki and on this mailing list (and on the gravitystorm's github indeed). JOSM already asking you a voltage=* tag

Re: [Tagging] Track grades

On Tue, Jul 8, 2014 at 9:39 PM, Volker Schmidt wrote: > The combination of tracktype, surface and smoothness could fit the bill. You cannot expect that any renderer will be able to display all possible combinations of these three keys and dozen values. Or you map is unreadable. > However smoothn

Re: [Tagging] Track grades

> Am 09/lug/2014 um 12:08 schrieb Pieren : > > You cannot expect that any renderer will be able to display all > possible combinations of these three keys and dozen values. Or you map > is unreadable. you don't have to display every combination differently, you could have lists where you redu

Re: [Tagging] Track grades

2014-07-09 12:08 GMT+02:00 Pieren : > Forget the "smoothness" tag > please. We might replace it by the 4wd tag (but it's only a partial > solution) or another passable tag (for city car, 4wd, mtb, etc) > > I don't think smoothness should be forgotten, it should just have better values. Something l

Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag

On Wednesday 09 July 2014, Daniel Koć wrote: > [...] It's just my beginnings there, so > I'll wait some time before saying anything conclusive, but for now > I'm very surprised how the low hanging fruit can be not picked for so > long without anybody noticing it, even if all the code is already > w

Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag

Thanks for starting this discussion. Personally I think it makes sense to define different types of peaks in the data. It would solve the problem we have now, where tiny hillocks are rendered just like huge mountains. On 8 July 2014 15:14, SomeoneElse wrote: > The "Proposed_features" page seems c

Re: [Tagging] Track grades

On 09/07/2014 12:32, Janko Mihelic' wrote: 2014-07-09 12:08 GMT+02:00 Pieren >: Forget the "smoothness" tag please. We might replace it by the 4wd tag (but it's only a partial solution) or another passable tag (for city car, 4wd, mtb, etc) I don't think sm

[Tagging] tree shrines

Wayside shrines and crosses are quite common here in Austria, and probably in other parts of Europe too. They are mounted on posts (or pillars, walls...) made of various materials (wood, stone...), or on trees. When mounted on trees, I use a tag combination of historic=wayside_cross (or _shrine) wi

Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag

On 9 July 2014 00:05, Daniel Koć wrote: > W dniu 08.07.2014 20:04, yvecai napisał(a): >> However, if rendering is an interesting topic, wiki is full of >> rendering examples and advices that aren't followed anywhere. Let the > You don't even realize how sad is this observation for me... > > What

Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag

On 9 July 2014 02:56, Daniel Koć wrote: > but for now I'm very surprised how the > low hanging fruit can be not picked for so long without anybody noticing it, > even if all the code is already waiting to be merged ( > https://github.com/gravitystorm/openstreetmap-carto/issues/705 ). Two reasons.

[Tagging] Tagging-rendering relations

W dniu 09.07.2014 13:39, Christoph Hormann napisał(a): I can very much relate to that but this is not a matter that can be resolved easily. Everyone has things he/she likes to change in the Of course, but even open projects are not completely disconnected and we can try to find a good balanc

Re: [Tagging] Feature proposal - Power transmission refinement - RFC 2

On Jul 9, 2014, at 2:07 AM, François Lacombe wrote: > > JOSM already asking you a voltage=* tag on any power=* object. > > Which I, as a mapper more interested in roads and trails, ignore as I don't know what to put there and I'd rather have nothing than something that is wrong. Many of the

[Tagging] Tagging-rendering relations

W dniu 09.07.2014 14:01, Matthijs Melissen napisał(a): I think it's best to think of it as a two step process: first propose the tags that describe the reality (here), then propose how they should be rendered (on the openstreetmap-carto Github). Well, as I said: in my proposition I did _nothin

[Tagging] Tag for toilet with ostomate/stoma equipment

Hi, Please let me clarify how to be tagged toilets for "ostomate/stoma equipment" is settled. Here in Japan, some public toilets have such a equipment. http://ja.wikipedia.org/wiki/%E3%82%AA%E3%82%B9%E3%83%88%E3%83%A1%E3%82%A4%E3%83%88 I think it is better to be tagged like "wheelchair =[yes|no]

Re: [Tagging] Subsequent wikipedia links

I made some changes to the page Key:wikipedia on the wiki. Please review: http://wiki.openstreetmap.org/w/index.php?title=Key%3Awikipedia&diff=1060207&oldid=1041603 2014-07-01 19:58 GMT-03:00 Jo : > I've been experimenting with Wikidata a bit. I'm not a Wikipedian, rather > a convinced Openstree

Re: [Tagging] Subsequent wikipedia links

2014-07-09 16:37 GMT+02:00 John Packer : > I made some changes to the page Key:wikipedia on the wiki. > Please review: > http://wiki.openstreetmap.org/w/index.php?title=Key%3Awikipedia&diff=1060207&oldid=1041603 > your edit looks fine to me, besides that you removed the "url" reference. This is

Re: [Tagging] Feature proposal - Power transmission refinement - RFC 2

2014-07-09 15:40 GMT+02:00 Tod Fitch : > > > Which I, as a mapper more interested in roads and trails, ignore as I > don't know what to put there and I'd rather have nothing than something > that is wrong. > You're absolutely right. JOSM ask for voltage to encourage users to look for it. If they

Re: [Tagging] tree shrines

2014-07-09 14:02 GMT+02:00 Friedrich Volkmann : > I use a tag combination of historic=wayside_cross (or > _shrine) with natural=tree + species=* etc. and (if applicable) name=*. I > mapped a lot of these that way. > I think that this kind of mapping is not optimal, because you are mixing the tre

Re: [Tagging] Subsequent wikipedia links

I removed the link to the key url=* because it's own wiki page advises it shouldn't be used, so I figured there was no need to link it here. As far as I understood, although it might make sense to tag an URL in some cases, the meaning of this key is too generic, making it hard to be used by tools.

Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag

2014-07-09 13:39 GMT+02:00 Christoph Hormann : > In general a good tagging scheme should stand alone and not be designed > specifically for a certain rendering. To this aim it is quite good not > to have a too close connection between tagging and rendering. > +1. These are really two different

Re: [Tagging] Tagging-rendering relations

On Wednesday 09 July 2014, Daniel Koć wrote: > > > My opinion is that the best approach would be to establish better > > means for people to create variants of the style and present them > > to a broad audicence. This would have two effects - first it would > > allow changes > > That would be awes

Re: [Tagging] Subsequent wikipedia links

2014-07-09 16:57 GMT+02:00 John Packer : > I removed the link to the key url=* because it's own wiki page advises it > shouldn't be used, so I figured there was no need to link it here. > Thanks for pointing at this, I have amended this sentence to make more sense, please check: http://wiki.ope

[Tagging] Tagging-rendering relations

W dniu 09.07.2014 14:19, Matthijs Melissen napisał(a): Two reasons. First, we are trying to clean up current problems with the style sheet first, rather than adding new features. Also, development of the stylesheet has been put on hold for like four Ok, I get it. =} It explains a lot, thanks!

Re: [Tagging] Rendering change: buildings within highway areas

We get increasing feedbacks on my local list that the new rendering rule is counter-intuitive (to not say that it is considered as a bug). Now roads are rendered on top of buildings even when roads are really under buildings or underground (tunnels). Why not when your primary interest is for roads,

Re: [Tagging] Tagging-rendering relations

On 9 July 2014 16:24, Daniel Koć wrote: > W dniu 09.07.2014 14:19, Matthijs Melissen napisał(a): > So - what about making the testing map and adding there all the already > documented features for the start? Maybe we should discuss it elsewhere, > because we're far from the tagging: what is a bett

Re: [Tagging] Rendering change: buildings within highway areas

On 9 July 2014 16:29, Pieren wrote: > We get increasing feedbacks on my local list that the new rendering > rule is counter-intuitive (to not say that it is considered as a bug). > Now roads are rendered on top of buildings even when roads are really > under buildings or underground (tunnels). Why

Re: [Tagging] Tagging-rendering relations

2014-07-09 17:24 GMT+02:00 Daniel Koć : > I think "shop=*" key should be always rendered - HOT has nice basket icon > for that. What makes some types of shops better than the others? the idea to use a whitelist is to avoid rendering objects with syntax errors in the tags, because this gives the

Re: [Tagging] Rendering change: buildings within highway areas

Am 09.07.2014 17:29, schrieb Pieren: > We get increasing feedbacks on my local list that the new rendering > rule is counter-intuitive (to not say that it is considered as a bug). > Now roads are rendered on top of buildings even when roads are really > under buildings or underground (tunnels). Why

Re: [Tagging] Tagging-rendering relations

On 9 July 2014 16:57, Martin Koppenhoefer wrote: > the idea to use a whitelist is to avoid rendering objects with syntax errors > in the tags, because this gives the mappers feedback that there is indeed a > problem if something is not rendered... That said, we are planning to render far more sho

Re: [Tagging] Rendering change: buildings within highway areas

MapQuest Open seems to have a good compromise in this case--the tunnel is rendered above the buildings, but is partly transparent (to allow the user to see other features) and has more prominent dashed casing (to indicate it is below-ground). On Wed, Jul 9, 2014 at 10:56 AM, Matthijs Melissen wr

Re: [Tagging] Tagging-rendering relations

W dniu 09.07.2014 16:56, Christoph Hormann napisał(a): This would still require significant additional ressources including the workload of managing two separate styles. I don't think testing is the In my vision testing would be not very much different, but include all the standard tags we

Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag

W dniu 09.07.2014 17:01, Martin Koppenhoefer napisał(a): +1. These are really two different aspects, because the tagging has the aim to give a short, detailed, precise, specific description of something (and so allows distinction from something different). And then sometimes you end up with re

Re: [Tagging] Feature Proposal - RFC - Enhancing natural=peak tag

2014-07-09 18:51 GMT+02:00 Daniel Koć : > And then sometimes you end up with rendering problem because of lack of > enough distinction in the tagging (they are by your definition not what > they really should be), and what than? I would get back to tagging studio > and think if this visual distinc

Re: [Tagging] Tagging-rendering relations

On 09/07/2014 16:39, Matthijs Melissen wrote: On 9 July 2014 16:24, Daniel Koć wrote: W dniu 09.07.2014 14:19, Matthijs Melissen napisał(a): So - what about making the testing map and adding there all the already documented features for the start? Maybe we should discuss it elsewhere, because w

Re: [Tagging] Tagging-rendering relations

2014-07-09 18:24 GMT+02:00 Daniel Koć : > You will always fall in the trap of localities when working on a global > level, there's no escape - sorry... And which mapper? Our polish team wants > to go mapping to Kazakhstan and what they see as under-track by our > standards is the best road one can

Re: [Tagging] tree shrines

I suppose you were in contact with Lutz. Our policy is to render what's mapped and in that be quick to market. If there's a tagging found sufficiently often it is considered for inclusion in the historic map. The wiki page "map features" describes what kind of tagging is depicted in OUR map. It

[Tagging] RFC: Proposed Node Relation

I have proposed the node relation, a concept that I was missing for some time now. Have a look here: https://wiki.openstreetmap.org/wiki/Relations/Proposed/Node cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetma

Re: [Tagging] tree shrines

In the US, most of these sort of things are markers where people died in accidents. Wikipedia calls them "roadside memorials" ( https://en.wikipedia.org/wiki/Roadside_memorial), and I guess that might be the most common term in the US. "Shrine", to my ears, has a different, more specifically relig

Re: [Tagging] tree shrines

> In the US, most of *these* sort of things are markers where people died > in accidents. Wikipedia calls them "roadside memorials" ( > https://en.wikipedia.org/wiki/Roadside_memorial), and I guess that might > be the most common term in the US. To clarify, by "these", you mean historic=wayside_cr

Re: [Tagging] Feature proposal - Power transmission refinement - RFC 2

On 09/07/2014 09:44, Kytömaa Lauri wrote: Calling it "replacement" doesn't mean it's not "deprecation". The proposal is still trying to deprecate power=minor_line, and to remove the simple physical distinction between "really big thing on big pylons" vs. smaller overhead lines that you can often

[Tagging] Rendering for mappers

W dniu 09.07.2014 19:08, SomeoneElse napisał(a): Historically, the "standard" style was a "for mappers" style - it was designed to show features that mappers had mapped. That has been changing (largely without community involvement or review). I tried That is exactly what I would expect! The

Re: [Tagging] Rendering for mappers

> > MapQuest Open is the only map style I never truly understood - it's a > general purpose map, while others have their purpose stated clear in the > name. What were the reason behind taking it on board, does anybody know? MapQuest matches the prerequisites to be a feature tile on OSM homepage [1

Re: [Tagging] Rendering for mappers

W dniu 09.07.2014 22:03, John Packer napisał(a): MapQuest matches the prerequisites to be a feature tile on OSM homepage [1]. OpenSeaMap matches them even better, so it's still not clear to me why MQ was selected and OSeaM was not. A similar discussion recently started on the _talk_ mailin

Re: [Tagging] tree shrines

On Wed, Jul 9, 2014 at 12:52 PM, John Packer wrote: > To clarify, by "these", you mean historic=wayside_cross, correct? > Or does historic=tree_shrine has the same meaning? > I would suspect so - this is consistent with my area as well, where these features are called "descansos" (a Spanish word

Re: [Tagging] Feature proposal - Power transmission refinement - RFC 2

On Wed, Jul 9, 2014 at 1:30 PM, Ole Nielsen wrote: > 1) This proposal requires a voltage tag to distinguish "big" and "small" > power lines. If mappers don't add a voltage tag then it's probably because > they don't know the voltage and this information is often difficult to get > hand on. Howeve

Re: [Tagging] tree shrines

What Jesse said. :) Including that they're often relatively temporary. That might explain why there are so few in the US compared to Europe? I'd seen this discussion before and thought it was kind of obscure, then just looked at taginfo and was surprised by how many there are--wow! I'd seen many

Re: [Tagging] Feature proposal - Power transmission refinement - RFC 2

If really you insist to have an indication for "minor", we can introduce line:type=minor/major but I definitely recommend to get this out of the primary tag. Ok ? *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com _

Re: [Tagging] Rendering for mappers

I think the problem with Openseamap is that they have two layers of tiles, one standard layer which they take from openstreetmap servers: http://b.tile.openstreetmap.org/15/17484/10492.png and one over it, with all the symbols: http://tiles.openseamap.org/seamark/15/17484/10492.png 2014-07-09

Re: [Tagging] RFC: Proposed Node Relation

Should there be a relation with type=way? For when you need a way that is not an area over an existing way. Example would be a fence that is put on a wall. Janko Dana 9. 7. 2014. 19:47 osoba "Martin Koppenhoefer" napisala je: > I have proposed the node relation, a concept that I was missing for

Re: [Tagging] RFC: Proposed Node Relation

> Am 09/lug/2014 um 23:49 schrieb Janko Mihelić : > > Should there be a relation with type=way? For when you need a way that is not > an area over an existing way. Example would be a fence that is put on a wall. I think yes ___ Tagging mailing list

Re: [Tagging] tree shrines

I think the OP meant something like this: http://xian.smugmug.com/OSM/OSM-2014/20140608-Mol-Geel-vanaf-Sas-VI/i-zmPkm4P/A or this http://xian.smugmug.com/OSM/OSM-2014/20140528-Rumst/i-KwGzNXX/A regards m On Wed, Jul 9, 2014 at 10:34 PM, Brad Neuhauser wrote: > What Jesse said. :) Including