Re: [Tagging] Proposal: logo tag. Opinions?

On 19.09.2017 16:27, José G Moya Y. wrote: > It's up to > the rendering app creators to decide if they want to display some shops > using its logos. In that case, the app would probably have some other > way to display them. What way would that be? Unless we want each render style author to maint

Re: [Tagging] Proposal: "slogan" tag. Opinions?

On 19.09.2017 09:46, SwiftFast wrote: > Imagine an app where you'd click a shop, then you'd get a popup with a > logo(see my other proposal), a slogan, and a description. All of these > help a user understand what they're looking it. While I accept the argument that logos allow easy visual identif

Re: [Tagging] Feature Proposals - RFC for multiple features - Education Reform - Magnetic Levitation Trains

On 17.09.2017 07:54, Erkin Alp Güney wrote: > This brings education key instead of amenity=school. In my opinion, and speaking broadly, the job of the OSM tagging system is to answer two questions: - What kind of feature is this? - What properties does this feature have? The first question can u

Re: [Tagging] contact:* for review websites

On 16.09.2017 00:56, Tom Pfeifer wrote: > IMHO these are not means of contact, instead these are review websites. > While I personally think that we do not need them in OSM at all, they > certainly do not belong in the contact:* namespace. I agree that these aren't contact channels, and it makes n

Re: [Tagging] Simplify building:part areas

On 18.08.2017 10:01, Tom Pfeifer wrote: > If e.g. the lower floors of the apartment building is wider than the > upper floors, you can tag the outline with both, building=apartments and > building:part=yes and the appropriate 3D-properties, and the narrower > upper floors with building:part=yes and

Re: [Tagging] Formally informal sidewalks

On 15.07.2017 19:06, Nick Bolten wrote: [...] > It can't properly describe > crossings, since they've been condensed into a node, but important > information like length, the curbs at each side (direction of > traversal + curb type both matter), APS directionality, etc, are all > essentially linear

Re: [Tagging] Time is now: tag ALL traffic signs in OSM

On 21.05.2017 22:23, yo paseopor wrote: > As you can see in http://imgur.com/gallery/SgE90 with Kendzi3D JOSM > plugin you can locate the traffic signs belonging to a way. Of course it's always possible to guess a place next to the road, but even with your proposed side=* tagging, that's not nearl

Re: [Tagging] Time is now: tag ALL traffic signs in OSM

On 21.05.2017 14:05, Colin Smale wrote: > So, in simple language, WHY do we put traffic signs into > OSM? The use case I'm interested in is having the location of the physical object available, e.g. for 3D rendering. This is also why I'm in favour of placing signs in their actual on-the-ground loc

Re: [Tagging] wikipedia links and copy + paste in tag definitions

On 29.04.2017 22:26, Martin Koppenhoefer wrote: > Don't link to WP, especially not in the beginning (as if their definition > automatically was equal to ours), because even if the current state is fine, > we don't control WP and don't know how they will structure their lemmas in > the future. T

[Tagging] Advertising redefinitions in the wiki (was: Re: message=*)

On 06.04.2017 13:36, Martin Koppenhoefer wrote: indeed, the original proposal had no mention of "size" This is only the tip of the iceberg. In fact, pretty much all advertising-related pages have undergone broad changes compared to what was originally proposed. A while ago, I raised the issue

Re: [Tagging] Feature Proposal - RFC - bus bay

On 06.04.2017 19:40, Martin Koppenhoefer wrote: why do you define this as a node? bus_bay=right or left does not make sense on a node, and bus bays have a certain length anyway, I'd make it a way. It should not be a separate way if there is no physical separation. But I agree a node is not a g

Re: [Tagging] simple 3D buildings, proposed redefinition of building:levels and building:min_level for building:part

On 08.03.2017 18:32, Martin Koppenhoefer wrote: building:levels - building:min_level < 0 yes: new no: old I believe you are mistaken here. Consider the following example: building:levels = 2 building:min_level = 1 According to the Simple 3D Buildings standard, this means that there is a buil

Re: [Tagging] how to map simple buildings

On 04.03.2017 18:05, "Christian Müller" wrote: Thanks for the examples and conclusion given. This is a strong reason to demand its usage in wiki docs and IMO we should even suggest their usage generally, regardless of the construction site's complexity. Situations complex enough to require typ

Re: [Tagging] how to map simple buildings

On 02.03.2017 17:19, Martin Koppenhoefer wrote: do I understand you correctly, we use 1 way (or multipolygon) for every building:part plus 1 multipolygon relation with building=* as a fallback plus 1 type=building relation for every single building? We use one area for every building:part, plus

Re: [Tagging] Invalid voting of proposed feature motorcycle_friendly=*

Hi Michael, On 02.03.2017 20:21, Michael Reichert wrote: Because the proposal violated the guideline, I would like to - remove the status "proposed" from its feature documentation page - reset the status of the proposal to "RFC" - to declare the voting as invalid by adding a note at the top of t

Re: [Tagging] Feature Proposal - RFC - CoreIndoor

Hello Pavel, On 08.02.2017 09:09, Pavel Zbytovský wrote: https://wiki.openstreetmap.org/wiki/Proposed_features/CoreIndoor as one of the authors of Simple Indoor Tagging (SIT), I'd like to comment on each of your proposed changes. So please excuse the wall of text below. :) First, thank you

Re: [Tagging] lit=yes, but with luminous discs built into the path

On 17.09.2016 23:07, Warin wrote: lit=yes lit:intensity=dim/ambient/day_light lit:type=led/halogon lit:layer=0/1/2 Before you invent a detailed tagging schema from scratch, consider basing this on the light_source schema instead: http://wiki.openstreetmap.org/wiki/Proposed_features/Key:light

Re: [Tagging] tunnel=building_passage or covered=yes

On 11.09.2016 12:46, Dave F wrote: But it's *not a tunnel* Before there was any dedicated tag for it, many people mapped it as tunnel=yes, so people definitely appear to intuitively consider it tunnel-like. (Perhaps that's also a language issue, not sure.) That's why the new value was also

Re: [Tagging] steps parallel to escalator

Hi Bjoern, On 02.07.2016 10:14, Bjoern Hassler wrote: Would you be able to give me an example for the use of the tag? Say for steps running in parallel with two escalators (running up/down)? you didn't mention the exact arrangement of the escalators, so I'm going to assume two escalators (on

Re: [Tagging] steps parallel to escalator

On 01.07.2016 20:02, Michael Reichert wrote: Am 01.07.2016 um 19:30 schrieb Bjoern Hassler: Yes, you draw to parallel ways. One way gets conveying=yes, the other one not (or conveying=no). As the co-author of the conveying proposal, I'd like to offer an alternative here. The proposal already m

Re: [Tagging] sloped_curb, kerb and god knows what left in limbo ......

On 02.03.2016 17:42, Simon Poole wrote: > While the abandoned proposal seems to be more complete and I can't > say anything about the other variant because of the lacking > documentation, I don't really care either way, it would simply > make easier if we could come to some consensus on what the

Re: [Tagging] natural=wood status=approved?

Am 07.02.2016 19:03, schrieb Martin Koppenhoefer: > I'm not very familiar with how the proposed templates work (which ones are > actually in use) but it doesn't seem as if defacto was a valid status now: > http://wiki.openstreetmap.org/w/index.php?title=Template:Proposal_Status The status "defac

Re: [Tagging] natural=wood status=approved?

Am 07.02.2016 09:20, schrieb Martin Koppenhoefer: > in this particular case I'd say that setting the wiki docu to approved seems > consistent with the atual usage reality. The "approved" setting isn't about usage reality, though, but about the proposal process. As this tag has, as far as I know,

Re: [Tagging] Sidewalk Tagging for Routing

On 24.11.2015 17:21, Clifford Snow wrote: > Thanks everyone for the input. As much as I like the concept of using > the sidewalk attribute to the road, it doesn't seem like it is all that > useful for adding kerb slope. Sure, but the sidewalk attribute is essential for other, much more basic use c

Re: [Tagging] RFC - Level:ref=*

On 14.11.2015 07:17, johnw wrote: > http://wiki.openstreetmap.org/wiki/Proposed_features/level:ref Thanks for the proposal! One question though: What's the rationale for calling it level:ref, rather than level:name? ___ Tagging mailing list Tagging@op

Re: [Tagging] Xxzme edit of wiki proposed features page voting

On 19.09.2015 08:32, Warin wrote: > Category:Proposed_features_ "Voting" > to > Category:Proposals with "Voting" status > > not a large change but ... where is there any though to others? After > his past history I would have though some consultation would be a the > first step, rather than just d

Re: [Tagging] large roof garden

On 14.09.2015 23:17, Richard wrote: > if it has an assigned level=* as part of the building than that would > be better than location=rooftop. Or maybe both together. Both together would also be an option. The thing is, I expect this to be commonly mapped independently from the indoor environment,

Re: [Tagging] large roof garden

On 13.09.2015 14:16, Volker Schmidt wrote: > How does one correctly map a roof garden (or better: roof park) like this: > https://www.openstreetmap.org/way/303934391 It has been suggested to use the location=roof or location=rooftop tags to map things that are on top of a roof. Mapping a rooftop

[Tagging] Feature Proposal - RFC - Street area

On behalf of the proposal author, I would like to introduce you to the following proposal, which intends to formalize the area:highway tag: http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area The idea to use areas tagged as area:highway in addition to the highway way is almost 5 year

Re: [Tagging] Sidewalk=none vs sidewalk=no

On 11.08.2015 19:13, Clifford Snow wrote: > Personally I prefer sidewalk=none. No implies not allowed That's not at all the case, as evidenced by the use of "no" or "yes" with keys such as cycleway, building:part, and flags like button_operated, segregated, lit, tactile_paving, the recycling keys

[Tagging] Feature Proposal - RFC - Paving stone details

Hi all, my new proposal introduces some subtags for surface=paving_stones. This will hopefully allow mappers who are interested in the topic to add more detail to the relatively broad "paving stones" category, without affecting applications which don't need such detailed information. For the full

Re: [Tagging] symmetrical guardrails

On 11.07.2015 11:33, Joachim wrote: > Just draw a closed way. This also represents the reality since there > are two rails. But no two set of posts etc., which would be assumed with your mapping. I think two_sided=yes would work well: http://taginfo.openstreetmap.org/keys/two_sided _

Re: [Tagging] Feature Proposal - RFC - reception_point

On 24.06.2015 10:56, Warin wrote > There were a significant number against 'desk' (4 voice concerns > over 'desk'). My impression was that people didn't object the word 'desk' so much (although some did), but instead the concept of mapping _only_ the desk. As far as I am concerned, drawing an ar

Re: [Tagging] Future of categories

On 26.05.2015 20:06, Janko Mihelić wrote: > I think we need a separate instalation of wikibase on our wiki. A wikibase installation on wiki.osm.org would be really useful, in many different ways. ___ Tagging mailing list Tagging@openstreetmap.org https

Re: [Tagging] surface=brick -> surface=bricks?

On 11.05.2015 22:40, Mateusz Konieczny wrote: > Is there any good reason to avoid changing existing surface=brick to > surface=bricks? Considering the existence of building:material=brick (documented, 100'000 uses), it would be odd if surface used the plural. _

Re: [Tagging] How to model sidewalks, crossings and kerbs with respect to routing applications?

On 07.05.2015 20:49, Clifford Snow wrote: > Like sidewalks, kerbs could be assigned to the road as in > both/right/left/none. But that doesn't solve the problem of crosswalks. > Since crosswalks are nodes, it is impossible to tag one side as > wheelchair accessible while the other side isn't. For

Re: [Tagging] How to model sidewalks, crossings and kerbs with respect to routing applications?

On 07.05.2015 21:11, wrote Andrew Guertin: > On 05/07/2015 12:52 PM, Philip Barnes wrote: >> I still favour tagging the road with sidewalk tags, unless the sidewalk >> is physically separate from the road. Otherwise you are limited to >> crossing at defined points. +1 > Many people ARE limited to

Re: [Tagging] AE and BE orthography in tagging

On 27.04.2015 13:58, Matthijs Melissen wrote: > Note that shop=jewelry is not the only US English term we use. Afaik, the rule is not about terms, but about spelling. With terms there is no issue memorizing either one, it's spelling that can trip a mapper up despite familiarity with the tag.

Re: [Tagging] Way inside riverbank

On 23.04.2015 10:01, Christoph Hormann wrote: > Nobody should feel bad about not being able to accurately place the > waterway at the right location in some cases but the aim to do this > where possible is a sound one. Sure, but the page currently states that the waterway=river "must" be placed

Re: [Tagging] Way inside riverbank

On 13.04.2015 15:06, Torstein Ingebrigtsen Bø wrote: > I'm currently importing topological data of Norway to OSM. From the data > set we have riverbanks; however, we do not have the deepest middle way > as required by the wiki [1]. As the deepest middle way is hard to identify for regular mappers,

Re: [Tagging] inuse, defacto

On 18.04.2015 09:31, Friedrich Volkmann wrote: > So far we have 3 parameters: number of OSM objects, number of real-word > objects, number of users. Let's put them into a formula in order to enable > objective decisions and avoid edit wars. I don't think it's as easy as that. Other things to consi

Re: [Tagging] Straw pole Temperature=objective default unit?

On 09.04.2015 02:52, Warin wrote: > c) No default unit. All entries would require a declaration of the units > used. Thus this would be an incorrect entry and ignored. This is my clear favourite. If providing a default is favoured by the majority, then I won't insist on this further. However, mak

Re: [Tagging] Proposal: Rename wiki status "Approved" to "Published"

On 03.04.2015 11:22, Bryce Nesbitt wrote: > The proposal on the table is to change the wiki status of "Approved" to > read "Published" I would prefer to stay with "approved". Using "published" would not actually make things clearer, quite the opposite: Using the normal meaning of "published", a pr

Re: [Tagging] foreign siren:range format

On 01.04.2015 23:04, wrote Johannes: > Should the format of siren:range link a "apply the format of the > width tag"? Alternatively, you could reference the length/distance unit conventions on http://wiki.openstreetmap.org/wiki/Map_Features/Units ___ Ta

Re: [Tagging] New Key:indoor wiki page

On 24.03.2015 05:23, Bryce Nesbitt wrote: > Tagging list folks may wish to track or comment on: > http://wiki.openstreetmap.org/wiki/Key:indoor In my opinion, documenting a single indoor-related tag without a complete indoor tagging schema makes no sense. We should wait until a complete solution,

Re: [Tagging] Accepted or rejected?

On 17.03.2015 15:04, Kotya Karapetyan wrote: > I propose to clarify it by changing the recommended number of votes > in https://wiki.openstreetmap.org/wiki/Proposed_features#Approved_or_rejected > from ".../8 unanimous approval votes/ /or //15 total votes with a > majority approval.../" > to "/...8

Re: [Tagging] Draft Proposed Relationship Area Steps

On 05.03.2015 00:54, Warin wrote: > https://wiki.openstreetmap.org/wiki/Relation/Proposed/Area-steps First, let me thank you for putting some effort into this long-dormant topic. I fully agree that area steps are a necessary addition. My impression from previous discussions of the topic was that

Re: [Tagging] paving_stones:n

On 04.03.2015 02:45, Bryce Nesbitt wrote: > Please retag indeed! > > paving_stones:size=20cm I agree that we should use a subtag instead of adding this kind of rarely-used information to the surface value. However, I would prefer to use paving_stones:width (as it is unclear what dimension "size"

Re: [Tagging] tagging very wide steps - highway=steps on an area?

On 01.03.2015 23:26, Warin wrote: > I have edited the wiki to better reflect the situation. I have also > changed the order ... Thank you! :) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging very wide steps - highway=steps on an area?

On 28.02.2015 05:44, Warin wrote: > Within OSM .. I've checked > http://wiki.openstreetmap.org/wiki/Key:incline - that sets a 'standard' > for the incline direction. > > I'm tempted to simply add the information to the wiki for steps. The > past discussion on this topic is from years ago. I'll th

Re: [Tagging] Breakdown bays?

On 27.02.2015 18:38, Jo wrote: > I can't help but keep hoping that a way to tag bus bays emerges as a > side product of this discussion. At the moment I'm resorting to drawing > the platform way, the cycleway or the landuse around them, but there are > cases where the cycleway goes straight through

Re: [Tagging] bridge=movable?

On 27.02.2015 13:05, Dave F. wrote: > What's the purpose of bridge=movable? > > http://wiki.openstreetmap.org/wiki/Key:bridge:movable > > It's good that the different types of bridge are tagged & the graphics > are excellent, but I'm unsure why they need to be separated to a sub tag. For many ap

Re: [Tagging] Canopy radius for natural=tree

On 23.02.2015 19:09, althio wrote: > I will suggest you look into: > 145 135 diameter_crown > =* With only 30 users, that's almost certainly an import. So we should not let this dictate our tag choice if there are reasons to choose a different

Re: [Tagging] maxwidth vs. maxwidth:physical vs. width

On 18.02.2015 10:39, moltonel 3x Combo wrote: > Allow me to disagree: > > * maxheight is defined this way. Having maxwidth defined differently > is asking for trouble. I agree with you that we should define all the max* keys in the same way. But it would actually make much more sense to achieve t

Re: [Tagging] building=yes on nodes?

On 14.02.2015 22:11, SomeoneElse wrote: > ... it also says that it shouldn't be used on relations, which would > exclude perfectly valid multipolygons, such as this one: Multipolygons are a means to map areas. So they are covered by the area icon. The relation icon stands for relations that are n

Re: [Tagging] building=yes on nodes?

On 14.02.2015 12:23, Tom Pfeifer wrote: > I see nothing wrong with building=* on a node, used 772612 times. Which is still only 0.006 of all buildings. Personally, I don't think building nodes are really useful. They are little more than a formalized note, as most applications using buildings wil

Re: [Tagging] Feature Proposal - Voting - traffic_signals (Lukas Schaus)

On 09.02.2015 15:31, Lukas Schaus wrote: > My proposal concerning the modelling of traffic signals is now open for > voting. Oh dear. I had hoped to discuss the mapping of physical traffic signal locations with you before the vote. I was not aware that you had planned to vote after just 1 week of

Re: [Tagging] courtyards

On 08.02.2015 15:47, wrote Martin Koppenhoefer: > I am not in favour of place (neither locality nor courtyard), maybe > building:part=courtyard would be a good tag semantic wise No, it definitely wouldn't. The building:part key has a clear definition e.g. in the context of 3D rendering that does

Re: [Tagging] Feature Proposal - RFC - Reception Desk

On 06.02.2015 12:16, Dan S wrote: > However it occurs to me that it would be useful to have some way of > indicating _what_ it is the reception for. For example, if it was part > of a "site" relation*, then a role like role=reception would connect > it to the larger entity in a meaningful way. That

Re: [Tagging] Lifecycle concepts, "REMOVED"

On 30.01.2015 17:17, sly (sylvain letuffe) wrote: > The goal was to describe an allready in use practice about the removed: > prefix which I thought defered from the destroyed: prefix which was intended > for features that once were, but were destroyed, while the removed: prefix > is a more generic

Re: [Tagging] Deprecation of associatedStreet-relations

On 24.01.2015 13:12, moltonel 3x Combo wrote: > Recomended isn't mandatory. The name tag of associatedStreet is only > of use to mappers (to find the relation in the editor), not consumers. Not mandatory, but still used in 93.20% of relations. So ignoring the relation is not practically feasible.

Re: [Tagging] Deprecation of associatedStreet-relations

On 23.01.2015 21:53, moltonel 3x Combo wrote: > The counter-argument is that a novice is less likely to break the data > when updating an area that is mapped using associatedStreet. I like > the fact the fact that people need not even be aware of addresses in > order to fix a street name. That's n

Re: [Tagging] Overhead signs (Überkopfwegweiser)

On 16.01.2015 10:19, Andreas Labres wrote: > I'd like to suggest an idea to map overhead signposts > ("Überkopfwegweiser" in German) That's a good idea, I would like to see a possibility to map these! > Of course this should match the information given in any lane tags, > but it gives the exact p

Re: [Tagging] Feature Proposal - RFC - Cluster

On 15.01.2015 02:02, Friedrich Volkmann wrote: > http://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster > > This is for grouping features that are more or less of the same kind. See > examples. I feel this is far too generic. Imagine a renderer which wants to show names of lakes at zoom 12

Re: [Tagging] Various alt_name values?

On 23.11.2014 19:46, Zecke wrote: > Am 23.11.2014 18:20, schrieb Lukas Sommer: >> Would a feature proposal be a good way to get there? > No need to do so. The semi-colon is the accepted way to separate multi > values in cases where there's no other scheme defined. > http://wiki.openstreetmap.org/wi

Re: [Tagging] pipeline flow direction; was: Feature Proposal - RFC - Pipeline Extensions

On 17.11.2014 22:33, Rainer Fügenstein wrote: > MK> +1, also this way you give information about the direction of flow > relative > MK> to the osm way, while flow_direction=oneway doesn't imply any specific > MK> direction, it only states that the direction is not reversible. > > proposal updated

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

On 12.11.2014 10:34, Pieren wrote: > On Tue, Nov 11, 2014 at 11:22 PM, johnw wrote: >> 2014-11-11 12:53 GMT+01:00 Tobias Knerr : > >>> Therefore, would prefer a generic tag that can be added to any feature, >>> e.g. location=rooftop. > > -1 > 'loc

Re: [Tagging] Rooftop parking -> new parking=rooftop value?

On 11.11.2014 06:38, johnw wrote: > I assume there is a need to create a new parking=rooftop or similar tag, > which can then be used to create more accurate renderers (perhaps by also > placing the parking=rooftop tag onto the service=parking isle service roads, > so they are similarly (translu

Re: [Tagging] Feature Proposal - RFC - Water tap

On 10.10.2014 19:05, Kotya Karapetyan wrote: > I would hereby like to propose a new value for the man_made tag: > > man_made=water_tap > > The proposal page is: > http://wiki.openstreetmap.org/wiki/Proposed_features/water_tap My question: Why man_made? All the other water-related things are amen

Re: [Tagging] University accommodation (was Re: Future proposal - RFC - amenity=dormitory)

On 19.09.2014 14:22 Dan S wrote: > for buildings: building=residential + residential=university + operator=* > OR > for sites: landuse=residential + residential=university + operator=* > > Note that the same scheme seems to me to work well for building and for > landuse. > > I thou

Re: [Tagging] key:destination Signpost question

On 29.08.2014 21:16, Paul Johnson wrote: > Destinations are supposed to be relations, and the members are pretty > clear. http://wiki.openstreetmap.org/wiki/Relation:destination_sign#Members I believe Kristen was talking about Key:destination, which is what should replace exit_to. There are no re

Re: [Tagging] Unification of google-plus links

On 29.08.2014 20:09, Andreas Neumann wrote: > I don't want to change the addr:-, website-, phone-, fax- or > email-key!!! I never said it. But we have to look at these to decide whether it's better to move towards the contact namespace as a whole or move away from it. It makes little sense to move

Re: [Tagging] Contact-Tag for Webcam

On 27.08.2014 04:14, Martin Koppenhoefer wrote: > Agreed, but the tag prefix in discussion here is "contact", to be used for > channels/means to contact the feature, while a webcam is working the other > way round, it communicates from the feature to the audience. I agree that "contact" does not

Re: [Tagging] Forest vs Wood

On 20.08.2014 20:30, Matthijs Melissen wrote: > On 20 August 2014 19:24, Tobias Knerr wrote: >> 3. This distinction feels unusual for people in countries where >> traditional maps use other factors to distinguish different wood >> signatures, e.g. broadleaved/needleleaved.

Re: [Tagging] Forest vs Wood

On 20.08.2014 19:45, Rob Nickerson wrote: > Wood: Woodland with no forestry > Forest: Managed woodland or woodland plantation. > > In my eyes this is pretty clear. What am I missing / why does there seem > to be so much confusion? I believe some reasons why this topic comes up repeatedly are: 1.

Re: [Tagging] changing wiki , changing definitions

On 19.08.2014 09:04, Pee Wee wrote: > Sure I could send an email to the person that changed this but what do > you think is the best way to deal with this changing wiki pages? Or > should I just accept that these things happen and change it back and > send an email? If someone changes the meaning

Re: [Tagging] Commons: mixed purposes

On 18.08.2014 23:57, Andy Mabbett wrote: > Is there significant opposition, that means this might not be used? The key itself is probably relatively uncontroversial, but the details need some discussion. For example, I consider it problematic to duplicate the functionality of the image key by all

Re: [Tagging] problem with bicycle=designated

On 18.08.2014 15:33, Mateusz Konieczny wrote: > For example according to > http://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated > bicycle=designated may be tagged > on "suggested route", in general conditions are unclear and really > inclusive. I believe that part of the "designated" wiki pa

Re: [Tagging] To: "Tag discussion, strategy and related tools"

On 16.08.2014 17:50, Martin Koppenhoefer wrote: > >> Il giorno 15/ago/2014, alle ore 23:52, St Niklaas ha >> scritto: >> >> I would go for building=bridge, since a bridge is a building > > actually a bridge isn't a building according to standard terminology, it is a > structure. But since in o

Re: [Tagging] Mapping cave tunnels passable by human

On 14.08.2014 12:47, Dan S wrote: > Well, no-one ever supports "new" tagging, the question is if it's > needed. But I agree, I can't see a benefit keeping it separate. Are you suggesting that there are no relevant differences between a man-made tunnel and a cave? I can think of a lot – naturally f

Re: [Tagging] bridge movable vs swing vs swinging

On 08.08.2014 11:35, Richard Z. wrote: > My idea was > * abandon bridge=swing in favor of bridge=movable which could provide > subtyping if someone really needed it. We already have an approved proposal that provides this subtyping: http://wiki.openstreetmap.org/wiki/Proposed_features/Bridge_t

Re: [Tagging] Climbing access path

On 08.08.2014 12:07, Tom Pfeifer wrote: >>>access=destination >>>destination=climbing > > Just to reinforce the opinion, "access=destination" forbids through > traffic, > in this case general hikers taking a short cut. This is what we want, > and using > an established tag for this purpose

Re: [Tagging] Climbing access path

On 07.08.2014 09:51, k4r573n wrote: > I would like to distinguish between hiking paths and climbing_access paths. > In my area only climbers are allowed to use the paths to access the cliffs. > > Therefore I thought of this tagging for climbing_access paths: > access=customers > customers=clim

Re: [Tagging] Synonymous values in the shop key

On 30.07.2014 20:42, Mateusz Konieczny wrote: > There were no objections to following changes: > shop=jewellery (139) -> shop=jewelry (13299, documented) Actually, we discussed a suggestion to change this in the other direction while this thread was running. Although it was in a separate thread, I

Re: [Tagging] Problem with access=designated

On 13.07.2014 20:44, Mateusz Konieczny wrote: > According to http://wiki.openstreetmap.org/wiki/Tag:access%3Dofficial > access=designated "often includes ways that have no legal dedication > like e.g. recommended routes of a local bicycle club" > > Is it OK to use this tag in situations like this?

Re: [Tagging] Subsequent wikipedia links

On 01.07.2014 22:25, yvecai wrote: > This map could also be done with a third project linking OSM and > Wikidata by automatically linking both datasets instead of manual tag > entry of technical references. > Call Overpass for OSM data (admin boundaries), then search wikimedia > commons for flags w

Re: [Tagging] Subsequent wikipedia links

On 01.07.2014 17:40, Pieren wrote: > It was said at the beginning that wikidata or wikipedia tags will > never replace OSM tags but now I see counter examples or duplicates of > what is already there (like on this scary proposal for the operator, > architect, brand, artist, subject, name etymology

Re: [Tagging] "No abbreviations in names" edge case

Am 19.06.2014 16:59, schrieb John Packer: > there are 13 name:signposted in the db, not sure if there are more > established alternatives... > > I don't think we should use this key, since it clashes with the usage of > the key name for other languages (i.e. name: ). > Something like name_

Re: [Tagging] RFC: Door Values

On 10.06.2014 21:51, Michael Maier wrote: > There was the key 'door', but with very little documentation. > > So I created a Proposal Page for the values of the 'door' key: > https://wiki.openstreetmap.org/wiki/Proposed_features/door Thanks for starting the proposal, having a tag for this would b

Re: [Tagging] Wiki edits, building tags on nodes versus areas

Am 04.06.2014 22:35, schrieb André Pirard: > Exactly, this and below, my POV. > I even say more: that a shop is an activity more than an object. > Just as an amenity, it takes place in a building or part of it. > But it can be in open air. > > building=yes > shop:fishing=yes > shop:fishing:rod:ren

Re: [Tagging] Making TagInfo more useful

On 15.05.2014 12:36, Andy Mabbett wrote: > It's very disappointing to see this minor feature rewuest: > >https://github.com/joto/taginfo/issues/47 > > summarily closed. Can anyone suggest a work-around or alternative, please? Write the name of the tag as a level 3 or 4 headline above the box

Re: [Tagging] small change to turn restriction relation tagging

On 22.04.2014 23:46, Richard Welty wrote: > i would like to add emergency (for emergency vehicles) to the list of > vehicle types for the except tag. > > this doesn't seem like it should be a major or controversial issue, > but i'd like to hear any objections/suggestions I don't think this would

Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway

On 02.04.2014 18:14, Richard Z. wrote: > On Wed, Apr 02, 2014 at 05:59:40PM +0200, Martin Koppenhoefer wrote: >> IMHO there is a fundamental problem to your proposal because you want to >> connect 2 ways with a node which are in reality disjunct > > objects connected with pylons and lifts are als

Re: [Tagging] Ticket for JOSM to read contact metadata closed

On 02.04.2014 19:25, Andy Mabbett wrote: > (...) I don't understand the reason given: > >This format seems not to be used much. >Too much work for too little gain. > > not least since I specifically referred to "an hCard microformat or > some other contact metadata". > > Was I unclear in

Re: [Tagging] Feature Proposal - RFC - Wikidata

On 02.04.2014 12:24, Jo wrote: > I've been experimenting with wikidata tagging in OSM a bit lately. One > doubt I have is when tagging tombstones with subject:wikidata. Is that > correct? wikipedia:subject is mentioned on the German wiki page https://wiki.openstreetmap.org/wiki/Friedhofmapping (gr

Re: [Tagging] Feature Proposal - RFC - Wikidata

On 01.04.2014 19:04, Andy Mabbett wrote: > I commend this proposal to the list: > >https://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata I like Wikidata and therefore want to see this proposal approved. :) What I'm interested in, though: If an object exists both in Wikipedia and Wik

Re: [Tagging] Driving side

On 27.03.2014 16:11, Pieren wrote: > But you force the QA tools to search and load country relations even > if they just have to check locally a way. This is not a problem for > tools like osmose or keepright but it is a problem for tools like JOSM > validator. There are other reasons why JOSM and

Re: [Tagging] Driving side

On 23.03.2014 19:23, Pieren wrote: > I like the idea to use "left/right" on the global definition (on > relation) and "opposite" on exceptions (on ways). It's also easier for > QA tools I guess. I modified the wiki accordingly. Revert if you don't > like it. I don't like it, but before I consider

Re: [Tagging] Driving side

On 22.03.2014 14:30, John Packer: > I think having only one value (driving_side=opposite (or inverted)) > would be better to tag highways. > It is a little shameful to admit it, but sometimes I confuse left and > right; so by restricting this tag's values there wouldn't be any > confusion, and rest

Re: [Tagging] Driving side

On 21.03.2014 21:07, John Packer wrote: > There are, in my city, a couple of streets that have an /inverted/ > driving side. > So I am going to extend this tag's documentation to include ways that > have it's driving side opposite to it's country's normal driving side. That's a good and useful ext

<    1   2   3   4   5   >