Re: [Tagging] Access tags (general question, but mostly regarding bicycle)

Just a minor correction. On Thu, 3 Sep 2015, Paul Johnson wrote: > Bonus round from yet further up: > > highway=tertiary > bicycle=designated > cycleway=lane > parking:lanes:right=parallel   (after the parking restriction sign at least; > before that it's fire_lane) > parking:lanes:left=no_stopp

Re: [Tagging] Proposed mechanical edit: surface=soil to surface=dirt

On Mon, 31 Aug 2015, Mateusz Konieczny wrote: > On Mon, 31 Aug 2015 12:55:27 +0200 > moltonel 3x Combo wrote: > > > On 31/08/2015, Mateusz Konieczny wrote: > > > Is there some method to automate finding who introduced tags? Doing > > > it manually would not be worth the effort. On the other han

Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path

On Sat, 29 Aug 2015, Richard wrote: > On Sat, Aug 29, 2015 at 12:09:44AM +0300, Ilpo Järvinen wrote: > > On Sat, 29 Aug 2015, Ilpo Järvinen wrote: > > > > > On Fri, 28 Aug 2015, Warin wrote: > > > > > > > On 28/08/2015 9:47 AM, Martin Koppenhoefer w

Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path

On Fri, 28 Aug 2015, geow wrote: > Ilpo Järvinen wrote > > On Fri, 28 Aug 2015, Warin wrote: > > > > For those who would want to have a separate tag for 'trails', it's > > exclusive but obviously those who would want to tag everything with > > hi

Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path

On Sat, 29 Aug 2015, Ilpo Järvinen wrote: > On Fri, 28 Aug 2015, Warin wrote: > > > On 28/08/2015 9:47 AM, Martin Koppenhoefer wrote: > > > > > > My suggestion is to not assume any access defaults but rather > > > explicitly tag everything, and surface as

Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path

On Fri, 28 Aug 2015, Warin wrote: > On 28/08/2015 9:47 AM, Martin Koppenhoefer wrote: > > > > My suggestion is to not assume any access defaults but rather > > explicitly tag everything, and surface as well. Everything you assume > > will be questioned and taken from you in a few years ;-) what

Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path

On Fri, 28 Aug 2015, John Willis wrote: > Footway is a constructed or engineered way, dedicated and built to a > grade where foot traffic should expect an easy walk. This might make > other traffic passage easier as well ( bikes), but engineered with > pedestrians in mind. > > Path is a cleare

Re: [Tagging] Describe explicitly that values of highway tag do not imply anything about road quality (except highway=motorway and highway=motorway_link)

On Wed, 19 Aug 2015, Mateusz Konieczny wrote: > I am planning on adding this information to wiki in near future. > > Note that it afffects also highway=path - in that case some/many > people are convinced that there is some kind of difference of implied > quality between highway=path and highway=

Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path

On Fri, 7 Aug 2015, Martin Koppenhoefer wrote: > > Am 07.08.2015 um 01:15 schrieb Ilpo Järvinen : > > > > "unpaved paths" is actually built-up > > recretional route whereas the others are just tiny, some even faintly > > visible, forest trails. > &

Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path

On Thu, 6 Aug 2015, Greg Troxel wrote: > > Ilpo Järvinen writes: > > > It's not just about paved/unpaved. What I mean that there are two kinds of > > "not paved trails through forest". Those which come with man applied > > surface, even if

Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path

On Thu, 6 Aug 2015, geow wrote: > The difference between a cycleway, a footway, and a trail can be access > rules, but mostly its *the built condition of the way* and that *will* vary > from a 1st world to 3rd would country - and from continent to > continent. > > Therefore proper tags

Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path

On Thu, 6 Aug 2015, Greg Troxel wrote: > > Ilpo Järvinen writes: > > > You seem to admit that there's need for some hierarchy, however, on the > > same time you seem to oppose the idea that such hierarcy would exists > > based on physical properties (man-made

Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path

On Wed, 5 Aug 2015, Greg Troxel wrote: > > Martin Koppenhoefer writes: > > >> Then what is the point of having path and all these other tags that > >> overlap? > > > > because path and bicycle=designated is the same as highway =cycleway > > > > path with horse=designated is the same as highway

Re: [Tagging] highway=footway - Advanced definition: Distinction footway vs path

On Sun, 2 Aug 2015, geow wrote: > Richard Z. wrote > > ... > > I would leave it alone and introduce highway=footpath which would be a > > variant > > of path for pedestrians, not suited or permitted for horses and vehicles > > unless > > otherwise tagged and expected to be more demanding than fo

Re: [Tagging] Node objects in tunnels or on bridges?

On Mon, 8 Jun 2015, Richard wrote: > On Mon, Jun 08, 2015 at 01:57:52PM +0200, Dominik George wrote: > > > In that case, I believe the layer=* tag should be used instead, giving > > the object the same layer as the tunnel or bridge. > > not such a good solution. > > For real-world-node-objects

Re: [Tagging] Node objects in tunnels or on bridges?

On Mon, 8 Jun 2015, Dominik George wrote: > > quite often there are node-type objects on bridges or in tunnels. > > > > What to do with them? Tunnel or bridge tags are dfined only for > > ways. > > please be a bit more specific on what you mean. Do you mean… > > a) … a node on a way that is ta

Re: [Tagging] [Bug] calculated shortest route wrong (was: often longer than fastest route)

On Wed, 29 Apr 2015, Paul Johnson wrote: > On Wed, Apr 29, 2015 at 1:58 PM, john whelan wrote: > The difficulty is in many cities traffic lights are synchronised > in such a way that cars may have to stop at the first but there > after if they are travelling at or close to the s

Re: [Tagging] New values for entrance=

different floors.   I guess. > > But I’m not sure how it would be used when rendering entrances yet.  > > On Apr 9, 2015, at 1:45 PM, Bryce Nesbitt > wrote: > > > > On Wed, Apr 8, 2015 at 12:08 PM, Ilpo Järvinen > wrote: > I added entrance

Re: [Tagging] New values for entrance=

On Wed, 8 Apr 2015, fly wrote: > > entrance=staircase > > > > Nice one with completely empty own wiki page in two languages [1]. > Wonder which import or editor did promote this tag ? No import for sure and probably "editor" also not in

Re: [Tagging] New values for entrance=

On Wed, 8 Apr 2015, fly wrote: > Am 06.04.2015 um 23:45 schrieb Ilpo Järvinen: > > On Mon, 6 Apr 2015, fly wrote: > > > >> Even entrance=staircase seems to be problematic as it overlaps with > >> entrance=main and entrance=service. > > > > N

Re: [Tagging] Which entities use area=yes

highway=track too. -- i. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New values for entrance=

On Mon, 6 Apr 2015, fly wrote: > Even entrance=staircase seems to be problematic as it overlaps with > entrance=main and entrance=service. No it doesn't. The entrance is either entrance=staircase or entrance=service so I see entrance=staircase as a sort of subclass of entrance=main. And BTW, the

Re: [Tagging] Mapping private home toilets

On Tue, 3 Mar 2015, Bryce Nesbitt wrote: > Here's a draft of a wiki tag for this: > http://wiki.openstreetmap.org/wiki/Template:Mapping_Private_Property > > I'm not sure this fully captures the complexity though.  We want building > outlines and perhaps private swimming pools as landuse indicator

Re: [Tagging] building=yes on nodes?

On Sat, 14 Feb 2015, Tom Pfeifer wrote: > I see nothing wrong with building=* on a node, used 772612 times. > > Typical cases are: > > - somebody collects house numbers along a road, but has no access >to the geometry. Thus she can use plain addr: tags on unbuilt >properties, and add bui

[Tagging] Spatial triggers/conditions changing/affecting tags elsewhere

Hi, We've have *:conditional=* which is useful to describe complex tagging cases, however, it is not able to cover one particular case with spatially distinct trigger. Lets look to this issue through two examples: A) There's Vantaanjoki river that goes under a motorway. Alongside the river

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

On Sat, 24 Jan 2015, Никита wrote: > Valid point, but also should suggest good practices for people who would > like to benefit from default indexes: > API performance API doesn't care. Or which API call you're refering to? > overpass performance Overpass could handle semicolons, if it wanted t

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

On Sat, 24 Jan 2015, Никита wrote: > > You know that it's always a trade-off, right? > Exactly. Regex advocates are ponies in DB design. > > > disk usage/IO  > Index lookup for "color:green:lightgreen"=yes is fast. So is the index lookup for color=...;lightgreen;... ! > > network traffic could

Re: [Tagging] hrmpf.

On Thu, 1 Jan 2015, Rainer Fügenstein wrote: > can you please check the comments on this changeset: > http://www.openstreetmap.org/changeset/27805365 > > short summary: manually editing 13 nodes is a mechanical edit that > needs to be discussed in advance, this list here is unimportant, > nobody

Re: [Tagging] Mapping of kids areas

Let me highlight something that was said by you(!) in the email I answered to: > > Do you have tags forplayground=pony? playground=pencils? playground=books?  > > playground=table? > > playground=horses? If not, there no reason to talk about it in > > kids_area proposal ...and then you proceed t

Re: [Tagging] Mapping of kids areas

On Fri, 19 Dec 2014, Никита wrote: > > leisure=playground > > playground:supervised=yes/no > > playground:outdoor=yes/no > > playground:indoor=yes/no > kids_area=* is not about these 4 tags. kids_area=* is disjoint to > leisure=playgrounds. Please read proposal. > > http://www.imenno.ru/wp-conten

Re: [Tagging] natural=bay as nodes are evil

On Thu, 30 Oct 2014, Marc Gemis wrote: > Could we try an example to see whether mappers agree on bay areas ? could > you draw the Gulf of Biscay on a map ? > This guy did it:  > http://1.bp.blogspot.com/_-9_Y031ZiZQ/THowBMn81dI/Ci8/inSvDDa1DC4 > /s1600/Golf+van+Biskaje.jpg  > I might have

Re: [Tagging] Default maxspeed unit on waterways

On Wed, 29 Oct 2014, Pieren wrote: > On Wed, Oct 29, 2014 at 2:52 PM, Tom Pfeifer wrote: > > km/h is derived, at least with an integer multiple of seconds, > > from SI units. mph and knots are not. I would prefer to keep > > one default unit per tag, consistently, everything else leads > > to con

Re: [Tagging] natural=bay as nodes are evil

On Tue, 28 Oct 2014, Christoph Hormann wrote: > On Tuesday 28 October 2014, Janko Mihelić wrote: > > > If you want to formulate a formal mathematical rule for where the > > > node for a bay is best placed: Place it so the variance of the > > > distance of the node to the bay's shores is minimized.

Re: [Tagging] natural=bay as nodes are evil

On Mon, 27 Oct 2014, Martin Koppenhoefer wrote: > > 2014-10-27 17:37 GMT+01:00 Christoph Hormann : > > But this is exactly what does not work with a hand mapped > polygon either > since the edge of the bay is not well defined. > > > > it will work in most cases, and only giv

Re: [Tagging] natural=bay as nodes are evil

On Mon, 27 Oct 2014, Marc Gemis wrote: > > On Mon, Oct 27, 2014 at 11:33 AM, Ilpo Järvinen > wrote: > Besides, we really need to deal with object that have fuzzy > borders > already, e.g., some of the natural=wetland object come to my > mind as

Re: [Tagging] what does maxheight=none mean?

On Mon, 27 Oct 2014, moltonel 3x Combo wrote: > On 27/10/2014, Martin Koppenhoefer wrote: > > 2014-10-27 11:04 GMT+01:00 moltonel 3x Combo : > >> The maxheight=* tag maps the physical limitation, not the sign (which > >> can be absent or even wrong). Tagging maxheight=none really makes no > >> se

Re: [Tagging] natural=bay as nodes are evil

On Sun, 26 Oct 2014, Christoph Hormann wrote: > On Sunday 26 October 2014, Mateusz Konieczny wrote: > > > Furthermore the outer edge of a bay, i.e. the edge that is not > > > coastline is usually not well defined and would require an > > > arbitrary cutoff. > > > > Yes, cutoff is unfortunately qui

Re: [Tagging] Feature Proposal - Voting - relation type=person

On Wed, 15 Oct 2014, Pieren wrote: > On Wed, Oct 15, 2014 at 11:34 AM, Ilpo Järvinen > wrote: > > > Not that it would interest me personally to find some distant relative's > > grave, but I've been on multiple occassions on with somebody who has been > > lo

Re: [Tagging] Feature Proposal - Voting - relation type=person

On Wed, 15 Oct 2014, Martin Vonwald wrote: > 2014-10-14 23:31 GMT+02:00 moltonel 3x Combo : > I think that "who is in which tomb" is information that does > belong in OSM. > > Finding the tomb you want in a cemetery is *hard* and I'd love > to be > able to use OS

Re: [Tagging] usage of maxspeed:practical is described as recommended on wiki

On Sat, 23 Aug 2014, Martin Koppenhoefer wrote: > > > > Il giorno 23/ago/2014, alle ore 21:08, Ilpo Järvinen > > ha scritto: > > > > How much of such ways that would be a candidate for maxspeed:practical > > > IMHO this is a highly subjective tag

Re: [Tagging] usage of maxspeed:practical is described as recommended on wiki

On Sat, 23 Aug 2014, Mateusz Konieczny wrote: > 2014-08-23 10:48 GMT+02:00 Richard Z. : > On Sat, Aug 23, 2014 at 09:08:08AM +0200, Mateusz Konieczny > wrote: > > See > https://wiki.openstreetmap.org/wiki/Talk:Key:surface#maxspeed:practical > > for proposed change >

Re: [Tagging] interpolated housenumbers on single objects

On Wed, 20 Aug 2014, Simon Poole wrote: > Am 20.08.2014 12:11, schrieb Ilpo Järvinen: > ... lots of stuff from past experiences ... > > There is no reason not to immediately enter the address data, preferably > as entrance nodes if the building outlines exist, if they don't,

Re: [Tagging] interpolated housenumbers on single objects

On Wed, 20 Aug 2014, Will Phillips wrote: > On 20/08/2014 00:02, Martin Koppenhoefer wrote: > > > Il giorno 19/ago/2014, alle ore 23:45, Will Phillips ha > > > scritto: > > > > > > I find that by far the most time consuming part of surveying house > > > numbers is actually adding the data after

Re: [Tagging] Synonymous values in the shop key

On Thu, 31 Jul 2014, Martin Koppenhoefer wrote: > > Am 31/lug/2014 um 10:38 schrieb Ilpo Järvinen : > > > > shop:seats=yes/no > > shop:waiter/service=yes/no > > > > ...Or something along those lines rather than the black magic you outlined > > above

Re: [Tagging] Synonymous values in the shop key

On Thu, 31 Jul 2014, Martin Koppenhoefer wrote: > I use them like this > > amenity=cafe cuisine=ice_cream > there is a waiter / service > > amenity=ice_cream > they sell take away ice cream, but also have at least some tables to sit down > (no service) > > shop=ice_cream > you can only buy ice

Re: [Tagging] layer=-1, rivers, bridges and tunnels

On Tue, 22 Apr 2014, Richard Z. wrote: > On Tue, Apr 22, 2014 at 10:54:37PM +0300, Ilpo Järvinen wrote: > > On Tue, 22 Apr 2014, Richard Z. wrote: > > > > Now what is that key:layer anyway? Given that nobody knows or cares how > > > it > > > works does i

Re: [Tagging] layer=-1, rivers, bridges and tunnels

On Tue, 22 Apr 2014, Richard Z. wrote: > > Layer tag is a *hint* to the renderer, nothing more. > > the wiki page says > << > The layer=* tag is one of several methods used to describe vertical > relationships between crossing or overlapping features. > >> > > Not a single word of a "hint to t

Re: [Tagging] layer=-1, rivers, bridges and tunnels

On Sat, 5 Apr 2014, Richard Z. wrote: > On Fri, Apr 04, 2014 at 09:41:56PM +0200, André Pirard wrote: > > In addition, "key:layer" *is not* rendering layer/order. > > One example, a road is going through a forest, both should have implicit > "key:layer" ==0. > Obviously they still have a defin

Re: [Tagging] layer=-1, rivers, bridges and tunnels

On Wed, 2 Apr 2014, Richard Z. wrote: > On Wed, Apr 02, 2014 at 03:53:25PM +0300, Ilpo Järvinen wrote: > > On Wed, 2 Apr 2014, Dave Swarthout wrote: > > > > > C'mon guys. Tagging an entire river at layer=-1 is simply not the way to > > > do > > > t

Re: [Tagging] layer=-1, rivers, bridges and tunnels

On Wed, 2 Apr 2014, Nelson A. de Oliveira wrote: > On Wed, Apr 2, 2014 at 9:53 AM, Ilpo Järvinen > wrote: > > C'mon guys. It should be done with sensible defaults rather than forcing > > mappers to tell such plain obvious things. Rivers tend to pretty > > universall

Re: [Tagging] layer=-1, rivers, bridges and tunnels

On Wed, 2 Apr 2014, Dave Swarthout wrote: > C'mon guys. Tagging an entire river at layer=-1 is simply not the way to do > things, unless it is a covered river or one that runs underground. What > other possible justification is there other than not wanting to do the work > of tagging bridges with

Re: [Tagging] layer=-1, rivers, bridges and tunnels

On Wed, 2 Apr 2014, Martin Koppenhoefer wrote: > 2014-04-02 13:51 GMT+02:00 Richard Z. : > It is not wrong by itself but there are many circumstances > where it > is plain wrong > > +1, it is not wrong as long as there aren't any crossing / overlapping > objects that have a diff

Re: [Tagging] layer=-1, rivers, bridges and tunnels

On Sat, 15 Mar 2014, Richard Z. wrote: > On Sat, Mar 15, 2014 at 12:30:30AM +0200, Ilpo Järvinen wrote: > > On Fri, 14 Mar 2014, Richard Z. wrote: > > > > > On Fri, Mar 14, 2014 at 10:34:41PM +0200, Ilpo Järvinen wrote: > > > > On Fri, 14 Mar 2014, Richard

Re: [Tagging] layer=-1, rivers, bridges and tunnels

On Fri, 14 Mar 2014, Richard Z. wrote: > On Fri, Mar 14, 2014 at 10:34:41PM +0200, Ilpo Järvinen wrote: > > On Fri, 14 Mar 2014, Richard Z. wrote: > > > > > On Fri, Mar 14, 2014 at 04:51:18PM +0100, Pieren wrote: > > > > On Fri, Mar 14, 2014 at 4:45 PM, Richa

Re: [Tagging] layer=-1, rivers, bridges and tunnels

On Fri, 14 Mar 2014, Richard Z. wrote: > On Fri, Mar 14, 2014 at 04:51:18PM +0100, Pieren wrote: > > On Fri, Mar 14, 2014 at 4:45 PM, Richard Z. wrote: > > There has been a proposal long ago for bridges to have implicit an layer > and it was not accepted. Was that for bridges being equal to lay

Re: [Tagging] How to tag an imaginary oneway barrier

On Sat, 1 Feb 2014, Masi Master wrote: > Am 01.02.2014, 10:05 Uhr, schrieb Pee Wee : > > > 1 Cut the way where the sign is and use a relation type : > > restriction. > > > > 2 Add a node on the way where the sign is and add a motorcar:back

Re: [Tagging] emergency=yes

On Thu, 23 Jan 2014, Paul Johnson wrote: > > On Thu, Jan 23, 2014 at 2:20 PM, Ilpo Järvinen > wrote: > Besides that, here in Finland some of the service ways to > residential > buildings are designated as "rescue road" ("pelastustie" in >

Re: [Tagging] emergency=yes

On Thu, 23 Jan 2014, Richard Welty wrote: > On 1/23/14 1:13 PM, Bryce Nesbitt wrote: > > What might people using the tag 'emergency=yes' have meant it to mean? > > And is it a good use? > > > > It's the #2 tag in a space that has some gems (emergency=aed and > > emergency=phone for example). But I

Re: [Tagging] End voting bicycle=use_cycleway

On Fri, 13 Dec 2013, Pee Wee wrote: > > Today the voting of the bicycle=use_cycleway ended.  Voting results: > >   > > Yes:  10 (not counting the 2 that made the proposal)  > > No:  11  > > Abstain:  3 > >   > > This is reason enough for us to work on a better proposal so we reject the > current o

Re: [Tagging] give way and stop tag for ways

On Tue, 5 Nov 2013, Balázs Barcsik wrote: > Do you think that routing/navigation apps are using turn restrictions tags > instead of oneway tag to create the route?I dont think so... It's still wrong even if everyone would be doing it. :-) And btw, I was only saying that in order to get it right,

Re: [Tagging] give way and stop tag for ways

On Tue, 5 Nov 2013, Balázs Barcsik wrote: > Think about oneway > tag.http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing > That is a property of a way. > So as a routing app I just would like to examine this tag, and forget the > relations restrictions: > http://wiki.openstreetmap.org/wiki/Rel

Re: [Tagging] foot=yes or bicycle=yes on track without other limitations?

On Thu, 11 Jul 2013, Friedrich Volkmann wrote: > > It is better to tag signs: bicycle=yes only if there is a "bicycle > > free" sign. Same with other signs. So if we see the tags, we know > > which sign is there, and backwards. > > I don't see a benefit of mapping the traffic signs themselves, t

Re: [Tagging] fire_hydrant extensions proposal

On Sat, 9 Mar 2013, Richard Welty wrote: > for the US, water mains are specified in inches. i presume that centimeter is > the correct > unit elsewhere. correct? In Finland, mm is used in all signs. I've not seen other classifications here besides the diameter. Then we only have only "O" marking

Re: [Tagging] How to solve the problem with relation overload?

On Tue, 4 Dec 2012, Martin Vonwald wrote: > 2012/12/4 Erik Johansson : > > > But then maybe the "no-right-turn" relation is too complicated as well. > > The problem is not really the complexity of those relations, but the > fact that they create some kind of extreme long "relation-way". The > pr

Re: [Tagging] Fwd: Door to door routing to buildings with multiple occupants

On Sun, 2 Dec 2012, Martin Koppenhoefer wrote: > 2012/12/2 Kytömaa Lauri : > > Just a reminder that in many countries buildings can have several > > addresses, each address on different streets; none of the addresses is > > a "primary" address, and all staircases of said building are > > reference

Re: [Tagging] How to solve the problem with relation overload?

On Fri, 30 Nov 2012, Martin Koppenhoefer wrote: > 2012/11/30 Pieren : > > In the example you are pointing, 6 of the 9 relations are for the Bus > > 311. I never map public transport relations but I've seen its modeling > > expanding very far in complexity in recent time (fault is also because > >

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

On Wed, 19 Sep 2012, Eckhart Wörner wrote: > Am Dienstag, 18. September 2012, 23:15:57 schrieb Rob Nickerson: > > Variable parts in keys will also lead to an undesired > > proliferation of unique keys. > > This is the only argument that is not completely broken, and it has two > sides: the Extende

Re: [Tagging] on the name of a tag for landcover

On Wed, 15 Aug 2012, Martin Koppenhoefer wrote: > 2012/8/15 David ``Smith'' : > > I thought we used natural=* for this kind of thing. > > > "natural" is not defined in a clear way IMHO, it is a mixture of > different kind of features, but most of them could be called > "geographical features" an

Re: [Tagging] Advice & clarification of the railway tracks=* tag required.

On Tue, 14 Aug 2012, Pieren wrote: > Personally I find the suggestion of total_tracks reasonably appealing > initially, however it would have to be repeated across all the tracks > which seems ugly and still doesn't say with confidence which tracks > are connected. > > The relation approach is cl

Re: [Tagging] Mapping larger Mini-roundabouts

On Wed, 6 Jun 2012, Martin Vonwald wrote: > So I'm still not sure, that it is a good idea to use anything than a > node for mini-roundabout. Why isn't it sufficient to use a node and > simply add a tag (if really necessary) to specify the dimension? For small ones, node seems just fine. However,

Re: [Tagging] Mapping larger Mini-roundabouts

On Wed, 6 Jun 2012, Martin Vonwald wrote: > IMO tagging a mini - no matter how large it is - as a way would be > inconsistent with our way we map (most?) features. When mapping a > street, we draw the way where one can drive/go. On a normal roundabout > you can not drive in the middle, that's why

Re: [Tagging] [OSM-talk] Cycle lanes & cycle tracks - my findings and a proposal

On Wed, 23 May 2012, Martin Koppenhoefer wrote: > 2012/5/23 Martin Vonwald : > > >>> If I > >>> want to move the "street" I have to move seven ways. > >> why would you want to move a street that you have surveyed up to this > >> level of detail? I think this is hypothetical (and btw: it is 6 in >

Re: [Tagging] Tagging: minimum required tags

On Fri, 18 May 2012, Tobias Johansson wrote: > I see your point concerning you don't have to do it that way. But I > don't really se any reason for not doing it that way? And if it makes > it simpler? > > But I have no big objection for what you say. I myself have mapped a > lot of houses the way

Re: [Tagging] Dispute prevention: meaning of lanes tag

On Fri, 27 Apr 2012, Martin Vonwald wrote: > Maybe we could put an end to this discussion by enumerating the pro > and cons for both approaches? What exactly is the problem with > lanes=+width, that is solved with lanes=1.5 ? Please pick the integer first so we can discuss more. ...Although I thi

Re: [Tagging] Dispute prevention: meaning of lanes tag

On Fri, 27 Apr 2012, Georg Feddern wrote: > Am 27.04.2012 09:23, schrieb Ilpo Järvinen: > > On Thu, 26 Apr 2012, Martin Koppenhoefer wrote: > > > > > What do you think of lanes=3.5? I have an example here: > > > > > > Not sure, how many lanes the

Re: [Tagging] Dispute prevention: meaning of lanes tag

On Fri, 27 Apr 2012, Andrew Errington wrote: > A lane count of 1.5 is very confusing. What does it mean? What is the width > of each lane? Is it really 1.5? Should it be 1.55, or 1.4, or 1.6? ...No, it's not multiple of some magical "default lane width" like you imply. But simply _somethin

Re: [Tagging] Dispute prevention: meaning of lanes tag

On Fri, 27 Apr 2012, Pieren wrote: > On Fri, Apr 27, 2012 at 9:58 AM, Ilpo Järvinen > > > if there's anything else than some fancy wordsmithing looking into the > > very same road from different angles? :-) > > Well, sometimes you have 1 lane, sometimes 2, or somethi

Re: [Tagging] Dispute prevention: meaning of lanes tag

On Fri, 27 Apr 2012, Ilpo Järvinen wrote: > On Fri, 27 Apr 2012, Pieren wrote: > > > On Fri, Apr 27, 2012 at 9:18 AM, Martin Vonwald > > > > > Anyone else has a problem with the suggested solution to the lanes=1.5 > > > problem? > > > > I think

Re: [Tagging] Dispute prevention: meaning of lanes tag

On Fri, 27 Apr 2012, Pieren wrote: > On Fri, Apr 27, 2012 at 9:18 AM, Martin Vonwald > > > Anyone else has a problem with the suggested solution to the lanes=1.5 > > problem? > > I think we should simply recommend to not use fractions since they can > be misinterpreted by any one (not only app

Re: [Tagging] Dispute prevention: meaning of lanes tag

On Thu, 26 Apr 2012, Martin Koppenhoefer wrote: > Am 26. April 2012 20:03 schrieb Jason Cunningham : > > Major problem: You've haven't adequately dealt with the lanes=1.5 issue. > > You've suggested something that can't solve the issue, but simply looks like > > an attempt to cleanse it from the l

Re: [Tagging] Dispute prevention: meaning of lanes tag

On Sun, 22 Apr 2012, martinq wrote: > > I've had a look for uk guidance as the uk's ordnance survey was > > mentioned, and a lot of older uk advice appears based around a now > > historic view that 'cars = saloon cars' and were 1.8m or less. If cars > > were assumed to be 1.8m wide then implied OS

Re: [Tagging] Dispute prevention: meaning of lanes tag

On Sat, 21 Apr 2012, Martin Vonwald (Imagic) wrote: > Am 21.04.2012 um 13:34 schrieb "Ilpo Järvinen" : > > > ...What I don't really care if it is called lanes=1.5 or > > lanes=1/2+some_other_agreed_tag_which_is_not_an_estimated_width=x, but > > simply sa

Re: [Tagging] Dispute prevention: meaning of lanes tag

On Sat, 21 Apr 2012, Ronnie Soak wrote: > In my opinion, lanes=1.5 is a very bad choice. We have a tag for > this situation: width . According to taginfo, lanes=1.5 is used, > but not too often. What should we do? I would recommend not to > use it and advise to specify a wi

Re: [Tagging] demolished buildings, temporal component of data

On Fri, 20 Apr 2012, Martin Koppenhoefer wrote: > In some regions of the world OSM is already in a state where many of > the map modifications are not due to missing or wrong data, but result > from actual changes in the real world, e.g. a building gets > demolished. > > Given that we store not o

Re: [Tagging] RFC: highway=tidal_road

On Wed, 23 Nov 2011, Nathan Edgars II wrote: > On 11/23/2011 5:40 AM, Martin Koppenhoefer wrote: > > Yes, this would fit the proposed tag. As you can see from your picture > > not beeing aware about the tide situation can cost your life. IMHO > > this kind of road merits its own main highway tag,

Re: [Tagging] Key "location"

On Fri, 14 Oct 2011, John F. Eldredge wrote: > Pieren wrote: > > > As an old mapper, you should also avoid the key "location" since the > > location is stored in the nodes lat/lon coordinates... > > In the case of underground structures such as subway stations > (Underground stations in UK par

Re: [Tagging] Feature Proposal - Voting - entrance=*

On Wed, 12 Oct 2011, Nathan Edgars II wrote: > On 10/12/2011 6:52 PM, Ilpo Järvinen wrote: > > Please let me know when did my private renderer for those > > building=entrances cease being something that renders (besides the > > times > > when my VM is down of course :-)

Re: [Tagging] Feature Proposal - Voting - entrance=*

On Thu, 13 Oct 2011, Erik Johansson wrote: > On Wed, Oct 12, 2011 at 11:12 PM, Ilya Zverev wrote: > > aren't we better of without building=entrance? I really > hope that DWG can be kept out of this. > > Further I would like to propose railway=subway_entrance => > entrance=public_transport, since

Re: [Tagging] Feature Proposal - RFC - Turn Lanes

On Thu, 6 Oct 2011, Pieren wrote: > On Thu, Oct 6, 2011 at 11:10 AM, Ilpo Järvinen > wrote: > > however, it should not be solved using some data klugde but > > making the tasks you mention easy to do in editors even if the ways would > > contain only two nodes each. >

Re: [Tagging] Feature Proposal - RFC - Turn Lanes

On Thu, 6 Oct 2011, Kytömaa Lauri wrote: > >The tag lanes should be reserved for the straight > >forward lanes. > > At a T-junction, the road ending there would then be > lanes=0, given that wording. Nice. ...And it gets even funnier if you have an intersection where all those straight forward la

Re: [Tagging] Feature Proposal - RFC - Turn Lanes

On Thu, 6 Oct 2011, Pieren wrote: > On Thu, Oct 6, 2011 at 10:52 AM, Ilya Zverev wrote: > > The big problem is that mappers think splitting ways is damaging them. Why? > > It's just painful to work with many small segments (to add or rename > tags or use route relations). People editing on such