From adrianpbrain at yahoo.co.uk  Mon Apr  2 21:26:01 2012
From: adrianpbrain at yahoo.co.uk (Adrian Brain)
Date: Mon, 2 Apr 2012 21:26:01 +0100 (BST)
Subject: [Tagging] (no subject)
Message-ID: <1333398361.49409.YahooMailMobile@web171504.mail.ir2.yahoo.com>

<a href="http://googlechecks.com/Plone-3.0.3-UnifiedInstaller/helper_scripts/02efpk.html"> http://googlechecks.com/Plone-3.0.3-UnifiedInstaller/helper_scripts/02efpk.html</a>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120402/69500348/attachment.html>

From flukas.robot+osm at gmail.com  Wed Apr  4 16:15:59 2012
From: flukas.robot+osm at gmail.com (LM_1)
Date: Wed, 4 Apr 2012 17:15:59 +0200
Subject: [Tagging] reference_point and landmark for addresses
In-Reply-To: <CABPTjTDG-gRhJoc3_kF_1cR=RAYBUAw4W+BpO8Yq1E0f8wetpA@mail.gmail.com>
References: <4F690A2B.8040201@delattre.de> <4F69B118.6060608@gmail.com>
	<CA+z=q=v0GJ5beM_hv4O17=yMh2rDRmNHRYUM3Tmtkbm0NJGr+w@mail.gmail.com>
	<4F6A275C.7050602@delattre.de> <4F6E30AD.30100@delattre.de>
	<loom.20120326T221910-592@post.gmane.org>
	<4F7115E0.5010006@googlemail.com>
	<loom.20120327T193308-167@post.gmane.org>
	<CAKs=k7p0wcPS-+2Ty6N9GH+wS7g3PKR2wqhLeQp2kqeS0fv2fQ@mail.gmail.com>
	<CABPTjTDG-gRhJoc3_kF_1cR=RAYBUAw4W+BpO8Yq1E0f8wetpA@mail.gmail.com>
Message-ID: <CAKho1CJFe9LqRfY+qxz5cKdDBUTCu3iffeD76fqx44C4RJp22g@mail.gmail.com>

Would not the problem with describing the position on the object be
that you could still not find the reference object and thus it would
be completely useless?
If you have a location description referenced from "big tree" you need
to find the big tree.
There are multiple ways to get to the location from the reference
point - one address can be north from big tree and south from small
tree at the same time.
We are used to take addresses as absolute positions, but this does not
seem to be the case. You have absolute positions of reference points
(should be in the map) and then use relative directions to get to the
location - this is not an address and should not be tagged as one.

Luk?? Mat?jka (LM_1)

Dne 30. b?ezna 2012 10:11 Martin Koppenhoefer <dieterdreist at gmail.com>
napsal(a):
> What about the established tag "addr:full"? This was intended for
> cases like this.
>
> cheers,
> Martin
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging


From linux at delattre.de  Wed Apr  4 16:58:45 2012
From: linux at delattre.de (Felix Delattre)
Date: Wed, 04 Apr 2012 09:58:45 -0600
Subject: [Tagging] reference_point and landmark for addresses
In-Reply-To: <CAKho1CJFe9LqRfY+qxz5cKdDBUTCu3iffeD76fqx44C4RJp22g@mail.gmail.com>
References: <4F690A2B.8040201@delattre.de>
	<4F69B118.6060608@gmail.com>	<CA+z=q=v0GJ5beM_hv4O17=yMh2rDRmNHRYUM3Tmtkbm0NJGr+w@mail.gmail.com>	<4F6A275C.7050602@delattre.de>
	<4F6E30AD.30100@delattre.de>	<loom.20120326T221910-592@post.gmane.org>	<4F7115E0.5010006@googlemail.com>	<loom.20120327T193308-167@post.gmane.org>	<CAKs=k7p0wcPS-+2Ty6N9GH+wS7g3PKR2wqhLeQp2kqeS0fv2fQ@mail.gmail.com>	<CABPTjTDG-gRhJoc3_kF_1cR=RAYBUAw4W+BpO8Yq1E0f8wetpA@mail.gmail.com>
	<CAKho1CJFe9LqRfY+qxz5cKdDBUTCu3iffeD76fqx44C4RJp22g@mail.gmail.com>
Message-ID: <4F7C6FB5.6090005@delattre.de>


Right. So I just moved to proposal to
https://wiki.openstreetmap.org/wiki/Proposed_features/reference_point
The comments from Erik Johansson I posted on the previous proposal wiki
page in order to not forget them in the future. As Luk?? explained I
agree and as a first step i give priority to have "just" the reference
points being markable as such.

On 04/04/2012 09:15 AM, LM_1 wrote:
> Would not the problem with describing the position on the object be
> that you could still not find the reference object and thus it would
> be completely useless?
> If you have a location description referenced from "big tree" you need
> to find the big tree.
> There are multiple ways to get to the location from the reference
> point - one address can be north from big tree and south from small
> tree at the same time.
> We are used to take addresses as absolute positions, but this does not
> seem to be the case. You have absolute positions of reference points
> (should be in the map) and then use relative directions to get to the
> location - this is not an address and should not be tagged as one.
>
> Luk?? Mat?jka (LM_1)
>
> Dne 30. b?ezna 2012 10:11 Martin Koppenhoefer <dieterdreist at gmail.com>
> napsal(a):
>> What about the established tag "addr:full"? This was intended for
>> cases like this.
>>
>> cheers,
>> Martin


On 03/30/2012 01:50 AM, Erik Johansson wrote:
> I see why you would want to tag addr:reference_point=yes instead.
> Felix do you have any examples from real life? I think you should
> start collecting them, and please use Spanish since that is what the
> addresses are written in...
>

Here are a some examples from real life:

Example with a usual reference point:
Nicaragua Guest House
Bello Horizonte
VI Etapa 217
Rotonda de la Virgen 2 cuadras al sur 2 1/2 abajo/west
Managua, Nicaragua

Example with a reference point, which usually would not be on a map:
Ferreter?a Bland?n Moreno
Barrio Santa Ana.
Del Arbolito 1 1/2 cuadra al norte (al lago)
Managua, Nicaragua

Example with reference point from the past:
Colegio Filimon Ribera
Reparto Schick
De donde fue el Cine Ideal una cuadra arriba
Managua, Nicaragua
(Where Cine Ideal today is a Pizzeria)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120404/798dd0b4/attachment.html>

From yvecai at gmail.com  Wed Apr  4 22:16:35 2012
From: yvecai at gmail.com (yvecai)
Date: Wed, 04 Apr 2012 23:16:35 +0200
Subject: [Tagging] Value separator
Message-ID: <4F7CBA33.3050809@gmail.com>

Hi,

What is the best way to 'separate' values?
I think about piste:grooming='classic;skating' or 'classic+skating'.

Actually, this can be argued that this is a particular grooming type of 
crosscountry ski pistes, not a simple addition of a 'classic' and 
'skating' grooming.

So, is there any reason to prefer a semicolon or a plus?

Yves


From flukas.robot+osm at gmail.com  Wed Apr  4 22:31:23 2012
From: flukas.robot+osm at gmail.com (LM_1)
Date: Wed, 4 Apr 2012 23:31:23 +0200
Subject: [Tagging] Value separator
In-Reply-To: <4F7CBA33.3050809@gmail.com>
References: <4F7CBA33.3050809@gmail.com>
Message-ID: <CAKho1C+bq7jDJKvJ1FMuHDEzsTkz59BugaWfVSqJBnx4jgigVw@mail.gmail.com>

I would choose semicolon, because it is used already (even if not
actually supported)
LM_1

Dne 4. dubna 2012 23:16 yvecai <yvecai at gmail.com> napsal(a):
> Hi,
>
> What is the best way to 'separate' values?
> I think about piste:grooming='classic;skating' or 'classic+skating'.
>
> Actually, this can be argued that this is a particular grooming type of
> crosscountry ski pistes, not a simple addition of a 'classic' and 'skating'
> grooming.
>
> So, is there any reason to prefer a semicolon or a plus?
>
> Yves
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging


From toby.murray at gmail.com  Wed Apr  4 22:35:18 2012
From: toby.murray at gmail.com (Toby Murray)
Date: Wed, 4 Apr 2012 16:35:18 -0500
Subject: [Tagging] Value separator
In-Reply-To: <CAKho1C+bq7jDJKvJ1FMuHDEzsTkz59BugaWfVSqJBnx4jgigVw@mail.gmail.com>
References: <4F7CBA33.3050809@gmail.com>
	<CAKho1C+bq7jDJKvJ1FMuHDEzsTkz59BugaWfVSqJBnx4jgigVw@mail.gmail.com>
Message-ID: <CAJeqKgvdb8r=7FvkAeAmS=mvdpgy+YEmMi-fVVm4X3hfXQk4pA@mail.gmail.com>

On Wed, Apr 4, 2012 at 4:31 PM, LM_1 <flukas.robot+osm at gmail.com> wrote:
> I would choose semicolon, because it is used already (even if not
> actually supported)

Yes, semicolon has existing support, at least in editors. Data
consuming tools don't really support any form of multiple tag values
though. Except possibly the MQ Open renderer... I think I've seen it
parse multiple ref=* values out of US highways.

Toby


From osm at tobias-knerr.de  Wed Apr  4 22:35:50 2012
From: osm at tobias-knerr.de (Tobias Knerr)
Date: Wed, 04 Apr 2012 23:35:50 +0200
Subject: [Tagging] Value separator
In-Reply-To: <4F7CBA33.3050809@gmail.com>
References: <4F7CBA33.3050809@gmail.com>
Message-ID: <4F7CBEB6.2010207@tobias-knerr.de>

yvecai wrote:
> What is the best way to 'separate' values?
> I think about piste:grooming='classic;skating' or 'classic+skating'.

Reasons to prefer semicolon: Has been done that way for years. Is also
documented in the wiki. http://wiki.osm.org/Semi-colon_value_separator

> Actually, this can be argued that this is a particular grooming type of
> crosscountry ski pistes, not a simple addition of a 'classic' and
> 'skating' grooming.

If you consider your example a grooming type on its own, then of course
you aren't looking for a value separator at all.

Tobias


From ewoerner at kde.org  Thu Apr  5 03:27:39 2012
From: ewoerner at kde.org (Eckhart =?ISO-8859-1?Q?W=F6rner?=)
Date: Thu, 05 Apr 2012 04:27:39 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
Message-ID: <2170714.HYHGOC0Ss3@obiwan>

Hi,

(sorry for starting a new thread, I just subscribed to the list)

> infoware GmbH, Bonn, Germany, and Geofabrik GmbH, Karlsruhe, Germany, have
> developed an improved tagging scheme for TMC data which we would like to
> propopose to the OSM community.

I believe this is much needed, so thank you for starting this effort.

The one thing I like very much about the proposal is that it allows people to 
start using TMC information without spending too much time implementing insane 
heuristics or programming shortest path algorithms.

However, I feel like there are some problems with your design, which should be 
discussed on a mailing list, since Wiki discussions are ugly.

1) The big problem: missing directional information

Let's assume there is a way in OSM tagged tmc=DE:123+456;DE:456-123. One also 
has real-time traffic information that talks about a traffic jam at LCD 456, 
negative direction, extent 1. One therefore knows that this traffic jam affects 
DE:123-456, and since we have a way with that information, we know that this 
way is affected.
However, there's one problem: which direction of the way is affected? It could 
be either the direction from the first point of the way to the last (called 
forward from now on), or vice versa (backward). This essential information is 
missing and makes the TMC information on non-oneway ways useless.
There are several solutions to this problem. Probably the best solution is not 
using the tmc tag at all, but using tmc:forward and tmc:backward instead. Thus 
assuming the direction of the way is from LCD 123 to LCD 456, the tagging 
would be tmc:forward=DE:123+456, tmc:backward=DE:456-123. "forward" and 
"backward" are already used in tagging (for example, maxspeed:forward) and are 
also protected by tools. E.g. if you try to reverse the before-mentioned way, 
JOSM suggests to swap tmc:forward and tmc:backward (which is the correct thing 
to do in that case).

2) A matter of taste: + and -

I'm not sure how others are feeling about this, but I find DE:123+456, 
DE:456-123 somehow confusing. Here's an alternate proposal: DE:123+456 becomes 
DE:123->456, and DE:456-123 becomes DE:123<-456 (notice the changed order). 
Therefore, the LCD order is encoded in the position of the numbers, and the 
movement between the LCDs is encoded in the arrow.
I would go even one step further and allow ? (LEFTWARDS ARROW; U+2190) and ? 
(RIGHTWARDS ARROW; U+2192) as an *alternative*. I know that not everybody 
knows how to enter these codes, but every editor and every operating system 
nowadays should be able to display them, and we have full unicode support in 
the database.
Because of 1), DE:123/456 does not make sense at all.

3) Bad influence: TMC information at junctions

One thing that I cannot wrap my head around is the TMC information *at* 
junctions. As far as I remember, a traffic jam at LCD 456, negative direction, 
extent 1 affects the road *between* LCD 123 and LCD 456, but not the actual 
junctions 123 or 456. However, the rules of adding tmc tags to the actual 
junctions influence a lot of maneuvers going over those junctions but not using 
any other part of the way. This is especially true for roundabouts or 
junctions between dual carriageways.

4) Exits and entries

TMC specifies messages that apply to entries or exits, which I feel are not 
adequately represented in the proposal, even though the proposal mentions 
them. For example, assume that the 2nd exit slip road going west at K?ln-S?d 
(where I already discovered the new tagging) is closed (and I believe there is 
a TMC message for that). How do I find this 2nd slip road? (Yes, I picked a 
really hard one.)

5) Versioning

You argue that versioning is not needed, since data can be changed in a timely 
manner, and the errors that appear are mostly harmless. I don't feel that way:
a) Experience tells that data is not always changed in a timely matter, 
especially since TMC data does not appear on most of the maps. It takes a 
while to process data (being half a month outdated seems to be normal even for 
online routing), and offline maps make this situation worse (just look at the 
bug reports at MapDust that appeared since Skobbler had started shipping offline 
maps).
b) When LCDs are inserted into chains, things break *badly*, since the extents 
are then out of sync as well.

Eckhart W?rner


From liste at letuffe.org  Thu Apr  5 14:06:39 2012
From: liste at letuffe.org (sly (sylvain letuffe))
Date: Thu, 5 Apr 2012 15:06:39 +0200
Subject: [Tagging] RFC : Isolated buildings in mountain/wild used by
	hikers(/...) for shelter/sleeping/eating
Message-ID: <201204051506.39878.liste@letuffe.org>

Hi,

The proposal :
http://wiki.openstreetmap.org/wiki/Proposed_features/wilderness_mountain_buildings
is re-opened for comments after 2 years of clean up



-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org


From on-osm at xs4all.nl  Fri Apr  6 22:50:12 2012
From: on-osm at xs4all.nl (Ole Nielsen)
Date: Fri, 06 Apr 2012 23:50:12 +0200
Subject: [Tagging] Proposal for some additional power line tags
Message-ID: <4F7F6514.60106@xs4all.nl>

Please see http://wiki.openstreetmap.org/wiki/Talk:Tag:power%3Dtower for 
some additional tags for advanced tagging of transmission towers.

I intend to add these tags to the 
http://wiki.openstreetmap.org/wiki/Tag:power%3Dtower feature page but 
first I would like to receive any comments you may have to these 
proposed tags. Please add any comments on the discussion page.

Ole N / polderrunner


From allegre.guillaume at free.fr  Mon Apr  9 20:11:23 2012
From: allegre.guillaume at free.fr (Guillaume Allegre)
Date: Mon, 9 Apr 2012 21:11:23 +0200
Subject: [Tagging] Proposal for some additional power line tags
In-Reply-To: <4F7F6514.60106@xs4all.nl>
References: <4F7F6514.60106@xs4all.nl>
Message-ID: <20120409191123.GA10210@griffon.silecs.info>

Le ven. 06 avril 2012 ? 23:50 +0200, Ole Nielsen a ecrit :
> Please see http://wiki.openstreetmap.org/wiki/Talk:Tag:power%3Dtower
> for some additional tags for advanced tagging of transmission
> towers.
> 
> I intend to add these tags to the
> http://wiki.openstreetmap.org/wiki/Tag:power%3Dtower feature page
> but first I would like to receive any comments you may have to these
> proposed tags. Please add any comments on the discussion page.

Please add a tag to specify that a specific tower is the point where the line
comes from underground to aerial. I previously proposed "raiser=yes", but it didn't
seem to match exactly what I meant.


-- 
 ? /\    Guillaume All?gre            OpenStreetMap France
  /~~\/\   Allegre.Guillaume at free.fr  Cartographie libre et collaborative
 /   /~~\    t?l. 04.76.63.26.99      http://www.openstreetmap.fr



From on-osm at xs4all.nl  Mon Apr  9 21:23:22 2012
From: on-osm at xs4all.nl (Ole Nielsen)
Date: Mon, 09 Apr 2012 22:23:22 +0200
Subject: [Tagging] Proposal for some additional power line tags
In-Reply-To: <20120409191123.GA10210@griffon.silecs.info>
References: <4F7F6514.60106@xs4all.nl>
	<20120409191123.GA10210@griffon.silecs.info>
Message-ID: <4F83453A.8040104@xs4all.nl>

On 09/04/2012 21:11, Guillaume Allegre wrote:
> Please add a tag to specify that a specific tower is the point where the line
> comes from underground to aerial. I previously proposed "raiser=yes", but it didn't
> seem to match exactly what I meant.

Somebody has already proposed 'tower=air_to_ground' and 
'pole=air_to_ground', see http://wiki.openstreetmap.org/wiki/Power_lines
These values seem clearer to me than "raiser". My proposal will adapt 
'air_to_ground' to be used in combination with either tower:terminal=yes 
or tower:branch=yes (if the cable begins as one leg of a T-branch).

Please continue the discussion on the talk page 
http://wiki.openstreetmap.org/wiki/Talk:Tag:power%3Dtower

Ole N


From christoph-jainek at gmx.de  Mon Apr  9 22:45:12 2012
From: christoph-jainek at gmx.de (Christoph Jainek)
Date: Mon, 09 Apr 2012 23:45:12 +0200
Subject: [Tagging] areaAddress
Message-ID: <20120409214512.171500@gmx.net>

Hi,
i created a proposal, that could be used for tagging named sites, open fields and junctions. The proposal page is here:
http://wiki.openstreetmap.org/wiki/Proposed_features/areaAddress
I'd be very glad of any kind of feedback.
-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!                                  
Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a


From mvexel at gmail.com  Tue Apr 10 04:33:18 2012
From: mvexel at gmail.com (Martijn van Exel)
Date: Mon, 09 Apr 2012 21:33:18 -0600
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <4F745D0C.2020206@infoware.de>
References: <4F745D0C.2020206@infoware.de>
Message-ID: <4F83A9FE.9010904@gmail.com>

On 3/29/2012 7:01 AM, Heinrich Knauf wrote:
> Hello,
>
> infoware GmbH, Bonn, Germany, and Geofabrik GmbH, Karlsruhe, Germany,
> have developed an
> improved tagging scheme for TMC data which we would like to propopose
> to the OSM community.
>
> Currently, this feature is explained in German only.
>
> Pelase refer to
>
> http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/New_TMC_Scheme
>
> Your comments are greatly appreceated!

Heinrich,

That looks like a huge improvement from the existing proposal. A few 
questions for clarification and discussion:
* In this proposal, the actual TMC LCDs are not technically required, 
are they? If all the ways are tagged according to this schema, you can 
look up the segments just by looking at the ways? I guess having the LCD 
encoded onto nodes will speed up lookup.
* How do you plan to make this huge effort (even just for Germany) 
manageable? I mean, it's simpler than it looks, but it still is a *lot* 
of work. A JOSM plugin? A dedicated website to track progress and show 
bugs / inconsistencies? Other supporting tools for mappers?
* Do you (or anyone) have any info on the 'openness' of this data in 
other countries? I believe they are proprietary data here in the US, not 
sure though (will ask in talk-us).

-- 
Martijn van Exel


From mvexel at gmail.com  Tue Apr 10 05:12:13 2012
From: mvexel at gmail.com (Martijn van Exel)
Date: Mon, 09 Apr 2012 22:12:13 -0600
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <4F83A9FE.9010904@gmail.com>
References: <4F745D0C.2020206@infoware.de> <4F83A9FE.9010904@gmail.com>
Message-ID: <4F83B31D.5020502@gmail.com>

On 4/9/2012 9:33 PM, Martijn van Exel wrote:
> On 3/29/2012 7:01 AM, Heinrich Knauf wrote:
>> Hello,
>>
>> infoware GmbH, Bonn, Germany, and Geofabrik GmbH, Karlsruhe, Germany,
>> have developed an
>> improved tagging scheme for TMC data which we would like to propopose
>> to the OSM community.
>>
>> Currently, this feature is explained in German only.
>>
>> Pelase refer to
>>
>> http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme
>>
>> http://wiki.openstreetmap.org/wiki/Proposed_features/New_TMC_Scheme
>>
>> Your comments are greatly appreceated!
>
> Heinrich,
>
> That looks like a huge improvement from the existing proposal. A few
> questions for clarification and discussion:
> * In this proposal, the actual TMC LCDs are not technically required,
> are they? If all the ways are tagged according to this schema, you can
> look up the segments just by looking at the ways? I guess having the LCD
> encoded onto nodes will speed up lookup.
> * How do you plan to make this huge effort (even just for Germany)
> manageable? I mean, it's simpler than it looks, but it still is a *lot*
> of work. A JOSM plugin? A dedicated website to track progress and show
> bugs / inconsistencies? Other supporting tools for mappers?

On that topic: how was this updated? Manually? Or was there some 
monitoring bot active that kept these values updated?
https://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany/Roads#roads_to_import_2

> * Do you (or anyone) have any info on the 'openness' of this data in
> other countries? I believe they are proprietary data here in the US, not
> sure though (will ask in talk-us).
>


-- 
Martijn van Exel


From allegre.guillaume at free.fr  Tue Apr 10 08:09:12 2012
From: allegre.guillaume at free.fr (Guillaume Allegre)
Date: Tue, 10 Apr 2012 09:09:12 +0200
Subject: [Tagging] Proposal for some additional power line tags
In-Reply-To: <4F83453A.8040104@xs4all.nl>
References: <4F7F6514.60106@xs4all.nl>
	<20120409191123.GA10210@griffon.silecs.info>
	<4F83453A.8040104@xs4all.nl>
Message-ID: <20120410070912.GB10210@griffon.silecs.info>

Le lun. 09 avril 2012 ? 22:23 +0200, Ole Nielsen a ecrit :
> On 09/04/2012 21:11, Guillaume Allegre wrote:
> >Please add a tag to specify that a specific tower is the point where the line
> >comes from underground to aerial. I previously proposed "raiser=yes", but it didn't
> >seem to match exactly what I meant.
> 
> Somebody has already proposed 'tower=air_to_ground' and
> 'pole=air_to_ground', see
> http://wiki.openstreetmap.org/wiki/Power_lines

thanks, I didn't notice that.


-- 
 ? /\    Guillaume All?gre            OpenStreetMap France
  /~~\/\   Allegre.Guillaume at free.fr  Cartographie libre et collaborative
 /   /~~\    t?l. 04.76.63.26.99      http://www.openstreetmap.fr



From dieterdreist at gmail.com  Tue Apr 10 17:38:46 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Tue, 10 Apr 2012 18:38:46 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
Message-ID: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>

I am coming back to a topic we had some time ago: sidewalks.

According to this page
http://wiki.openstreetmap.org/wiki/Tag:footway%3Dsidewalk

sidewalks should be tagged with
highway=footway
footway=sidewalk

While I agree that for complex situations it is helpful to have
dedicated geometry in OSM, I fail to understand why this should be
tagged "highway=*". Usually a distinct highway should be drawn only in
the case of a separated carriageway.

The suggested tagging is IMHO "tagging for the renderer". For tagging
sidewalks it would be sufficent to tag them with footway=sidewalk
without the highway-tag. In analogy to this tagging we would
optionally be mapping an ordinary street as dual carriageway and tag
each with highway=residential, oneway=yes, residential=lane.

New tags should be constructed in a way that doesn't change the
meaning of existing tags, but only adds detail to the existing meaning
in the case of a suggested tag-combination. In the case of sidewalks
dataconsumers that don't evaluate the footway=sidewalk tag will get
those highway=footway, which are tagged like this, wrong.

cheers,
Martin


From sabas88 at gmail.com  Tue Apr 10 17:42:12 2012
From: sabas88 at gmail.com (sabas88)
Date: Tue, 10 Apr 2012 18:42:12 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
Message-ID: <CAMePwhDvwsRr=T1DeN7BPzxTmmFqpxTHX_-1ii_7PLfwd04vFQ@mail.gmail.com>

2012/4/10 Martin Koppenhoefer <dieterdreist at gmail.com>

> I am coming back to a topic we had some time ago: sidewalks.
>
> According to this page
> http://wiki.openstreetmap.org/wiki/Tag:footway%3Dsidewalk
>
> sidewalks should be tagged with
> highway=footway
> footway=sidewalk
>
> While I agree that for complex situations it is helpful to have
> dedicated geometry in OSM, I fail to understand why this should be
> tagged "highway=*". Usually a distinct highway should be drawn only in
> the case of a separated carriageway.
>

You can add only a tag on the existing highway.

http://wiki.openstreetmap.org/wiki/Key:sidewalk

cheers,
> Martin
>

Stefano

>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120410/4df06864/attachment.html>

From neroute2 at gmail.com  Tue Apr 10 18:26:41 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Tue, 10 Apr 2012 13:26:41 -0400
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
Message-ID: <4F846D51.8020702@gmail.com>

On 4/10/2012 12:38 PM, Martin Koppenhoefer wrote:
> The suggested tagging is IMHO "tagging for the renderer". For tagging
> sidewalks it would be sufficent to tag them with footway=sidewalk
> without the highway-tag. In analogy to this tagging we would
> optionally be mapping an ordinary street as dual carriageway and tag
> each with highway=residential, oneway=yes, residential=lane.

Well, no. Sidewalks are generally separated from the roadway by at least 
a curb.


From wendorff at uni-paderborn.de  Tue Apr 10 18:44:21 2012
From: wendorff at uni-paderborn.de (Peter Wendorff)
Date: Tue, 10 Apr 2012 19:44:21 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
Message-ID: <4F847175.1070708@uni-paderborn.de>

Hi Martin.
You are right in that highway=footway is obsolete from a pure data point 
of view, IF the application supports it.
On the other hand, it might be very likely, that the corresponding 
street then gets a foot=no, as that's often the case, if you look at the 
street without the footway.

 From my point of view, highway=footway could be omitted as you suggest, 
but on the other hand, that would break routing for pedestrians, because 
the legacy/compatibility attribute highway=footway is missing.

The question is: is more data basically good or bad? Are 
applications/developers asked to adapt their code to a changing tagging 
system, or has the tagging system keep track of compatibility issues 
with more or less outdated software?

In this case IMHO forcing devs (of software and styles) to adapt to the 
new possibilities is better as the maps gets more and more cluttered for 
software, that is not aware of the change.
Software/Style, that is up to date can cope with that, at outdated 
software it's visible that things go wrong and people will complain 
about it, until it's changed.

If in turn we remove the highway=footway tag, devs simply ignore good 
ideas and features, because they are probably even not aware of the 
possibilities inside.

regards
Peter

Am 10.04.2012 18:38, schrieb Martin Koppenhoefer:
> I am coming back to a topic we had some time ago: sidewalks.
>
> According to this page
> http://wiki.openstreetmap.org/wiki/Tag:footway%3Dsidewalk
>
> sidewalks should be tagged with
> highway=footway
> footway=sidewalk
>
> While I agree that for complex situations it is helpful to have
> dedicated geometry in OSM, I fail to understand why this should be
> tagged "highway=*". Usually a distinct highway should be drawn only in
> the case of a separated carriageway.
>
> The suggested tagging is IMHO "tagging for the renderer". For tagging
> sidewalks it would be sufficent to tag them with footway=sidewalk
> without the highway-tag. In analogy to this tagging we would
> optionally be mapping an ordinary street as dual carriageway and tag
> each with highway=residential, oneway=yes, residential=lane.
>
> New tags should be constructed in a way that doesn't change the
> meaning of existing tags, but only adds detail to the existing meaning
> in the case of a suggested tag-combination. In the case of sidewalks
> dataconsumers that don't evaluate the footway=sidewalk tag will get
> those highway=footway, which are tagged like this, wrong.
>
> cheers,
> Martin
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
>



From pieren3 at gmail.com  Tue Apr 10 19:26:03 2012
From: pieren3 at gmail.com (Pieren)
Date: Tue, 10 Apr 2012 20:26:03 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F846D51.8020702@gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
Message-ID: <CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>

On Tue, Apr 10, 2012 at 7:26 PM, Nathan Edgars II <neroute2 at gmail.com> wrote:
> On 4/10/2012 12:38 PM, Martin Koppenhoefer wrote:
>>
>> The suggested tagging is IMHO "tagging for the renderer". For tagging
>> sidewalks it would be sufficent to tag them with footway=sidewalk
>> without the highway-tag. In analogy to this tagging we would
>> optionally be mapping an ordinary street as dual carriageway and tag
>> each with highway=residential, oneway=yes, residential=lane.
>
>
> Well, no. Sidewalks are generally separated from the roadway by at least a
> curb.
>

Well. We have a similar situation with "highway=cycleway" or
"cycleway=track". Not everybody is ready to trace multiple parallel
ways just for micromapping.

Pieren


From neroute2 at gmail.com  Tue Apr 10 19:42:49 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Tue, 10 Apr 2012 14:42:49 -0400
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
Message-ID: <4F847F29.4060808@gmail.com>

On 4/10/2012 2:26 PM, Pieren wrote:
> On Tue, Apr 10, 2012 at 7:26 PM, Nathan Edgars II<neroute2 at gmail.com>  wrote:
>> On 4/10/2012 12:38 PM, Martin Koppenhoefer wrote:
>>>
>>> The suggested tagging is IMHO "tagging for the renderer". For tagging
>>> sidewalks it would be sufficent to tag them with footway=sidewalk
>>> without the highway-tag. In analogy to this tagging we would
>>> optionally be mapping an ordinary street as dual carriageway and tag
>>> each with highway=residential, oneway=yes, residential=lane.
>>
>>
>> Well, no. Sidewalks are generally separated from the roadway by at least a
>> curb.
>>
>
> Well. We have a similar situation with "highway=cycleway" or
> "cycleway=track". Not everybody is ready to trace multiple parallel
> ways just for micromapping.

Nobody said you have to draw sidewalks. The question is whether 
highway=footway is appropriate when a sidewalk is drawn.


From jcg.sturdy at gmail.com  Tue Apr 10 19:55:05 2012
From: jcg.sturdy at gmail.com (John Sturdy)
Date: Tue, 10 Apr 2012 19:55:05 +0100
Subject: [Tagging] Extension of the "payment:*" keys
Message-ID: <CAFJf9KMwY3L-Yxz_zVAgrusWSgB2gV+-h0AEkVvA9ufb7+3C7A@mail.gmail.com>

I recently found myself inconvenienced by turning up for lunch at a
pub that only took cash, when I had only card money on me (something
that I gather a growing number of people make a habit of doing), and
immediately thought that would be a good thing to be able to warn
about on OSM.  So now I've had a look at
http://wiki.openstreetmap.org/wiki/Payment, and there's no concise way
of doing this: I'd have to mark it as "payment:<whatever>=no" for
every type of card.  So I'd like to suggest either:

(1) a "payment:cards" key, intended specifically for use with the
value "no", to indicate that a shop / pub / whatever doesn't take
electronic payment;

or

(2) a "payment:other" key, intended specifically for use with the
value "no", to indicate that a shop / pub / whatever takes only the
forms of payment that have been listed with other keys.

I think I prefer (2), as being more flexible, but would be interested
to hear others' opinions on this.

__John


From mvexel at gmail.com  Tue Apr 10 20:12:11 2012
From: mvexel at gmail.com (Martijn van Exel)
Date: Tue, 10 Apr 2012 13:12:11 -0600
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F847F29.4060808@gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<4F847F29.4060808@gmail.com>
Message-ID: <4F84860B.1080904@gmail.com>

On 4/10/2012 12:42 PM, Nathan Edgars II wrote:
> Nobody said you have to draw sidewalks.

I'm going a little off-topic here, but I just wanted to throw in my 
argument for mapping sidewalks separately, because I know there are a 
lot of opponents to this practice. Consider this situation: a road on an 
incline, the sidewalk follows the road but has steps in some places. You 
would want to capture the steps for accessibility reasons, and you can't 
by just adding a sidewalk tag to the main way feature.

-- 
Martijn van Exel


From me at komzpa.net  Tue Apr 10 21:01:57 2012
From: me at komzpa.net (=?UTF-8?Q?Kom=D1=8Fpa?=)
Date: Tue, 10 Apr 2012 23:01:57 +0300
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
Message-ID: <CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>

> Well. We have a similar situation with "highway=cycleway" or
> "cycleway=track". Not everybody is ready to trace multiple parallel
> ways just for micromapping.

If someone isn't ready - fine, just wait for active mapper to come.

In Minsk, we've come to agreement that highway=* are just routing
lines, with highway=footway as a part of routing graph for
pedestrians, and highway=cycleway - for cyclists.

It's possible to have pedestrian routing without separate ways for
sidewalks, but it's nicer when it shows you where you can actually
cross the road.

These represent "how people actually move", and doesn't try to follow
some idiom like "sidewalk is/isn't a part of the road" and "if it's a
single bridge, it should be single line".

We've got almost all sidewalks mapped as separate highway=footway lines.

For those who wish to "join the road back" we're starting to map
area:highway polygons.

http://www.openstreetmap.by/?zoom=18&lat=53.868776&lon=27.65056

The highway=footway is the main part of the pedestrian graph,
footway=sidewalk is just some tag I find no use for.

-- 
Darafei "Kom?pa" Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:me at komzpa.net mailto:me at komzpa.net


From osm at tobias-knerr.de  Tue Apr 10 21:15:19 2012
From: osm at tobias-knerr.de (Tobias Knerr)
Date: Tue, 10 Apr 2012 22:15:19 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F84860B.1080904@gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<4F847F29.4060808@gmail.com> <4F84860B.1080904@gmail.com>
Message-ID: <4F8494D7.3080008@tobias-knerr.de>

Martijn van Exel wrote:
> Consider this situation: a road on an
> incline, the sidewalk follows the road but has steps in some places. You
> would want to capture the steps for accessibility reasons, and you can't
> by just adding a sidewalk tag to the main way feature.

Except if you use one of the more general approaches for mapping lanes
as tags (such as [1]). Then you can add arbitrary tags to each lane,
including any that identify them as steps.

Tobias

[1] http://wiki.osm.org/Proposed_features/lanes_General_Extension



From mvexel at gmail.com  Tue Apr 10 23:10:08 2012
From: mvexel at gmail.com (Martijn van Exel)
Date: Tue, 10 Apr 2012 16:10:08 -0600
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F8494D7.3080008@tobias-knerr.de>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<4F847F29.4060808@gmail.com> <4F84860B.1080904@gmail.com>
	<4F8494D7.3080008@tobias-knerr.de>
Message-ID: <4F84AFC0.7090400@gmail.com>

On 4/10/2012 2:15 PM, Tobias Knerr wrote:
> Martijn van Exel wrote:
>> Consider this situation: a road on an
>> incline, the sidewalk follows the road but has steps in some places. You
>> would want to capture the steps for accessibility reasons, and you can't
>> by just adding a sidewalk tag to the main way feature.
>
> Except if you use one of the more general approaches for mapping lanes
> as tags (such as [1]). Then you can add arbitrary tags to each lane,
> including any that identify them as steps.
>
> Tobias
>
> [1] http://wiki.osm.org/Proposed_features/lanes_General_Extension
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging

A sidewalk is not a lane and it should not be tagged as such. Doing so 
would be utterly confusing. Does the lanes proposal (which I think is 
horribly overwrought to begin with) not exclude sidewalks? It should.
The sidewalks are not tagged in any of the examples: 
https://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension#Examples

-- 
Martijn van Exel


From osm at tobias-knerr.de  Tue Apr 10 23:38:19 2012
From: osm at tobias-knerr.de (Tobias Knerr)
Date: Wed, 11 Apr 2012 00:38:19 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F84AFC0.7090400@gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<4F847F29.4060808@gmail.com> <4F84860B.1080904@gmail.com>
	<4F8494D7.3080008@tobias-knerr.de> <4F84AFC0.7090400@gmail.com>
Message-ID: <4F84B65B.1030501@tobias-knerr.de>

Martijn van Exel wrote:
> A sidewalk is not a lane and it should not be tagged as such. Doing so
> would be utterly confusing. Does the lanes proposal (which I think is
> horribly overwrought to begin with) not exclude sidewalks?

Not explicitly. And while it is true that the examples don't include
sidewalks, they do include cycleways, where we have basically the same
debate whether or not they should be separate ways.

Anyway, I see no reason to exclude sidewalks here. No matter whether you
think of a sidewalk when you hear the word "lane", the requirements are
the same as for other "stripes" of the highway: They run parallel to the
highway centreline, you want to define their relative ordering, they
share properties of the highway such as its name, but you also want to
be able to add tags to them individually sometimes.

A sidewalk=left/right/both fails when you want to define the relative
ordering, and separate footway=cycleway fail in practice because no
renderer is actually able to puzzle the highway back together from
unconnected parallel ways.

Tobias


From neroute2 at gmail.com  Tue Apr 10 23:46:17 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Tue, 10 Apr 2012 18:46:17 -0400
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F84B65B.1030501@tobias-knerr.de>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<4F847F29.4060808@gmail.com> <4F84860B.1080904@gmail.com>
	<4F8494D7.3080008@tobias-knerr.de> <4F84AFC0.7090400@gmail.com>
	<4F84B65B.1030501@tobias-knerr.de>
Message-ID: <4F84B839.2050706@gmail.com>

On 4/10/2012 6:38 PM, Tobias Knerr wrote:
> Not explicitly. And while it is true that the examples don't include
> sidewalks, they do include cycleways, where we have basically the same
> debate whether or not they should be separate ways.

Are you talking about bike lanes or sidepaths? The latter is a separate 
roadway, and can be either mapped as such or with cycleway=track.


From osm at tobias-knerr.de  Wed Apr 11 00:06:23 2012
From: osm at tobias-knerr.de (Tobias Knerr)
Date: Wed, 11 Apr 2012 01:06:23 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F84B839.2050706@gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<4F847F29.4060808@gmail.com> <4F84860B.1080904@gmail.com>
	<4F8494D7.3080008@tobias-knerr.de> <4F84AFC0.7090400@gmail.com>
	<4F84B65B.1030501@tobias-knerr.de> <4F84B839.2050706@gmail.com>
Message-ID: <4F84BCEF.3020501@tobias-knerr.de>

Nathan Edgars II wrote:
> On 4/10/2012 6:38 PM, Tobias Knerr wrote:
>> Not explicitly. And while it is true that the examples don't include
>> sidewalks, they do include cycleways, where we have basically the same
>> debate whether or not they should be separate ways.
> 
> Are you talking about bike lanes or sidepaths?

I am talking about bicycle lanes that are not physically separate from
the car lanes. These should  be mapped as cycleway=lane (or variants
thereof, such as cycleway:left/right=lane), but some micromappers seem
to like mapping them as individual ways for some reason.

While cycleway=lane is fine as a start, I would suggest that these
should also be added to the *:lanes list _if_ you use a proposal such as
the one I linked to earlier. Otherwise, some situations cannot be
adequately modelled.

Tobias


From mvexel at gmail.com  Wed Apr 11 01:04:17 2012
From: mvexel at gmail.com (Martijn van Exel)
Date: Tue, 10 Apr 2012 18:04:17 -0600
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F84B65B.1030501@tobias-knerr.de>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<4F847F29.4060808@gmail.com> <4F84860B.1080904@gmail.com>
	<4F8494D7.3080008@tobias-knerr.de> <4F84AFC0.7090400@gmail.com>
	<4F84B65B.1030501@tobias-knerr.de>
Message-ID: <4F84CA81.7070109@gmail.com>

On 4/10/2012 4:38 PM, Tobias Knerr wrote:
> Martijn van Exel wrote:
>> A sidewalk is not a lane and it should not be tagged as such. Doing so
>> would be utterly confusing. Does the lanes proposal (which I think is
>> horribly overwrought to begin with) not exclude sidewalks?
>
> Not explicitly. And while it is true that the examples don't include
> sidewalks, they do include cycleways, where we have basically the same
> debate whether or not they should be separate ways.

That just makes it more confusing then. If you're going to use an 
example that clearly shows a sidewalk in the aerial image, you should 
also include it in the tagging example.

> Anyway, I see no reason to exclude sidewalks here. No matter whether you
> think of a sidewalk when you hear the word "lane", the requirements are
> the same as for other "stripes" of the highway: They run parallel to the
> highway centreline, you want to define their relative ordering, they
> share properties of the highway such as its name, but you also want to
> be able to add tags to them individually sometimes.

I disagree. If you're going to include sidewalks and cycleways that run 
parallel to the roadway but are not part of them, the key should not be 
'lane' but 'road_element' or something abstract like that. How are you 
going to gain adoption for a proposal that violates the natural language 
use of the word and makes mapping more confusing for so many people?

> A sidewalk=left/right/both fails when you want to define the relative
> ordering, and separate footway=cycleway fail in practice because no
> renderer is actually able to puzzle the highway back together from
> unconnected parallel ways.

What is the use case for being able to do that? What can you do that you 
can't with a separate geometry for a sidewalk that may be as much as 6 
feet from the main roadway?

All in all, I think that this entire lanes proposal over-complicates 
things by aiming to be a catch-all for too many situations. To me, it 
violates the prime directive of OSM (well half of it): 'have fun' - and 
you won't see me use it for that reason alone.

-- 
Martijn van Exel


From dieterdreist at gmail.com  Wed Apr 11 09:22:57 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Wed, 11 Apr 2012 10:22:57 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
Message-ID: <CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>

Am 10. April 2012 22:01 schrieb Kom?pa <me at komzpa.net>:
> In Minsk, we've come to agreement that highway=* are just routing
> lines, with highway=footway as a part of routing graph for
> pedestrians, and highway=cycleway - for cyclists.
>
> It's possible to have pedestrian routing without separate ways for
> sidewalks, but it's nicer when it shows you where you can actually
> cross the road.


The thing is that you can generally cross any road at any spot, as
long it is not impossible or too dangerous ;-), i.e. in most of the
cases you can simply cross the road if your destination is right on
the other side for example. With explicit footways your router will
send you to the next crossing and tell you to cross the road there and
then come back.

If sidewalks were tagged without the highway tag, routing would
continue to work like it does for everybody and only who wants to take
the risk of routing also on explicit sidewalks could do so by adding
the footway=sidewalk elements into consideration. People that want to
add an additional element would do so explicitly. The way it is now
suggested to do will instead require additional action for everybody
who does NOT want them in his data: they will have to filter out
everything from their highway=* selection that has a footway=sidewalk
attached.

cheers,
Martin


From me at komzpa.net  Wed Apr 11 09:49:39 2012
From: me at komzpa.net (=?UTF-8?Q?Kom=D1=8Fpa?=)
Date: Wed, 11 Apr 2012 11:49:39 +0300
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
Message-ID: <CAC8Q8t+WaSvUovs+AAU1wBxuR-5d_gVAk7Y9u9RGvyaabEEhtg@mail.gmail.com>

2012/4/11 Martin Koppenhoefer <dieterdreist at gmail.com>:
> Am 10. April 2012 22:01 schrieb Kom?pa <me at komzpa.net>:
>> In Minsk, we've come to agreement that highway=* are just routing
>> lines, with highway=footway as a part of routing graph for
>> pedestrians, and highway=cycleway - for cyclists.

>> It's possible to have pedestrian routing without separate ways for
>> sidewalks, but it's nicer when it shows you where you can actually
>> cross the road.

> The thing is that you can generally cross any road at any spot, as
> long it is not impossible or too dangerous ;-), i.e. in most of the
> cases you can simply cross the road if your destination is right on
> the other side for example. With explicit footways your router will
> send you to the next crossing and tell you to cross the road there and
> then come back.

First, there are road behaviour rules, that basically disallow that.
You MUST go to crossing to cross a road here.

Second, if you want to hide sidewalks on rendering, postgis's
ST_DFullyWithin is your friend. You don't have to TAG everything you
can rather easily distinguish geometrically.

Third, try to cross these not on the crossing staying alive:

http://upload.wikimedia.org/wikipedia/commons/thumb/1/14/Partyzanski_praspekt_8.jpg/300px-Partyzanski_praspekt_8.jpg

http://kp.ru/f/4/image/26/67/396726.jpg

-- 
Darafei "Kom?pa" Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:me at komzpa.net mailto:me at komzpa.net


From dieterdreist at gmail.com  Wed Apr 11 10:35:05 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Wed, 11 Apr 2012 11:35:05 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CAC8Q8t+WaSvUovs+AAU1wBxuR-5d_gVAk7Y9u9RGvyaabEEhtg@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<CAC8Q8t+WaSvUovs+AAU1wBxuR-5d_gVAk7Y9u9RGvyaabEEhtg@mail.gmail.com>
Message-ID: <CABPTjTC1W-E5k-EE-EdvAdyYH9gwEw0Din=mx-n1azBosxbpCQ@mail.gmail.com>

Am 11. April 2012 10:49 schrieb Kom?pa <me at komzpa.net>:
> First, there are road behaviour rules, that basically disallow that.
> You MUST go to crossing to cross a road here.


you can't asume this to be a global law. In other countries (e.g.
Germany or Italy) you must use a pedestrian crossing if it is close to
you. If you are more then x meters away (i.e. you are in the middle of
a road) you can simply cross anywhere, provided you don't endanger the
traffic or yourself. I find it difficult to believe that belarussian
law urges pedestrians to only cross on a crossing, and if there is
none, they will have to walk kilometers just to cross the street, or
did I get this wrong?


> Second, if you want to hide sidewalks on rendering, postgis's
> ST_DFullyWithin is your friend. You don't have to TAG everything you
> can rather easily distinguish geometrically.


in the case of parallel ways it is impossible to tell whether you can
filter them out or not (there could be a separation or they could be
on different height levels), especially if people are mapping
sidewalks the same as separated footways. My main concern is routing,
not rendering. I wouldn't take them into account in routing, because I
feel you would get worse results.
E.g. 100 m South of the spot you posted above:
http://www.openstreetmap.org/?mlat=53.865988&mlon=27.651201&zoom=18&layers=M
Imagine you stand there and want to go to the parking on the other
side of the road:
http://openrouteservice.org/index.php?start=27.6511152,53.8661793&end=27.6513996,53.8661698&pref=Pedestrian&lang=de&noMotorways=false&noTollways=false
http://openrouteservice.org/index.php?start=27.6526656,53.8626553&end=27.6529552,53.8627217&pref=Pedestrian&lang=de&noMotorways=false&noTollways=false
You find this everywhere:
http://openrouteservice.org/index.php?start=27.6555434,53.866273&end=27.6557157,53.8662298&pref=Pedestrian&lang=en&noMotorways=false&noTollways=false

Another similar issue is that with these sidewalks people often don't
connect crossing footways to the street, they only connect them to the
sidewalk. There are examples for this also in your area, so
unfortunately simply omitting them won't do the job either, because
you would get gaps near crossings.


> Third, try to cross these not on the crossing staying alive:
> http://upload.wikimedia.org/wikipedia/commons/thumb/1/14/Partyzanski_praspekt_8.jpg/300px-Partyzanski_praspekt_8.jpg
> http://kp.ru/f/4/image/26/67/396726.jpg


I'll do next time I visit your town. What should be the problem? You
wait until there is no car coming or all cars stop and then you cross.

cheers,
Martin


From dieterdreist at gmail.com  Wed Apr 11 10:36:23 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Wed, 11 Apr 2012 11:36:23 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CABPTjTC1W-E5k-EE-EdvAdyYH9gwEw0Din=mx-n1azBosxbpCQ@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<CAC8Q8t+WaSvUovs+AAU1wBxuR-5d_gVAk7Y9u9RGvyaabEEhtg@mail.gmail.com>
	<CABPTjTC1W-E5k-EE-EdvAdyYH9gwEw0Din=mx-n1azBosxbpCQ@mail.gmail.com>
Message-ID: <CABPTjTBrjEnfuHpyVjV6Koo02UwFAU6CE9kVxQu6iwdU3gG7rA@mail.gmail.com>

Am 11. April 2012 11:35 schrieb Martin Koppenhoefer <dieterdreist at gmail.com>:
> Another similar issue is that with these sidewalks people often don't
> connect crossing footways to the street, they only connect them to the
> sidewalk. There are examples for this also in your area, so
> unfortunately simply omitting them won't do the job either, because
> you would get gaps near crossings.


sorry, forgot an example:
http://www.openstreetmap.org/?lat=53.865684&lon=27.657735&zoom=18&layers=M

cheers,
Martin


From dieterdreist at gmail.com  Wed Apr 11 10:56:42 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Wed, 11 Apr 2012 11:56:42 +0200
Subject: [Tagging] Wikifiddling,
	surface=cobblestone vs. sett & paving_stones
In-Reply-To: <CABPTjTDjK73H9Q4xDO-E9mgd8ExvWfXf8=XNZf=nU-M8qw6xKg@mail.gmail.com>
References: <CABPTjTAgawEmKoCfXvV=+wAzwjv4M4v8iDWmCoa8uQfaavwVsw@mail.gmail.com>
	<4F4245DD.7050300@jonno.cix.co.uk> <4F425337.802@tobias-knerr.de>
	<CAMLmWVteinYd8wzq8y482DAwQvYw32us+zM2KbNGWuQH1bbFqg@mail.gmail.com>
	<CABPTjTDjK73H9Q4xDO-E9mgd8ExvWfXf8=XNZf=nU-M8qw6xKg@mail.gmail.com>
Message-ID: <CABPTjTB2CrPmZSZs9rboOWHbQ4WjdLEABOMRBa5pZyx_QxpJZQ@mail.gmail.com>

I'm pushing this one up because we have taken no action so far. Can we
agree how we want to deal with this?

here is the full thread:
http://gis.19327.n5.nabble.com/Wikifiddling-surface-cobblestone-vs-sett-amp-paving-stones-tt5498912.html#none

cheers,
Martin


From dieterdreist at gmail.com  Wed Apr 11 11:09:03 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Wed, 11 Apr 2012 12:09:03 +0200
Subject: [Tagging] Extension of the "payment:*" keys
In-Reply-To: <CAFJf9KMwY3L-Yxz_zVAgrusWSgB2gV+-h0AEkVvA9ufb7+3C7A@mail.gmail.com>
References: <CAFJf9KMwY3L-Yxz_zVAgrusWSgB2gV+-h0AEkVvA9ufb7+3C7A@mail.gmail.com>
Message-ID: <CABPTjTC08DgTw90gvwLJdjw8hP76bqZRRgBz_PJ_n4-FJH30vg@mail.gmail.com>

Am 10. April 2012 20:55 schrieb John Sturdy <jcg.sturdy at gmail.com>:
> (1) a "payment:cards" key, intended specifically for use with the
> value "no", to indicate that a shop / pub / whatever doesn't take
> electronic payment;


the mostly used keys are:
payment:credit_cards
payment:account_cards


> (2) a "payment:other" key, intended specifically for use with the
> value "no", to indicate that a shop / pub / whatever takes only the
> forms of payment that have been listed with other keys.


you could also tag:

payment:cash=only

and no other key would be needed.

cheers,
Martin


From jcg.sturdy at gmail.com  Wed Apr 11 11:32:57 2012
From: jcg.sturdy at gmail.com (John Sturdy)
Date: Wed, 11 Apr 2012 11:32:57 +0100
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
Message-ID: <CAFJf9KM6Hpu3bru5YJ-Z9xpTHQ5NC3Fa4oAwkNAJOjU6NBKH9g@mail.gmail.com>

On Wed, Apr 11, 2012 at 9:22 AM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
> Am 10. April 2012 22:01 schrieb Kom?pa <me at komzpa.net>:
>> It's possible to have pedestrian routing without separate ways for
>> sidewalks, but it's nicer when it shows you where you can actually
>> cross the road.
> The thing is that you can generally cross any road at any spot, as
> long it is not impossible or too dangerous ;-), i.e. in most of the
> cases you can simply cross the road if your destination is right on
> the other side for example.

I think that in some countries this is illegal.

> With explicit footways your router will
> send you to the next crossing and tell you to cross the road there and
> then come back.

This is probably useful information for blind people.


From phil at trigpoint.me.uk  Wed Apr 11 11:47:30 2012
From: phil at trigpoint.me.uk (phil at trigpoint.me.uk)
Date: Wed, 11 Apr 2012 11:47:30 +0100
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CAFJf9KM6Hpu3bru5YJ-Z9xpTHQ5NC3Fa4oAwkNAJOjU6NBKH9g@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<CAFJf9KM6Hpu3bru5YJ-Z9xpTHQ5NC3Fa4oAwkNAJOjU6NBKH9g@mail.gmail.com>
Message-ID: <ud3gvz.m2b9zv.2zlsav-qmf@auth.smtp.oneandone.co.uk>

I am wondering what happens where there are no crossings, or outside of built up areas where there are no sidewalks.

Phil


On 11/04/2012 11:32 John Sturdy wrote:

On Wed, Apr 11, 2012 at 9:22 AM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
> Am 10. April 2012 22:01 schrieb Kom?pa <me at komzpa.net>:
>> It's possible to have pedestrian routing without separate ways for
>> sidewalks, but it's nicer when it shows you where you can actually
>> cross the road.
> The thing is that you can generally cross any road at any spot, as
> long it is not impossible or too dangerous ;-), i.e. in most of the
> cases you can simply cross the road if your destination is right on
> the other side for example.

I think that in some countries this is illegal.

> With explicit footways your router will
> send you to the next crossing and tell you to cross the road there and
> then come back.

This is probably useful information for blind people.

_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120411/7bc93844/attachment.html>

From phil at trigpoint.me.uk  Wed Apr 11 12:04:42 2012
From: phil at trigpoint.me.uk (phil at trigpoint.me.uk)
Date: Wed, 11 Apr 2012 12:04:42 +0100
Subject: [Tagging] Extension of the "payment:*" keys
In-Reply-To: <CABPTjTC08DgTw90gvwLJdjw8hP76bqZRRgBz_PJ_n4-FJH30vg@mail.gmail.com>
References: <CAFJf9KMwY3L-Yxz_zVAgrusWSgB2gV+-h0AEkVvA9ufb7+3C7A@mail.gmail.com>
	<CABPTjTC08DgTw90gvwLJdjw8hP76bqZRRgBz_PJ_n4-FJH30vg@mail.gmail.com>
Message-ID: <lcic0w.m2bas0.2zlsav-qmf@auth.smtp.oneandone.co.uk>

You also need:
payment:debit_cards for shops such as aldi and lidl.

Phil


On 11/04/2012 11:09 Martin Koppenhoefer wrote:

Am 10. April 2012 20:55 schrieb John Sturdy <jcg.sturdy at gmail.com>:
> (1) a "payment:cards" key, intended specifically for use with the
> value "no", to indicate that a shop / pub / whatever doesn't take
> electronic payment;


the mostly used keys are:
payment:credit_cards
payment:account_cards


> (2) a "payment:other" key, intended specifically for use with the
> value "no", to indicate that a shop / pub / whatever takes only the
> forms of payment that have been listed with other keys.


you could also tag:

payment:cash=only

and no other key would be needed.

cheers,
Martin

_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120411/43c8fc1b/attachment.html>

From edaversa at yahoo.com  Wed Apr 11 12:29:12 2012
From: edaversa at yahoo.com (Emiliano D'Aversa)
Date: Wed, 11 Apr 2012 04:29:12 -0700 (PDT)
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CABPTjTC1W-E5k-EE-EdvAdyYH9gwEw0Din=mx-n1azBosxbpCQ@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<CAC8Q8t+WaSvUovs+AAU1wBxuR-5d_gVAk7Y9u9RGvyaabEEhtg@mail.gmail.com>
	<CABPTjTC1W-E5k-EE-EdvAdyYH9gwEw0Din=mx-n1azBosxbpCQ@mail.gmail.com>
Message-ID: <1334143752.17333.YahooMailNeo@web43142.mail.sp1.yahoo.com>





________________________________
Da: Martin Koppenhoefer <dieterdreist at gmail.com>
A: "Tag discussion, strategy and related tools" <tagging at openstreetmap.org> 
Inviato: Mercoled? 11 Aprile 2012 11:35
Oggetto: Re: [Tagging] sidewalks and tagging for the renderer


Am 11. April 2012 10:49 schrieb Kom?pa <me at komzpa.net>:
> First, there are road behaviour rules, that basically disallow that.
> You MUST go to crossing to cross a road here.

you can't asume this to be a global law. In other countries (e.g.
Germany or Italy) you must use a pedestrian crossing if it is close to
you. If you are more then x meters away (i.e. you are in the middle of
a road) you can simply cross anywhere, provided you don't endanger the
traffic or yourself. 
?
In Italy this is true (only if you cross perpendicularly to the street), but how?can we map where this is not possible without drawing the sidewalk separately??I'm not so experienced in tagging and I wonder which tags can we use on the?highway for cases like?in [1] or even more complicated??Maybe if you are in shape you can jump over the fence :-), if you are in a wheelchair you can't even cross?the small step of the sidewalk..?

[1] http://maps.google.it/maps?hl=it&ll=41.886113,12.528148&spn=0.000064,0.042787&t=m&z=15&layer=c&cbll=41.886165,12.503703&panoid=pWjJuW1TM-RXzrD5-gI8iw&cbp=12,354.51,,0,11.24

Cheers,
Emiliano
_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120411/724af709/attachment.html>

From slhope at gmail.com  Wed Apr 11 13:04:27 2012
From: slhope at gmail.com (Stephen Hope)
Date: Wed, 11 Apr 2012 22:04:27 +1000
Subject: [Tagging] Turn Restriction usage
Message-ID: <CAF1ph740i_hz64ev_td0pEOTEGPGmyCJNLSMo5kB5A75rMEEsA@mail.gmail.com>

I've been clearing up some routing bugs reported in my area on Mapdust.
Some of them are valid errors, and I've fixed them. Some I'm not so sure
about.

In one case there is a road where a two way section comes to a divider and
becomes two one way sections for a while. The suggested route came along
one of the one way sections, then turned about 340 degrees to go down the
other side of the road. It may be legal to do a u-turn there, but I don't
think it's safe, or even possible for most cars. I was thinking about it,
and many other divided road are similar where they split/join. Should we be
putting no u-turn restrictions on these? There's no actual signs.

The other thing I was wondering about is traffic lights.  Where I live, it
is illegal to do a u-turn at an intersection with traffic lights unless
there is a sign allowing you to. There's no signs saying not to, you're
just supposed to know. There has been some discussion in the past with
routers that have this sort of knowledge built in. Did anything come of
this, or should I just start putting four turn restriction relations on all
the traffic light intersections in my neighbourhood? That's going to be
painful, not to mention causing a lot of road splitting.

Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120411/37c1c5a9/attachment.html>

From simone.saviolo at gmail.com  Wed Apr 11 13:10:52 2012
From: simone.saviolo at gmail.com (Simone Saviolo)
Date: Wed, 11 Apr 2012 14:10:52 +0200
Subject: [Tagging] Extension of the "payment:*" keys
In-Reply-To: <lcic0w.m2bas0.2zlsav-qmf@auth.smtp.oneandone.co.uk>
References: <CAFJf9KMwY3L-Yxz_zVAgrusWSgB2gV+-h0AEkVvA9ufb7+3C7A@mail.gmail.com>
	<CABPTjTC08DgTw90gvwLJdjw8hP76bqZRRgBz_PJ_n4-FJH30vg@mail.gmail.com>
	<lcic0w.m2bas0.2zlsav-qmf@auth.smtp.oneandone.co.uk>
Message-ID: <CAJJ1XA4EVoKXftcOj8isW_4J8P7PgGLv6j3igDy6HLATbp5wMw@mail.gmail.com>

2012/4/11  <phil at trigpoint.me.uk>:
> You also need:
>
> payment:debit_cards for shops such as aldi and lidl.

Would you mind to clarify that? Debit cards
(http://en.wikipedia.org/wiki/Debit_card) are accepted in most shops,
not only Lidl. I'm not sure I understood what you meant.

Thanks,

Simone


From info at 4x4falcon.com  Wed Apr 11 13:12:54 2012
From: info at 4x4falcon.com (Ross Scanlon)
Date: Wed, 11 Apr 2012 20:12:54 +0800
Subject: [Tagging] Turn Restriction usage
In-Reply-To: <CAF1ph740i_hz64ev_td0pEOTEGPGmyCJNLSMo5kB5A75rMEEsA@mail.gmail.com>
References: <CAF1ph740i_hz64ev_td0pEOTEGPGmyCJNLSMo5kB5A75rMEEsA@mail.gmail.com>
Message-ID: <4F857546.7020100@4x4falcon.com>

> In one case there is a road where a two way section comes to a divider
> and becomes two one way sections for a while. The suggested route came
> along one of the one way sections, then turned about 340 degrees to go
> down the other side of the road. It may be legal to do a u-turn there,
> but I don't think it's safe, or even possible for most cars. I was
> thinking about it, and many other divided road are similar where they
> split/join. Should we be putting no u-turn restrictions on these?
> There's no actual signs.

No.  The router should know not to do this. Likewise as below the router 
should not make u turns at traffic lights.


> The other thing I was wondering about is traffic lights.  Where I live,
> it is illegal to do a u-turn at an intersection with traffic lights
> unless there is a sign allowing you to. There's no signs saying not to,
> you're just supposed to know. There has been some discussion in the past
> with routers that have this sort of knowledge built in. Did anything
> come of this, or should I just start putting four turn restriction
> relations on all the traffic light intersections in my neighbourhood?
> That's going to be painful, not to mention causing a lot of road splitting.
>
> Stephen

Cheers
Ross


From simone.saviolo at gmail.com  Wed Apr 11 13:25:05 2012
From: simone.saviolo at gmail.com (Simone Saviolo)
Date: Wed, 11 Apr 2012 14:25:05 +0200
Subject: [Tagging] Turn Restriction usage
In-Reply-To: <4F857546.7020100@4x4falcon.com>
References: <CAF1ph740i_hz64ev_td0pEOTEGPGmyCJNLSMo5kB5A75rMEEsA@mail.gmail.com>
	<4F857546.7020100@4x4falcon.com>
Message-ID: <CAJJ1XA5VFFdch5pgtQP5q6ntZu52QqhXUWfisyhnFkHjSY6ouw@mail.gmail.com>

2012/4/11 Ross Scanlon <info at 4x4falcon.com>:
>> In one case there is a road where a two way section comes to a divider
>> and becomes two one way sections for a while. The suggested route came
>> along one of the one way sections, then turned about 340 degrees to go
>> down the other side of the road. It may be legal to do a u-turn there,
>> but I don't think it's safe, or even possible for most cars. I was
>> thinking about it, and many other divided road are similar where they
>> split/join. Should we be putting no u-turn restrictions on these?
>> There's no actual signs.
>
> No. ?The router should know not to do this. Likewise as below the router
> should not make u turns at traffic lights.

Based on what? How does the router know that the two ways are two
carriageways of a single road? Couldn't they be a straight road, that
becomes a oneway street at a certain point, and at that point a
junction brings to a oneway secondary road?

Regards,

Simone


From phil at trigpoint.me.uk  Wed Apr 11 13:35:54 2012
From: phil at trigpoint.me.uk (phil at trigpoint.me.uk)
Date: Wed, 11 Apr 2012 13:35:54 +0100
Subject: [Tagging] Extension of the "payment:*" keys
In-Reply-To: <CAJJ1XA4EVoKXftcOj8isW_4J8P7PgGLv6j3igDy6HLATbp5wMw@mail.gmail.com>
References: <CAFJf9KMwY3L-Yxz_zVAgrusWSgB2gV+-h0AEkVvA9ufb7+3C7A@mail.gmail.com>
	<CABPTjTC08DgTw90gvwLJdjw8hP76bqZRRgBz_PJ_n4-FJH30vg@mail.gmail.com>
	<lcic0w.m2bas0.2zlsav-qmf@auth.smtp.oneandone.co.uk>
	<CAJJ1XA4EVoKXftcOj8isW_4J8P7PgGLv6j3igDy6HLATbp5wMw@mail.gmail.com>
Message-ID: <7v6azm.m2bf02.2zlsav-qmf@auth.smtp.oneandone.co.uk>

Debit cards are accepted in most shops, but not usually accepted in pubs.
The point I was making is that Aldi and Lidl accept debit cards but not credit cards.

Phil


On 11/04/2012 13:10 Simone Saviolo wrote:

2012/4/11 <phil at trigpoint.me.uk>:
> You also need:
>
> payment:debit_cards for shops such as aldi and lidl.

Would you mind to clarify that? Debit cards
(http://en.wikipedia.org/wiki/Debit_card) are accepted in most shops,
not only Lidl. I'm not sure I understood what you meant.

Thanks,

Simone

_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120411/b11adad2/attachment-0001.html>

From info at 4x4falcon.com  Wed Apr 11 13:52:33 2012
From: info at 4x4falcon.com (Ross Scanlon)
Date: Wed, 11 Apr 2012 20:52:33 +0800
Subject: [Tagging] Turn Restriction usage
In-Reply-To: <CAJJ1XA5VFFdch5pgtQP5q6ntZu52QqhXUWfisyhnFkHjSY6ouw@mail.gmail.com>
References: <CAF1ph740i_hz64ev_td0pEOTEGPGmyCJNLSMo5kB5A75rMEEsA@mail.gmail.com>
	<4F857546.7020100@4x4falcon.com>
	<CAJJ1XA5VFFdch5pgtQP5q6ntZu52QqhXUWfisyhnFkHjSY6ouw@mail.gmail.com>
Message-ID: <4F857E91.7000701@4x4falcon.com>

>> No.  The router should know not to do this. Likewise as below the router
>> should not make u turns at traffic lights.
>
> Based on what? How does the router know that the two ways are two
> carriageways of a single road? Couldn't they be a straight road, that
> becomes a oneway street at a certain point, and at that point a
> junction brings to a oneway secondary road?

The name of the way, the fact that you are turning > 180 degrees on the 
same way.

Cheers
Ross



From phil at trigpoint.me.uk  Wed Apr 11 13:54:31 2012
From: phil at trigpoint.me.uk (phil at trigpoint.me.uk)
Date: Wed, 11 Apr 2012 13:54:31 +0100
Subject: [Tagging] Extension of the "payment:*" keys
In-Reply-To: <7v6azm.m2bf02.2zlsav-qmf@auth.smtp.oneandone.co.uk>
References: <CAFJf9KMwY3L-Yxz_zVAgrusWSgB2gV+-h0AEkVvA9ufb7+3C7A@mail.gmail.com>
	<CABPTjTC08DgTw90gvwLJdjw8hP76bqZRRgBz_PJ_n4-FJH30vg@mail.gmail.com>
	<lcic0w.m2bas0.2zlsav-qmf@auth.smtp.oneandone.co.uk>
	<CAJJ1XA4EVoKXftcOj8isW_4J8P7PgGLv6j3igDy6HLATbp5wMw@mail.gmail.com>
	<7v6azm.m2bf02.2zlsav-qmf@auth.smtp.oneandone.co.uk>
Message-ID: <v1032i.m2bfv2.2zlsav-qmf@auth.smtp.oneandone.co.uk>

I should add that the most useful key would be:
cards_accepted:amex

As a general rule, everywhere accepts debit cards, non-foodie pubs are cash only.

The helpful tag would be amex as so few places accept it, and all of my business expenses should be on my corporate amex card, usual routine is to walk in to several resturants and walk out again, until I find one that will take it.

Phil


On 11/04/2012 13:35 phil at trigpoint.me.uk wrote:

Debit cards are accepted in most shops, but not usually accepted in pubs.
The point I was making is that Aldi and Lidl accept debit cards but not credit cards.

Phil


On 11/04/2012 13:10 Simone Saviolo wrote:

2012/4/11 <phil at trigpoint.me.uk>:
> You also need:
>
> payment:debit_cards for shops such as aldi and lidl.

Would you mind to clarify that? Debit cards
(http://en.wikipedia.org/wiki/Debit_card) are accepted in most shops,
not only Lidl. I'm not sure I understood what you meant.

Thanks,

Simone

_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120411/d3f36bdd/attachment.html>

From simone.saviolo at gmail.com  Wed Apr 11 14:42:06 2012
From: simone.saviolo at gmail.com (Simone Saviolo)
Date: Wed, 11 Apr 2012 15:42:06 +0200
Subject: [Tagging] Turn Restriction usage
In-Reply-To: <4F857E91.7000701@4x4falcon.com>
References: <CAF1ph740i_hz64ev_td0pEOTEGPGmyCJNLSMo5kB5A75rMEEsA@mail.gmail.com>
	<4F857546.7020100@4x4falcon.com>
	<CAJJ1XA5VFFdch5pgtQP5q6ntZu52QqhXUWfisyhnFkHjSY6ouw@mail.gmail.com>
	<4F857E91.7000701@4x4falcon.com>
Message-ID: <CAJJ1XA424W2mAEL_gEU7T-V1aN-zs=t7rEsoxe0mWRym8OTRtA@mail.gmail.com>

2012/4/11 Ross Scanlon <info at 4x4falcon.com>:
>>> No. ?The router should know not to do this. Likewise as below the router
>>> should not make u turns at traffic lights.
>>
>>
>> Based on what? How does the router know that the two ways are two
>> carriageways of a single road? Couldn't they be a straight road, that
>> becomes a oneway street at a certain point, and at that point a
>> junction brings to a oneway secondary road?
>
>
> The name of the way, the fact that you are turning > 180 degrees on the same
> way.

I don't agree.

First, if you're on the same way, you're not turning, but going
straight and following the road. In the case of the OP, I expect to
see three ways, two of which tagged oneway=yes.

Second, if you turn more than 180 degrees, you're hopefully going on a
bridge ;-)

Third, think of a situation like this: http://osm.org/go/0CKuMhs89-
Suppose that the tertiary has to be split at the junction for any
reason (a relation needs only a part of it, or the surface changes, or
the incline changes, whatever). Also suppose that the tertiary is
oneway=yes. You would end up with two ways with the same name, both
oneway=yes, with an acute angle between them and a third way exiting
from the junction. Would you, as a router, ban the prosecution on the
tertiary?

Regards,

Simone


From lowflight66 at googlemail.com  Wed Apr 11 14:42:29 2012
From: lowflight66 at googlemail.com (fly)
Date: Wed, 11 Apr 2012 15:42:29 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <4F83B31D.5020502@gmail.com>
References: <4F745D0C.2020206@infoware.de> <4F83A9FE.9010904@gmail.com>
	<4F83B31D.5020502@gmail.com>
Message-ID: <4F858A45.2010603@googlemail.com>

On 10/04/12 06:12, Martijn van Exel wrote:
> On 4/9/2012 9:33 PM, Martijn van Exel wrote:
>> On 3/29/2012 7:01 AM, Heinrich Knauf wrote:
>>> Hello,
>>>
>>> infoware GmbH, Bonn, Germany, and Geofabrik GmbH, Karlsruhe, Germany,
>>> have developed an
>>> improved tagging scheme for TMC data which we would like to propopose
>>> to the OSM community.
>>>
>>> Currently, this feature is explained in German only.
>>>
>>> Pelase refer to
>>>
>>> http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme
>>>
>>> http://wiki.openstreetmap.org/wiki/Proposed_features/New_TMC_Scheme
>>>
>>> Your comments are greatly appreceated!

I still do not get one major point which was totally left out on the first
scheme. What actually belongs to a "point" and how are they tagged. Especially
on big crossings and roundabouts I always was confused (e.g. it might be
possible that a part of this point is blocked but how do I know which one and
you might be able to use  the first/last exit/entrance of a junction but not the
rest. )


>> That looks like a huge improvement from the existing proposal. A few
>> questions for clarification and discussion:
>> * In this proposal, the actual TMC LCDs are not technically required,
>> are they? If all the ways are tagged according to this schema, you can
>> look up the segments just by looking at the ways? I guess having the LCD
>> encoded onto nodes will speed up lookup.
>> * How do you plan to make this huge effort (even just for Germany)
>> manageable? I mean, it's simpler than it looks, but it still is a *lot*
>> of work. A JOSM plugin? A dedicated website to track progress and show
>> bugs / inconsistencies? Other supporting tools for mappers?

There was only the inspector and a overlay for the first round in Germany and it
worked.

> On that topic: how was this updated? Manually? Or was there some monitoring bot
> active that kept these values updated?
> https://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany/Roads#roads_to_import_2

Think this was all handwork.


cu fly


From baloo at ursamundi.org  Wed Apr 11 15:07:36 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Wed, 11 Apr 2012 07:07:36 -0700
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CABPTjTC1W-E5k-EE-EdvAdyYH9gwEw0Din=mx-n1azBosxbpCQ@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<CAC8Q8t+WaSvUovs+AAU1wBxuR-5d_gVAk7Y9u9RGvyaabEEhtg@mail.gmail.com>
	<CABPTjTC1W-E5k-EE-EdvAdyYH9gwEw0Din=mx-n1azBosxbpCQ@mail.gmail.com>
Message-ID: <CAMPM96p1bNv23KtyjVwTxV9dMFVXSWRDDS1_0_y0xXHetq=Hjw@mail.gmail.com>

On Wed, Apr 11, 2012 at 2:35 AM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
> Am 11. April 2012 10:49 schrieb Kom?pa <me at komzpa.net>:
>> First, there are road behaviour rules, that basically disallow that.
>> You MUST go to crossing to cross a road here.
>
> you can't asume this to be a global law. In other countries (e.g.
> Germany or Italy) you must use a pedestrian crossing if it is close to
> you. If you are more then x meters away (i.e. you are in the middle of
> a road) you can simply cross anywhere, provided you don't endanger the
> traffic or yourself. I find it difficult to believe that belarussian
> law urges pedestrians to only cross on a crossing, and if there is
> none, they will have to walk kilometers just to cross the street, or
> did I get this wrong?

This seems like something the router would need to be more aware of
than anything; mapping the sidewalks as adjacent footways would allow
safety- and/or citation-conscious pedestrians to get routed ideally on
the sidewalks, while pedestrians that aren't bound by such obligations
could still get routed across the open space (many routers, Garmin
included, have been known to do some routing parkour with open spaces
given that pedestrians aren't anywhere near as bound to known mapped
objects as vehicles are).


From phil at trigpoint.me.uk  Wed Apr 11 15:22:50 2012
From: phil at trigpoint.me.uk (phil at trigpoint.me.uk)
Date: Wed, 11 Apr 2012 15:22:50 +0100
Subject: [Tagging] Turn Restriction usage
In-Reply-To: <CAJJ1XA424W2mAEL_gEU7T-V1aN-zs=t7rEsoxe0mWRym8OTRtA@mail.gmail.com>
References: <CAF1ph740i_hz64ev_td0pEOTEGPGmyCJNLSMo5kB5A75rMEEsA@mail.gmail.com>
	<4F857546.7020100@4x4falcon.com>
	<CAJJ1XA5VFFdch5pgtQP5q6ntZu52QqhXUWfisyhnFkHjSY6ouw@mail.gmail.com>
	<4F857E91.7000701@4x4falcon.com>
	<CAJJ1XA424W2mAEL_gEU7T-V1aN-zs=t7rEsoxe0mWRym8OTRtA@mail.gmail.com>
Message-ID: <us4iw4.m2bjya.2zlsav-qmf@auth.smtp.oneandone.co.uk>

I found a similar problem with u-turns while investigating a mapdust bug.
http://map.project-osrm.org/hC

Not wrong, u turns are allowed for vehicles under 7.5 tonnes, but not sensible either. 

My commercial satnav told me to do a u turn here, http://bit.ly/HBOoJv, I didn't.

Phil


On 11/04/2012 14:42 Simone Saviolo wrote:

2012/4/11 Ross Scanlon <info at 4x4falcon.com>:
>>> No.  The router should know not to do this. Likewise as below the router
>>> should not make u turns at traffic lights.
>>
>>
>> Based on what? How does the router know that the two ways are two
>> carriageways of a single road? Couldn't they be a straight road, that
>> becomes a oneway street at a certain point, and at that point a
>> junction brings to a oneway secondary road?
>
>
> The name of the way, the fact that you are turning > 180 degrees on the same
> way.

I don't agree.

First, if you're on the same way, you're not turning, but going
straight and following the road. In the case of the OP, I expect to
see three ways, two of which tagged oneway=yes.

Second, if you turn more than 180 degrees, you're hopefully going on a
bridge ;-)

Third, think of a situation like this: http://osm.org/go/0CKuMhs89-
Suppose that the tertiary has to be split at the junction for any
reason (a relation needs only a part of it, or the surface changes, or
the incline changes, whatever). Also suppose that the tertiary is
oneway=yes. You would end up with two ways with the same name, both
oneway=yes, with an acute angle between them and a third way exiting
from the junction. Would you, as a router, ban the prosecution on the
tertiary?

Regards,

Simone

_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120411/cc01c38f/attachment.html>

From osm at tobias-knerr.de  Wed Apr 11 16:21:59 2012
From: osm at tobias-knerr.de (Tobias Knerr)
Date: Wed, 11 Apr 2012 17:21:59 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F84CA81.7070109@gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<4F847F29.4060808@gmail.com> <4F84860B.1080904@gmail.com>
	<4F8494D7.3080008@tobias-knerr.de> <4F84AFC0.7090400@gmail.com>
	<4F84B65B.1030501@tobias-knerr.de> <4F84CA81.7070109@gmail.com>
Message-ID: <4F85A197.7040604@tobias-knerr.de>

On 11.04.2012 02:04, Martijn van Exel wrote:
> On 4/10/2012 4:38 PM, Tobias Knerr wrote:
>> A sidewalk=left/right/both fails when you want to define the relative
>> ordering, and separate footway=cycleway fail in practice because no
>> renderer is actually able to puzzle the highway back together from
>> unconnected parallel ways.
> 
> What is the use case for being able to do that? What can you do that you
> can't with a separate geometry for a sidewalk that may be as much as 6
> feet from the main roadway?

For one, you can render them without overlaps and gaps between the
sidewalk and roadway.

Around here, sidewalks are usually just the width of a kerb (~ 15 cm)
away from the main roadway. That's not wider than a white line on the
road and isn't much of a physical separation (which contributes to my
reluctance to treat them as separate ways).

This also means that, with separate ways for the sidewalk, the mapper
would have to draw with unlikely precision to avoid graphical glitches -
a few pixels too far from the road, and there's a very noticeable gap
between road and sidewalk that does not exist in reality. A few pixels
less, and the sidewalk disappears below the road - or the other way round.

And of course: As soon as you don't render road and/or sidewalk not to
scale, rendering breaks down even with centimetre-precise mapping.
With tags on a highway, on the other hand, the sidewalk is part of the
render style of the highway and is always placed perfectly.

Besides rendering, other reasons why a program would want to associate
the sidewalk with the highway include: routing instructions; adding the
possibility to cross the road anywhere to the routing graph where this
is allowed; and accessing the name or other attributes of the highway
(unless all relevant tags are copied to the sidewalk).

Tobias


From neroute2 at gmail.com  Wed Apr 11 18:28:08 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Wed, 11 Apr 2012 13:28:08 -0400
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
Message-ID: <4F85BF28.7040508@gmail.com>

On 4/11/2012 4:22 AM, Martin Koppenhoefer wrote:
> If sidewalks were tagged without the highway tag, routing would
> continue to work like it does for everybody

Except when a motorway has a sidewalk.


From stevagewp at gmail.com  Wed Apr 11 23:31:53 2012
From: stevagewp at gmail.com (Steve Bennett)
Date: Thu, 12 Apr 2012 08:31:53 +1000
Subject: [Tagging] Wikifiddling,
	surface=cobblestone vs. sett & paving_stones
In-Reply-To: <CABPTjTB2CrPmZSZs9rboOWHbQ4WjdLEABOMRBa5pZyx_QxpJZQ@mail.gmail.com>
References: <CABPTjTAgawEmKoCfXvV=+wAzwjv4M4v8iDWmCoa8uQfaavwVsw@mail.gmail.com>
	<4F4245DD.7050300@jonno.cix.co.uk> <4F425337.802@tobias-knerr.de>
	<CAMLmWVteinYd8wzq8y482DAwQvYw32us+zM2KbNGWuQH1bbFqg@mail.gmail.com>
	<CABPTjTDjK73H9Q4xDO-E9mgd8ExvWfXf8=XNZf=nU-M8qw6xKg@mail.gmail.com>
	<CABPTjTB2CrPmZSZs9rboOWHbQ4WjdLEABOMRBa5pZyx_QxpJZQ@mail.gmail.com>
Message-ID: <CA+z=q=uho+5A0D+TBBwQ8W3ySJLyZRO6R0-bPevLqu2RAC-ETA@mail.gmail.com>

Clearly the change that was made was disruptive and changes the
meaning of the 80,000 or so surface=cobblestone tags already in
existence. I have thus changed the definition back and commented out
surface=sett for the moment.

Now, some issues with introducing sett:
1) No one knows what "sett" means.
2) The distinction is probably not important to most people.
3) There is far more sett than true cobblestone in the world.
4) We can't introduce a distinction by splitting an existing tag this
way. Clearly surface=cobblestone means "Cobblestone or sett". There
are too many instances to change that.

So, whoever really wants to introduce this distinction is going to
have to find another way, perhaps "surface=cobblestone,
cobblestone=sett".

Steve

On Wed, Apr 11, 2012 at 7:56 PM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
> I'm pushing this one up because we have taken no action so far. Can we
> agree how we want to deal with this?
>
> here is the full thread:
> http://gis.19327.n5.nabble.com/Wikifiddling-surface-cobblestone-vs-sett-amp-paving-stones-tt5498912.html#none
>
> cheers,
> Martin
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging


From slhope at gmail.com  Thu Apr 12 00:02:56 2012
From: slhope at gmail.com (Stephen Hope)
Date: Thu, 12 Apr 2012 09:02:56 +1000
Subject: [Tagging] Turn Restriction usage
In-Reply-To: <4F857546.7020100@4x4falcon.com>
References: <CAF1ph740i_hz64ev_td0pEOTEGPGmyCJNLSMo5kB5A75rMEEsA@mail.gmail.com>
	<4F857546.7020100@4x4falcon.com>
Message-ID: <CAF1ph76i_wX1fAYDhP5sv8+dnD52R7ZwTCsruhfvi2cDGOzWdA@mail.gmail.com>

On 11 April 2012 22:12, Ross Scanlon <info at 4x4falcon.com> wrote:

 Likewise as below the router should not make u turns at traffic lights.
>


I don't have a problem with this, except we then are going to need some way
to tag "U-turn allowed" to mark the cases where you are allowed to turn.
These are generally traffic lights that have a turning lane for cross
traffic and a dedicated turn signal.

If we started using a "U-turn allowed" turn restriction, would that be too
confusing?


Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120412/f2367d42/attachment.html>

From dieterdreist at gmail.com  Thu Apr 12 00:07:37 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Thu, 12 Apr 2012 01:07:37 +0200
Subject: [Tagging] Extension of the "payment:*" keys
In-Reply-To: <v1032i.m2bfv2.2zlsav-qmf@auth.smtp.oneandone.co.uk>
References: <CAFJf9KMwY3L-Yxz_zVAgrusWSgB2gV+-h0AEkVvA9ufb7+3C7A@mail.gmail.com>
	<CABPTjTC08DgTw90gvwLJdjw8hP76bqZRRgBz_PJ_n4-FJH30vg@mail.gmail.com>
	<lcic0w.m2bas0.2zlsav-qmf@auth.smtp.oneandone.co.uk>
	<CAJJ1XA4EVoKXftcOj8isW_4J8P7PgGLv6j3igDy6HLATbp5wMw@mail.gmail.com>
	<7v6azm.m2bf02.2zlsav-qmf@auth.smtp.oneandone.co.uk>
	<v1032i.m2bfv2.2zlsav-qmf@auth.smtp.oneandone.co.uk>
Message-ID: <CABPTjTDRe=VYCpCk99Ji_XkWEw5bpsvpp5ZkB=4gVdo=MULYzQ@mail.gmail.com>

Am 11. April 2012 14:54 schrieb  <phil at trigpoint.me.uk>:
> I should add that the most useful key would be:
>
> cards_accepted:amex


Please, read the mails, the OP already linked to the wiki page with
definitions for these and for debit cards:
http://wiki.openstreetmap.org/wiki/Payment

The problem was: "there's no concise way of doing this: I'd have to
mark it as "payment:<whatever>=no" for every type of card. "

cheers,
Martin


From phil at trigpoint.me.uk  Thu Apr 12 00:17:38 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Thu, 12 Apr 2012 00:17:38 +0100
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F85BF28.7040508@gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com>
Message-ID: <1334186258.1972.62.camel@marvin>

On Wed, 2012-04-11 at 13:28 -0400, Nathan Edgars II wrote:
> On 4/11/2012 4:22 AM, Martin Koppenhoefer wrote:
> > If sidewalks were tagged without the highway tag, routing would
> > continue to work like it does for everybody
> 
> Except when a motorway has a sidewalk.
Do motorways ever have a sidewalk? Sometimes a footpath/cycle track
follows the motorway, and often there are footpath/cycle tracks where
motorway bridges cross estuarys, but they are separate ways.

Phil



From neroute2 at gmail.com  Thu Apr 12 00:50:10 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Wed, 11 Apr 2012 19:50:10 -0400
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <1334186258.1972.62.camel@marvin>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
Message-ID: <4F8618B2.4000609@gmail.com>

On 4/11/2012 7:17 PM, Philip Barnes wrote:
> On Wed, 2012-04-11 at 13:28 -0400, Nathan Edgars II wrote:
>> On 4/11/2012 4:22 AM, Martin Koppenhoefer wrote:
>>> If sidewalks were tagged without the highway tag, routing would
>>> continue to work like it does for everybody
>>
>> Except when a motorway has a sidewalk.
> Do motorways ever have a sidewalk? Sometimes a footpath/cycle track
> follows the motorway, and often there are footpath/cycle tracks where
> motorway bridges cross estuarys, but they are separate ways.

What are you asking? A sidewalk is almost always a separate physical way 
(if not, it's a shoulder, except on minor urban streets with flush 
sidewalks and no curb).


From osm at bavarianmallet.de  Thu Apr 12 07:26:19 2012
From: osm at bavarianmallet.de (Georg Feddern)
Date: Thu, 12 Apr 2012 08:26:19 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CABPTjTC1W-E5k-EE-EdvAdyYH9gwEw0Din=mx-n1azBosxbpCQ@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<CAC8Q8t+WaSvUovs+AAU1wBxuR-5d_gVAk7Y9u9RGvyaabEEhtg@mail.gmail.com>
	<CABPTjTC1W-E5k-EE-EdvAdyYH9gwEw0Din=mx-n1azBosxbpCQ@mail.gmail.com>
Message-ID: <4F86758B.5020202@bavarianmallet.de>

Am 11.04.2012 11:35, schrieb Martin Koppenhoefer:
> in the case of parallel ways it is impossible to tell whether you can
> filter them out or not (there could be a separation or they could be
> on different height levels), especially if people are mapping
> sidewalks the same as separated footways.

Thats a point - and the differentiation should be really considered in 
the tagging.

>   My main concern is routing,
> not rendering. I wouldn't take them into account in routing, because I
> feel you would get worse results.
> E.g. 100 m South of the spot you posted above:
> http://www.openstreetmap.org/?mlat=53.865988&mlon=27.651201&zoom=18&layers=M
> Imagine you stand there and want to go to the parking on the other
> side of the road:

You take very 'short way' examples - to show the point of concern, thats ok.
But these are examples where - I think - no one would even consider to 
use routing.
On the other hand:
1.
Use 'practicable' examples (far longer ways) and you will see, that many 
(not all) of these 'problems' fade away, because the routing will use 
those crossings anyway and lead to the right side before .
If there is no sidewalk on the destination side or another adequate 
footway - it will use your approach anyway ...
2.
A person who can see the situation can see the routing too - and may 
shorten the route on his own risk.
A person who does not .. well, I would not recommend them a shorting 
anyway ...

> Another similar issue is that with these sidewalks people often don't
> connect crossing footways to the street, they only connect them to the
> sidewalk. There are examples for this also in your area, so
> unfortunately simply omitting them won't do the job either, because
> you would get gaps near crossings.

A crossing footway over a street with bothside sidewalk must not always 
be connected to the street - carriageway and sidewalk are considered as 
different transport route with different usage then.
For routing there is no need to connect them.
For renderer there is no need to consider which is top or bottom - he 
may choose  itself by usage preference. (Distinction of bridge and 
tunnel presumed.)
The signal points or the 'consider a hazard' points may be outside of 
the crossing point itself.
Connections are only needed at points where you can really use a parting 
transport way (which may be a street without sidewalk).

>
>> Third, try to cross these not on the crossing staying alive:
>> http://upload.wikimedia.org/wikipedia/commons/thumb/1/14/Partyzanski_praspekt_8.jpg/300px-Partyzanski_praspekt_8.jpg
>> http://kp.ru/f/4/image/26/67/396726.jpg
>
> I'll do next time I visit your town. What should be the problem? You
> wait until there is no car coming or all cars stop and then you cross.

Yes - I see, you have _seen_ the point already. ;-)

cheers,
Georg


From phil at trigpoint.me.uk  Thu Apr 12 07:33:31 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Thu, 12 Apr 2012 07:33:31 +0100
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F8618B2.4000609@gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com>
Message-ID: <1334212411.1972.69.camel@marvin>

On Wed, 2012-04-11 at 19:50 -0400, Nathan Edgars II wrote:
> On 4/11/2012 7:17 PM, Philip Barnes wrote:
> > On Wed, 2012-04-11 at 13:28 -0400, Nathan Edgars II wrote:
> >> On 4/11/2012 4:22 AM, Martin Koppenhoefer wrote:
> >>> If sidewalks were tagged without the highway tag, routing would
> >>> continue to work like it does for everybody
> >>
> >> Except when a motorway has a sidewalk.
> > Do motorways ever have a sidewalk? Sometimes a footpath/cycle track
> > follows the motorway, and often there are footpath/cycle tracks where
> > motorway bridges cross estuarys, but they are separate ways.
> 
> What are you asking? A sidewalk is almost always a separate physical way 
> (if not, it's a shoulder, except on minor urban streets with flush 
> sidewalks and no curb).

In the Netherlands I have sometimes seen cycleways paralleling
motorways, some 20-30 metres away, and on long estuary bridges there is
often a cycleway but beyond that motorways never have a sidewalk.

The term motorway implies a lot of rules,
No Pedestrians.
No Cyclists.
No Learner Drivers.
No Tracked Vehicles.
No Agricultural Vehicles.
No Motorcycles under 50cc.
Horses
Mobility Scooters

Phil 




From osm at bavarianmallet.de  Thu Apr 12 07:44:27 2012
From: osm at bavarianmallet.de (Georg Feddern)
Date: Thu, 12 Apr 2012 08:44:27 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <ud3gvz.m2b9zv.2zlsav-qmf@auth.smtp.oneandone.co.uk>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<CAFJf9KM6Hpu3bru5YJ-Z9xpTHQ5NC3Fa4oAwkNAJOjU6NBKH9g@mail.gmail.com>
	<ud3gvz.m2b9zv.2zlsav-qmf@auth.smtp.oneandone.co.uk>
Message-ID: <4F8679CB.2020906@bavarianmallet.de>

Am 11.04.2012 12:47, schrieb phil at trigpoint.me.uk:
> I am wondering what happens where there are no crossings, or outside of built up areas where there are no sidewalks.
>

That's quite easy:
Where there are no crossings - no crossings can be used, any routing 
will use the nearest point approach - with 'wild crossing' ("your 
destination is on the other side of the road") or "use the road" - the 
rest is your personal responsibility to adhere the laws and to preserve 
your health.
Where there are no sidewalks - well, there are no sidewalks, you and the 
router will have to use the 'road'.

A router that does consider sidewalks, will _prefer_ sidewalks and use 
roads otherwise.
A router that does not consider sidewalks will use the roads anyway.

Georg


From m at rtijn.org  Thu Apr 12 07:48:11 2012
From: m at rtijn.org (Martijn van Exel)
Date: Thu, 12 Apr 2012 00:48:11 -0600
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <1334212411.1972.69.camel@marvin>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
Message-ID: <CAGCum_4CagKcUr3k_j10eJgr6=yaKLeyAMfo6G3-FmhgOtDTnA@mail.gmail.com>

On Thu, Apr 12, 2012 at 12:33 AM, Philip Barnes <phil at trigpoint.me.uk>wrote:

>  The term motorway implies a lot of rules,
> No Pedestrians.
> No Cyclists.
>

Not necessarily. In some US states you can legally bike on the freeway.
Wyoming is one of them: 'Although bicyclists are discouraged from riding on
interstate highways, there are locations where alternate routes are not
available'[1].

[1]
http://www.dot.state.wy.us/files/content/sites/wydot/files/shared/Planning/Wyoming%20Bicycle%20&%20Pedestrian%20Transportation%20Plan.pdf,
page 5

-- 
martijn van exel
geospatial omnivore
1109 1st ave #2
salt lake city, ut 84103
801-550-5815
http://oegeo.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120412/2659b683/attachment.html>

From neroute2 at gmail.com  Thu Apr 12 08:12:36 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Thu, 12 Apr 2012 03:12:36 -0400
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <1334212411.1972.69.camel@marvin>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
Message-ID: <4F868064.30604@gmail.com>

On 4/12/2012 2:33 AM, Philip Barnes wrote:
> On Wed, 2012-04-11 at 19:50 -0400, Nathan Edgars II wrote:
>> On 4/11/2012 7:17 PM, Philip Barnes wrote:
>>> On Wed, 2012-04-11 at 13:28 -0400, Nathan Edgars II wrote:
>>>> On 4/11/2012 4:22 AM, Martin Koppenhoefer wrote:
>>>>> If sidewalks were tagged without the highway tag, routing would
>>>>> continue to work like it does for everybody
>>>>
>>>> Except when a motorway has a sidewalk.
>>> Do motorways ever have a sidewalk? Sometimes a footpath/cycle track
>>> follows the motorway, and often there are footpath/cycle tracks where
>>> motorway bridges cross estuarys, but they are separate ways.
>>
>> What are you asking? A sidewalk is almost always a separate physical way
>> (if not, it's a shoulder, except on minor urban streets with flush
>> sidewalks and no curb).
>
> In the Netherlands I have sometimes seen cycleways paralleling
> motorways, some 20-30 metres away, and on long estuary bridges there is
> often a cycleway but beyond that motorways never have a sidewalk.
>
> The term motorway implies a lot of rules,
> No Pedestrians.

Not in many U.S. states. But even where it does, there is the occasional 
(barrier-separated) sidewalk. No different from a sidewalk next to any 
other busy road. For example: 
http://www.panynj.gov/bridges-tunnels/gwb-pedestian-bicycle-info.html
http://www.commuterpageblog.com/2009/02/stupidest-bike-lane.html


From osm at bavarianmallet.de  Thu Apr 12 08:38:51 2012
From: osm at bavarianmallet.de (Georg Feddern)
Date: Thu, 12 Apr 2012 09:38:51 +0200
Subject: [Tagging] Turn Restriction usage
In-Reply-To: <CAJJ1XA424W2mAEL_gEU7T-V1aN-zs=t7rEsoxe0mWRym8OTRtA@mail.gmail.com>
References: <CAF1ph740i_hz64ev_td0pEOTEGPGmyCJNLSMo5kB5A75rMEEsA@mail.gmail.com>
	<4F857546.7020100@4x4falcon.com>
	<CAJJ1XA5VFFdch5pgtQP5q6ntZu52QqhXUWfisyhnFkHjSY6ouw@mail.gmail.com>
	<4F857E91.7000701@4x4falcon.com>
	<CAJJ1XA424W2mAEL_gEU7T-V1aN-zs=t7rEsoxe0mWRym8OTRtA@mail.gmail.com>
Message-ID: <4F86868B.3050105@bavarianmallet.de>

Am 11.04.2012 15:42, schrieb Simone Saviolo:
> 2012/4/11 Ross Scanlon<info at 4x4falcon.com>:
>>>> No.  The router should know not to do this. Likewise as below the router
>>>> should not make u turns at traffic lights.
>>>
>>> Based on what? How does the router know that the two ways are two
>>> carriageways of a single road? Couldn't they be a straight road, that
>>> becomes a oneway street at a certain point, and at that point a
>>> junction brings to a oneway secondary road?
>>
>> The name of the way, the fact that you are turning>  180 degrees on the same
>> way.
> I don't agree.
>
> First, if you're on the same way, you're not turning, but going
> straight and following the road. In the case of the OP, I expect to
> see three ways, two of which tagged oneway=yes.
>
> Second, if you turn more than 180 degrees, you're hopefully going on a
> bridge ;-)
>
> Third, think of a situation like this: http://osm.org/go/0CKuMhs89-
>

in your example the angle at the considered point is far from dangerous 
or considerable.
Your angle is in the range up to 45? and doesn't even reach 90? (a 
typical crossing / turn situation).

Points of no u-turn - that have to be considered - have angles
- beyond 90? (may be a sharp turn or a crossing at a combine situation)
- mostly beyond 120? and often beyond 150?
This is the range to consider - and that is possible for a router.
The angles depend a bit on the mapper's 'style' and should be considered 
by the mapper - but in most cases the angle will reach those range 
anyway - a split and combine would not be 'rectangle'.
(U-turns at dual-carriage ways with two 90? turns because of a via-way 
have to be considered separately.
If not allowed - even only by law - a turn restriction may be helpful 
there.)

Greetings
Georg


From openstreetmap at arlindopereira.com  Thu Apr 12 13:32:47 2012
From: openstreetmap at arlindopereira.com (Arlindo Pereira)
Date: Thu, 12 Apr 2012 09:32:47 -0300
Subject: [Tagging] [Talk-br] Superquadras in Brasilia?
In-Reply-To: <07FE0337-EDC4-4017-807E-19D2884AF18D@mapbox.com>
References: <07FE0337-EDC4-4017-807E-19D2884AF18D@mapbox.com>
Message-ID: <CADWq+2vTWnPobg14w1VmHVaaMbeQfx-_S-tiipw3A+tcy3gdSw@mail.gmail.com>

I don't know Bras?lia, but landuse=residential + name=* makes more sense to
me.

[]s

On Wed, Apr 11, 2012 at 2:03 PM, Ian Villeda <villeda at mapbox.com> wrote:

> ?la pessoal,
>
> Our team is working hard to get Brasilia well mapped [1]. We've noticed
> that superquadras are tagged with place=suburbs, which makes them stand
> out[2] and seems inconsistent. One idea would be to name the streets
> according to the the superquadra, but I was wondering if there was a better
> place= tag to use?
>
> Thanks,
>
> Ian Villeda
>
>
> [1] https://twitter.com/#!/lxbarth/status/189359575785418754
> [2] https://img.skitch.com/20120411-1xeam2u36y2srax9ak5btxisux.jpg
> _______________________________________________
> Talk-br mailing list
> Talk-br at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-br
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120412/7dfb924f/attachment.html>

From dieterdreist at gmail.com  Thu Apr 12 14:11:09 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Thu, 12 Apr 2012 15:11:09 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <1334212411.1972.69.camel@marvin>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
Message-ID: <CABPTjTD7vStUMnddQjySnyX3EXqpynBXpM6cVNj=Xu_7y5gprA@mail.gmail.com>

Am 12. April 2012 08:33 schrieb Philip Barnes <phil at trigpoint.me.uk>:
>> What are you asking? A sidewalk is almost always a separate physical way
>> (if not, it's a shoulder, except on minor urban streets with flush
>> sidewalks and no curb).
>
> In the Netherlands I have sometimes seen cycleways paralleling
> motorways, some 20-30 metres away, and on long estuary bridges there is
> often a cycleway but beyond that motorways never have a sidewalk.


I guess that in all of these Dutch cases there will be a guard rail
separating the cycleway from the motorway, so there is really no doubt
these should be mapped distinctly. On the other hand I wouldn't call
this a sidewalk.

cheers,
Martin


From dieterdreist at gmail.com  Thu Apr 12 14:15:09 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Thu, 12 Apr 2012 15:15:09 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F8679CB.2020906@bavarianmallet.de>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<CAFJf9KM6Hpu3bru5YJ-Z9xpTHQ5NC3Fa4oAwkNAJOjU6NBKH9g@mail.gmail.com>
	<ud3gvz.m2b9zv.2zlsav-qmf@auth.smtp.oneandone.co.uk>
	<4F8679CB.2020906@bavarianmallet.de>
Message-ID: <CABPTjTAiKZgPq23dGT=DNuVGrpXRCr2WPq5OoN8TRMp8mNVL2w@mail.gmail.com>

Am 12. April 2012 08:44 schrieb Georg Feddern <osm at bavarianmallet.de>:

> A router that does not consider sidewalks will use the roads anyway.


No, a router that doesn't consider sidewalks would with the currently
suggested tagging use the sidewalk and think it was a usual footway.
It will not be aware that there is a continuous connection between the
sidewalk and the road, and it will not tell you to cross the street
because it will "think" that there is a separation preventing you to
cross.

cheers,
Martin


From osm at bavarianmallet.de  Thu Apr 12 14:53:12 2012
From: osm at bavarianmallet.de (Georg Feddern)
Date: Thu, 12 Apr 2012 15:53:12 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CABPTjTAiKZgPq23dGT=DNuVGrpXRCr2WPq5OoN8TRMp8mNVL2w@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<CAFJf9KM6Hpu3bru5YJ-Z9xpTHQ5NC3Fa4oAwkNAJOjU6NBKH9g@mail.gmail.com>
	<ud3gvz.m2b9zv.2zlsav-qmf@auth.smtp.oneandone.co.uk>
	<4F8679CB.2020906@bavarianmallet.de>
	<CABPTjTAiKZgPq23dGT=DNuVGrpXRCr2WPq5OoN8TRMp8mNVL2w@mail.gmail.com>
Message-ID: <4F86DE48.9070407@bavarianmallet.de>

Am 12.04.2012 15:15, schrieb Martin Koppenhoefer:
> Am 12. April 2012 08:44 schrieb Georg Feddern<osm at bavarianmallet.de>:
>
>> A router that does not consider sidewalks will use the roads anyway.
>
> No, a router that doesn't consider sidewalks would with the currently
> suggested tagging use the sidewalk and think it was a usual footway.
>

Sorry, I kept my own
 > Am 11.04.2012 11:35, schrieb Martin Koppenhoefer:
> in the case of parallel ways it is impossible to tell whether you can
> filter them out or not (there could be a separation or they could be
> on different height levels), especially if people are mapping
> sidewalks the same as separated footways.

 > Thats a point - and the differentiation should be really considered 
in the tagging.

with the suggested tagging
footway=sidewalk and sidewalk=yes as differentiation

in mind (writing quite the same time).

Georg


From dieterdreist at gmail.com  Thu Apr 12 15:21:21 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Thu, 12 Apr 2012 16:21:21 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F86DE48.9070407@bavarianmallet.de>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<CAFJf9KM6Hpu3bru5YJ-Z9xpTHQ5NC3Fa4oAwkNAJOjU6NBKH9g@mail.gmail.com>
	<ud3gvz.m2b9zv.2zlsav-qmf@auth.smtp.oneandone.co.uk>
	<4F8679CB.2020906@bavarianmallet.de>
	<CABPTjTAiKZgPq23dGT=DNuVGrpXRCr2WPq5OoN8TRMp8mNVL2w@mail.gmail.com>
	<4F86DE48.9070407@bavarianmallet.de>
Message-ID: <CABPTjTByxF9EjU_tJ0F+cF9c24dn-DWU26zQA3X3J-N5ukriJg@mail.gmail.com>

Am 12. April 2012 15:53 schrieb Georg Feddern <osm at bavarianmallet.de>:
> with the suggested tagging
> footway=sidewalk and sidewalk=yes as differentiation
>
> in mind (writing quite the same time).


yes, my concern was not to tag ordinary sidewalks, which are only
separated by a kerb from the street, with an own "highway=footway".

cheers,
Martin


From dieterdreist at gmail.com  Thu Apr 12 15:29:39 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Thu, 12 Apr 2012 16:29:39 +0200
Subject: [Tagging] [Talk-br] Superquadras in Brasilia?
In-Reply-To: <CADWq+2vTWnPobg14w1VmHVaaMbeQfx-_S-tiipw3A+tcy3gdSw@mail.gmail.com>
References: <07FE0337-EDC4-4017-807E-19D2884AF18D@mapbox.com>
	<CADWq+2vTWnPobg14w1VmHVaaMbeQfx-_S-tiipw3A+tcy3gdSw@mail.gmail.com>
Message-ID: <CABPTjTDEcVZhHyEDFT2BNObKhCpRb1q0BbWq95NebVv8t3gb=w@mail.gmail.com>

Am 12. April 2012 14:32 schrieb Arlindo Pereira
<openstreetmap at arlindopereira.com>:
> I don't know Bras?lia, but landuse=residential + name=* makes more sense to
> me.


I also don't know Bras?lia. If the superquadras are sub-part of a
settlement (i.e. they are settlement entities) I suggest you have a
look at

place=neighbourhood
and
place=quarter

both can be used for sub-parts of a city (or town/village), which are
smaller then a suburb.

independent from the landuse (which should also be added accordingly,
but has a different meaning).

cheers,
Martin


From phil at trigpoint.me.uk  Thu Apr 12 16:07:32 2012
From: phil at trigpoint.me.uk (phil at trigpoint.me.uk)
Date: Thu, 12 Apr 2012 16:07:32 +0100
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CABPTjTD7vStUMnddQjySnyX3EXqpynBXpM6cVNj=Xu_7y5gprA@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CABPTjTD7vStUMnddQjySnyX3EXqpynBXpM6cVNj=Xu_7y5gprA@mail.gmail.com>
Message-ID: <23riiq.m2dgoy.2y8e8v-qmf@auth.smtp.oneandone.co.uk>

That was my point, any footpath or cycleway following a motorway should be treated as a separate way.

After more careful thought, the only UK instance of a path following a motorway, that I am aware of, is the old Severn bridge, and they are on different decks.

Phil


On 12/04/2012 14:11 Martin Koppenhoefer wrote:

Am 12. April 2012 08:33 schrieb Philip Barnes <phil at trigpoint.me.uk>:
>> What are you asking? A sidewalk is almost always a separate physical way
>> (if not, it's a shoulder, except on minor urban streets with flush
>> sidewalks and no curb).
>
> In the Netherlands I have sometimes seen cycleways paralleling
> motorways, some 20-30 metres away, and on long estuary bridges there is
> often a cycleway but beyond that motorways never have a sidewalk.


I guess that in all of these Dutch cases there will be a guard rail
separating the cycleway from the motorway, so there is really no doubt
these should be mapped distinctly. On the other hand I wouldn't call
this a sidewalk.

cheers,
Martin

_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120412/d638a661/attachment.html>

From richard at systemed.net  Thu Apr 12 16:11:11 2012
From: richard at systemed.net (Richard Fairhurst)
Date: Thu, 12 Apr 2012 08:11:11 -0700 (PDT)
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <23riiq.m2dgoy.2y8e8v-qmf@auth.smtp.oneandone.co.uk>
References: <4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CABPTjTD7vStUMnddQjySnyX3EXqpynBXpM6cVNj=Xu_7y5gprA@mail.gmail.com>
	<23riiq.m2dgoy.2y8e8v-qmf@auth.smtp.oneandone.co.uk>
Message-ID: <1334243471780-5635950.post@n5.nabble.com>

Philip Barnes wrote:
> After more careful thought, the only UK instance of a 
> path following a motorway, that I am aware of, is the 
> old Severn bridge, and they are on different decks.

There's a similar one on the nearby M5 bridge over the Avon, too.

cheers
Richard



--
View this message in context: http://gis.19327.n5.nabble.com/sidewalks-and-tagging-for-the-renderer-tp5630482p5635950.html
Sent from the Tagging mailing list archive at Nabble.com.


From baloo at ursamundi.org  Thu Apr 12 16:47:25 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Thu, 12 Apr 2012 08:47:25 -0700
Subject: [Tagging] Turn Restriction usage
In-Reply-To: <CAF1ph740i_hz64ev_td0pEOTEGPGmyCJNLSMo5kB5A75rMEEsA@mail.gmail.com>
References: <CAF1ph740i_hz64ev_td0pEOTEGPGmyCJNLSMo5kB5A75rMEEsA@mail.gmail.com>
Message-ID: <CAMPM96oxbEJFtS-F53fotskbGsDJOh=fYJ3iPG2bFA9LYfWwbg@mail.gmail.com>

On Wed, Apr 11, 2012 at 5:04 AM, Stephen Hope <slhope at gmail.com> wrote:
> In one case there is a road where a two way section comes to a divider and
> becomes two one way sections for a while. The suggested route came along one
> of the one way sections, then turned about 340 degrees to go down the other
> side of the road. It may be legal to do a u-turn there, but I don't think
> it's safe, or even possible for most cars. I was thinking about it, and many
> other divided road are similar where they split/join. Should we be putting
> no u-turn restrictions on these? There's no actual signs.

This is of special interest to the pacific northwest.  In Oregon for
sure, and probably Washington and British Columbia, U-turns are
prohibited at or within a relatively short distance of a controlled
intersection (meaning any intersection that has a stop sign, yield
sign or traffic signal head facing one or more directions), except
when explicitly permitted by signage (most common sign combination is
"LEFT TURN SIGNAL - U TURN PERMITTED - NO TRUCKS."


From jaakko at helleranta.com  Thu Apr 12 17:58:47 2012
From: jaakko at helleranta.com (Jaakko Helleranta.com)
Date: Thu, 12 Apr 2012 12:58:47 -0400
Subject: [Tagging] Turn Restriction usage
In-Reply-To: <4F86868B.3050105@bavarianmallet.de>
References: <CAF1ph740i_hz64ev_td0pEOTEGPGmyCJNLSMo5kB5A75rMEEsA@mail.gmail.com>
	<4F857546.7020100@4x4falcon.com>
	<CAJJ1XA5VFFdch5pgtQP5q6ntZu52QqhXUWfisyhnFkHjSY6ouw@mail.gmail.com>
	<4F857E91.7000701@4x4falcon.com>
	<CAJJ1XA424W2mAEL_gEU7T-V1aN-zs=t7rEsoxe0mWRym8OTRtA@mail.gmail.com>
	<4F86868B.3050105@bavarianmallet.de>
Message-ID: <CAHGgj+vMY0EAhu=S+rbT7On+Q22EpewGfB2bLrOk7oSyLmU54Q@mail.gmail.com>

On Thu, Apr 12, 2012 at 3:38 AM, Georg Feddern <osm at bavarianmallet.de>wrote:

> in your example the angle at the considered point is far from dangerous or
> considerable.
> Your angle is in the range up to 45? and doesn't even reach 90? (a typical
> crossing / turn situation).
>
> Points of no u-turn - that have to be considered - have angles
> - beyond 90? (may be a sharp turn or a crossing at a combine situation)
> - mostly beyond 120? and often beyond 150?
>

Roads on the sides of hills very often have turns off the road that are
more then 120deg, even 150. The first example I can think of is:
http://osm.org/go/YeSTZ08Fj-- (from one of Port-au-Prince main roads, not
even a very steep hillside = ca. 125-130 deg turn coming downhill and
turning left to a bit of a drop-off but something that is a regular thing
here).

I'm only starting to get into routing data issues but just thinking of this
logically it would seem to me as odd if we assumed something to be
forbidden globally based on a local rule -- without explicit data marking
the restriction.

Or am I missing something?

Cheers from Haiti,
-Jaakko

http://osm.org/user/jaakkoh
--
jaakko at helleranta.com * Skype: jhelleranta * Mobile: +509-37-269154  *
http://go.hel.cc/MyProfile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120412/642b3f94/attachment.html>

From baloo at ursamundi.org  Thu Apr 12 18:35:41 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Thu, 12 Apr 2012 10:35:41 -0700
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <1334212411.1972.69.camel@marvin>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
Message-ID: <CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>

On Wed, Apr 11, 2012 at 11:33 PM, Philip Barnes <phil at trigpoint.me.uk> wrote:

> The term motorway implies a lot of rules,
> No Pedestrians.
> No Cyclists.
> No Learner Drivers.
> No Tracked Vehicles.
> No Agricultural Vehicles.
> No Motorcycles under 50cc.
> Horses
> Mobility Scooters

Not universally true by any stretch.  Almost half of the US and most
of Canada, for example, allow pretty much everything on the motorway.
With trunks and motorways, as with any other way unclassified and
larger, it's best to explicitly define restrictions rather than expect
them to be implicit.


From pieren3 at gmail.com  Thu Apr 12 19:14:49 2012
From: pieren3 at gmail.com (Pieren)
Date: Thu, 12 Apr 2012 20:14:49 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
Message-ID: <CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>

On Thu, Apr 12, 2012 at 7:35 PM, Paul Johnson <baloo at ursamundi.org> wrote:
> With trunks and motorways, as with any other way unclassified and
> larger, it's best to explicitly define restrictions rather than expect
> them to be implicit.

So, if horses are allowed in Texas motorways, we should add "horse=no"
in German motorways ? Or if camels are allowed in Egyptians motorways,
we shoudl add "camel=no" in Canadian motorways ?

Pieren


From baloo at ursamundi.org  Thu Apr 12 19:35:56 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Thu, 12 Apr 2012 11:35:56 -0700
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
Message-ID: <CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>

On Thu, Apr 12, 2012 at 11:14 AM, Pieren <pieren3 at gmail.com> wrote:
> On Thu, Apr 12, 2012 at 7:35 PM, Paul Johnson <baloo at ursamundi.org> wrote:
>> With trunks and motorways, as with any other way unclassified and
>> larger, it's best to explicitly define restrictions rather than expect
>> them to be implicit.
>
> So, if horses are allowed in Texas motorways, we should add "horse=no"
> in German motorways ? Or if camels are allowed in Egyptians motorways,
> we shoudl add "camel=no" in Canadian motorways ?

Not necessarily that specific given the realms of possibility, but
yes, more detail is better.  A somewhat random example:
http://www.openstreetmap.org/browse/way/60957683


From slhope at gmail.com  Fri Apr 13 06:27:07 2012
From: slhope at gmail.com (Stephen Hope)
Date: Fri, 13 Apr 2012 15:27:07 +1000
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
Message-ID: <CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>

The problem with this, is many mappers are not even aware of what implicit
assumptions they are making, and hence won't map them. Saying that they
should map them won't help.

Do we need a database* of  explicit default settings for different areas,
to be used by renderers, routers and other tools as appropriate? Rules like
"In Germany, motorway implies foot=no if there is no foot tag on the way".
This could also help give sane guesses of defaults for roads that haven't
been tagged at all yet.

* either a separate database, or polygons inside OSM with tags, whatever.
That's not the point at the moment

Stephen


On 13 April 2012 04:35, Paul Johnson <baloo at ursamundi.org> wrote:

> On Thu, Apr 12, 2012 at 11:14 AM, Pieren <pieren3 at gmail.com> wrote:
> > On Thu, Apr 12, 2012 at 7:35 PM, Paul Johnson <baloo at ursamundi.org>
> wrote:
> >> With trunks and motorways, as with any other way unclassified and
> >> larger, it's best to explicitly define restrictions rather than expect
> >> them to be implicit.
> >
> > So, if horses are allowed in Texas motorways, we should add "horse=no"
> > in German motorways ? Or if camels are allowed in Egyptians motorways,
> > we shoudl add "camel=no" in Canadian motorways ?
>
> Not necessarily that specific given the realms of possibility, but
> yes, more detail is better.  A somewhat random example:
> http://www.openstreetmap.org/browse/way/60957683
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120413/6aea02ea/attachment.html>

From colin.smale at xs4all.nl  Fri Apr 13 07:11:25 2012
From: colin.smale at xs4all.nl (Colin Smale)
Date: Fri, 13 Apr 2012 08:11:25 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
Message-ID: <4F87C38D.9080003@xs4all.nl>

Yes please!

I was also thinking on the lines of documenting implicit tagging:
*    to save mappers time
*    to save space in the database
*    to avoid confusion
*    to allow a single point of maintenance

At a generic "territory" level with some kind of hierarchy please, so 
for example cities can override counties which can override states which 
can override national rules. As traffic rules are made by some kind of 
government, I am sure the current boundary/admin_level stuff can be used 
as a base as long as a true hierarchy can be found (no multiple 
inheritance!)

<defaults territory="uk">
<defaultentry>
<match>
<tag k="highway" v="motorway" />
</match>
<implies>
<tag k="foot" v="no" />
<tag k="maxspeed" v="70 mph" />
<tag k="bicycle" v="no" />
</implies>
</defaultentry>
</defaults>

Technically it doesn't seem that difficult.

Colin

On 13/04/2012 07:27, Stephen Hope wrote:
> The problem with this, is many mappers are not even aware of what 
> implicit assumptions they are making, and hence won't map them. Saying 
> that they should map them won't help.
>
> Do we need a database* of  explicit default settings for different 
> areas, to be used by renderers, routers and other tools as 
> appropriate? Rules like "In Germany, motorway implies foot=no if there 
> is no foot tag on the way". This could also help give sane guesses of 
> defaults for roads that haven't been tagged at all yet.
>
> * either a separate database, or polygons inside OSM with tags, 
> whatever. That's not the point at the moment
>
> Stephen
>
>



From wendorff at uni-paderborn.de  Fri Apr 13 07:20:00 2012
From: wendorff at uni-paderborn.de (Peter Wendorff)
Date: Fri, 13 Apr 2012 08:20:00 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F87C38D.9080003@xs4all.nl>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl>
Message-ID: <4F87C590.3070007@uni-paderborn.de>

-10 for adding defaults as a hint for mappers!!!

Every application using OSM data has to make assumptions about data not 
present in the database, sure, but reliable data has to be present in 
the database, as a missing tag in general can be both: missing/unknown, 
or "default", whatever "default" means.

If we would define a set of defaults and mappers follow that set, nobody 
will add "default" values again, and it's not possible to distinguish 
between default and unknown any more.

Yes, sure: Applications should have these default values, and probably 
it is useful to define some kind of "common defaults" in a file that can 
be used and parsed by applications, but this should not be part of the 
osm mapping work, but part of the software development around OSM (not 
in the osm core).

regards
Peter

Am 13.04.2012 08:11, schrieb Colin Smale:
> Yes please!
>
> I was also thinking on the lines of documenting implicit tagging:
> *    to save mappers time
> *    to save space in the database
> *    to avoid confusion
> *    to allow a single point of maintenance
>
> At a generic "territory" level with some kind of hierarchy please, so 
> for example cities can override counties which can override states 
> which can override national rules. As traffic rules are made by some 
> kind of government, I am sure the current boundary/admin_level stuff 
> can be used as a base as long as a true hierarchy can be found (no 
> multiple inheritance!)
>
> <defaults territory="uk">
> <defaultentry>
> <match>
> <tag k="highway" v="motorway" />
> </match>
> <implies>
> <tag k="foot" v="no" />
> <tag k="maxspeed" v="70 mph" />
> <tag k="bicycle" v="no" />
> </implies>
> </defaultentry>
> </defaults>
>
> Technically it doesn't seem that difficult.
>
> Colin
>
> On 13/04/2012 07:27, Stephen Hope wrote:
>> The problem with this, is many mappers are not even aware of what 
>> implicit assumptions they are making, and hence won't map them. 
>> Saying that they should map them won't help.
>>
>> Do we need a database* of  explicit default settings for different 
>> areas, to be used by renderers, routers and other tools as 
>> appropriate? Rules like "In Germany, motorway implies foot=no if 
>> there is no foot tag on the way". This could also help give sane 
>> guesses of defaults for roads that haven't been tagged at all yet.
>>
>> * either a separate database, or polygons inside OSM with tags, 
>> whatever. That's not the point at the moment
>>
>> Stephen
>>
>>
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
>



From colin.smale at xs4all.nl  Fri Apr 13 07:55:44 2012
From: colin.smale at xs4all.nl (Colin Smale)
Date: Fri, 13 Apr 2012 08:55:44 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F87C590.3070007@uni-paderborn.de>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl> <4F87C590.3070007@uni-paderborn.de>
Message-ID: <4F87CDF0.8040000@xs4all.nl>

On 13/04/2012 08:20, Peter Wendorff wrote:
> -10 for adding defaults as a hint for mappers!!!
You sure know how to lower the barriers to entry and attract new mappers...
> Every application using OSM data has to make assumptions about data 
> not present in the database, sure, but reliable data has to be present 
> in the database, as a missing tag in general can be both: 
> missing/unknown, or "default", whatever "default" means.
And that's exactly the problem. The alternative to documented defaults, 
is explicit tagging for absolutely everything. No way will we ever get 
mappers to accept that they have to enter all that stuff a million 
times. And undocumented defaults make the data unreliable as you say.

> If we would define a set of defaults and mappers follow that set, 
> nobody will add "default" values again, and it's not possible to 
> distinguish between default and unknown any more.
If there is no default value, don't define it. For very many important, 
everyday things, there are valid defaults, i.e. it is not "unknown" or 
even "unknowable", just not written down. If I'm on a normal road in a 
built-up area in the UK and there is no traffic sign to say otherwise, 
the speed limit IS 30mph.

> Yes, sure: Applications should have these default values, and probably 
> it is useful to define some kind of "common defaults" in a file that 
> can be used and parsed by applications, but this should not be part of 
> the osm mapping work, but part of the software development around OSM 
> (not in the osm core).

I don't make a distinction between the "OSM Core" and the software 
development. The two have to work together. What one writes, the other 
must be able to read and understand. Neither is truly autonomous as 
failing to understand and react to the needs of your stakeholders is a 
recipe for suicide.

If common applications publish their built-in assumptions, I expect they 
would tend to converge over time. If the mappers can be sure of how data 
consumers handle missing tags, there is no longer a necessity to tag 
everything so explicitly, thus saving time on mapping and lots of 
discussions, not to mention terabytes of data. Surely we are not going 
to add a tag for everything that an object is NOT.

I see this not just as a theoretical issue, but one of real 
practicality. Given that data consumers have a need for good data 
quality, one way of achieving that is by full explicit tagging. I just 
don't see that happening. A more heuristic approach involving 
documenting assumptions/defaults would allow the data's usability 
dramatically to be improved without full explicit tagging.

>
> regards
> Peter
>
> Am 13.04.2012 08:11, schrieb Colin Smale:
>> Yes please!
>>
>> I was also thinking on the lines of documenting implicit tagging:
>> *    to save mappers time
>> *    to save space in the database
>> *    to avoid confusion
>> *    to allow a single point of maintenance
>>
>> At a generic "territory" level with some kind of hierarchy please, so 
>> for example cities can override counties which can override states 
>> which can override national rules. As traffic rules are made by some 
>> kind of government, I am sure the current boundary/admin_level stuff 
>> can be used as a base as long as a true hierarchy can be found (no 
>> multiple inheritance!)
>>
>> <defaults territory="uk">
>> <defaultentry>
>> <match>
>> <tag k="highway" v="motorway" />
>> </match>
>> <implies>
>> <tag k="foot" v="no" />
>> <tag k="maxspeed" v="70 mph" />
>> <tag k="bicycle" v="no" />
>> </implies>
>> </defaultentry>
>> </defaults>
>>
>> Technically it doesn't seem that difficult.
>>
>> Colin
>>
>> On 13/04/2012 07:27, Stephen Hope wrote:
>>> The problem with this, is many mappers are not even aware of what 
>>> implicit assumptions they are making, and hence won't map them. 
>>> Saying that they should map them won't help.
>>>
>>> Do we need a database* of  explicit default settings for different 
>>> areas, to be used by renderers, routers and other tools as 
>>> appropriate? Rules like "In Germany, motorway implies foot=no if 
>>> there is no foot tag on the way". This could also help give sane 
>>> guesses of defaults for roads that haven't been tagged at all yet.
>>>
>>> * either a separate database, or polygons inside OSM with tags, 
>>> whatever. That's not the point at the moment
>>>
>>> Stephen
>>>
>>>
>>
>>
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging



From jais at pedersens.net  Fri Apr 13 08:06:10 2012
From: jais at pedersens.net (Jais Pedersen)
Date: Fri, 13 Apr 2012 14:06:10 +0700
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F87CDF0.8040000@xs4all.nl>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl> <4F87C590.3070007@uni-paderborn.de>
	<4F87CDF0.8040000@xs4all.nl>
Message-ID: <CAL6RrKcCqWiSqWp6h=FEPoyEBRccngPRpAqSw373PHaobJk4kw@mail.gmail.com>

I think Frederik describes the problem very well here:
http://osm.gryph.de/2012/02/freedom-to-tag and I really like the Tag
Central idea, but as usual it requires that somebody with the right skills
and available time falls in love with the idea. It is probably too late
now, but it might have been a nice GSoC project - maybe next year.

On Fri, Apr 13, 2012 at 1:55 PM, Colin Smale <colin.smale at xs4all.nl> wrote:

> On 13/04/2012 08:20, Peter Wendorff wrote:
>
>> -10 for adding defaults as a hint for mappers!!!
>>
> You sure know how to lower the barriers to entry and attract new mappers...
>
>  Every application using OSM data has to make assumptions about data not
>> present in the database, sure, but reliable data has to be present in the
>> database, as a missing tag in general can be both: missing/unknown, or
>> "default", whatever "default" means.
>>
> And that's exactly the problem. The alternative to documented defaults, is
> explicit tagging for absolutely everything. No way will we ever get mappers
> to accept that they have to enter all that stuff a million times. And
> undocumented defaults make the data unreliable as you say.
>
>
>  If we would define a set of defaults and mappers follow that set, nobody
>> will add "default" values again, and it's not possible to distinguish
>> between default and unknown any more.
>>
> If there is no default value, don't define it. For very many important,
> everyday things, there are valid defaults, i.e. it is not "unknown" or even
> "unknowable", just not written down. If I'm on a normal road in a built-up
> area in the UK and there is no traffic sign to say otherwise, the speed
> limit IS 30mph.
>
>
>  Yes, sure: Applications should have these default values, and probably it
>> is useful to define some kind of "common defaults" in a file that can be
>> used and parsed by applications, but this should not be part of the osm
>> mapping work, but part of the software development around OSM (not in the
>> osm core).
>>
>
> I don't make a distinction between the "OSM Core" and the software
> development. The two have to work together. What one writes, the other must
> be able to read and understand. Neither is truly autonomous as failing to
> understand and react to the needs of your stakeholders is a recipe for
> suicide.
>
> If common applications publish their built-in assumptions, I expect they
> would tend to converge over time. If the mappers can be sure of how data
> consumers handle missing tags, there is no longer a necessity to tag
> everything so explicitly, thus saving time on mapping and lots of
> discussions, not to mention terabytes of data. Surely we are not going to
> add a tag for everything that an object is NOT.
>
> I see this not just as a theoretical issue, but one of real practicality.
> Given that data consumers have a need for good data quality, one way of
> achieving that is by full explicit tagging. I just don't see that
> happening. A more heuristic approach involving documenting
> assumptions/defaults would allow the data's usability dramatically to be
> improved without full explicit tagging.
>
>
>
>> regards
>> Peter
>>
>> Am 13.04.2012 08:11, schrieb Colin Smale:
>>
>>> Yes please!
>>>
>>> I was also thinking on the lines of documenting implicit tagging:
>>> *    to save mappers time
>>> *    to save space in the database
>>> *    to avoid confusion
>>> *    to allow a single point of maintenance
>>>
>>> At a generic "territory" level with some kind of hierarchy please, so
>>> for example cities can override counties which can override states which
>>> can override national rules. As traffic rules are made by some kind of
>>> government, I am sure the current boundary/admin_level stuff can be used as
>>> a base as long as a true hierarchy can be found (no multiple inheritance!)
>>>
>>> <defaults territory="uk">
>>> <defaultentry>
>>> <match>
>>> <tag k="highway" v="motorway" />
>>> </match>
>>> <implies>
>>> <tag k="foot" v="no" />
>>> <tag k="maxspeed" v="70 mph" />
>>> <tag k="bicycle" v="no" />
>>> </implies>
>>> </defaultentry>
>>> </defaults>
>>>
>>> Technically it doesn't seem that difficult.
>>>
>>> Colin
>>>
>>> On 13/04/2012 07:27, Stephen Hope wrote:
>>>
>>>> The problem with this, is many mappers are not even aware of what
>>>> implicit assumptions they are making, and hence won't map them. Saying that
>>>> they should map them won't help.
>>>>
>>>> Do we need a database* of  explicit default settings for different
>>>> areas, to be used by renderers, routers and other tools as appropriate?
>>>> Rules like "In Germany, motorway implies foot=no if there is no foot tag on
>>>> the way". This could also help give sane guesses of defaults for roads that
>>>> haven't been tagged at all yet.
>>>>
>>>> * either a separate database, or polygons inside OSM with tags,
>>>> whatever. That's not the point at the moment
>>>>
>>>> Stephen
>>>>
>>>>
>>>>
>>>
>>> ______________________________**_________________
>>> Tagging mailing list
>>> Tagging at openstreetmap.org
>>> http://lists.openstreetmap.**org/listinfo/tagging<http://lists.openstreetmap.org/listinfo/tagging>
>>>
>>>
>>
>> ______________________________**_________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> http://lists.openstreetmap.**org/listinfo/tagging<http://lists.openstreetmap.org/listinfo/tagging>
>>
>
>
> ______________________________**_________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/tagging<http://lists.openstreetmap.org/listinfo/tagging>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120413/6ace39b9/attachment.html>

From osm at tobias-knerr.de  Fri Apr 13 08:27:33 2012
From: osm at tobias-knerr.de (Tobias Knerr)
Date: Fri, 13 Apr 2012 09:27:33 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F87C590.3070007@uni-paderborn.de>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl> <4F87C590.3070007@uni-paderborn.de>
Message-ID: <4F87D565.6050204@tobias-knerr.de>

Am 13.04.2012 08:20, schrieb Peter Wendorff:
> If we would define a set of defaults and mappers follow that set, nobody
> will add "default" values again, and it's not possible to distinguish
> between default and unknown any more.

You have identified a real problem: The distinction between default and
unknown values is lost with a default that is more than just a fallback
for programs. And I agree that certain tags with more than one commonly
used value should preferably be set explicitly everywhere.

However, I think that relying on defaults cannot really be avoided in
_all_ cases. For example, in many countries there are so few roads
usable only with 4wd vehicles that you will never see the default
explicitly tagged on all highways. Instead, you will have a small number
of roads tagged as "4wd only", and a lot of roads for which we just
assume not to have this restriction.

So for attributes that almost always have a certain value, I really
don't see any option except using that one as the default and accepting
that this makes "undefined" essentially impossible.

As a crude analogy: We don't add a node with "there's no shop here" at
every unoccupied coordinate either. Instead, we just treat unmapped
areas the same as areas where someone has already checked that there
really is no shop around. There are just too many coordinates without
shops, relatively speaking. And I think we will need to do the same for
rare attributes, too.

Tobias


From colin.smale at xs4all.nl  Fri Apr 13 08:31:17 2012
From: colin.smale at xs4all.nl (Colin Smale)
Date: Fri, 13 Apr 2012 09:31:17 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F87C590.3070007@uni-paderborn.de>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl> <4F87C590.3070007@uni-paderborn.de>
Message-ID: <4F87D645.6080601@xs4all.nl>

On 13/04/2012 08:20, Peter Wendorff wrote:
> -10 for adding defaults as a hint for mappers!!!
>
What would you do with this page? Enhance/complete it, or delete it?

http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions

Just noticed that links to a proposal for defaults - 
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Defaults

Colin


From neroute2 at gmail.com  Fri Apr 13 08:49:31 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Fri, 13 Apr 2012 03:49:31 -0400
Subject: [Tagging] Defaults (Re:  sidewalks and tagging for the renderer)
In-Reply-To: <4F87C590.3070007@uni-paderborn.de>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl> <4F87C590.3070007@uni-paderborn.de>
Message-ID: <4F87DA8B.2020207@gmail.com>

I think we're talking about two different things here.

(a) An editor (program) automatically applying tags to an object. This 
is bad, because we don't know whether the mapper has specifically 
verified this, or whether it's just being assumed and may be false.

(b) Tags on an area that specify defaults for objects within the area, 
to be processed by the end-user who downloads the OSM data. This could 
be good. For example, in Florida, whether bicycles are allowed on 
sidewalks is a matter for the local government to decide. So it would be 
useful to specify that footway=sidewalk implies bicycle=no inside city 
limits, unless otherwise overridden by a tag on the sidewalk way. And 
you could still set bicycle=no on the ways if you want.


From pieren3 at gmail.com  Fri Apr 13 08:58:59 2012
From: pieren3 at gmail.com (Pieren)
Date: Fri, 13 Apr 2012 09:58:59 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F87D645.6080601@xs4all.nl>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl> <4F87C590.3070007@uni-paderborn.de>
	<4F87D645.6080601@xs4all.nl>
Message-ID: <CAPT3zJphMh8B-W_j8UXnADxSaDC-fN_uw5jWbLWmN3dKkuzdRw@mail.gmail.com>

On Fri, Apr 13, 2012 at 9:31 AM, Colin Smale <colin.smale at xs4all.nl> wrote:

> Just noticed that links to a proposal for defaults -
> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Defaults

An example:
http://www.openstreetmap.org/browse/relation/934933

Data consumers should check if the element contains the value (e.g.
foot=no). If not, look for the smallest containing polygone where a
default is defined (relations can be translated into a database)(a
district, state, country or continent). This is better than "doing
assumption when tag is missing".

Pieren


From vpottier at gmail.com  Fri Apr 13 10:17:15 2012
From: vpottier at gmail.com (Vincent Pottier)
Date: Fri, 13 Apr 2012 11:17:15 +0200
Subject: [Tagging] Defaults (Re: sidewalks and tagging for the renderer)
In-Reply-To: <4F87DA8B.2020207@gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl> <4F87C590.3070007@uni-paderborn.de>
	<4F87DA8B.2020207@gmail.com>
Message-ID: <4F87EF1B.4010308@gmail.com>

Le 13/04/2012 09:49, Nathan Edgars II a ?crit :
> I think we're talking about two different things here.
>
> (a) An editor (program) automatically applying tags to an object. This 
> is bad, because we don't know whether the mapper has specifically 
> verified this, or whether it's just being assumed and may be false.
+1
>
> (b) Tags on an area that specify defaults for objects within the area, 
> to be processed by the end-user who downloads the OSM data. This could 
> be good. For example, in Florida, whether bicycles are allowed on 
> sidewalks is a matter for the local government to decide. So it would 
> be useful to specify that footway=sidewalk implies bicycle=no inside 
> city limits, unless otherwise overridden by a tag on the sidewalk way. 
> And you could still set bicycle=no on the ways if you want.
>
There is a proposal for it :
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Defaults
--
FrViPofm


From wendorff at uni-paderborn.de  Fri Apr 13 11:20:04 2012
From: wendorff at uni-paderborn.de (Peter Wendorff)
Date: Fri, 13 Apr 2012 12:20:04 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F87CDF0.8040000@xs4all.nl>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl> <4F87C590.3070007@uni-paderborn.de>
	<4F87CDF0.8040000@xs4all.nl>
Message-ID: <4F87FDD4.3060401@uni-paderborn.de>

Am 13.04.2012 08:55, schrieb Colin Smale:
> On 13/04/2012 08:20, Peter Wendorff wrote:
>> -10 for adding defaults as a hint for mappers!!!
> You sure know how to lower the barriers to entry and attract new 
> mappers...
Not exactly, but a big catalogue of explicit defaults IMHO does not make 
anything easier.
>> Every application using OSM data has to make assumptions about data 
>> not present in the database, sure, but reliable data has to be 
>> present in the database, as a missing tag in general can be both: 
>> missing/unknown, or "default", whatever "default" means.
> And that's exactly the problem. The alternative to documented 
> defaults, is explicit tagging for absolutely everything. No way will 
> we ever get mappers to accept that they have to enter all that stuff a 
> million times. And undocumented defaults make the data unreliable as 
> you say.
We don't have to force mappers to tag everything. But to clearly state 
that a fact is the default it is definitively not sufficient to count on 
the default.
There are many many mappers who mainly draw streets from aerials, and in 
most cases there is no way to identify a maxspeed.
Germany has a "default"/implicit maxspeed in urban areas of 50km/h, but 
in fact many cities reduce that explicitely to 30 for big parts of the city.

A documented default of 50 for cities in Germany would lead to exactly 
the opposite of what we want: applications don't identify streets as 
"unknown speed limit" if they want to, they assume 50 exactly as they (I 
think) do today, but mappers don't explicitly state that 50 is the 
correct assumption any more, because it's a default.

In this case it's not in any way possible to identify missing maxspeed 
attributes that differ from the default any more, as long as there's no 
fixme or sth. like that, but then we have in contrast MORE tags (here 
fixme) to do the same as we can do now, and these are more difficult to 
identify automatically.
>> If we would define a set of defaults and mappers follow that set, 
>> nobody will add "default" values again, and it's not possible to 
>> distinguish between default and unknown any more.
> If there is no default value, don't define it. For very many 
> important, everyday things, there are valid defaults, i.e. it is not 
> "unknown" or even "unknowable", just not written down. If I'm on a 
> normal road in a built-up area in the UK and there is no traffic sign 
> to say otherwise, the speed limit IS 30mph.
Sure, but if there's no tag, you don't know if the default is true or 
the tag is missing, it's just a guess.
With "mapper defaults" you will have to guess more often than today.
>> Yes, sure: Applications should have these default values, and 
>> probably it is useful to define some kind of "common defaults" in a 
>> file that can be used and parsed by applications, but this should not 
>> be part of the osm mapping work, but part of the software development 
>> around OSM (not in the osm core).
> [...]
>
> If common applications publish their built-in assumptions, I expect 
> they would tend to converge over time. If the mappers can be sure of 
> how data consumers handle missing tags, there is no longer a necessity 
> to tag everything so explicitly, thus saving time on mapping and lots 
> of discussions, not to mention terabytes of data.
Counter-argument see above.
> Surely we are not going to add a tag for everything that an object is 
> NOT.
I agree here and I usually don't add (all) defaults either, but I don't 
want to do that as a RULE as I see where it's necessary, and if I am 
interested in a particular topic (e.g. lit=yes/no) I would add even 
lit=yes in cities and lit=no outside (what I would see as the default in 
Germany for lit), just to keep track of where this attribute is checked 
and proven, and where it's not.
> I see this not just as a theoretical issue, but one of real 
> practicality. Given that data consumers have a need for good data 
> quality, one way of achieving that is by full explicit tagging. I just 
> don't see that happening. A more heuristic approach involving 
> documenting assumptions/defaults would allow the data's usability 
> dramatically to be improved without full explicit tagging.
Sure, but that's the data consumer/software side, it's not the mapper part.
And a common set of "interpretation in software-defaults" allows to give 
mapper tools to identify issues, where missing attributes are wrongly 
interpreted due to missing tags. But these issues are only more 
important than others, "matching" defaults are only by chance 
interpreted correctly - even if the defaults are documented as "mapper 
defaults".

regards
Peter


From wendorff at uni-paderborn.de  Fri Apr 13 11:25:48 2012
From: wendorff at uni-paderborn.de (Peter Wendorff)
Date: Fri, 13 Apr 2012 12:25:48 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F87D645.6080601@xs4all.nl>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl> <4F87C590.3070007@uni-paderborn.de>
	<4F87D645.6080601@xs4all.nl>
Message-ID: <4F87FF2C.9050504@uni-paderborn.de>

Am 13.04.2012 09:31, schrieb Colin Smale:
> On 13/04/2012 08:20, Peter Wendorff wrote:
>> -10 for adding defaults as a hint for mappers!!!
>>
> What would you do with this page? Enhance/complete it, or delete it?
>
> http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions 
>
>
> Just noticed that links to a proposal for defaults - 
> http://wiki.openstreetmap.org/wiki/Relations/Proposed/Defaults
I would keep it, but make a big hint that these are defaults, that 
SOFTWARE can assume.
It should IMHO not be a rule for mapper, that motivates to delete or 
willingly omitt these values.

regards
Peter


From pieren3 at gmail.com  Fri Apr 13 11:47:56 2012
From: pieren3 at gmail.com (Pieren)
Date: Fri, 13 Apr 2012 12:47:56 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F87FF2C.9050504@uni-paderborn.de>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl> <4F87C590.3070007@uni-paderborn.de>
	<4F87D645.6080601@xs4all.nl> <4F87FF2C.9050504@uni-paderborn.de>
Message-ID: <CAPT3zJrS76rY5fo31TfUY+uwF6xwYk=GiR2Y5XiZEL0LA6UxDA@mail.gmail.com>

On Fri, Apr 13, 2012 at 12:25 PM, Peter Wendorff
<wendorff at uni-paderborn.de> wrote:

> I would keep it, but make a big hint that these are defaults, that SOFTWARE
> can assume.
> It should IMHO not be a rule for mapper, that motivates to delete or
> willingly omitt these values.

Point is that editors should support these default values and inform
contributors about what can be implied.
I think this is the best compromise between GIS people or data
consumers who want explicite tags and average contributors who want to
minimize the efforts for edition. Presets can help but look how the
oneway tag works in Potlatch2. The result is that many "oneway=no" are
unnecessarily added in the db and data consumers will ask the same for
maxspeed, width, surface, lanes, sidewalks, lit, and so on... And this
is for sure not lowering the barrier entry for new contributors which
is one of the key issues for the future of this project, (see what's
happening to wikipedia).
When you leave the assumptions to the software level, you can be sure
that you will end up with different results on different softwares.
The best way to keep consistency is to fix the rules in the database.

Pieren


From wendorff at uni-paderborn.de  Fri Apr 13 12:47:05 2012
From: wendorff at uni-paderborn.de (Peter Wendorff)
Date: Fri, 13 Apr 2012 13:47:05 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <CAPT3zJrS76rY5fo31TfUY+uwF6xwYk=GiR2Y5XiZEL0LA6UxDA@mail.gmail.com>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl> <4F87C590.3070007@uni-paderborn.de>
	<4F87D645.6080601@xs4all.nl> <4F87FF2C.9050504@uni-paderborn.de>
	<CAPT3zJrS76rY5fo31TfUY+uwF6xwYk=GiR2Y5XiZEL0LA6UxDA@mail.gmail.com>
Message-ID: <4F881239.70107@uni-paderborn.de>

Am 13.04.2012 12:47, schrieb Pieren:
> On Fri, Apr 13, 2012 at 12:25 PM, Peter Wendorff
> <wendorff at uni-paderborn.de>  wrote:
>
>> I would keep it, but make a big hint that these are defaults, that SOFTWARE
>> can assume.
>> It should IMHO not be a rule for mapper, that motivates to delete or
>> willingly omitt these values.
> Point is that editors should support these default values and inform
> contributors about what can be implied.
What's the benefit of these information?
Nobody will add more precise information because of the hint, but some 
people will add less precise information by omitting tags they would 
have added otherwise.
Information about "what can be implied" could easily be exchanged to tag 
suggestions (you are adding a highway. do you want to add maxspeed 
too?), as long as the user has to explicitely agree with that particular 
tag.
Pure implicit tag additions don't help as they produce wrong data by 
suggesting that a particular tag may be necessary(!) and that it may be 
better to add it with a wrong value than omitting it completely.
> I think this is the best compromise between GIS people or data
> consumers who want explicite tags
Data consumers prefer explicite, but CORRECT tags over implicite/unknown 
tags over explicit and UNCORRECT tags.
Forcing mappers to add more tags just for the "completeness" produces 
more uncorrect tags and makes quality assurance and error tracking more 
difficult.
> and average contributors who want to minimize the efforts for edition.
...which creates less, but correct tags, second best option for data 
consumers, not more work for editors.
> Presets can help but look how the
> oneway tag works in Potlatch2. The result is that many "oneway=no" are
> unnecessarily added in the db
oneway=no is not necessary, but it does not harm, as long as it's correct.
Quality research in OSM states, that in particular this kind of 
attributes is often missing in osm. But why?
One reason is, that it's impossible to check a particular area for 
completeness of e.g. oneway tagging.
Here the explicit oneway=no is not primarily directed to the data 
consumers - they should use it as a default, it is directed to mappers, 
who can check if others took care about that tag already or not.

Presets, that always add all attributes are IMHO a design error of the 
editor software. A preset for a bench should add amenity=bench, and 
suggest to add more tags - but not enforce that.
It should be a "hey, do you know, if that bench has a backrest, too? If 
so, you may want to add it." instead of "has it a backrest or not?"
> and data consumers will ask the same for
> maxspeed, width, surface, lanes, sidewalks, lit, and so on...
Usually we (at least I, and I guess many others, too) would response to 
that question, that consuming applications should expect to have 
fallback values, that OSM is a living system without guaranteed 
completeness and that nobody can ask for complete tagging - in no way 
and for no attribute or data type.

But if a company would like to have complete maxspeed tagging, they are 
allowed to collect the data and even add it explicitely everywhere they 
know it.
And I think, that's fine.
> And this
> is for sure not lowering the barrier entry for new contributors which
> is one of the key issues for the future of this project, (see what's
> happening to wikipedia).
As I said: Noone - neither other mappers nor "consumers" are able, 
allowed or ignored when enforcing other mappers to add a fixed set of 
attributes.
Presets user interface should be designed in a way that allows and makes 
it easy to omitt values, that are unknown.
> When you leave the assumptions to the software level, you can be sure
> that you will end up with different results on different softwares.
> The best way to keep consistency is to fix the rules in the database.
IMHO the best way is to agree on rules across data consuming 
applications (and their developers), but to not include these default 
rules in the editors.

regards
Peter


From osm at tobias-knerr.de  Fri Apr 13 20:06:37 2012
From: osm at tobias-knerr.de (Tobias Knerr)
Date: Fri, 13 Apr 2012 21:06:37 +0200
Subject: [Tagging] Wikifiddling,
	surface=cobblestone vs. sett & paving_stones
In-Reply-To: <CA+z=q=uho+5A0D+TBBwQ8W3ySJLyZRO6R0-bPevLqu2RAC-ETA@mail.gmail.com>
References: <CABPTjTAgawEmKoCfXvV=+wAzwjv4M4v8iDWmCoa8uQfaavwVsw@mail.gmail.com>
	<4F4245DD.7050300@jonno.cix.co.uk> <4F425337.802@tobias-knerr.de>
	<CAMLmWVteinYd8wzq8y482DAwQvYw32us+zM2KbNGWuQH1bbFqg@mail.gmail.com>
	<CABPTjTDjK73H9Q4xDO-E9mgd8ExvWfXf8=XNZf=nU-M8qw6xKg@mail.gmail.com>
	<CABPTjTB2CrPmZSZs9rboOWHbQ4WjdLEABOMRBa5pZyx_QxpJZQ@mail.gmail.com>
	<CA+z=q=uho+5A0D+TBBwQ8W3ySJLyZRO6R0-bPevLqu2RAC-ETA@mail.gmail.com>
Message-ID: <4F88793D.3010004@tobias-knerr.de>

Steve Bennett wrote:
> So, whoever really wants to introduce this distinction is going to
> have to find another way, perhaps "surface=cobblestone,
> cobblestone=sett".

Thank you for dealing with the issue.

Subtagging seems like a good suggestion for making this distinction. We
would also need a value for "real" cobblestone, though, not just sett.
After all, it's much more likely that the subtag will be used on the
small number of non-sett surfaces.

Of course, cobblestone=cobblestone seems a bit silly. Maybe
cobblestone=cobbles/sett? Any other suggestions?

There also is a rarely used surface=cobblestone:flattened tag documented
in the Map Features template. This should probably also be turned into a
subtag value, _if_ it is actually a variant of its own and not just
referring to setts.

Tobias


From dieterdreist at gmail.com  Fri Apr 13 20:28:02 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Fri, 13 Apr 2012 21:28:02 +0200
Subject: [Tagging] Wikifiddling,
	surface=cobblestone vs. sett & paving_stones
In-Reply-To: <CA+z=q=uho+5A0D+TBBwQ8W3ySJLyZRO6R0-bPevLqu2RAC-ETA@mail.gmail.com>
References: <CABPTjTAgawEmKoCfXvV=+wAzwjv4M4v8iDWmCoa8uQfaavwVsw@mail.gmail.com>
	<4F4245DD.7050300@jonno.cix.co.uk> <4F425337.802@tobias-knerr.de>
	<CAMLmWVteinYd8wzq8y482DAwQvYw32us+zM2KbNGWuQH1bbFqg@mail.gmail.com>
	<CABPTjTDjK73H9Q4xDO-E9mgd8ExvWfXf8=XNZf=nU-M8qw6xKg@mail.gmail.com>
	<CABPTjTB2CrPmZSZs9rboOWHbQ4WjdLEABOMRBa5pZyx_QxpJZQ@mail.gmail.com>
	<CA+z=q=uho+5A0D+TBBwQ8W3ySJLyZRO6R0-bPevLqu2RAC-ETA@mail.gmail.com>
Message-ID: <CABPTjTCeirA95rYWNXvbcj_kN5cW6yBZpudd+hfw0YESEE0kbA@mail.gmail.com>

Am 12. April 2012 00:31 schrieb Steve Bennett <stevagewp at gmail.com>:
> Clearly the change that was made was disruptive and changes the
> meaning of the 80,000 or so surface=cobblestone tags already in
> existence. I have thus changed the definition back and commented out
> surface=sett for the moment.
>
> Now, some issues with introducing sett:
> 1) No one knows what "sett" means.
> 2) The distinction is probably not important to most people.
> 3) There is far more sett than true cobblestone in the world.
> 4) We can't introduce a distinction by splitting an existing tag this
> way. Clearly surface=cobblestone means "Cobblestone or sett". There
> are too many instances to change that.


+1 to all this


> So, whoever really wants to introduce this distinction is going to
> have to find another way, perhaps "surface=cobblestone,
> cobblestone=sett".


not so sure about this. Currently there is really a lot of values in
surface but (as far as I know) none of them gets subtagged. Instead of
subtagging we could also keep cobblestone for "sett" and invent
another value for old cobblestones, could be something dumb like
real_cobblestone, real_cobbles, round_cobbles, round_cobblestone,
old_cobblestone or similar. We would subsequently change the tags for
the (probably few) surface=cobblestone which are actually old_cobbles
and done.

cheers,
Martin


From stevagewp at gmail.com  Sat Apr 14 02:10:17 2012
From: stevagewp at gmail.com (Steve Bennett)
Date: Sat, 14 Apr 2012 11:10:17 +1000
Subject: [Tagging] Wikifiddling,
	surface=cobblestone vs. sett & paving_stones
In-Reply-To: <CABPTjTCeirA95rYWNXvbcj_kN5cW6yBZpudd+hfw0YESEE0kbA@mail.gmail.com>
References: <CABPTjTAgawEmKoCfXvV=+wAzwjv4M4v8iDWmCoa8uQfaavwVsw@mail.gmail.com>
	<4F4245DD.7050300@jonno.cix.co.uk> <4F425337.802@tobias-knerr.de>
	<CAMLmWVteinYd8wzq8y482DAwQvYw32us+zM2KbNGWuQH1bbFqg@mail.gmail.com>
	<CABPTjTDjK73H9Q4xDO-E9mgd8ExvWfXf8=XNZf=nU-M8qw6xKg@mail.gmail.com>
	<CABPTjTB2CrPmZSZs9rboOWHbQ4WjdLEABOMRBa5pZyx_QxpJZQ@mail.gmail.com>
	<CA+z=q=uho+5A0D+TBBwQ8W3ySJLyZRO6R0-bPevLqu2RAC-ETA@mail.gmail.com>
	<CABPTjTCeirA95rYWNXvbcj_kN5cW6yBZpudd+hfw0YESEE0kbA@mail.gmail.com>
Message-ID: <CA+z=q=tuRe5YamHxUWeigLre0MkPJdZRqpvLteddnxwaWKD7Vg@mail.gmail.com>

On Sat, Apr 14, 2012 at 5:28 AM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
> not so sure about this. Currently there is really a lot of values in
> surface but (as far as I know) none of them gets subtagged. Instead of
> subtagging we could also keep cobblestone for "sett" and invent
> another value for old cobblestones, could be something dumb like
> real_cobblestone, real_cobbles, round_cobbles, round_cobblestone,
> old_cobblestone or similar. We would subsequently change the tags for
> the (probably few) surface=cobblestone which are actually old_cobbles
> and done.

Ok - I guess I'm wary of there being so many surface values, but that
does seem to be the practice. (How does any data reuser cope with so
many?)

Possible values:
surface=historic_cobblestone
surface=preserved_cobblestone
surface=rounded_cobblestone

Steve


From dieterdreist at gmail.com  Sat Apr 14 11:37:34 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sat, 14 Apr 2012 12:37:34 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F87C590.3070007@uni-paderborn.de>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl> <4F87C590.3070007@uni-paderborn.de>
Message-ID: <CABPTjTBB7AR5VYS=h9xk6scub8KGPwiq8DsmOegVzcQybw+DjA@mail.gmail.com>

Am 13. April 2012 08:20 schrieb Peter Wendorff <wendorff at uni-paderborn.de>:
> -10 for adding defaults as a hint for mappers!!!
>
> Every application using OSM data has to make assumptions about data not
> present in the database, sure, but reliable data has to be present in the
> database, as a missing tag in general can be both: missing/unknown, or
> "default", whatever "default" means.
>
> If we would define a set of defaults and mappers follow that set, nobody
> will add "default" values again, and it's not possible to distinguish
> between default and unknown any more.
>
> Yes, sure: Applications should have these default values, and probably it is
> useful to define some kind of "common defaults" in a file that can be used
> and parsed by applications, but this should not be part of the osm mapping
> work, but part of the software development around OSM (not in the osm core).


+1 to all of these

cheers,
Martin


From dieterdreist at gmail.com  Sat Apr 14 11:45:24 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sat, 14 Apr 2012 12:45:24 +0200
Subject: [Tagging] sidewalks and tagging for the renderer
In-Reply-To: <4F87D645.6080601@xs4all.nl>
References: <CABPTjTAt-P2fZcfRuAhLUfWkhtcSGRduWZTm_aRz-0DpaW6VZA@mail.gmail.com>
	<4F846D51.8020702@gmail.com>
	<CAPT3zJo6yYdqR_APeS0WyHkEdqrznoCbyg4OmcuvkFtFhgjxLw@mail.gmail.com>
	<CAC8Q8tLW-_33Qk_=N6+Xr1-pmwRv1-7Qo4Cjdh5Ef+3hE7ow4Q@mail.gmail.com>
	<CABPTjTB_Ra9Q=VQagODV=jCt0-462xi+AbFag2OYhBcoReVDkQ@mail.gmail.com>
	<4F85BF28.7040508@gmail.com> <1334186258.1972.62.camel@marvin>
	<4F8618B2.4000609@gmail.com> <1334212411.1972.69.camel@marvin>
	<CAMPM96oed5ZEKPeZgzs7E-gWWaLF-Mm7cR22+AKFm2S-21iy1w@mail.gmail.com>
	<CAPT3zJoEkwsPdFVyMMquZ5DH5DUgQi31D0SiS60z9K2AgoH4JA@mail.gmail.com>
	<CAMPM96oDX78jcdDPoEv0kb70u+1rNvRCL=iKtB2yDR7FBJSMQA@mail.gmail.com>
	<CAF1ph77SzdR99pxmffXUO+Q=ee_Ws1zHKAJ1a907osrE5P8P-Q@mail.gmail.com>
	<4F87C38D.9080003@xs4all.nl> <4F87C590.3070007@uni-paderborn.de>
	<4F87D645.6080601@xs4all.nl>
Message-ID: <CABPTjTDJtqAhnQxjGy4XouBG+pBkgfiS5E=+=RL51aB2WKwWbA@mail.gmail.com>

Am 13. April 2012 09:31 schrieb Colin Smale <colin.smale at xs4all.nl>:
> On 13/04/2012 08:20, Peter Wendorff wrote:
>> -10 for adding defaults as a hint for mappers!!!
> What would you do with this page? Enhance/complete it, or delete it?
> http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions


I would at least put it into the proposal namespace in the wiki. I
think the page is quite useful for application programmers to be used
as suggestion which fallback might be appropriate if no explicit tags
are given, but it shouldn't be used to discourage mappers in being
explicit.


cheers,
Martin


From neroute2 at gmail.com  Sun Apr 15 06:10:43 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Sun, 15 Apr 2012 01:10:43 -0400
Subject: [Tagging] Gated communities - access=private or destination?
Message-ID: <4F8A5853.4050505@gmail.com>

In the U.S., a gated residential community usually allows anyone in who 
has a legitimate reason to be there (e.g. visiting a friend, delivering 
a package, repairing a TV). It seems that this fits access=destination 
as well as private. Would it be reasonable to tag it as such, and leave 
access=private for secondary entrances that lack a guard and can only be 
opened by residents?


From Alan_Mintz+OSM at Earthlink.Net  Sun Apr 15 08:55:48 2012
From: Alan_Mintz+OSM at Earthlink.Net (Alan Mintz)
Date: Sun, 15 Apr 2012 00:55:48 -0700
Subject: [Tagging] Gated communities - access=private or  destination?
In-Reply-To: <4F8A5853.4050505@gmail.com>
Message-ID: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>

At 2012-04-14 22:10, Nathan Edgars II wrote:
>In the U.S., a gated residential community usually allows anyone in who 
>has a legitimate reason to be there (e.g. visiting a friend, delivering a 
>package, repairing a TV). It seems that this fits access=destination as 
>well as private. Would it be reasonable to tag it as such, and leave 
>access=private for secondary entrances that lack a guard and can only be 
>opened by residents?

access=destination says nothing about a legitimate reason to be there 
according to the wiki (http://wiki.openstreetmap.org/wiki/Access) - just 
that it's your destination. For example, you might want to go to a park 
within such a community to walk your dog, which would seem to be allowed by 
access=destination on the gate node, roads, or parking, but that would be 
incorrect unless you are, or are the guest of, a resident.

I tag everything within such gated communities as access=private.

--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>



From david at frankieandshadow.com  Sun Apr 15 09:02:05 2012
From: david at frankieandshadow.com (David Earl)
Date: Sun, 15 Apr 2012 09:02:05 +0100
Subject: [Tagging] Gated communities - access=private or destination?
In-Reply-To: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
References: <4F8A5853.4050505@gmail.com>
	<5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
Message-ID: <CANt01SRpNeTD=5UcjZvuYtYOCrfFib5XkV2wsDOu6xtFxSF9pQ@mail.gmail.com>

On Sunday, April 15, 2012, Alan Mintz wrote:

> At 2012-04-14 22:10, Nathan Edgars II wrote:
>
>> In the U.S., a gated residential community usually allows anyone in who
>> has a legitimate reason to be there (e.g. visiting a friend, delivering a
>> package, repairing a TV). It seems that this fits access=destination as
>> well as private. Would it be reasonable to tag it as such, and leave
>> access=private for secondary entrances that lack a guard and can only be
>> opened by residents?
>>
>
> access=destination says nothing about a legitimate reason to be there
> according to the wiki (http://wiki.openstreetmap.**org/wiki/Access<http://wiki.openstreetmap.org/wiki/Access>)
> - just that it's your destination. For example, you might want to go to a
> park within such a community to walk your dog, which would seem to be
> allowed by access=destination on the gate node, roads, or parking, but that
> would be incorrect unless you are, or are the guest of, a resident.
>
> I tag everything within such gated communities as access=private.
>
> +1

Everywhere private has a class of people who are legitimately allowed there.

The point about destination is that anyone is allowed but only if they are
going to that place (typically the restriction is to stop rat running).

There's also access=permissive, where a location is private (not a right)
but the owner gives blanket permission for anyone to access. That doesn't
sem to be the case here.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120415/a351a43e/attachment.html>

From neroute2 at gmail.com  Sun Apr 15 09:10:51 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Sun, 15 Apr 2012 04:10:51 -0400
Subject: [Tagging] Gated communities - access=private or  destination?
In-Reply-To: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
References: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
Message-ID: <4F8A828B.5010204@gmail.com>

On 4/15/2012 3:55 AM, Alan Mintz wrote:
> At 2012-04-14 22:10, Nathan Edgars II wrote:
>> In the U.S., a gated residential community usually allows anyone in
>> who has a legitimate reason to be there (e.g. visiting a friend,
>> delivering a package, repairing a TV). It seems that this fits
>> access=destination as well as private. Would it be reasonable to tag
>> it as such, and leave access=private for secondary entrances that lack
>> a guard and can only be opened by residents?
>
> access=destination says nothing about a legitimate reason to be there
> according to the wiki (http://wiki.openstreetmap.org/wiki/Access) - just
> that it's your destination. For example, you might want to go to a park
> within such a community to walk your dog, which would seem to be allowed
> by access=destination on the gate node, roads, or parking, but that
> would be incorrect unless you are, or are the guest of, a resident.

On the other hand, private says "Only with permission of the owner on an 
individual basis". But the owner is the homeowners association, and the 
individual residents can allow people in.

In addition, the example for destination - "customer parking lots" - has 
the same problems as a gated community. You (usually) can't park there 
to sleep in your car or have a tailgate party.

How would you distinguish an entry for visitors from an entry for 
residents only?


From dieterdreist at gmail.com  Sun Apr 15 10:08:41 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sun, 15 Apr 2012 11:08:41 +0200
Subject: [Tagging] [OSM-talk] POI for Hotel
In-Reply-To: <CAFJf9KNPe-6+ACCc+WYkF2SUDpFeCJi8g3Bx4BuMghqJ_kuxpA@mail.gmail.com>
References: <CAOeeQypkuMxQpGV57OPtdevkqg6=QEXsRvecYwuiuy6xAhE9Eg@mail.gmail.com>
	<25221.125.248.153.122.1334287720.squirrel@webmail02.lancs.ac.uk>
	<CAOeeQyo8p2d8X_q-LfsJetNrg21nVnd14Ha1GD8371g1HEfUkQ@mail.gmail.com>
	<22423.125.248.153.122.1334294073.squirrel@webmail02.lancs.ac.uk>
	<CABPTjTDSY6YZhd-P2kbG=ukJc-ZA5w=KWu4twxsEHeeJC-8nLA@mail.gmail.com>
	<CAFJf9KNPe-6+ACCc+WYkF2SUDpFeCJi8g3Bx4BuMghqJ_kuxpA@mail.gmail.com>
Message-ID: <CABPTjTBvN-ct5=uYggyjfrYDo0ym+C+TqSNtwhoFLWnNTXfkFw@mail.gmail.com>

Am 13. April 2012 19:44 schrieb John Sturdy <jcg.sturdy at gmail.com>:
> On Fri, Apr 13, 2012 at 12:10 PM, Martin Koppenhoefer
> <dieterdreist at gmail.com> wrote:
>> ?Prices on the other hand
>> are also of interest if you look for a hotel, but there is currently
>> no hope to keep this information up to date (and usually there are
>> lots of prices, dependent on the particular room (view/orientation,
>> location, size, ...).
>
> To make these reachable from OSM, perhaps the best thing to do would
> be to use the "website" tag to point to the hotel's own web site.


That's always useful, but it doesn't solve the issue of getting the
data for a query like: give me all the hotels cheaper than 66 EUR for
a double room with bathroom in this bounding box.


From dieterdreist at gmail.com  Sun Apr 15 10:12:18 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sun, 15 Apr 2012 11:12:18 +0200
Subject: [Tagging] Wikifiddling,
	surface=cobblestone vs. sett & paving_stones
In-Reply-To: <CA+z=q=tuRe5YamHxUWeigLre0MkPJdZRqpvLteddnxwaWKD7Vg@mail.gmail.com>
References: <CABPTjTAgawEmKoCfXvV=+wAzwjv4M4v8iDWmCoa8uQfaavwVsw@mail.gmail.com>
	<4F4245DD.7050300@jonno.cix.co.uk> <4F425337.802@tobias-knerr.de>
	<CAMLmWVteinYd8wzq8y482DAwQvYw32us+zM2KbNGWuQH1bbFqg@mail.gmail.com>
	<CABPTjTDjK73H9Q4xDO-E9mgd8ExvWfXf8=XNZf=nU-M8qw6xKg@mail.gmail.com>
	<CABPTjTB2CrPmZSZs9rboOWHbQ4WjdLEABOMRBa5pZyx_QxpJZQ@mail.gmail.com>
	<CA+z=q=uho+5A0D+TBBwQ8W3ySJLyZRO6R0-bPevLqu2RAC-ETA@mail.gmail.com>
	<CABPTjTCeirA95rYWNXvbcj_kN5cW6yBZpudd+hfw0YESEE0kbA@mail.gmail.com>
	<CA+z=q=tuRe5YamHxUWeigLre0MkPJdZRqpvLteddnxwaWKD7Vg@mail.gmail.com>
Message-ID: <CABPTjTBnaOCwPmALB0W5rN_UB1fxgY5CYyX3r+eXn-wJ9bTSYA@mail.gmail.com>

Am 14. April 2012 03:10 schrieb Steve Bennett <stevagewp at gmail.com>:
> Possible values:
> surface=historic_cobblestone
> surface=preserved_cobblestone
> surface=rounded_cobblestone


I'd prefer to focus on the shape and therefore "rounded_cobblestone",
because other aspects like historic can be expressed with additional
tags. Also not all "true cobblestones" are necessarily old.

cheers,
Martin


From toby.murray at gmail.com  Sun Apr 15 10:33:23 2012
From: toby.murray at gmail.com (Toby Murray)
Date: Sun, 15 Apr 2012 04:33:23 -0500
Subject: [Tagging] [OSM-talk] POI for Hotel
In-Reply-To: <CABPTjTBvN-ct5=uYggyjfrYDo0ym+C+TqSNtwhoFLWnNTXfkFw@mail.gmail.com>
References: <CAOeeQypkuMxQpGV57OPtdevkqg6=QEXsRvecYwuiuy6xAhE9Eg@mail.gmail.com>
	<25221.125.248.153.122.1334287720.squirrel@webmail02.lancs.ac.uk>
	<CAOeeQyo8p2d8X_q-LfsJetNrg21nVnd14Ha1GD8371g1HEfUkQ@mail.gmail.com>
	<22423.125.248.153.122.1334294073.squirrel@webmail02.lancs.ac.uk>
	<CABPTjTDSY6YZhd-P2kbG=ukJc-ZA5w=KWu4twxsEHeeJC-8nLA@mail.gmail.com>
	<CAFJf9KNPe-6+ACCc+WYkF2SUDpFeCJi8g3Bx4BuMghqJ_kuxpA@mail.gmail.com>
	<CABPTjTBvN-ct5=uYggyjfrYDo0ym+C+TqSNtwhoFLWnNTXfkFw@mail.gmail.com>
Message-ID: <CAJeqKgsrfUEu1o0GyOzUhOYKKVmqkcGfzDMtahGGTTAjdQ_w5g@mail.gmail.com>

On Sun, Apr 15, 2012 at 4:08 AM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
>
> That's always useful, but it doesn't solve the issue of getting the
> data for a query like: give me all the hotels cheaper than 66 EUR for
> a double room with bathroom in this bounding box.

I'm not sure why you would attempt such a query with nothing but OSM
data. There are multiple websites that specialize in this type of
thing and are far better at it than OSM will ever be because they have
direct interaction with hotels to handle the volatility in prices,
room availability and other considerations that are entirely outside
of the scope of OSM.

hotels.com, orbitz.com, kayak.com, priceline.com, travelocity.com, etc, etc

There could certainly be interaction between these sites and OSM. But
OSM is not a travel site and I would never use it as such.

Toby


From voschix at gmail.com  Sun Apr 15 11:22:30 2012
From: voschix at gmail.com (Volker Schmidt)
Date: Sun, 15 Apr 2012 12:22:30 +0200
Subject: [Tagging] [OSM-talk] POI for Hotel
In-Reply-To: <CAJeqKgsrfUEu1o0GyOzUhOYKKVmqkcGfzDMtahGGTTAjdQ_w5g@mail.gmail.com>
References: <CAOeeQypkuMxQpGV57OPtdevkqg6=QEXsRvecYwuiuy6xAhE9Eg@mail.gmail.com>
	<25221.125.248.153.122.1334287720.squirrel@webmail02.lancs.ac.uk>
	<CAOeeQyo8p2d8X_q-LfsJetNrg21nVnd14Ha1GD8371g1HEfUkQ@mail.gmail.com>
	<22423.125.248.153.122.1334294073.squirrel@webmail02.lancs.ac.uk>
	<CABPTjTDSY6YZhd-P2kbG=ukJc-ZA5w=KWu4twxsEHeeJC-8nLA@mail.gmail.com>
	<CAFJf9KNPe-6+ACCc+WYkF2SUDpFeCJi8g3Bx4BuMghqJ_kuxpA@mail.gmail.com>
	<CABPTjTBvN-ct5=uYggyjfrYDo0ym+C+TqSNtwhoFLWnNTXfkFw@mail.gmail.com>
	<CAJeqKgsrfUEu1o0GyOzUhOYKKVmqkcGfzDMtahGGTTAjdQ_w5g@mail.gmail.com>
Message-ID: <CALQ-OR7F_bwV4iRVSgKncc1BwA0FrLpjOHN-=pDoyKd_KdfHng@mail.gmail.com>

> I'm not sure why you would attempt such a query with nothing but OSM
> data. There are multiple websites that specialize in this type of
> thing and are far better at it than OSM will ever be because they have
> direct interaction with hotels to handle the volatility in prices,
> room availability and other considerations that are entirely outside
> of the scope of OSM.
>


> OSM is not a travel site and I would never use it as such.
>

Absolutely correct.
We need to be extremely careful not to put volatile info into the OSM
database.
We would end up with a heap of useless data. We simply do not have the
means for maintaining that type of data.

Volker
Padova, Italy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120415/c6b96c85/attachment-0001.html>

From Alan_Mintz+OSM at Earthlink.Net  Sun Apr 15 11:30:16 2012
From: Alan_Mintz+OSM at Earthlink.Net (Alan Mintz)
Date: Sun, 15 Apr 2012 03:30:16 -0700
Subject: [Tagging] Gated communities - access=private or   destination?
In-Reply-To: <4F8A828B.5010204@gmail.com>
References: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
Message-ID: <5.1.0.14.2.20120415032503.03e12ec0@mail.earthlink.net>

At 2012-04-15 01:10, Nathan Edgars II wrote:
>How would you distinguish an entry for visitors from an entry for 
>residents only?

name= or ref= or whatever else Mapnik was designed to render on a gate.

--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>



From jaakko at helleranta.com  Sun Apr 15 13:38:08 2012
From: jaakko at helleranta.com (Jaakko Helleranta.com)
Date: Sun, 15 Apr 2012 12:38:08 +0000
Subject: [Tagging] Gated communities - access=private or   destination?
Message-ID: <997178509-1334489712-cardhu_decombobulator_blackberry.rim.net-1326375907-@b3.c26.bise6.blackberry>

Btw. I think current Mapnik rendering renders addr:housenumber=* over barrier=gate .
Meaning: if u tag em both u won't see the gate icon at all but only the house number. .. Which imho is not ideal.

I'd love to see both rendered (when space allows) as both are of high importance.

This is based on my experience in Haiti where often the only instructions to a place is eg: "about 400m down, black gate on the left with #15 on it".

Has anyone bn thinking about this? (How) can I submit a ticket to suggest fixing this? 
.. Nico, Sev, Brian: could this be taken in consideration in the possible Haiti custom rendering style? 

Cheers,
-Jaakko

------Original Message------
From: Alan Mintz
To: Tag discussion, strategy and related tools
ReplyTo: Tag discussion,	strategy and related tools
Subject: Re: [Tagging] Gated communities - access=private or   destination?
Sent: Apr 15, 2012 05:30

At 2012-04-15 01:10, Nathan Edgars II wrote:
>How would you distinguish an entry for visitors from an entry for 
>residents only?

name= or ref= or whatever else Mapnik was designed to render on a gate.

--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>


_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


Sent from my BlackBerry? device from Digicel
--
Mobile: +509-37-26 91 54, Skype/GoogleTalk: jhelleranta

From vpottier at gmail.com  Sun Apr 15 12:39:52 2012
From: vpottier at gmail.com (Vincent Pottier)
Date: Sun, 15 Apr 2012 13:39:52 +0200
Subject: [Tagging] Gated communities - access=private or  destination?
In-Reply-To: <4F8A828B.5010204@gmail.com>
References: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<4F8A828B.5010204@gmail.com>
Message-ID: <4F8AB388.7040400@gmail.com>

Le 15/04/2012 10:10, Nathan Edgars II a ?crit :
> On 4/15/2012 3:55 AM, Alan Mintz wrote:
>> At 2012-04-14 22:10, Nathan Edgars II wrote:
>>> In the U.S., a gated residential community usually allows anyone in
>>> who has a legitimate reason to be there (e.g. visiting a friend,
>>> delivering a package, repairing a TV). It seems that this fits
>>> access=destination as well as private. Would it be reasonable to tag
>>> it as such, and leave access=private for secondary entrances that lack
>>> a guard and can only be opened by residents?
>>
>> access=destination says nothing about a legitimate reason to be there
>> according to the wiki (http://wiki.openstreetmap.org/wiki/Access) - just
>> that it's your destination. For example, you might want to go to a park
>> within such a community to walk your dog, which would seem to be allowed
>> by access=destination on the gate node, roads, or parking, but that
>> would be incorrect unless you are, or are the guest of, a resident.
>
> On the other hand, private says "Only with permission of the owner on 
> an individual basis". But the owner is the homeowners association, and 
> the individual residents can allow people in.
Permission can be given 'a priori' for friends, delivery men, rather 
than case by case, so access=private fits.
--
FrViPofm



From Alan_Mintz+OSM at Earthlink.Net  Sun Apr 15 12:50:31 2012
From: Alan_Mintz+OSM at Earthlink.Net (Alan Mintz)
Date: Sun, 15 Apr 2012 04:50:31 -0700
Subject: [Tagging] Gated communities - access=private or destination?
In-Reply-To: <997178509-1334489712-cardhu_decombobulator_blackberry.rim.
	net-1326375907-@b3.c26.bise6.blackberry>
Message-ID: <5.1.0.14.2.20120415044320.03e2db10@mail.earthlink.net>

At 2012-04-15 05:38, Jaakko Helleranta.com wrote:
>Btw. I think current Mapnik rendering renders addr:housenumber=* over 
>barrier=gate .
>Meaning: if u tag em both u won't see the gate icon at all but only the 
>house number. .. Which imho is not ideal.
>
>I'd love to see both rendered (when space allows) as both are of high 
>importance.
>
>This is based on my experience in Haiti where often the only instructions 
>to a place is eg: "about 400m down, black gate on the left with #15 on it".
>
>Has anyone bn thinking about this? (How) can I submit a ticket to suggest 
>fixing this?
>.. Nico, Sev, Brian: could this be taken in consideration in the possible 
>Haiti custom rendering style?

I would normally tag the address on a landuse area or a building node or 
area, not on the gate. However, I would agree that Mapnik should render 
whatever icon is represented by the other tagging on a node at a higher 
priority than using the "house" icon associated with addr:housenumber.

--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>



From jaakko at helleranta.com  Sun Apr 15 14:15:44 2012
From: jaakko at helleranta.com (Jaakko Helleranta.com)
Date: Sun, 15 Apr 2012 13:15:44 +0000
Subject: [Tagging] Gated communities - access=private or destination?
In-Reply-To: <5.1.0.14.2.20120415044320.03e2db10@mail.earthlink.net>
References: <997178509-1334489712-cardhu_decombobulator_blackberry.rim.	net-1326375907-@b3.c26.bise6.blackberry>
	<5.1.0.14.2.20120415044320.03e2db10@mail.earthlink.net>
Message-ID: <1437716689-1334491991-cardhu_decombobulator_blackberry.rim.net-387516477-@b3.c26.bise6.blackberry>

I prefer tagging the addr:housenumber on building outline, landuse, parcel, etc, too. That's clearly the right place for it.

The challenge, though, is that if/when one is simply "driving by" it's very difficult to know especially in densly built areas where the # should be placed -- even when looking at the imagery afterwards. 

So, in these cases it makes sense to me to tag the house# on the gate. .. And it might make sense to tag it on that in any case to pinpoint which gate (of the often many nearby gates) is the one with that specific #).

And just to clarify: Mapnik doesn't render any "house icon" on addr:housenumber, it merely renders the number (and in the case of combined use of barrier=gate it does that currently at the expense of the gate icon).

Cheers,
-Jaakko

Sent from my BlackBerry? device from Digicel
--
Mobile: +509-37-26 91 54, Skype/GoogleTalk: jhelleranta

-----Original Message-----
From: Alan Mintz <Alan_Mintz+OSM at Earthlink.Net>
Date: Sun, 15 Apr 2012 04:50:31 
To: Tag discussion, strategy and related tools<tagging at openstreetmap.org>
Reply-To: "Tag discussion,
	strategy and related tools" <tagging at openstreetmap.org>
Subject: Re: [Tagging] Gated communities - access=private or destination?

At 2012-04-15 05:38, Jaakko Helleranta.com wrote:
>Btw. I think current Mapnik rendering renders addr:housenumber=* over 
>barrier=gate .
>Meaning: if u tag em both u won't see the gate icon at all but only the 
>house number. .. Which imho is not ideal.
>
>I'd love to see both rendered (when space allows) as both are of high 
>importance.
>
>This is based on my experience in Haiti where often the only instructions 
>to a place is eg: "about 400m down, black gate on the left with #15 on it".
>
>Has anyone bn thinking about this? (How) can I submit a ticket to suggest 
>fixing this?
>.. Nico, Sev, Brian: could this be taken in consideration in the possible 
>Haiti custom rendering style?

I would normally tag the address on a landuse area or a building node or 
area, not on the gate. However, I would agree that Mapnik should render 
whatever icon is represented by the other tagging on a node at a higher 
priority than using the "house" icon associated with addr:housenumber.

--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>


_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

From john at jfeldredge.com  Sun Apr 15 14:18:01 2012
From: john at jfeldredge.com (John F. Eldredge)
Date: Sun, 15 Apr 2012 08:18:01 -0500
Subject: [Tagging]
	=?utf-8?q?Wikifiddling=2C=09surface=3Dcobblestone_vs=2E?=
	=?utf-8?q?_sett_=26_paving=5Fstones?=
In-Reply-To: <CABPTjTBnaOCwPmALB0W5rN_UB1fxgY5CYyX3r+eXn-wJ9bTSYA@mail.gmail.com>
References: <CABPTjTAgawEmKoCfXvV=+wAzwjv4M4v8iDWmCoa8uQfaavwVsw@mail.gmail.com>
	<4F4245DD.7050300@jonno.cix.co.uk> <4F425337.802@tobias-knerr.de>
	<CAMLmWVteinYd8wzq8y482DAwQvYw32us+zM2KbNGWuQH1bbFqg@mail.gmail.com>
	<CABPTjTDjK73H9Q4xDO-E9mgd8ExvWfXf8=XNZf=nU-M8qw6xKg@mail.gmail.com>
	<CABPTjTB2CrPmZSZs9rboOWHbQ4WjdLEABOMRBa5pZyx_QxpJZQ@mail.gmail.com>
	<CA+z=q=uho+5A0D+TBBwQ8W3ySJLyZRO6R0-bPevLqu2RAC-ETA@mail.gmail.com>
	<CABPTjTCeirA95rYWNXvbcj_kN5cW6yBZpudd+hfw0YESEE0kbA@mail.gmail.com>
	<CA+z=q=tuRe5YamHxUWeigLre0MkPJdZRqpvLteddnxwaWKD7Vg@mail.gmail.com>
	<CABPTjTBnaOCwPmALB0W5rN_UB1fxgY5CYyX3r+eXn-wJ9bTSYA@mail.gmail.com>
Message-ID: <14867f61-602d-455f-ac3d-03fa282dbdf5@email.android.com>

Martin Koppenhoefer <dieterdreist at gmail.com> wrote:

> Am 14. April 2012 03:10 schrieb Steve Bennett <stevagewp at gmail.com>:
> > Possible values:
> > surface=historic_cobblestone
> > surface=preserved_cobblestone
> > surface=rounded_cobblestone
> 
> 
> I'd prefer to focus on the shape and therefore "rounded_cobblestone",
> because other aspects like historic can be expressed with additional
> tags. Also not all "true cobblestones" are necessarily old.
> 
> cheers,
> Martin
> 

True.  I have seen some modern construction that used natural river cobblestones, rather than cut stones.

-- 
John F. Eldredge --  john at jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria


From markus.lindholm at gmail.com  Sun Apr 15 14:57:44 2012
From: markus.lindholm at gmail.com (Markus Lindholm)
Date: Sun, 15 Apr 2012 15:57:44 +0200
Subject: [Tagging] Gated communities - access=private or destination?
In-Reply-To: <1437716689-1334491991-cardhu_decombobulator_blackberry.rim.net-387516477-@b3.c26.bise6.blackberry>
References: <5.1.0.14.2.20120415044320.03e2db10@mail.earthlink.net>
	<1437716689-1334491991-cardhu_decombobulator_blackberry.rim.net-387516477-@b3.c26.bise6.blackberry>
Message-ID: <CAF4WrPKV1aErzML_d1vr1wDS31buKW_Cvs4o9qDbUx-uRurKSA@mail.gmail.com>

On 15 April 2012 15:15, Jaakko Helleranta.com <jaakko at helleranta.com> wrote:
> I prefer tagging the addr:housenumber on building outline, landuse, parcel, etc, too. That's clearly the right place for it.

My personal mapping philosophy is to avoid overloading of information
on nodes and ways, so addr:housenumber always gets its own node. At
least to me that's the most sensible approach.

/Markus


From gdt at ir.bbn.com  Sun Apr 15 15:01:52 2012
From: gdt at ir.bbn.com (Greg Troxel)
Date: Sun, 15 Apr 2012 10:01:52 -0400
Subject: [Tagging] Gated communities - access=private or  destination?
In-Reply-To: <4F8A828B.5010204@gmail.com> (Nathan Edgars, II's message of
	"Sun, 15 Apr 2012 04:10:51 -0400")
References: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<4F8A828B.5010204@gmail.com>
Message-ID: <rmibomtozzj.fsf@fnord.ir.bbn.com>


Nathan Edgars II <neroute2 at gmail.com> writes:

> On the other hand, private says "Only with permission of the owner on
> an individual basis". But the owner is the homeowners association, and
> the individual residents can allow people in.

That's creating nits where they don't even exist!  Owner is a more
complicated concept (and for this discussion would include a person
leasing a single-family house).

I think the key issue with "legitimate reason" is that it's tied to
thinking about rights of access.  With an entirely private place, only
owners have a right of access (ignoring utility easements), and everyone
else is there by permission.

> In addition, the example for destination - "customer parking lots" -
> has the same problems as a gated community. You (usually) can't park
> there to sleep in your car or have a tailgate party.

True, but that raises the larger question we keep avoiding: are we
building an ontology to represent the entire world?

My impression is that access=destination is a slightly damaged version
of access=yes.  The road is a public way, but use for other than going
within the complex/etc. is specially prohibited.

It seems those lots are tagged access=customers.  That's an expanded
version of access=private, to note that customers of nearby stores have
permission.

These two uses are fundamentally different (public- vs private+).

access=private/permissive/destination/yes is currently more or less
based on concepts in English law.   I think what you're trying to do
(and I understand why and think it's reasonable) is to have a way to
define the set of people

> How would you distinguish an entry for visitors from an entry for
> residents only?

That's reasonable, but these are subtypes of access=private.
perhaps

 private=residents
 private=guests

I think it's helpful to articulate what the data consumers are going to
do, and what decisions they need to make, which leads to working on the
grand ontology (which is what I was doing above).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120415/e5f4f958/attachment.pgp>

From ewoerner at kde.org  Sun Apr 15 15:23:04 2012
From: ewoerner at kde.org (Eckhart =?ISO-8859-1?Q?W=F6rner?=)
Date: Sun, 15 Apr 2012 16:23:04 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <4F858A45.2010603@googlemail.com>
References: <4F745D0C.2020206@infoware.de> <4F83B31D.5020502@gmail.com>
	<4F858A45.2010603@googlemail.com>
Message-ID: <1382563.UEHgbvYOV3@obiwan>

Hi,

Am Mittwoch, 11. April 2012, 15:42:29 schrieb fly:
> I still do not get one major point which was totally left out on the first
> scheme. What actually belongs to a "point" and how are they tagged. 
Especially
> on big crossings and roundabouts I always was confused (e.g. it might be
> possible that a part of this point is blocked but how do I know which one 
and
> you might be able to use  the first/last exit/entrance of a junction but not 
the
> rest. )

Indeed, this is what I was worried about as well.
Here's a proposed (partial) fix, which starts from the original proposal.

Let's assume that 123, 456 and 789 are connected LCD which describe a road. 
Further assume that at 456 there's a big intersection.
Then:
- All ways between 123 and 456 are marked tmc=DE:123+456, and all ways between 
456 and 789 are marked tmc=DE:456+789.
- All ways on the intersection 456 leading from 123 to 789 are then marked 
tmc=DE:456+.

This has several advantages:
- A traffic jam between 123 and 456 will not block the intersection 456 anymore.
- Exits are defined as follows:  an exit at 456 in positive direction starts at 
a way that is tagged either tmc=DE:456+ or tmc=DE:123+456 ("from"), uses a 
node that is part of a way tagged either tmc=DE:456+ or tmc=DE:456+789 ("via") 
and ends at a way that is tagged neither tmc=DE:456+ nor tmc=DE:456+789, nor 
tmc=DE:123+456 ("to"). An exit is therefore a maneuver. This may sound a bit 
technical at first, but none of this is exposed to the tagging, and the idea of 
an exit is probably quite intuitive.
- Likewise, entries are defined.
- Automatic consistency checking is still possible, as there are no holes.

There is at least one issue that still has to be addressed: this tagging does 
not imply an ordering of the exits / entries; it is not clear what the first, 
second? exit would be.

Eckhart W?rner


From dieterdreist at gmail.com  Sun Apr 15 15:36:18 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sun, 15 Apr 2012 16:36:18 +0200
Subject: [Tagging] [OSM-talk] POI for Hotel
In-Reply-To: <CALQ-OR7F_bwV4iRVSgKncc1BwA0FrLpjOHN-=pDoyKd_KdfHng@mail.gmail.com>
References: <CAOeeQypkuMxQpGV57OPtdevkqg6=QEXsRvecYwuiuy6xAhE9Eg@mail.gmail.com>
	<25221.125.248.153.122.1334287720.squirrel@webmail02.lancs.ac.uk>
	<CAOeeQyo8p2d8X_q-LfsJetNrg21nVnd14Ha1GD8371g1HEfUkQ@mail.gmail.com>
	<22423.125.248.153.122.1334294073.squirrel@webmail02.lancs.ac.uk>
	<CABPTjTDSY6YZhd-P2kbG=ukJc-ZA5w=KWu4twxsEHeeJC-8nLA@mail.gmail.com>
	<CAFJf9KNPe-6+ACCc+WYkF2SUDpFeCJi8g3Bx4BuMghqJ_kuxpA@mail.gmail.com>
	<CABPTjTBvN-ct5=uYggyjfrYDo0ym+C+TqSNtwhoFLWnNTXfkFw@mail.gmail.com>
	<CAJeqKgsrfUEu1o0GyOzUhOYKKVmqkcGfzDMtahGGTTAjdQ_w5g@mail.gmail.com>
	<CALQ-OR7F_bwV4iRVSgKncc1BwA0FrLpjOHN-=pDoyKd_KdfHng@mail.gmail.com>
Message-ID: <CABPTjTD9aNYHV6Kd9fokgA_NdqHQ7pGrZL0yPZLft4Ak0pKsZQ@mail.gmail.com>

Am 15. April 2012 12:22 schrieb Volker Schmidt <voschix at gmail.com>:
>
>> I'm not sure why you would attempt such a query with nothing but OSM
>> data. There are multiple websites that specialize in this type of
>> thing and are far better at it than OSM will ever be because they have
>> direct interaction with hotels to handle the volatility in prices,
>> room availability and other considerations that are entirely outside
>> of the scope of OSM.
>
>
>>
>> OSM is not a travel site and I would never use it as such.
>
>
> Absolutely correct.
> We need to be extremely careful not to put volatile info into the OSM
> database.
> We would end up with a heap of useless data. We simply do not have the means
> for maintaining that type of data.


I am not really convinced. Entering detailed price information is out
of the scope of the main OSM database, I agree. On the other hand OSM
is full of volatile information (e.g. people adding road constructions
which will be finished in short terms. I also remember a thread on
talk-de the other day, where someone complained that another mapper
had inserted a road as usable 2 days before it was actually opened).
The point is: if there is someone to maintain the data it could be
inserted, if instead there is high probability that this data will be
left untouched and unused, then don't enter it.

Rough pricing information (e.g. price classes like cheap, middle
range, expensive, ultra luxurious) will not be outdated any soon. Of
course prices get adjusted to inflation, hotels have special offers
and the like, but the rough price-range is in the very most of the
cases quite stable.

Toby mentioned a series of examples for hotel search sites (
hotels.com, orbitz.com, kayak.com, priceline.com, travelocity.com )
but none of them offer their database for download so it's not really
an alternative to open data. Basically we would have to get the hotel
operators themselves to enter their information into OSM (or into a
parallel system that is somehow linked to), and there probably won't
be the problem of keeping the data up to date.

Anyway, my post up there was to advocate the insertion of the total
number of rooms for a hotel, not the prices.

cheers,
Martin


From david at frankieandshadow.com  Sun Apr 15 15:45:41 2012
From: david at frankieandshadow.com (David Earl)
Date: Sun, 15 Apr 2012 15:45:41 +0100
Subject: [Tagging] Gated communities - access=private or  destination?
In-Reply-To: <rmibomtozzj.fsf@fnord.ir.bbn.com>
References: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<4F8A828B.5010204@gmail.com> <rmibomtozzj.fsf@fnord.ir.bbn.com>
Message-ID: <4F8ADF15.4080008@frankieandshadow.com>

On 15/04/2012 15:01, Greg Troxel wrote:
> My impression is that access=destination is a slightly damaged version
> of access=yes.  The road is a public way, but use for other than going
> within the complex/etc. is specially prohibited.

This is where it comes from: http://bit.ly/HJUjAh
(which is a legal, if widely flouted, status).

David




From markus.lindholm at gmail.com  Sun Apr 15 15:46:44 2012
From: markus.lindholm at gmail.com (Markus Lindholm)
Date: Sun, 15 Apr 2012 16:46:44 +0200
Subject: [Tagging] [OSM-talk] POI for Hotel
In-Reply-To: <CAJeqKgsrfUEu1o0GyOzUhOYKKVmqkcGfzDMtahGGTTAjdQ_w5g@mail.gmail.com>
References: <CAOeeQypkuMxQpGV57OPtdevkqg6=QEXsRvecYwuiuy6xAhE9Eg@mail.gmail.com>
	<25221.125.248.153.122.1334287720.squirrel@webmail02.lancs.ac.uk>
	<CAOeeQyo8p2d8X_q-LfsJetNrg21nVnd14Ha1GD8371g1HEfUkQ@mail.gmail.com>
	<22423.125.248.153.122.1334294073.squirrel@webmail02.lancs.ac.uk>
	<CABPTjTDSY6YZhd-P2kbG=ukJc-ZA5w=KWu4twxsEHeeJC-8nLA@mail.gmail.com>
	<CAFJf9KNPe-6+ACCc+WYkF2SUDpFeCJi8g3Bx4BuMghqJ_kuxpA@mail.gmail.com>
	<CABPTjTBvN-ct5=uYggyjfrYDo0ym+C+TqSNtwhoFLWnNTXfkFw@mail.gmail.com>
	<CAJeqKgsrfUEu1o0GyOzUhOYKKVmqkcGfzDMtahGGTTAjdQ_w5g@mail.gmail.com>
Message-ID: <CAF4WrP+XRuUfYvLgfbOrp59m5jjP2qeAgGgfi+rC7hNMwCqQvg@mail.gmail.com>

On 15 April 2012 11:33, Toby Murray <toby.murray at gmail.com> wrote:
> On Sun, Apr 15, 2012 at 4:08 AM, Martin Koppenhoefer
> <dieterdreist at gmail.com> wrote:
>>
>> That's always useful, but it doesn't solve the issue of getting the
>> data for a query like: give me all the hotels cheaper than 66 EUR for
>> a double room with bathroom in this bounding box.
>
> I'm not sure why you would attempt such a query with nothing but OSM
> data. There are multiple websites that specialize in this type of
> thing and are far better at it than OSM will ever be because they have
> direct interaction with hotels to handle the volatility in prices,
> room availability and other considerations that are entirely outside
> of the scope of OSM.
>
> hotels.com, orbitz.com, kayak.com, priceline.com, travelocity.com, etc, etc
>
> There could certainly be interaction between these sites and OSM. But
> OSM is not a travel site and I would never use it as such.

Somebody should  start an OpenServicesDatabase-project, that would
host information about hotels, restaurants, cafes, museums and parks
with detailed description of amenities provided along with user
reviews.

/Markus


From dieterdreist at gmail.com  Sun Apr 15 15:59:54 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sun, 15 Apr 2012 16:59:54 +0200
Subject: [Tagging] Gated communities - access=private or destination?
In-Reply-To: <4F8A828B.5010204@gmail.com>
References: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<4F8A828B.5010204@gmail.com>
Message-ID: <CABPTjTBEfAA+KqOpzcdH4pMu6S_O+ja=EoP0_cZ5=PuPVATRZQ@mail.gmail.com>

Am 15. April 2012 10:10 schrieb Nathan Edgars II <neroute2 at gmail.com>:
> How would you distinguish an entry for visitors from an entry for residents
> only?


There is already an extension to the barrier class which allows to
mark the presence of a guard.
page: http://wiki.openstreetmap.org/wiki/Key:barrier:personnel
from this approved proposal: Proposal:
http://wiki.openstreetmap.org/wiki/Proposed_features/New_barrier_types

cheers,
Martin


From dieterdreist at gmail.com  Sun Apr 15 16:03:46 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sun, 15 Apr 2012 17:03:46 +0200
Subject: [Tagging] Gated communities - access=private or destination?
In-Reply-To: <1437716689-1334491991-cardhu_decombobulator_blackberry.rim.net-387516477-@b3.c26.bise6.blackberry>
References: <5.1.0.14.2.20120415044320.03e2db10@mail.earthlink.net>
	<1437716689-1334491991-cardhu_decombobulator_blackberry.rim.net-387516477-@b3.c26.bise6.blackberry>
Message-ID: <CABPTjTDRRR+7Ozf=SzRCJVf1_U79oQf2RQ=gCcq-S0x_cG-APg@mail.gmail.com>

Am 15. April 2012 15:15 schrieb Jaakko Helleranta.com <jaakko at helleranta.com>:
> I prefer tagging the addr:housenumber on building outline, landuse, parcel, etc, too. That's clearly the right place for it.


what is "right" and what is "wrong" depends on the circumstances. I
also prefer tagging addr:housenumbers to where they apply, but in
Italy this is (as I was recently told on talk-it) actually the gate,
not the house or the parcel.

cheers,
Martin


From baloo at ursamundi.org  Sun Apr 15 18:30:48 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Sun, 15 Apr 2012 10:30:48 -0700
Subject: [Tagging] Gated communities - access=private or destination?
In-Reply-To: <4F8A828B.5010204@gmail.com>
References: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<4F8A828B.5010204@gmail.com>
Message-ID: <CAMPM96qoTpfh3+W6jVAS3pDm4Z7-eEvzbabuzksND_2psPQihQ@mail.gmail.com>

On Sun, Apr 15, 2012 at 1:10 AM, Nathan Edgars II <neroute2 at gmail.com> wrote:

> On the other hand, private says "Only with permission of the owner on an
> individual basis". But the owner is the homeowners association, and the
> individual residents can allow people in.

And so could the security company.  But the HOA and security firm are
acting on behalf of, and with the authority of, the owner.  So
effectively, exactly what "private" is.

> How would you distinguish an entry for visitors from an entry for residents
> only?

Mark the callbox for nonresidents.


From neroute2 at gmail.com  Sun Apr 15 21:55:01 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Sun, 15 Apr 2012 16:55:01 -0400
Subject: [Tagging] Gated communities - access=private or   destination?
In-Reply-To: <5.1.0.14.2.20120415032503.03e12ec0@mail.earthlink.net>
References: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415032503.03e12ec0@mail.earthlink.net>
Message-ID: <4F8B35A5.1040509@gmail.com>

On 4/15/2012 6:30 AM, Alan Mintz wrote:
> At 2012-04-15 01:10, Nathan Edgars II wrote:
>> How would you distinguish an entry for visitors from an entry for
>> residents only?
>
> name= or ref= or whatever else Mapnik was designed to render on a gate.

That's only a solution if the gates actually have names. I've never seen 
such a name.


From john at jfeldredge.com  Sun Apr 15 22:51:38 2012
From: john at jfeldredge.com (John F. Eldredge)
Date: Sun, 15 Apr 2012 16:51:38 -0500
Subject: [Tagging] Gated communities - access=private or   destination?
In-Reply-To: <4F8B35A5.1040509@gmail.com>
References: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415032503.03e12ec0@mail.earthlink.net>
	<4F8B35A5.1040509@gmail.com>
Message-ID: <f3be2846-7cbc-4b9a-9684-f6084a5dad63@email.android.com>

Nathan Edgars II <neroute2 at gmail.com> wrote:

> On 4/15/2012 6:30 AM, Alan Mintz wrote:
> > At 2012-04-15 01:10, Nathan Edgars II wrote:
> >> How would you distinguish an entry for visitors from an entry for
> >> residents only?
> >
> > name= or ref= or whatever else Mapnik was designed to render on a
> gate.
> 
> That's only a solution if the gates actually have names. I've never
> seen 
> such a name.
> 

I have seen gates that had number signs (1, 2, 3, etc., not a street address).  This number would logically go into the name tag.

-- 
John F. Eldredge --  john at jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria


From wendorff at uni-paderborn.de  Sun Apr 15 23:21:33 2012
From: wendorff at uni-paderborn.de (Peter Wendorff)
Date: Mon, 16 Apr 2012 00:21:33 +0200
Subject: [Tagging] Gated communities - access=private or   destination?
In-Reply-To: <f3be2846-7cbc-4b9a-9684-f6084a5dad63@email.android.com>
References: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415032503.03e12ec0@mail.earthlink.net>
	<4F8B35A5.1040509@gmail.com>
	<f3be2846-7cbc-4b9a-9684-f6084a5dad63@email.android.com>
Message-ID: <4F8B49ED.7060701@uni-paderborn.de>

Am 15.04.2012 23:51, schrieb John F. Eldredge:
> I have seen gates that had number signs (1, 2, 3, etc., not a street 
> address). This number would logically go into the name tag. 
If these numbers are, what I expect them to be, then it's not a name, 
but a reference, and should go into the ref-Tag (which is used as a 
rendering fallback in mapnik, AFAIK, so it should be fine, too.

regards
Peter


From john at jfeldredge.com  Sun Apr 15 23:56:47 2012
From: john at jfeldredge.com (John F. Eldredge)
Date: Sun, 15 Apr 2012 17:56:47 -0500
Subject: [Tagging] Gated communities - access=private or   destination?
In-Reply-To: <19829b77-ddcc-474b-b095-3c583f2e67d8@email.android.com>
References: <5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415032503.03e12ec0@mail.earthlink.net>
	<4F8B35A5.1040509@gmail.com>
	<f3be2846-7cbc-4b9a-9684-f6084a5dad63@email.android.com>
	<4F8B49ED.7060701@uni-paderborn.de>
	<19829b77-ddcc-474b-b095-3c583f2e67d8@email.android.com>
Message-ID: <7f315f87-aef7-470b-8d1f-eb497f562293@email.android.com>

Peter Wendorff <wendorff at uni-paderborn.de> wrote:
> 
> > Am 15.04.2012 23:51, schrieb John F. Eldredge:
> > > I have seen gates that had number signs (1, 2, 3, etc., not a
> street
> > 
> > > address). This number would logically go into the name tag. 
> > If these numbers are, what I expect them to be, then it's not a
> name, 
> > but a reference, and should go into the ref-Tag (which is used as a 
> > rendering fallback in mapnik, AFAIK, so it should be fine, too.
> > 
> > regards
> > Peter
> > 
> 
No, I mean that I saw signs on the physical gates, labeling them as gate 1, gate 2, etc.  Admittedly, this is more common for gates into industrial facilities.


-- 
John F. Eldredge --  john at jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria


From Alan_Mintz+OSM at Earthlink.Net  Mon Apr 16 03:39:07 2012
From: Alan_Mintz+OSM at Earthlink.Net (Alan Mintz)
Date: Sun, 15 Apr 2012 19:39:07 -0700
Subject: [Tagging] Gated communities - access=private or destination?
In-Reply-To: <4F8B35A5.1040509@gmail.com>
References: <5.1.0.14.2.20120415032503.03e12ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415032503.03e12ec0@mail.earthlink.net>
Message-ID: <5.1.0.14.2.20120415193544.0515ea90@mail.earthlink.net>

At 2012-04-15 13:55, Nathan Edgars II wrote:
>On 4/15/2012 6:30 AM, Alan Mintz wrote:
>>At 2012-04-15 01:10, Nathan Edgars II wrote:
>>>How would you distinguish an entry for visitors from an entry for
>>>residents only?
>>
>>name= or ref= or whatever else Mapnik was designed to render on a gate.
>
>That's only a solution if the gates actually have names. I've never seen 
>such a name.

You were asking how to mark a residents only entrance and I suggested one. 
If you want to be a purist about it, find out what other tags Mapnik might 
render on a gate and, if one of them is more suitable to put a description 
in, use it. If not, suggest Mapnik render description=* and use it.

--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>



From neroute2 at gmail.com  Mon Apr 16 03:51:58 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Sun, 15 Apr 2012 22:51:58 -0400
Subject: [Tagging] Gated communities - access=private or destination?
In-Reply-To: <5.1.0.14.2.20120415193544.0515ea90@mail.earthlink.net>
References: <5.1.0.14.2.20120415032503.03e12ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415005045.04678ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415032503.03e12ec0@mail.earthlink.net>
	<5.1.0.14.2.20120415193544.0515ea90@mail.earthlink.net>
Message-ID: <4F8B894E.1050000@gmail.com>

On 4/15/2012 10:39 PM, Alan Mintz wrote:
> At 2012-04-15 13:55, Nathan Edgars II wrote:
>> On 4/15/2012 6:30 AM, Alan Mintz wrote:
>>> At 2012-04-15 01:10, Nathan Edgars II wrote:
>>>> How would you distinguish an entry for visitors from an entry for
>>>> residents only?
>>>
>>> name= or ref= or whatever else Mapnik was designed to render on a gate.
>>
>> That's only a solution if the gates actually have names. I've never
>> seen such a name.
>
> You were asking how to mark a residents only entrance and I suggested
> one. If you want to be a purist about it, find out what other tags
> Mapnik might render on a gate and, if one of them is more suitable to
> put a description in, use it. If not, suggest Mapnik render
> description=* and use it.

That's not a solution. Mapnik already renders the type of access in text 
if you use MapQuest's rendering rules. Routers should be able to point 
you to the proper gate.


From stevagewp at gmail.com  Mon Apr 16 08:30:10 2012
From: stevagewp at gmail.com (Steve Bennett)
Date: Mon, 16 Apr 2012 17:30:10 +1000
Subject: [Tagging] Wikifiddling,
	surface=cobblestone vs. sett & paving_stones
In-Reply-To: <CABPTjTBnaOCwPmALB0W5rN_UB1fxgY5CYyX3r+eXn-wJ9bTSYA@mail.gmail.com>
References: <CABPTjTAgawEmKoCfXvV=+wAzwjv4M4v8iDWmCoa8uQfaavwVsw@mail.gmail.com>
	<4F4245DD.7050300@jonno.cix.co.uk> <4F425337.802@tobias-knerr.de>
	<CAMLmWVteinYd8wzq8y482DAwQvYw32us+zM2KbNGWuQH1bbFqg@mail.gmail.com>
	<CABPTjTDjK73H9Q4xDO-E9mgd8ExvWfXf8=XNZf=nU-M8qw6xKg@mail.gmail.com>
	<CABPTjTB2CrPmZSZs9rboOWHbQ4WjdLEABOMRBa5pZyx_QxpJZQ@mail.gmail.com>
	<CA+z=q=uho+5A0D+TBBwQ8W3ySJLyZRO6R0-bPevLqu2RAC-ETA@mail.gmail.com>
	<CABPTjTCeirA95rYWNXvbcj_kN5cW6yBZpudd+hfw0YESEE0kbA@mail.gmail.com>
	<CA+z=q=tuRe5YamHxUWeigLre0MkPJdZRqpvLteddnxwaWKD7Vg@mail.gmail.com>
	<CABPTjTBnaOCwPmALB0W5rN_UB1fxgY5CYyX3r+eXn-wJ9bTSYA@mail.gmail.com>
Message-ID: <CA+z=q=s2ji4h1NNe=NbZ7=r4iYjTuz3FC=Qz3CcAPi35jnLaAw@mail.gmail.com>

On Sun, Apr 15, 2012 at 7:12 PM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
>> surface=rounded_cobblestone
>
>
> I'd prefer to focus on the shape and therefore "rounded_cobblestone",
> because other aspects like historic can be expressed with additional
> tags. Also not all "true cobblestones" are necessarily old.

More options:

surface=raised_cobblestone
surface=uneven_cobblestone

Probably the most salient fact here is that the cobblestones don't
form an even surface - the stones themselves are raised above the
primary surface (tar of some kind?).

Steve


From imagic.osm at gmail.com  Mon Apr 16 15:34:18 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Mon, 16 Apr 2012 16:34:18 +0200
Subject: [Tagging] Feature Proposal - RFC - highway=junction
Message-ID: <CAKjckyN+6HH2N7x-KFxcKSsRcLr5FONvc7tQbgKUUXKJ48J1Sw@mail.gmail.com>

Hi!

Something new to comment on:
http://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Djunction

The intention is to make mapping of junctions easier and provide some
information about the extent of a junction and what
nodes/ways/features belong to a single, individual junction.

Please use the discussion page for any comments. Thanks in advance.

regards,
Martin


From traffictower at gmail.com  Tue Apr 17 23:55:25 2012
From: traffictower at gmail.com (Robert Stack)
Date: Tue, 17 Apr 2012 15:55:25 -0700
Subject: [Tagging]  Feature Proposal - TMC - New tagging scheme for TMC
Message-ID: <CAFqS8ZLxZQ0fD3jda4Jqo80TZUyvLdxd2S7p8Pe6=mGdVM94Lw@mail.gmail.com>

Hello all,

A very interesting proposal, thanks.  The TMC Inspector you (Infoware)
provided (http://osm-tmc.infoware.de/tmc/) is most helpful in reviewing
this, too.  Here's an additional question beyond those from Eckhart Worner
and others.  Some ways span well beyond a single adjacent pair of TMC
locations.  For example, see way 4413896 (on Autobahn A20 near Rostock;
vicinity of coordinates 54.02593, 12.23133).  There are several TMC
locations along this way (10572, 47239, 10573, and a few more at the
boundaries)..

Will such long ways that span two or more location codes need to be rebuilt
into separate ways to make this work?  Or, alternatively, could the tagging
be expanded to have multiple TMC tags for a way, each one specifying which
portion of a way it applies to?  I realize that this would increase the
complexity of the tagging which would diminish the simplicity appeal of the
proposed tagging scheme.

thanks,

..robert
Robert Stack
traffictower at gmail.com

--

Hi,

Am Mittwoch, 11. April 2012, 15:42:29 schrieb fly:
>* I still do not get one major point which was totally left out on the first*>* scheme. What actually belongs to a "point" and how are they tagged. *Especially
>* on big crossings and roundabouts I always was confused (e.g. it might be*>* possible that a part of this point is blocked but how do I know which one *and
>* you might be able to use  the first/last exit/entrance of a junction but not *the
>* rest. )*
Indeed, this is what I was worried about as well.
Here's a proposed (partial) fix, which starts from the original proposal.

Let's assume that 123, 456 and 789 are connected LCD which describe a road.
Further assume that at 456 there's a big intersection.
Then:
- All ways between 123 and 456 are marked tmc=DE:123+456, and all ways between
456 and 789 are marked tmc=DE:456+789.
- All ways on the intersection 456 leading from 123 to 789 are then marked
tmc=DE:456+.

This has several advantages:
- A traffic jam between 123 and 456 will not block the intersection 456 anymore.
- Exits are defined as follows:  an exit at 456 in positive direction starts at
a way that is tagged either tmc=DE:456+ or tmc=DE:123+456 ("from"), uses a
node that is part of a way tagged either tmc=DE:456+ or tmc=DE:456+789 ("via")
and ends at a way that is tagged neither tmc=DE:456+ nor tmc=DE:456+789, nor
tmc=DE:123+456 ("to"). An exit is therefore a maneuver. This may sound a bit
technical at first, but none of this is exposed to the tagging, and the idea of
an exit is probably quite intuitive.
- Likewise, entries are defined.
- Automatic consistency checking is still possible, as there are no holes.

There is at least one issue that still has to be addressed: this tagging does
not imply an ordering of the exits / entries; it is not clear what the first,
second? exit would be.

Eckhart W?rner
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120417/72864591/attachment.html>

From neroute2 at gmail.com  Wed Apr 18 02:15:49 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Tue, 17 Apr 2012 21:15:49 -0400
Subject: [Tagging] Smooth shoulder intended for cycling
Message-ID: <4F8E15C5.6000405@gmail.com>

I'm wondering what the best way would be to tag a good-quality shoulder 
that acts essentially as an undesignated bike lane, in that you can use 
it but it is not required. Current Florida DOT policy is to use these on 
rural roads, with marked bike lanes only when there is a lane to the 
right. For example here: 
http://maps.google.com/maps?hl=en&ll=30.605358,-86.950672&spn=0.008255,0.016512&gl=us&t=m&z=17&layer=c&cbll=30.605241,-86.950558&panoid=X4-X3CdhvVO_ptMWbvB8SA&cbp=12,330.83,,0,9.24
One can choose to ride either in the right lane or on the shoulder 
beyond the intersection.

One regional mapper uses cycleway=shoulder for this, but I see that as 
sub-optimal, since it's primarily a shoulder, not a cycleway. It would 
be like putting cycleway=sidewalk whenever there's a smooth paved sidewalk.

On the other hand, shoulder=yes or shoulder=paved says nothing about the 
quality of the shoulder. Should there be a minimum width for a shoulder 
(FDOT's standard is 4 feet)?


From stevagewp at gmail.com  Wed Apr 18 04:47:02 2012
From: stevagewp at gmail.com (Steve Bennett)
Date: Wed, 18 Apr 2012 13:47:02 +1000
Subject: [Tagging] Smooth shoulder intended for cycling
In-Reply-To: <4F8E15C5.6000405@gmail.com>
References: <4F8E15C5.6000405@gmail.com>
Message-ID: <CA+z=q=vW92JHRVqntM5pdKzVxpd-kctNLstDE=00CyeuHJRbuA@mail.gmail.com>

On Wed, Apr 18, 2012 at 11:15 AM, Nathan Edgars II <neroute2 at gmail.com> wrote:
> One regional mapper uses cycleway=shoulder for this, but I see that as
> sub-optimal, since it's primarily a shoulder, not a cycleway. It would be
> like putting cycleway=sidewalk whenever there's a smooth paved sidewalk.

I quite like "cycleway=shoulder". It describes exactly what's going
on: the cycling infrastructure at this point isn't a marked lane
(cycleway=lane), nor a segregated lane (cycleway=track), it's a sealed
road shoulder.

Could you elaborate on your objections?

The real complication arises when there are shoulders of varying
quality that are assessed (by cyclists) as being more or less suitable
for cycling - leading to issues of subjectivity. At least the
situation you describe appears objective: the surface was intended for
cycling on.

Steve


From neroute2 at gmail.com  Wed Apr 18 05:18:57 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Wed, 18 Apr 2012 00:18:57 -0400
Subject: [Tagging] [Talk-us]  Smooth shoulder intended for cycling
In-Reply-To: <CA+z=q=vW92JHRVqntM5pdKzVxpd-kctNLstDE=00CyeuHJRbuA@mail.gmail.com>
References: <4F8E15C5.6000405@gmail.com>
	<CA+z=q=vW92JHRVqntM5pdKzVxpd-kctNLstDE=00CyeuHJRbuA@mail.gmail.com>
Message-ID: <4F8E40B1.60202@gmail.com>

Hmmm. Apparently Thunderbird's 'reply to list' fails when there are 
multiple lists. Sending again:

On 4/17/2012 11:47 PM, Steve Bennett wrote:
> I quite like "cycleway=shoulder". It describes exactly what's going
> on: the cycling infrastructure at this point isn't a marked lane
> (cycleway=lane), nor a segregated lane (cycleway=track), it's a sealed
> road shoulder.
>
> Could you elaborate on your objections?

It implies that the shoulder is an official cycleway, when in reality it 
may be full of debris (or worse: 
http://flbikelaw.org/2012/03/paved-shoulder/ ). Would you use a cycleway 
tag on any sidewalk that one can ride on (here that would be any outside 
city limits), or just those that have been specially designated as such?


From stevagewp at gmail.com  Wed Apr 18 06:17:23 2012
From: stevagewp at gmail.com (Steve Bennett)
Date: Wed, 18 Apr 2012 15:17:23 +1000
Subject: [Tagging] [Talk-us]  Smooth shoulder intended for cycling
In-Reply-To: <4F8E40B1.60202@gmail.com>
References: <4F8E15C5.6000405@gmail.com>
	<CA+z=q=vW92JHRVqntM5pdKzVxpd-kctNLstDE=00CyeuHJRbuA@mail.gmail.com>
	<4F8E40B1.60202@gmail.com>
Message-ID: <CA+z=q=sK4njbMPm2qanZA=AP7Kx7=fRL6rnEPTLe4H5kuS880Q@mail.gmail.com>

On Wed, Apr 18, 2012 at 2:18 PM, Nathan Edgars II <neroute2 at gmail.com> wrote:
> It implies that the shoulder is an official cycleway, when in reality it may
> be full of debris (or worse: http://flbikelaw.org/2012/03/paved-shoulder/ ).

You think it implies that because it's a cycleway=* tag? I wouldn't
read too much into the tag itself - the meaning of the tag is whatever
the documentation for the tag says.

> Would you use a cycleway tag on any sidewalk that one can ride on (here that
> would be any outside city limits), or just those that have been specially
> designated as such?

I don't do any mapping in the US - it depends what your local
community decides. cycleway=sidewalk doesn't sound terrible to me.

We do have a situation here where sometimes footpaths (sidewalks) have
signs allowing cycling on them (the default is no). Usually we
actually trace out that section as a highway=cycleway. (We don't
distinguish it from any other bike path.) If it's more common than
that, you probably want a different solution.

Steve


From masi-master at gmx.de  Wed Apr 18 14:34:34 2012
From: masi-master at gmx.de (Masi Master)
Date: Wed, 18 Apr 2012 15:34:34 +0200
Subject: [Tagging] Smooth shoulder intended for cycling
In-Reply-To: <CA+z=q=vW92JHRVqntM5pdKzVxpd-kctNLstDE=00CyeuHJRbuA@mail.gmail.com>
References: <4F8E15C5.6000405@gmail.com>
	<CA+z=q=vW92JHRVqntM5pdKzVxpd-kctNLstDE=00CyeuHJRbuA@mail.gmail.com>
Message-ID: <op.wcyqnwp8hg6zzq@masi.mshome.net>

For me, it looks like a bicycle-lane. On first look with no sign, so i  
would tag it cycleway=lane + bicycle=yes (<- no designated or official,  
because a OSM-cycleway is for me a way, that is "made for cycling" (with  
no implied access), access can be added with bicycle=*).

But on second look [1], you can see a bicycle symbol, so it is:  
cycleway=lane + bicycle=designated
[1]  
http://maps.google.com/maps?ll=30.605287,-86.950497&spn=0.00253,0.002972&t=k&z=20

Masi


Am 18.04.2012, 05:47 Uhr, schrieb Steve Bennett <stevagewp at gmail.com>:

> On Wed, Apr 18, 2012 at 11:15 AM, Nathan Edgars II <neroute2 at gmail.com>  
> wrote:
>> One regional mapper uses cycleway=shoulder for this, but I see that as
>> sub-optimal, since it's primarily a shoulder, not a cycleway. It would  
>> be
>> like putting cycleway=sidewalk whenever there's a smooth paved sidewalk.
>
> I quite like "cycleway=shoulder". It describes exactly what's going
> on: the cycling infrastructure at this point isn't a marked lane
> (cycleway=lane), nor a segregated lane (cycleway=track), it's a sealed
> road shoulder.
>
> Could you elaborate on your objections?
>
> The real complication arises when there are shoulders of varying
> quality that are assessed (by cyclists) as being more or less suitable
> for cycling - leading to issues of subjectivity. At least the
> situation you describe appears objective: the surface was intended for
> cycling on.
>
> Steve
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging




From neroute2 at gmail.com  Wed Apr 18 20:18:19 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Wed, 18 Apr 2012 15:18:19 -0400
Subject: [Tagging] Smooth shoulder intended for cycling
In-Reply-To: <op.wcyqnwp8hg6zzq@masi.mshome.net>
References: <4F8E15C5.6000405@gmail.com>
	<CA+z=q=vW92JHRVqntM5pdKzVxpd-kctNLstDE=00CyeuHJRbuA@mail.gmail.com>
	<op.wcyqnwp8hg6zzq@masi.mshome.net>
Message-ID: <4F8F137B.60600@gmail.com>

On 4/18/2012 9:34 AM, Masi Master wrote:
> For me, it looks like a bicycle-lane. On first look with no sign, so i
> would tag it cycleway=lane + bicycle=yes (<- no designated or official,
> because a OSM-cycleway is for me a way, that is "made for cycling" (with
> no implied access), access can be added with bicycle=*).
>
> But on second look [1], you can see a bicycle symbol, so it is:
> cycleway=lane + bicycle=designated
> [1]
> http://maps.google.com/maps?ll=30.605287,-86.950497&spn=0.00253,0.002972&t=k&z=20

The bike lane is only before the intersection. After the intersection it 
reverts to shoulder.


From pieren3 at gmail.com  Thu Apr 19 09:25:12 2012
From: pieren3 at gmail.com (Pieren)
Date: Thu, 19 Apr 2012 10:25:12 +0200
Subject: [Tagging] Post office attributes
Message-ID: <CAPT3zJra=i1yRW8n4GtJ3oOeOEeEF=QsuMevBbpL_Dd1OYhDDw@mail.gmail.com>

Hi,

In France, we are able now to complete some additional information
about the French post offices in the whole territory (thanks open data
movement) but we are looking for some ideas here about tagging helpful
attributes.

For instance, we have 3 types of post offices : the "bureau" which is
the old style fully managed by the public operator, the "agency" which
is managed by the same operator but employees are externals (this
implies some restrictions like limited cash transactions) and the
"post office agent" (or "relay point") within a shop or restaurant or
amenity (library, townhall).
For this, we think about a sub-tag in "amenity=post_office" like
"post_office=shop" or "post_office=amenity" or
"post_office=convenience", etc for the post office agent. No idea how
to distinguish the "agency" and the old "bureau" since the difference
is only the employees (but still important since it implies some
limitations). "post_office:type" ?

We also would like to add some additional services/attributes:
- a "stamping machine", a self-service machine where you weigh and
stamp yourself your mails and small boxes. "stamping_machine=yes" ?
- a "change machine" changing bank notes to coins. "change_machine=yes" ?
- a "copying machine", a single copier ("shop=copyshop" is not really
appropriate). "copy_facility=yes" ?
- a kind of atm but only used to reload cash in an electronic cash
card (the system is called "moneo" and we propose "moneo:loading=yes")
- "monnaie de Paris" is where special coins editions and medals issued
by this administration are available (for collectors)

Do you have similar attributs in your country or any ideas here ?

Pieren


From knauf at infoware.de  Thu Apr 19 10:25:21 2012
From: knauf at infoware.de (Heinrich Knauf)
Date: Thu, 19 Apr 2012 11:25:21 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <1382563.UEHgbvYOV3@obiwan>
References: <4F745D0C.2020206@infoware.de> <4F83B31D.5020502@gmail.com>
	<4F858A45.2010603@googlemail.com> <1382563.UEHgbvYOV3@obiwan>
Message-ID: <4F8FDA01.7020904@infoware.de>

Am 15.04.2012 16:23, schrieb Eckhart W?rner:
> Hi,
>
> Am Mittwoch, 11. April 2012, 15:42:29 schrieb fly:
>> I still do not get one major point which was totally left out on the first
>> scheme. What actually belongs to a "point" and how are they tagged.
> Especially
>> on big crossings and roundabouts I always was confused (e.g. it might be
>> possible that a part of this point is blocked but how do I know which one
> and
>> you might be able to use  the first/last exit/entrance of a junction but not
> the
>> rest. )
> Indeed, this is what I was worried about as well.
> Here's a proposed (partial) fix, which starts from the original proposal.
>
> Let's assume that 123, 456 and 789 are connected LCD which describe a road.
> Further assume that at 456 there's a big intersection.
> Then:
> - All ways between 123 and 456 are marked tmc=DE:123+456, and all ways between
> 456 and 789 are marked tmc=DE:456+789.
> - All ways on the intersection 456 leading from 123 to 789 are then marked
> tmc=DE:456+.
>
> This has several advantages:
> - A traffic jam between 123 and 456 will not block the intersection 456 anymore.
> - Exits are defined as follows:  an exit at 456 in positive direction starts at
> a way that is tagged either tmc=DE:456+ or tmc=DE:123+456 ("from"), uses a
> node that is part of a way tagged either tmc=DE:456+ or tmc=DE:456+789 ("via")
> and ends at a way that is tagged neither tmc=DE:456+ nor tmc=DE:456+789, nor
> tmc=DE:123+456 ("to"). An exit is therefore a maneuver. This may sound a bit
> technical at first, but none of this is exposed to the tagging, and the idea of
> an exit is probably quite intuitive.
> - Likewise, entries are defined.
> - Automatic consistency checking is still possible, as there are no holes.
>
> There is at least one issue that still has to be addressed: this tagging does
> not imply an ordering of the exits / entries; it is not clear what the first,
> second? exit would be.
>
> Eckhart W?rner
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
Hello,
thank you far all your contributions so far, and here's just a 
preliminary response. It was my idea to mail an answer to all open 
technical questions as soon as I can come with a reasonable result in 
all depth, and some topics are still discussed with our TMC team. So I 
apologize for not resonding earlier, but please allow another day.

Best regards,

Mit freundlichen Gr??en,
Heinrich Knauf

infoware GmbH
Riemenschneiderstr. 11
53175 Bonn
GERMANY

facebook_follow_us <http://facebook.infoware.de/>

office: +49 228 338899-21
email: knauf at infoware.de <mailto:knauf at infoware.de>
web: www.infoware.de <http://www.infoware.de>
infoware Gesellschaft f?r Informationstechnik mbH
Gesch?ftsf?hrer: Thomas Schulte-Hillen, Martin Langhoff;
Sitz Bonn; Amtsgericht Bonn HRB 14141

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120419/fc324f53/attachment.html>

From imagic.osm at gmail.com  Thu Apr 19 12:38:41 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Thu, 19 Apr 2012 13:38:41 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
Message-ID: <CAKjckyN+-iSPAGb0ZSK+G9fLaVpNR0ukVyg5-jRM-3n97aZoLg@mail.gmail.com>

Hi!

I'm planning to improve the articles (english, german and russian) for
the lanes-tag (http://wiki.openstreetmap.org/wiki/Key:lanes). Right
now a few points are left open and desperately need some
clarification. As some of the latest changes lead to some dispute (see
[1]) I will let you know what I would like to add/update.

* The lanes tag should count all lanes which are wide enough for
motorized vehicles other than motor cycles  (see [2]). This is (more
or less) the way as it is written in the english and russian article,
but not e.g. in the german. I will add also a link to the UN Vienna
Convention and try to think of an easier understandable wording
compared to the official text.
* PSV lanes SHOULD be included (also [2]). Example: lanes=3 and
lanes:psv=1 means we have three lanes and one OF THEM is for PSV only.
* Cycle lanes should NOT be included (see [3]), because they are not
"wide enough for one moving line of motor vehicles other than motor
cycles".
* Parking lanes/spaces should NOT be included (see [4]).
* Turn lanes SHOULD be included (see [2] and [5]).
* The lane count should change, as soon as a) new lane has reached its
full width or b) a lane starts to disappear (usually a merge with
another lane) (also [5]).
* Partly taken from the current german page I would add the following
assumptions for roads without explicit lane count:
  - A one-way road has one lane
  - Two-way roads have two lanes, one in each direction
  - Two-way roads with a specified lane count, but without a specified
lanes:forward OR lanes:backward and a lane count, that is divisible by
two, are assumed to have half of the lanes in each direction, e.g.
lanes=4 means two lanes in each direction if not specified otherwise.
I will add a recommendation for this situation, to add explicit
values.

I'm not sure what I should do with the comments about sidewalks. They
don't have anything to do with lanes (neither motorized traffic, psv,
cycle lanes, whatever), so they actually don't belong here. Maybe just
a link in Related Tags?

Martin

[1] http://lists.openstreetmap.org/pipermail/tagging/2011-September/008532.html
[2] http://lists.openstreetmap.org/pipermail/tagging/2011-September/008578.html
[3] http://lists.openstreetmap.org/pipermail/tagging/2011-September/008582.html
[4] http://lists.openstreetmap.org/pipermail/tagging/2011-September/008587.html
[5] http://lists.openstreetmap.org/pipermail/tagging/2011-September/008596.html


From pieren3 at gmail.com  Thu Apr 19 12:58:52 2012
From: pieren3 at gmail.com (Pieren)
Date: Thu, 19 Apr 2012 13:58:52 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyN+-iSPAGb0ZSK+G9fLaVpNR0ukVyg5-jRM-3n97aZoLg@mail.gmail.com>
References: <CAKjckyN+-iSPAGb0ZSK+G9fLaVpNR0ukVyg5-jRM-3n97aZoLg@mail.gmail.com>
Message-ID: <CAPT3zJoW3oYsm0a7b823tix3hsf=et9urHtyUDsfjU0Tv9=4ng@mail.gmail.com>

On Thu, Apr 19, 2012 at 1:38 PM, Martin Vonwald <imagic.osm at gmail.com> wrote:

> * PSV lanes SHOULD be included (also [2]). Example: lanes=3 and
> lanes:psv=1 means we have three lanes and one OF THEM is for PSV only.

Don't forget other reserved lanes like taxi lanes...

> * Parking lanes/spaces should NOT be included (see [4]).

What about stop lanes for bus stations ? (usually a short distance
extra lane used for loading/unloading passagers) ?

> * Turn lanes SHOULD be included (see [2] and [5]).

Not sure if it is a good idea.

> * The lane count should change, as soon as a) new lane has reached its
> full width or b) a lane starts to disappear (usually a merge with
> another lane) (also [5]).

And what about the space between e.g. lanes=2 and lanes=3 ?

> ?- A one-way road has one lane

excepted for motorways and trunk ?

> ?- Two-way roads have two lanes, one in each direction

also for highway=track/service ?

Pieren


From knauf at infoware.de  Thu Apr 19 13:09:47 2012
From: knauf at infoware.de (Heinrich Knauf)
Date: Thu, 19 Apr 2012 14:09:47 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <4F83A9FE.9010904@gmail.com>
References: <4F745D0C.2020206@infoware.de> <4F83A9FE.9010904@gmail.com>
Message-ID: <4F90008B.1000603@infoware.de>

Am 10.04.2012 05:33, schrieb Martijn van Exel:
> On 3/29/2012 7:01 AM, Heinrich Knauf wrote:
>> Hello,
>>
>> infoware GmbH, Bonn, Germany, and Geofabrik GmbH, Karlsruhe, Germany,
>> have developed an
>> improved tagging scheme for TMC data which we would like to propopose
>> to the OSM community.
>>
>> Currently, this feature is explained in German only.
>>
>> Pelase refer to
>>
>> http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme
>>
>> http://wiki.openstreetmap.org/wiki/Proposed_features/New_TMC_Scheme
>>
>> Your comments are greatly appreceated!
>
> Heinrich,
>
> That looks like a huge improvement from the existing proposal. A few 
> questions for clarification and discussion:
> * In this proposal, the actual TMC LCDs are not technically required, 
> are they? If all the ways are tagged according to this schema, you can 
> look up the segments just by looking at the ways? I guess having the 
> LCD encoded onto nodes will speed up lookup.
> * How do you plan to make this huge effort (even just for Germany) 
> manageable? I mean, it's simpler than it looks, but it still is a 
> *lot* of work. A JOSM plugin? A dedicated website to track progress 
> and show bugs / inconsistencies? Other supporting tools for mappers?
> * Do you (or anyone) have any info on the 'openness' of this data in 
> other countries? I believe they are proprietary data here in the US, 
> not sure though (will ask in talk-us).
>
Martijn,

I do not yet have an idea about a plug-in for JOSM, but TMC inspector is 
already online:

Visit http://osm-tmc.infoware.de/tmc/
(Please report if the link does not work.)

I think this is a good means of visualizing the state of TMC mapping.

And there is another project at infoware to install and run a server 
that continuously shows the current traffic status on these road 
segments that are tagged according to the the new scheme.


Mit freundlichen Gr??en,
Heinrich Knauf

infoware GmbH
Riemenschneiderstr. 11
53175 Bonn
GERMANY

facebook_follow_us <http://facebook.infoware.de/>

office: +49 228 338899-21
email: knauf at infoware.de <mailto:knauf at infoware.de>
web: www.infoware.de <http://www.infoware.de>
infoware Gesellschaft f?r Informationstechnik mbH
Gesch?ftsf?hrer: Thomas Schulte-Hillen, Martin Langhoff;
Sitz Bonn; Amtsgericht Bonn HRB 14141

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120419/0d7d90b7/attachment.html>

From imagic.osm at gmail.com  Thu Apr 19 13:31:38 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Thu, 19 Apr 2012 14:31:38 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAPT3zJoW3oYsm0a7b823tix3hsf=et9urHtyUDsfjU0Tv9=4ng@mail.gmail.com>
References: <CAKjckyN+-iSPAGb0ZSK+G9fLaVpNR0ukVyg5-jRM-3n97aZoLg@mail.gmail.com>
	<CAPT3zJoW3oYsm0a7b823tix3hsf=et9urHtyUDsfjU0Tv9=4ng@mail.gmail.com>
Message-ID: <CAKjckyMerG7FXES1qqiknM_f_CsmfG8+2P1D8_OrGDm2kOQQhA@mail.gmail.com>

2012/4/19 Pieren <pieren3 at gmail.com>:
>> * PSV lanes SHOULD be included (also [2]). Example: lanes=3 and
>> lanes:psv=1 means we have three lanes and one OF THEM is for PSV only.
> Don't forget other reserved lanes like taxi lanes...

Thanks - I won't.


>> * Parking lanes/spaces should NOT be included (see [4]).
> What about stop lanes for bus stations ? (usually a short distance
> extra lane used for loading/unloading passagers) ?

My feeling tells me, not to count them. They are in my opinion not
really traffic lanes, as they are intended only for stopping (maybe
similar to parking lanes).


>> * Turn lanes SHOULD be included (see [2] and [5]).
> Not sure if it is a good idea.

I can't see any reason, why they should be included. There were good
reasons in the linked discussion to add them.


>> * The lane count should change, as soon as a) new lane has reached its
>> full width or b) a lane starts to disappear (usually a merge with
>> another lane) (also [5]).
> And what about the space between e.g. lanes=2 and lanes=3 ?

I would suggest to continue with the previous lane count, until a new
lane count is valid. Values like lanes=2.5 are not "that" intuitive,
renderers could approximate the layout well enough and routers don't
really care about half lanes, as they couldn't use them anyway.


>> ?- A one-way road has one lane
> excepted for motorways and trunk ?
>> ?- Two-way roads have two lanes, one in each direction
> also for highway=track/service ?

After some additional thinking I notice that those assumptions are a
bad idea: they would be too much exceptions. This would mean, that the
assumptions currently present on the german page should be removed.

Martin


From lowflight66 at googlemail.com  Thu Apr 19 13:37:51 2012
From: lowflight66 at googlemail.com (fly)
Date: Thu, 19 Apr 2012 14:37:51 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAPT3zJoW3oYsm0a7b823tix3hsf=et9urHtyUDsfjU0Tv9=4ng@mail.gmail.com>
References: <CAKjckyN+-iSPAGb0ZSK+G9fLaVpNR0ukVyg5-jRM-3n97aZoLg@mail.gmail.com>
	<CAPT3zJoW3oYsm0a7b823tix3hsf=et9urHtyUDsfjU0Tv9=4ng@mail.gmail.com>
Message-ID: <4F90071F.9010104@googlemail.com>

On 19/04/12 13:58, Pieren wrote:
> On Thu, Apr 19, 2012 at 1:38 PM, Martin Vonwald <imagic.osm at gmail.com> wrote:
> 
>> * PSV lanes SHOULD be included (also [2]). Example: lanes=3 and
>> lanes:psv=1 means we have three lanes and one OF THEM is for PSV only.
> 
> Don't forget other reserved lanes like taxi lanes...

How does this work if the psv-lane is also allowed for bicycles and taxis ?

fly



From imagic.osm at gmail.com  Thu Apr 19 13:42:41 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Thu, 19 Apr 2012 14:42:41 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <4F90071F.9010104@googlemail.com>
References: <CAKjckyN+-iSPAGb0ZSK+G9fLaVpNR0ukVyg5-jRM-3n97aZoLg@mail.gmail.com>
	<CAPT3zJoW3oYsm0a7b823tix3hsf=et9urHtyUDsfjU0Tv9=4ng@mail.gmail.com>
	<4F90071F.9010104@googlemail.com>
Message-ID: <CAKjckyMeuYOSqkGTkBjDGVFbHSdxku-hwZNtZHOHecHdhURU5Q@mail.gmail.com>

>> Don't forget other reserved lanes like taxi lanes...
> How does this work if the psv-lane is also allowed for bicycles and taxis ?

It is wide enough, therefore it will be counted.


From lowflight66 at googlemail.com  Thu Apr 19 14:14:32 2012
From: lowflight66 at googlemail.com (fly)
Date: Thu, 19 Apr 2012 15:14:32 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyMeuYOSqkGTkBjDGVFbHSdxku-hwZNtZHOHecHdhURU5Q@mail.gmail.com>
References: <CAKjckyN+-iSPAGb0ZSK+G9fLaVpNR0ukVyg5-jRM-3n97aZoLg@mail.gmail.com>
	<CAPT3zJoW3oYsm0a7b823tix3hsf=et9urHtyUDsfjU0Tv9=4ng@mail.gmail.com>
	<4F90071F.9010104@googlemail.com>
	<CAKjckyMeuYOSqkGTkBjDGVFbHSdxku-hwZNtZHOHecHdhURU5Q@mail.gmail.com>
Message-ID: <4F900FB8.3000208@googlemail.com>

On 19/04/12 14:42, Martin Vonwald wrote:
>>> Don't forget other reserved lanes like taxi lanes...
>> How does this work if the psv-lane is also allowed for bicycles and taxis ?
> 
> It is wide enough, therefore it will be counted.

But how to map it ?

bicycle:lanes:forward:psv=yes ?

cu



From pieren3 at gmail.com  Thu Apr 19 14:24:42 2012
From: pieren3 at gmail.com (Pieren)
Date: Thu, 19 Apr 2012 15:24:42 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <4F900FB8.3000208@googlemail.com>
References: <CAKjckyN+-iSPAGb0ZSK+G9fLaVpNR0ukVyg5-jRM-3n97aZoLg@mail.gmail.com>
	<CAPT3zJoW3oYsm0a7b823tix3hsf=et9urHtyUDsfjU0Tv9=4ng@mail.gmail.com>
	<4F90071F.9010104@googlemail.com>
	<CAKjckyMeuYOSqkGTkBjDGVFbHSdxku-hwZNtZHOHecHdhURU5Q@mail.gmail.com>
	<4F900FB8.3000208@googlemail.com>
Message-ID: <CAPT3zJoCo_AMdKvV5abUyRTXiM9Jj-PQBXKHkwpBcBK4B1+14w@mail.gmail.com>

On Thu, Apr 19, 2012 at 3:14 PM, fly
> But how to map it ?
>
> bicycle:lanes:forward:psv=yes ?

Check this:
http://wiki.openstreetmap.org/wiki/Bicycle#Cycle_lanes_and_bus.2Ftaxi_lanes

But the thread is about the tag lanes=*, not sub-tags like this one.

Pieren


From imagic.osm at gmail.com  Thu Apr 19 14:43:41 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Thu, 19 Apr 2012 15:43:41 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAPT3zJoCo_AMdKvV5abUyRTXiM9Jj-PQBXKHkwpBcBK4B1+14w@mail.gmail.com>
References: <CAKjckyN+-iSPAGb0ZSK+G9fLaVpNR0ukVyg5-jRM-3n97aZoLg@mail.gmail.com>
	<CAPT3zJoW3oYsm0a7b823tix3hsf=et9urHtyUDsfjU0Tv9=4ng@mail.gmail.com>
	<4F90071F.9010104@googlemail.com>
	<CAKjckyMeuYOSqkGTkBjDGVFbHSdxku-hwZNtZHOHecHdhURU5Q@mail.gmail.com>
	<4F900FB8.3000208@googlemail.com>
	<CAPT3zJoCo_AMdKvV5abUyRTXiM9Jj-PQBXKHkwpBcBK4B1+14w@mail.gmail.com>
Message-ID: <CAKjckyNPmNLNwjs3hUHqWz1G2h_5itny1eCG+19rKeLrTLSwqA@mail.gmail.com>

2012/4/19 Pieren <pieren3 at gmail.com>:
> On Thu, Apr 19, 2012 at 3:14 PM, fly
>> But how to map it ?
>> bicycle:lanes:forward:psv=yes ?

As Pieren already wrote: this is beyond the scope of the lanes tag.

But as you already asked: if you want to tag the mere presence of a
cycle lane, use cycleway=lane and similar tags. If you want to tag the
exact layout of the lanes use the :lanes extension of the keys
(http://wiki.openstreetmap.org/wiki/Lanes). In short: if you have a
road with three lanes, on the leftmost bicycles are forbidden, on the
middle they are allowed and the rightmost is a designated lane, you
would tag this is bicycle:lanes=no|yes|designated .

Martin


From Alan_Mintz+OSM at Earthlink.Net  Thu Apr 19 20:33:00 2012
From: Alan_Mintz+OSM at Earthlink.Net (Alan Mintz)
Date: Thu, 19 Apr 2012 12:33:00 -0700
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyN+-iSPAGb0ZSK+G9fLaVpNR0ukVyg5-jRM-3n97aZoLg@mail.g
	mail.com>
Message-ID: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>

At 2012-04-19 04:38, Martin Vonwald wrote:
>* PSV lanes SHOULD be included (also [2]). Example: lanes=3 and
>lanes:psv=1 means we have three lanes and one OF THEM is for PSV only.

Same goes for HOV (high-occupancy-vehicles) lanes, unless they are 
separately mapped (which is a better solution for routing, given their 
controlled access).


>* Turn lanes SHOULD be included (see [2] and [5]).
>* The lane count should change, as soon as a) new lane has reached its
>full width or b) a lane starts to disappear (usually a merge with
>another lane) (also [5]).

Technically, yes, but it doesn't seem practical in developed areas in the 
US, which typically change lane configurations at every major intersection 
and then change back again. A typical secondary artery might be 2 lanes in 
each direction with a raised center island, expanding to 2 lanes in one 
direction and, in the other direction, a left-turn "pocket" (in place of 
the center island), 2 straight-ahead lanes, and a right-turn "pocket" (in 
place of some land or sidewalk on the right side). While these additional 
lanes can be added individually or the way broken to tag them, I just don't 
see people doing this. It seems like routers could just as easily assume 
these types of configuration between various road classes, unless told 
otherwise. I would tag such a road as lanes=4 (lanes=5 if the center island 
is, instead, a center turn lane).


>   - Two-way roads with a specified lane count, but without a specified
>lanes:forward OR lanes:backward and a lane count, that is divisible by
>two, are assumed to have half of the lanes in each direction, e.g.
>lanes=4 means two lanes in each direction if not specified otherwise.
>I will add a recommendation for this situation, to add explicit
>values.

If an odd number, assume a center turn lane (e.g. lanes=5 means 2 forward, 
2 backward, 1 center).

+1 to the rest.

--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>



From sanderd17 at gmail.com  Thu Apr 19 22:09:14 2012
From: sanderd17 at gmail.com (Sander Deryckere)
Date: Thu, 19 Apr 2012 23:09:14 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
Message-ID: <CABUOUO8fuCSH-1JkApWSN0dTwsrFhZuoXr2UdqsTdou9=bFiqg@mail.gmail.com>

There is a discussion about PSV lanes, but what about emergency lanes.
Nobody is allowed to use it, with the exception of people who have to stop
for a car problem, or by emergency vehicles when there is a traffic jam on
the other lanes (at least, that's the case in Belgium).

This is not one place where you can drive to and park your car to change a
wheel or so, it's a lane along a huge part of the way.

I think this should be discussed together with the other types of lanes,
but I won't join further discussion here.

Cheers,
Sander
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120419/3eb6d579/attachment.html>

From nick.w.austin at gmail.com  Thu Apr 19 23:56:25 2012
From: nick.w.austin at gmail.com (Nick Austin)
Date: Thu, 19 Apr 2012 23:56:25 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CABUOUO8fuCSH-1JkApWSN0dTwsrFhZuoXr2UdqsTdou9=bFiqg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CABUOUO8fuCSH-1JkApWSN0dTwsrFhZuoXr2UdqsTdou9=bFiqg@mail.gmail.com>
Message-ID: <CAGP1zmEdwHjt_FPsKNQSwh77pMSBetsg6HrrfADhxprYfyL6LA@mail.gmail.com>

In the UK emergency lanes are called shoulders.

Tags for them have been suggested in the past:
http://wiki.openstreetmap.org/wiki/Shoulder

Nick.


On Thu, Apr 19, 2012 at 10:09 PM, Sander Deryckere <sanderd17 at gmail.com> wrote:
> There is a discussion about PSV lanes, but what about emergency lanes.
> Nobody is allowed to use it, with the exception of people who have to stop
> for a car problem, or by emergency vehicles when there is a traffic jam on
> the other lanes (at least, that's the case in Belgium).
>
> This is not one place where you can drive to and park your car to change a
> wheel or so, it's a lane along a huge part of the way.
>
> I think this should be discussed together with the other types of lanes, but
> I won't join further discussion here.
>
> Cheers,
> Sander


From neroute2 at gmail.com  Fri Apr 20 08:02:00 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Fri, 20 Apr 2012 03:02:00 -0400
Subject: [Tagging] Weigh stations
Message-ID: <4F9109E8.3000603@gmail.com>

Is there a tag in use for weigh stations, places where trucks are 
weighed to ensure that they are not too heavy?


From imagic.osm at gmail.com  Fri Apr 20 08:09:26 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Fri, 20 Apr 2012 09:09:26 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
Message-ID: <CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>

2012/4/19 Alan Mintz <Alan_Mintz+OSM at earthlink.net>:
>> * PSV lanes SHOULD be included (also [2]). Example: lanes=3 and
>> lanes:psv=1 means we have three lanes and one OF THEM is for PSV only.
> Same goes for HOV (high-occupancy-vehicles) lanes, unless they are
> separately mapped (which is a better solution for routing, given their
> controlled access).

I will think about a phrase, that will cover all those lanes. For
english and russian: suggestions from native speakers are welcome!


>> * Turn lanes SHOULD be included (see [2] and [5]).
>> * The lane count should change, as soon as a) new lane has reached its
>> full width or b) a lane starts to disappear (usually a merge with
>> another lane) (also [5]).
> Technically, yes, but it doesn't seem practical in developed areas in the
> US, which typically change lane configurations at every major intersection
> and then change back again.
> ....

Yes - and no. That's called micromapping. I fully agree with you, that
under normal circumstances it should not be necessary. But for example
on motorways I actually tag this way, especially since turning lanes
can be properly mapped. This way routers could precisely determine
e.g. the start and end of lanes exiting the motorway and give very
accurate instructions.
As there are no obvious reasons to not include turning lanes, we
should not exclude them. But I think about adding a statement, that
usually only on major roads or very complex junctions those lanes are
actually mapped. Can we agree on this?


>> ?- Two-way roads with a specified lane count, but without a specified
>> lanes:forward OR lanes:backward and a lane count, that is divisible by
>> two, are assumed to have half of the lanes in each direction, e.g.
>> lanes=4 means two lanes in each direction if not specified otherwise.
>> I will add a recommendation for this situation, to add explicit
>> values.
> If an odd number, assume a center turn lane (e.g. lanes=5 means 2 forward, 2
> backward, 1 center).

This is simply not working that way. If we would use that assumption,
we would assume a lot of center turn lanes in Austria. I don't know 1
(in words: one) of them. Completely omitting those default assumptions
might also not be a good idea, because in my opinion it should not be
necessary to tag the lanes count on e.g. normal residential roads.
How about a table for the most common types of roads? Example:
residential is assumed to have one lane if one-way, two otherwise. For
motorways and trunks I would not add any assumptions, because they
simply differ too much.
Can we agree on that?

Martin


From imagic.osm at gmail.com  Fri Apr 20 08:16:52 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Fri, 20 Apr 2012 09:16:52 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CABUOUO8fuCSH-1JkApWSN0dTwsrFhZuoXr2UdqsTdou9=bFiqg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CABUOUO8fuCSH-1JkApWSN0dTwsrFhZuoXr2UdqsTdou9=bFiqg@mail.gmail.com>
Message-ID: <CAKjckyPjaZd=8sOVma2KPaS95E5tXAMj8xYoPKdNUi1oH5XLtg@mail.gmail.com>

> There is a discussion about PSV lanes, but what about emergency lanes.
> Nobody is allowed to use it, with the exception of people who have to stop
> for a car problem, or by emergency vehicles when there is a traffic jam on
> the other lanes (at least, that's the case in Belgium).
>
> This is not one place where you can drive to and park your car to change a
> wheel or so, it's a lane along a huge part of the way.

As they are not open (under normal circumstances) for traffic I would
use the same arguments with them as for parking lanes and therefore
not include them. Do we agree on this?

Martin


From richard.mann.westoxford at gmail.com  Fri Apr 20 08:31:42 2012
From: richard.mann.westoxford at gmail.com (Richard Mann)
Date: Fri, 20 Apr 2012 08:31:42 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
Message-ID: <CAMLmWVsh5mC__26ANNNCfc0624_Xj78iYrCdYJxYnAbygrHfbg@mail.gmail.com>

On Fri, Apr 20, 2012 at 8:09 AM, Martin Vonwald <imagic.osm at gmail.com>wrote:

> But I think about adding a statement, that
> usually only on major roads or very complex junctions those lanes are
> actually mapped. Can we agree on this?
>

+1 Urban roads are going to be very messy if every little centre turning
lane gets tagged.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120420/15d71575/attachment.html>

From osm at bavarianmallet.de  Fri Apr 20 09:19:54 2012
From: osm at bavarianmallet.de (Georg Feddern)
Date: Fri, 20 Apr 2012 10:19:54 +0200
Subject: [Tagging] Weigh stations
In-Reply-To: <4F9109E8.3000603@gmail.com>
References: <4F9109E8.3000603@gmail.com>
Message-ID: <4F911C2A.4030504@bavarianmallet.de>

Am 20.04.2012 09:02, schrieb Nathan Edgars II:
> Is there a tag in use for weigh stations, places where trucks are 
> weighed to ensure that they are not too heavy?

There is only a tag at
http://wiki.openstreetmap.org/wiki/Relation:enforcement
for such "enforcement" devices.

On the german page
http://http://wiki.openstreetmap.org/wiki/DE:Relation:enforcement
there is an example
Beispiel 6: Gewichtsmessung

Since I do not know of any of such a "flowing traffic enforcement 
device" but only of stationary devices, this may be used.
But I would expect "normal" weigh devices at amenity= or man_made= or 
such alike (*), because they are "normally" used to measure the load of 
goods - the "maxweight" is just a side effect they are used for.

(*) Maybe even at highway= like crossing, signal a. o., if you consider 
them as part of the automobile sector - but that is again a limitation 
already.


From neroute2 at gmail.com  Fri Apr 20 09:42:12 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Fri, 20 Apr 2012 04:42:12 -0400
Subject: [Tagging] Weigh stations
In-Reply-To: <4F911C2A.4030504@bavarianmallet.de>
References: <4F9109E8.3000603@gmail.com> <4F911C2A.4030504@bavarianmallet.de>
Message-ID: <4F912164.3090406@gmail.com>

On 4/20/2012 4:19 AM, Georg Feddern wrote:
> Am 20.04.2012 09:02, schrieb Nathan Edgars II:
>> Is there a tag in use for weigh stations, places where trucks are
>> weighed to ensure that they are not too heavy?
>
> There is only a tag at
> http://wiki.openstreetmap.org/wiki/Relation:enforcement
> for such "enforcement" devices.

It doesn't make sense to use a relation. It's more like a rest area 
(highway=services - though I just found a problem there and will send a 
separate message) than a traffic camera. See the photo here: 
http://www.dot.state.fl.us/statemaintenanceoffice/WeighStationListing.shtm#Plant%20City%20Weigh%20In%20Motion%20(WIM)%20-%20Static%20Station 
and the others on that page.


From neroute2 at gmail.com  Fri Apr 20 09:46:12 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Fri, 20 Apr 2012 04:46:12 -0400
Subject: [Tagging] highway=services/rest_area
Message-ID: <4F912254.9030405@gmail.com>

http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices says that it 
(usually) has fuel and food, but it links to Wikipedia:rest area. Should 
the Wikipedia link be removed (and added to 
http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area)? Should the 
word 'usually' be removed?


From colin.smale at xs4all.nl  Fri Apr 20 10:17:23 2012
From: colin.smale at xs4all.nl (Colin Smale)
Date: Fri, 20 Apr 2012 11:17:23 +0200
Subject: [Tagging] Weigh stations
In-Reply-To: <4F912164.3090406@gmail.com>
References: <4F9109E8.3000603@gmail.com> <4F911C2A.4030504@bavarianmallet.de>
	<4F912164.3090406@gmail.com>
Message-ID: <4F9129A3.1070307@xs4all.nl>

In Europe at any rate there are proper weighbridges which 
drivers/operators can use to check for compliancy with weight limits or 
for the registration of the transport of certain bulk materials (such as 
coal, oil etc - the truck is weighed before and after (un)loading). 
There are also invisible weight sensors embedded in the normal highway 
surface which are used for enforcement (while driving over it at full 
speed!). Sometimes these are announced on signs, sometimes they are not. 
These are IMHO very similar to speed cameras, which, by the way, can 
also often tell the difference between cars and trucks and apply the 
appropriate speed limit. If the police suspect a vehicle is overweight 
they can also require the vehicle to follow them to a convenient public 
(or, by agreement with the operator, private) weighbridge for a check.

So some weigh stations can be seen as a public facility, some are a 
private facility, and some are for enforcement.

Colin

On 20/04/2012 10:42, Nathan Edgars II wrote:
> On 4/20/2012 4:19 AM, Georg Feddern wrote:
>> Am 20.04.2012 09:02, schrieb Nathan Edgars II:
>>> Is there a tag in use for weigh stations, places where trucks are
>>> weighed to ensure that they are not too heavy?
>>
>> There is only a tag at
>> http://wiki.openstreetmap.org/wiki/Relation:enforcement
>> for such "enforcement" devices.
>
> It doesn't make sense to use a relation. It's more like a rest area 
> (highway=services - though I just found a problem there and will send 
> a separate message) than a traffic camera. See the photo here: 
> http://www.dot.state.fl.us/statemaintenanceoffice/WeighStationListing.shtm#Plant%20City%20Weigh%20In%20Motion%20(WIM)%20-%20Static%20Station 
> and the others on that page.



From osm at bavarianmallet.de  Fri Apr 20 10:50:44 2012
From: osm at bavarianmallet.de (Georg Feddern)
Date: Fri, 20 Apr 2012 11:50:44 +0200
Subject: [Tagging] highway=services/rest_area
In-Reply-To: <4F912254.9030405@gmail.com>
References: <4F912254.9030405@gmail.com>
Message-ID: <4F913174.4090902@bavarianmallet.de>

Am 20.04.2012 10:46, schrieb Nathan Edgars II:
> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices says that it 
> (usually) has fuel and food, but it links to Wikipedia:rest area.

> Should the Wikipedia link be removed (and added to 
> http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area)?

Uhmm, difficult, because the linked wikipedia article refers to rest 
area _and_ service area.

I would differ between
highway=rest_area as rest area (min. parking and rest rooms, may be a 
picnic area or a very small kiosk, but no further service)
and
highway=services as service area. (min. any 'full' service like refuel, 
restaurant, accomodation)

> Should the word 'usually' be removed?

Possibly, at least I am expecting a fuel service at highway=services - 
but that may be a result of my german / european practice.
I do not know of service areas with accomodation only, just of fuel and 
optional restaurant, optional accomodation.



From lists at mail.atownsend.org.uk  Fri Apr 20 10:54:11 2012
From: lists at mail.atownsend.org.uk (SomeoneElse)
Date: Fri, 20 Apr 2012 10:54:11 +0100
Subject: [Tagging] highway=services/rest_area
In-Reply-To: <4F912254.9030405@gmail.com>
References: <4F912254.9030405@gmail.com>
Message-ID: <4F913243.9060503@mail.atownsend.org.uk>

Nathan Edgars II wrote:
> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices says that it 
> (usually) has fuel and food, but it links to Wikipedia:rest area. 
> Should the Wikipedia link be removed (and added to 
> http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area)? Should 
> the word 'usually' be removed?

As I read it, Wikipedia:rest_area encompasses both highway=services and 
highway=rest_area.  The highway=rest_area page was created by an 
Australian, and I suspect it reflects the situation in (Eastern) 
Australia*.  It links to "Wikipedia:rest area#Australia. There are 
similar non-service rest areas in other countries of course - lots in 
the US, and there's at least one in the UK.

I'd say the wikipedia links are about right as thet are

Cheers,
Andy

* I don't remember seeing one in a few thousand km of driving in Western 
Australia last year.  Bottle-shops, plenty...


From neroute2 at gmail.com  Fri Apr 20 11:43:10 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Fri, 20 Apr 2012 06:43:10 -0400
Subject: [Tagging] highway=services/rest_area
In-Reply-To: <4F913174.4090902@bavarianmallet.de>
References: <4F912254.9030405@gmail.com> <4F913174.4090902@bavarianmallet.de>
Message-ID: <4F913DBE.3040402@gmail.com>

On 4/20/2012 5:50 AM, Georg Feddern wrote:
> Am 20.04.2012 10:46, schrieb Nathan Edgars II:
>> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices says that it
>> (usually) has fuel and food, but it links to Wikipedia:rest area.
>
>> Should the Wikipedia link be removed (and added to
>> http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area)?
>
> Uhmm, difficult, because the linked wikipedia article refers to rest
> area _and_ service area.

Wikipedia:service area redirects to rest area, so I'm going to change it 
to that. At least it won't give the wrong impression to someone skimming 
the description.


From phil at trigpoint.me.uk  Fri Apr 20 13:21:03 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Fri, 20 Apr 2012 13:21:03 +0100
Subject: [Tagging] highway=services/rest_area
In-Reply-To: <4F913DBE.3040402@gmail.com>
References: <4F912254.9030405@gmail.com>
	<4F913174.4090902@bavarianmallet.de> <4F913DBE.3040402@gmail.com>
Message-ID: <1334924463.12429.5.camel@marvin>

On Fri, 2012-04-20 at 06:43 -0400, Nathan Edgars II wrote:
> On 4/20/2012 5:50 AM, Georg Feddern wrote:
> > Am 20.04.2012 10:46, schrieb Nathan Edgars II:
> >> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices says that it
> >> (usually) has fuel and food, but it links to Wikipedia:rest area.
> >
> >> Should the Wikipedia link be removed (and added to
> >> http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area)?
> >
> > Uhmm, difficult, because the linked wikipedia article refers to rest
> > area _and_ service area.
> 
> Wikipedia:service area redirects to rest area, so I'm going to change it 
> to that. At least it won't give the wrong impression to someone skimming 
> the description. 
I think Wikipedia is very wrong on that one, and we really should not
follow it.

To give the impression that you will get fuel, food or drink at a rest
area is misleading. A rest area is a place to stop (to rest), that may
have a WC, picnic tables, somewhere maybe to set up a barbeque but no
'services' are available.

At a service area you can also get fuel, there will be a shop and
cafeteria/restaurants.

Phil




From knauf at infoware.de  Fri Apr 20 13:32:17 2012
From: knauf at infoware.de (Heinrich Knauf)
Date: Fri, 20 Apr 2012 14:32:17 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <2170714.HYHGOC0Ss3@obiwan>
References: <2170714.HYHGOC0Ss3@obiwan>
Message-ID: <4F915751.30002@infoware.de>

Am 05.04.2012 04:27, schrieb Eckhart W?rner:
> Hi,
>
> (sorry for starting a new thread, I just subscribed to the list)
>
>> infoware GmbH, Bonn, Germany, and Geofabrik GmbH, Karlsruhe, Germany, have
>> developed an improved tagging scheme for TMC data which we would like to
>> propopose to the OSM community.
> I believe this is much needed, so thank you for starting this effort.
>
> The one thing I like very much about the proposal is that it allows people to
> start using TMC information without spending too much time implementing insane
> heuristics or programming shortest path algorithms.
>
> However, I feel like there are some problems with your design, which should be
> discussed on a mailing list, since Wiki discussions are ugly.
>
> 1) The big problem: missing directional information
>
> Let's assume there is a way in OSM tagged tmc=DE:123+456;DE:456-123. One also
> has real-time traffic information that talks about a traffic jam at LCD 456,
> negative direction, extent 1. One therefore knows that this traffic jam affects
> DE:123-456, and since we have a way with that information, we know that this
> way is affected.
> However, there's one problem: which direction of the way is affected? It could
> be either the direction from the first point of the way to the last (called
> forward from now on), or vice versa (backward). This essential information is
> missing and makes the TMC information on non-oneway ways useless.
> There are several solutions to this problem. Probably the best solution is not
> using the tmc tag at all, but using tmc:forward and tmc:backward instead. Thus
> assuming the direction of the way is from LCD 123 to LCD 456, the tagging
> would be tmc:forward=DE:123+456, tmc:backward=DE:456-123. "forward" and
> "backward" are already used in tagging (for example, maxspeed:forward) and are
> also protected by tools. E.g. if you try to reverse the before-mentioned way,
> JOSM suggests to swap tmc:forward and tmc:backward (which is the correct thing
> to do in that case).
That's no problem at all. The TMC direction must not be mixed up with 
the driving direction, which here does not matter at all. All that 
counts is the direction given (and defined) by the TMC data. If a 
traffic event extends "forward" woth respect to the direction defined by 
TMC, then "+" is used, if it extends in the revers direction, we use 
"-". This is very concise, and using "forward" or "backward" instead 
would just blow the tags.
> 2) A matter of taste: + and -
>
> I'm not sure how others are feeling about this, but I find DE:123+456,
> DE:456-123 somehow confusing. Here's an alternate proposal: DE:123+456 becomes
> DE:123->456, and DE:456-123 becomes DE:123<-456 (notice the changed order).
> Therefore, the LCD order is encoded in the position of the numbers, and the
> movement between the LCDs is encoded in the arrow.
> I would go even one step further and allow ? (LEFTWARDS ARROW; U+2190) and ?
> (RIGHTWARDS ARROW; U+2192) as an *alternative*. I know that not everybody
> knows how to enter these codes, but every editor and every operating system
> nowadays should be able to display them, and we have full unicode support in
> the database.
> Because of 1), DE:123/456 does not make sense at all.
OK, I think special unicode characters should not be used at all because 
compatibility is uncertain and they are not available at any keyboard. 
Using "+" and "-" is just straightforward. I would not expected 
intereference or incompatibility with any other software from these, and 
for the tests that we made so far everything works fine.

However,  anybody having made experience with the issue what special 
characters to use for tagging without running into compatiblilty 
problems: Please would you share your ideas, your opinion is greatly 
appreciated.
> 3) Bad influence: TMC information at junctions
>
> One thing that I cannot wrap my head around is the TMC information *at*
> junctions. As far as I remember, a traffic jam at LCD 456, negative direction,
> extent 1 affects the road *between* LCD 123 and LCD 456, but not the actual
> junctions 123 or 456. However, the rules of adding tmc tags to the actual
> junctions influence a lot of maneuvers going over those junctions but not using
> any other part of the way. This is especially true for roundabouts or
> junctions between dual carriageways.
Please could you supply an image, or probably refer to the figures and 
the numbering that we use in the proposals examples? That would make it 
a lot clearer.
>
> 4) Exits and entries
>
> TMC specifies messages that apply to entries or exits, which I feel are not
> adequately represented in the proposal, even though the proposal mentions
> them. For example, assume that the 2nd exit slip road going west at K?ln-S?d
> (where I already discovered the new tagging) is closed (and I believe there is
> a TMC message for that). How do I find this 2nd slip road? (Yes, I picked a
> really hard one.)
Isn't that just a matter of the granularity of TMC location coding 
versus OSM mapping? If so, then there's nothing to help about that with 
any TMC tagging scheme whatsoever.
>
> 5) Versioning
>
> You argue that versioning is not needed, since data can be changed in a timely
> manner, and the errors that appear are mostly harmless. I don't feel that way:
> a) Experience tells that data is not always changed in a timely matter,
> especially since TMC data does not appear on most of the maps. It takes a
> while to process data (being half a month outdated seems to be normal even for
> online routing), and offline maps make this situation worse (just look at the
> bug reports at MapDust that appeared since Skobbler had started shipping offline
> maps).
> b) When LCDs are inserted into chains, things break *badly*, since the extents
> are then out of sync as well.
Since TMC tags will simply be part of all other road network data that 
any solution will use for mapping, navigaiton, etc., they will always 
fit together from the time of creation. So there's n need for 
versioning. On the other hand, it is abolutely certain that the issueing 
organisations that are in charge of TMC (like BASt in Germany) will 
never "re-cycle" previosly used location codes in a way that  might 
create trouble.
>
> Eckhart W?rner
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging

Best regards,
Mit freundlichen Gr??en,
Heinrich Knauf

infoware GmbH
Riemenschneiderstr. 11
53175 Bonn
GERMANY

facebook_follow_us <http://facebook.infoware.de/>

office: +49 228 338899-21
email: knauf at infoware.de <mailto:knauf at infoware.de>
web: www.infoware.de <http://www.infoware.de>
infoware Gesellschaft f?r Informationstechnik mbH
Gesch?ftsf?hrer: Thomas Schulte-Hillen, Martin Langhoff;
Sitz Bonn; Amtsgericht Bonn HRB 14141

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120420/043f1169/attachment.html>

From dieterdreist at gmail.com  Fri Apr 20 13:46:36 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Fri, 20 Apr 2012 14:46:36 +0200
Subject: [Tagging] highway=services/rest_area
In-Reply-To: <1334924463.12429.5.camel@marvin>
References: <4F912254.9030405@gmail.com> <4F913174.4090902@bavarianmallet.de>
	<4F913DBE.3040402@gmail.com> <1334924463.12429.5.camel@marvin>
Message-ID: <CABPTjTCudZawnDKU8Zoi7v3WC0s_JQznAhLoAMb4UTJ4xh7d9Q@mail.gmail.com>

Am 20. April 2012 14:21 schrieb Philip Barnes <phil at trigpoint.me.uk>:
> I think Wikipedia is very wrong on that one, and we really should not
> follow it.


+1, we might even think of correcting it in WP.


> To give the impression that you will get fuel, food or drink at a rest
> area is misleading. A rest area is a place to stop (to rest), that may
> have a WC, picnic tables, somewhere maybe to set up a barbeque but no
> 'services' are available.
>
> At a service area you can also get fuel, there will be a shop and
> cafeteria/restaurants.


+1, it is the same situation in Germany, Italy and probably mostly anywhere.

Cheers,
Martin


From phil at trigpoint.me.uk  Fri Apr 20 14:08:31 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Fri, 20 Apr 2012 14:08:31 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyN+-iSPAGb0ZSK+G9fLaVpNR0ukVyg5-jRM-3n97aZoLg@mail.gmail.com>
References: <CAKjckyN+-iSPAGb0ZSK+G9fLaVpNR0ukVyg5-jRM-3n97aZoLg@mail.gmail.com>
Message-ID: <1334927311.12429.12.camel@marvin>

On Thu, 2012-04-19 at 13:38 +0200, Martin Vonwald wrote:
>   - A one-way road has one lane
Not always it has however many lanes there are on the ground.
http://bit.ly/JTZo3k has 3 lanes.

>  - Two-way roads with a specified lane count, but without a specified
> lanes:forward OR lanes:backward and a lane count, that is divisible by
> two, are assumed to have half of the lanes in each direction, e.g.
> lanes=4 means two lanes in each direction if not specified otherwise.
> I will add a recommendation for this situation, to add explicit
> values.
What happens when there are 3, with the centre lane shared?
http://bit.ly/HYdlkF Google Streetview
http://www.openstreetmap.org/?lat=51.80666&lon=-3.19175&zoom=16 OSM

Phil



From phil at trigpoint.me.uk  Fri Apr 20 14:20:56 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Fri, 20 Apr 2012 14:20:56 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
Message-ID: <1334928056.12429.16.camel@marvin>

On Thu, 2012-04-19 at 12:33 -0700, Alan Mintz wrote:
> If an odd number, assume a center turn lane (e.g. lanes=5 means 2 forward, 
> 2 backward, 1 center).
> 
You cannot assume that, many 3 lane roads have a 'chicken' lane. Where
the centre lane is used for overtaking by traffic in either direction.

The presence of a solid and broken line together indicating that you
should give priority to traffic overtaking but travelling in the
opposite direction. But allows you to overtake otherwise.

Phil



From phil at trigpoint.me.uk  Fri Apr 20 14:35:05 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Fri, 20 Apr 2012 14:35:05 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
Message-ID: <1334928905.12429.24.camel@marvin>

On Fri, 2012-04-20 at 09:09 +0200, Martin Vonwald wrote:
>  For motorways and trunks I would not add any assumptions, because they
> simply differ too much.
> Can we agree on that?
> 
+1 
Very much agree with you there. Trunks in particular can vary
enormously, from practically motorway standard roads to having to give
way to traffic coming in the opposite direction because they are not
wide enough for two vehicles to pass.

When I was a child, back in the 1960s I can remember trunk roads, in
Scotland, that were single lane with passing places, although I don't
think they exist anymore, but am prepared to be proven wrong.

Which prompts another question, do we have a tag for a 'passing place'?
There is a photo of one on this page
http://en.wikipedia.org/wiki/Single-track_road

Phil



From ewoerner at kde.org  Fri Apr 20 14:39:00 2012
From: ewoerner at kde.org (Eckhart =?ISO-8859-1?Q?W=F6rner?=)
Date: Fri, 20 Apr 2012 15:39 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <4F915751.30002@infoware.de>
References: <2170714.HYHGOC0Ss3@obiwan> <4F915751.30002@infoware.de>
Message-ID: <2702755.l5opf4L5Gm@obiwan>

Hi,

Am Freitag, 20. April 2012, 14:32:17 schrieb Heinrich Knauf:
> > 1) The big problem: missing directional information
> >
> > Let's assume there is a way in OSM tagged tmc=DE:123+456;DE:456-123. One also
> > has real-time traffic information that talks about a traffic jam at LCD 456,
> > negative direction, extent 1. One therefore knows that this traffic jam affects
> > DE:123-456, and since we have a way with that information, we know that this
> > way is affected.
> > However, there's one problem: which direction of the way is affected? It could
> > be either the direction from the first point of the way to the last (called
> > forward from now on), or vice versa (backward). This essential information is
> > missing and makes the TMC information on non-oneway ways useless.
> > There are several solutions to this problem. Probably the best solution is not
> > using the tmc tag at all, but using tmc:forward and tmc:backward instead. Thus
> > assuming the direction of the way is from LCD 123 to LCD 456, the tagging
> > would be tmc:forward=DE:123+456, tmc:backward=DE:456-123. "forward" and
> > "backward" are already used in tagging (for example, maxspeed:forward) and are
> > also protected by tools. E.g. if you try to reverse the before-mentioned way,
> > JOSM suggests to swap tmc:forward and tmc:backward (which is the correct thing
> > to do in that case).
> That's no problem at all. The TMC direction must not be mixed up with 
> the driving direction, which here does not matter at all. All that 
> counts is the direction given (and defined) by the TMC data. If a 
> traffic event extends "forward" woth respect to the direction defined by 
> TMC, then "+" is used, if it extends in the revers direction, we use 
> "-". This is very concise, and using "forward" or "backward" instead 
> would just blow the tags.

Please re-read my argument. (Note that I use "positive"/"negative" to indicate a direction along TMC chains, and "forward"/"backward" to indicate a direction along an OSM way).
Arguing that the driving direction does not matter at all is wrong as soon as you're not talking about oneways anymore. An event affecting the positive direction of a TMC chain may affect either the forward or the backward direction of an OSM way, and this entirely depends on the OSM way.

> > 3) Bad influence: TMC information at junctions
> >
> > One thing that I cannot wrap my head around is the TMC information *at*
> > junctions. As far as I remember, a traffic jam at LCD 456, negative direction,
> > extent 1 affects the road *between* LCD 123 and LCD 456, but not the actual
> > junctions 123 or 456. However, the rules of adding tmc tags to the actual
> > junctions influence a lot of maneuvers going over those junctions but not using
> > any other part of the way. This is especially true for roundabouts or
> > junctions between dual carriageways.
> Please could you supply an image, or probably refer to the figures and 
> the numbering that we use in the proposals examples? That would make it 
> a lot clearer.

See http://wiki.openstreetmap.org/wiki/DE_talk:Proposed_features/New_TMC_scheme#Auswirkungen_von_TMC-Nachrichten_an_Kreuzungen for a discussion of the problem.

> > 4) Exits and entries
> >
> > TMC specifies messages that apply to entries or exits, which I feel are not
> > adequately represented in the proposal, even though the proposal mentions
> > them. For example, assume that the 2nd exit slip road going west at K?ln-S?d
> > (where I already discovered the new tagging) is closed (and I believe there is
> > a TMC message for that). How do I find this 2nd slip road? (Yes, I picked a
> > really hard one.)
> Isn't that just a matter of the granularity of TMC location coding 
> versus OSM mapping? If so, then there's nothing to help about that with 
> any TMC tagging scheme whatsoever.

Unless I'm wrong (and I haven't read the TMC specs in a while) this should be possible with TMC, OSM just needs to supply the relevant data.
Anyway, parts of this have been covered in a different mail.

Eckhart W?rner


From lowflight66 at googlemail.com  Fri Apr 20 14:59:51 2012
From: lowflight66 at googlemail.com (fly)
Date: Fri, 20 Apr 2012 15:59:51 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <4F915751.30002@infoware.de>
References: <2170714.HYHGOC0Ss3@obiwan> <4F915751.30002@infoware.de>
Message-ID: <4F916BD7.70300@googlemail.com>

On 20/04/12 14:32, Heinrich Knauf wrote:
> Am 05.04.2012 04:27, schrieb Eckhart W?rner:

Thanks for you effort.

>> 4) Exits and entries
>>
>> TMC specifies messages that apply to entries or exits, which I feel are not 
>> adequately represented in the proposal, even though the proposal mentions 
>> them. For example, assume that the 2nd exit slip road going west at K?ln-S?d 
>> (where I already discovered the new tagging) is closed (and I believe there is 
>> a TMC message for that). How do I find this 2nd slip road? (Yes, I picked a 
>> really hard one.)
> Isn't that just a matter of the granularity of TMC location coding versus OSM
> mapping? If so, then there's nothing to help about that with any TMC tagging
> scheme whatsoever.

I am not that into TMC but I thought there is a difference between a TMC Point
and TMC Roads/Segments and that either a TMC Point might be blocked or some part
of a Segment/Road (from Point A till Point D) with the TMC Points unblocked.
Please tell me if I am wrong.

With the new tagging system there is no difference between a way which is part
of a TMC Point (eg roundabout or junction with several slip roads). In your wiki
example of the roundabout let there be a small road intersect from the
northeast. In order to get there comming from Point 7 you need to turn at the
roundabout about 300? and using part of (20+8) and (20-5). Would this still work ?

>>
>> 5) Versioning
>>
>> You argue that versioning is not needed, since data can be changed in a timely 
>> manner, and the errors that appear are mostly harmless. I don't feel that way:
>> a) Experience tells that data is not always changed in a timely matter, 
>> especially since TMC data does not appear on most of the maps. It takes a 
>> while to process data (being half a month outdated seems to be normal even for 
>> online routing), and offline maps make this situation worse (just look at the 
>> bug reports at MapDust that appeared since Skobbler had started shipping offline 
>> maps).
>> b) When LCDs are inserted into chains, things break *badly*, since the extents 
>> are then out of sync as well.
> Since TMC tags will simply be part of all other road network data that any
> solution will use for mapping, navigaiton, etc., they will always fit together
> from the time of creation. So there's n need for versioning. On the other hand,
> it is abolutely certain that the issueing organisations that are in charge of
> TMC (like BASt in Germany) will never "re-cycle" previosly used location codes
> in a way that  might create trouble.

In my region there was and still is TMC data of the future available (version
9). This is due to changing routes and up/downgrading parts of the road system.
The decision was made before the (re)constuction was finished. E.g. TMC data
leads along roads with heavy constuctions or even non existing roads and was/is
inconsistant with the routes on the ground (traffic signs). With the versioning
I was able to tag the current (old) route and the future one.

> Best regards,
> Mit freundlichen Gr??en,
> Heinrich Knauf



From ewoerner at kde.org  Fri Apr 20 15:18:04 2012
From: ewoerner at kde.org (Eckhart =?ISO-8859-1?Q?W=F6rner?=)
Date: Fri, 20 Apr 2012 16:18:04 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <4F915751.30002@infoware.de>
References: <2170714.HYHGOC0Ss3@obiwan> <4F915751.30002@infoware.de>
Message-ID: <2543196.cAIYO6JHOn@obiwan>

Hi,

Am Freitag, 20. April 2012, 14:32:17 schrieb Heinrich Knauf:
> > 2) A matter of taste: + and -
> >
> Using "+" and "-" is just straightforward. I would not expected 
> intereference or incompatibility with any other software from these, and 
> for the tests that we made so far everything works fine.

I'll take this one back, in the context of my other mails + and - look like a sane solution.

Eckhart W?rner


From john at jfeldredge.com  Fri Apr 20 15:18:20 2012
From: john at jfeldredge.com (John F. Eldredge)
Date: Fri, 20 Apr 2012 09:18:20 -0500
Subject: [Tagging] highway=services/rest_area
In-Reply-To: <CABPTjTCudZawnDKU8Zoi7v3WC0s_JQznAhLoAMb4UTJ4xh7d9Q@mail.gmail.com>
References: <4F912254.9030405@gmail.com> <4F913174.4090902@bavarianmallet.de>
	<4F913DBE.3040402@gmail.com> <1334924463.12429.5.camel@marvin>
	<CABPTjTCudZawnDKU8Zoi7v3WC0s_JQznAhLoAMb4UTJ4xh7d9Q@mail.gmail.com>
Message-ID: <bb46a286-73e4-4279-b1f2-f93d0fe05ac4@email.android.com>

Martin Koppenhoefer <dieterdreist at gmail.com> wrote:

> Am 20. April 2012 14:21 schrieb Philip Barnes <phil at trigpoint.me.uk>:
> > I think Wikipedia is very wrong on that one, and we really should
> not
> > follow it.
> 
> 
> +1, we might even think of correcting it in WP.
> 
> 
> > To give the impression that you will get fuel, food or drink at a
> rest
> > area is misleading. A rest area is a place to stop (to rest), that
> may
> > have a WC, picnic tables, somewhere maybe to set up a barbeque but
> no
> > 'services' are available.
> >
> > At a service area you can also get fuel, there will be a shop and
> > cafeteria/restaurants.
> 
> 
> +1, it is the same situation in Germany, Italy and probably mostly
> anywhere.
> 
> Cheers,
> Martin
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging

In the USA, you have the same distinction between service areas and rest areas.  In addition, there will sometimes be "parking areas", meaning that there will be a parking lot but no restrooms or other amenities.  Fortunately, "parking areas" are rare.

-- 
John F. Eldredge --  john at jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria


From toby.murray at gmail.com  Fri Apr 20 15:26:40 2012
From: toby.murray at gmail.com (Toby Murray)
Date: Fri, 20 Apr 2012 09:26:40 -0500
Subject: [Tagging] Weigh stations
In-Reply-To: <4F9109E8.3000603@gmail.com>
References: <4F9109E8.3000603@gmail.com>
Message-ID: <CAJeqKgsFZOeVk-_6XP4rhrjhAYmeGZGp0Wzgs4AMGnEHcGGkgw@mail.gmail.com>

On Fri, Apr 20, 2012 at 2:02 AM, Nathan Edgars II <neroute2 at gmail.com> wrote:
> Is there a tag in use for weigh stations, places where trucks are weighed to
> ensure that they are not too heavy?

I think the only thing I've done for weigh stations so far is put a
"exit_to=Weigh Station" on the exit nodes on interstates. But I could
certainly see using a highway=weigh_station or something like that for
the area, similar to highway=rest_area|services. Is there any use in
noting wich weigh stations support PrePass[1]? Maybe just a
prepass=yes|no tag? This is clearly visible on the road with signs
that tell drivers to follow in-cab PrePass prompts plus the
overhanging sensors to read the transponder.

[1] http://www.prepass.com/services/prepass/Pages/WhatIsPrepass.aspx

Toby


From liste at letuffe.org  Fri Apr 20 15:31:21 2012
From: liste at letuffe.org (sly (sylvain letuffe))
Date: Fri, 20 Apr 2012 16:31:21 +0200
Subject: [Tagging] Voting : Isolated buildings in mountain/wild used by
	hikers(/...) for shelter/sleeping/eating
Message-ID: <201204201631.21768.liste@letuffe.org>

Hi,

After the huge clean up, improve and re-wording by rudof (thanks rudolf) the 4 
proposals are open for a vote at :
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Alpine_hut
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Wilderness_hut
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Basic_hut
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Lean_to

The grouping page is here :
http://wiki.openstreetmap.org/wiki/Proposed_features/wilderness_mountain_buildings

Please use the talk page for generic comments on all 4 proposal here :
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/wilderness_mountain_buildings

Or use one of the 4 specific proposal pages if you want to comment on one 
specific tag

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org


From jamicuosm at googlemail.com  Fri Apr 20 15:58:55 2012
From: jamicuosm at googlemail.com (Jason Cunningham)
Date: Fri, 20 Apr 2012 15:58:55 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <1334928905.12429.24.camel@marvin>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
Message-ID: <CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>

On 20 April 2012 14:35, Philip Barnes <phil at trigpoint.me.uk> wrote:

> Which prompts another question, do we have a tag for a 'passing place'?
> There is a photo of one on this page
> http://en.wikipedia.org/wiki/Single-track_road
>

Tag info shows it does highway=passing_place does get used
http://taginfo.openstreetmap.org/search?q=highway%3Dpassing
And there is a page on the wiki for it.

And here's another question.
A twoway single lane highway implies that if you meet a vehicle coming in
the other direction the road is blocked. Hence the the common of existence,
at least in the UK, of 'Passing Places' mentioned by Philip.
A twoway two lane highway implies that common road vehicles can drive down
the road each within their own lane?
But there is a third situation that in my area is arguably more common than
implied single lane status, and that is a road which is wide enough for
cars to pass each other at at crawl, but which would be blocked if a large
vehicle meets another vehicle. This I assume is impotant information,
especially for routing, because these are roads a car owner would wish to
avoid if there is an alternative 'true' 2 lane road, and which a lorry or
van should avoid unless they must use the road.

A while back I went through a period of trying to add lanes, speed limits,
and lighting info. This was prompted by the excellent "tools" produced by
ITO map eg www.itoworld.com/map/179
While trying to sort through the confusing speed limit laws in my country,
I stumbled across a document advising that roads where two cars could pass
slowly or with care, but wider vehciles could not, the road should be
considered to consist of  1.5 lanes. Didn't bother to save the document at
the time and search engines can't track it down. Does the idea of lanes=1.5
seem acceptable for roads where cars can pass slowly, but wider vehicles
will block the road. There is an obvious problem that the decision to label
a road as lanes=1.5 is subjective.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120420/ad0575e2/attachment-0001.html>

From dieterdreist at gmail.com  Fri Apr 20 16:08:07 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Fri, 20 Apr 2012 17:08:07 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <2543196.cAIYO6JHOn@obiwan>
References: <2170714.HYHGOC0Ss3@obiwan> <4F915751.30002@infoware.de>
	<2543196.cAIYO6JHOn@obiwan>
Message-ID: <CABPTjTDApZ6T3R4LHs=Bv6kEVcb+1ZLo9smwqQMH1uePb+ZGVg@mail.gmail.com>

I want to come back to the question from fly: how shall TMC-points be
tagged (or shouldn't they?). Somehow we should have them visible in
the Editor (because otherwise tagging TMC on ways would also become
difficult), but besides from having them explicitly in the data maybe
they could also be pulled from a parallel system at editing time. They
are official anyway, and there won't be much need for a mapper to move
them around or modify them in other ways.

cheers,
Martin


From dieterdreist at gmail.com  Fri Apr 20 16:11:16 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Fri, 20 Apr 2012 17:11:16 +0200
Subject: [Tagging] highway=services/rest_area
In-Reply-To: <bb46a286-73e4-4279-b1f2-f93d0fe05ac4@email.android.com>
References: <4F912254.9030405@gmail.com> <4F913174.4090902@bavarianmallet.de>
	<4F913DBE.3040402@gmail.com> <1334924463.12429.5.camel@marvin>
	<CABPTjTCudZawnDKU8Zoi7v3WC0s_JQznAhLoAMb4UTJ4xh7d9Q@mail.gmail.com>
	<bb46a286-73e4-4279-b1f2-f93d0fe05ac4@email.android.com>
Message-ID: <CABPTjTCp6xvYoyad9ZQG52CWRM+VHxLrkcKuADiW_YcJbyXTuQ@mail.gmail.com>

Am 20. April 2012 16:18 schrieb John F. Eldredge <john at jfeldredge.com>:
> n addition, there will sometimes be "parking areas", meaning that there will be a parking lot but no restrooms or other amenities. ?Fortunately, "parking areas" are rare.


we also have these, I'd include them in rest_areas. Basically you can
rest there, even if there is no toilet.

cheers,
Martin


From seav80 at gmail.com  Fri Apr 20 16:29:58 2012
From: seav80 at gmail.com (Eugene Alvin Villar)
Date: Fri, 20 Apr 2012 23:29:58 +0800
Subject: [Tagging] How to tag disputed names in the same language?
Message-ID: <CAPhqi6KyBnqpdkRJssUE61vDHsLWavPheKrSS29mFeAJO377gA@mail.gmail.com>

In the proverbial case of of Northern Cyprus, disputed names are
"easy" because both sides use different languages, Greek (el) and
Turkish (tr). What if the dispute names are in the same language?

I was wondering about this because Philippines and China are currently
in a stand-off regarding an atoll in the South China Sea. The atoll is
int_name=Scarborough Shoal but in English, the Philippines calls it
Panatag Shoal and China calls it Huangyang Island. How do we tag these
two names?

One possible way is to introduce ISO country codes (in all caps) and
with a format similar to int_name::

PH_name:en=Panatag Shoal
PH_name:tl=Isla ng Panatag
CN_name:en=Huangyang Island
CN_name:zh=<I have no idea>

But a possible problem is that the country codes might be confused for
the language codes, though using all caps should mitigate the
confusion.


From dieterdreist at gmail.com  Fri Apr 20 16:47:07 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Fri, 20 Apr 2012 17:47:07 +0200
Subject: [Tagging] How to tag disputed names in the same language?
In-Reply-To: <CAPhqi6KyBnqpdkRJssUE61vDHsLWavPheKrSS29mFeAJO377gA@mail.gmail.com>
References: <CAPhqi6KyBnqpdkRJssUE61vDHsLWavPheKrSS29mFeAJO377gA@mail.gmail.com>
Message-ID: <CABPTjTADQj_ovvAjC9PukwnXwYV0gkAWYb92QBM1LVCdhoNMSQ@mail.gmail.com>

Who is in actual control of the atoll? Are there people living there?

cheers,
Martin


From Alan_Mintz+OSM at Earthlink.Net  Fri Apr 20 17:02:14 2012
From: Alan_Mintz+OSM at Earthlink.Net (Alan Mintz)
Date: Fri, 20 Apr 2012 09:02:14 -0700
Subject: [Tagging] How to tag disputed names in the same language?
In-Reply-To: <CAPhqi6KyBnqpdkRJssUE61vDHsLWavPheKrSS29mFeAJO377gA@mail.g
	mail.com>
Message-ID: <5.1.0.14.2.20120420085457.044daae0@mail.earthlink.net>

At 2012-04-20 08:29, Eugene Alvin Villar wrote:
>One possible way is to introduce ISO country codes (in all caps) and
>with a format similar to int_name::
>
>PH_name:en=Panatag Shoal

I would go with name:en-PH=* or name:en:PH=* to mimic the standard IETF 
language tag format.

--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>



From dieterdreist at gmail.com  Fri Apr 20 17:31:10 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Fri, 20 Apr 2012 18:31:10 +0200
Subject: [Tagging] demolished buildings, temporal component of data
Message-ID: <CABPTjTDanxKaR-tPr_FRKq+ff0Sg11wxdo+Bg2nW3ZVBbQwR3A@mail.gmail.com>

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 only the actual state of the DB but also
record all kinds of changes that the mappers apply, I wonder if we
shouldn't agree on some formal mechanism to distinct the changes where
the map gets updated to the real world from those where the edit is
done to correct mapping errors, to increase the level of detail or to
store them for the first time.

Since the introduction of API 0.6 we have in theory one powerful tool
where this detail can already be associated to the edit: the changeset
comments. The only missing link for effective automated evaluation
would be an agreement on a formal way of storing information there
(and quite some discipline in structuring your edits and uploads ;-)
). E.g. we could use hashtags to distinguish free text from formal
comments ( e.g. #demolishion , #new_construction ,etc)

An alternative could be, e.g. for a building that was demolished, to
explicitly "map" this. Given an object tagged with building=yes we
could change the tag to building=demolished, upload to the server, and
in a second step delete the object and upload again. The deletion and
second upload could even be automated easily in the editors, if we
could agree on something like this.

As an advantage with the second method you would not need to structure
your edits and changesets in a special way, I'd expect to get more
reliable results and less oversight with this approach.

Is someone already using a scheme for this kind of information?

cheers,
Martin


From ilpo.jarvinen at helsinki.fi  Fri Apr 20 18:07:10 2012
From: ilpo.jarvinen at helsinki.fi (=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=)
Date: Fri, 20 Apr 2012 20:07:10 +0300 (EEST)
Subject: [Tagging] demolished buildings, temporal component of data
In-Reply-To: <CABPTjTDanxKaR-tPr_FRKq+ff0Sg11wxdo+Bg2nW3ZVBbQwR3A@mail.gmail.com>
References: <CABPTjTDanxKaR-tPr_FRKq+ff0Sg11wxdo+Bg2nW3ZVBbQwR3A@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204202001390.10800@melkinpaasi.cs.helsinki.fi>

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 only the actual state of the DB but also
> record all kinds of changes that the mappers apply, I wonder if we
> shouldn't agree on some formal mechanism to distinct the changes where
> the map gets updated to the real world from those where the edit is
> done to correct mapping errors, to increase the level of detail or to
> store them for the first time.
> 
> Since the introduction of API 0.6 we have in theory one powerful tool
> where this detail can already be associated to the edit: the changeset
> comments. The only missing link for effective automated evaluation
> would be an agreement on a formal way of storing information there
> (and quite some discipline in structuring your edits and uploads ;-)
> ). E.g. we could use hashtags to distinguish free text from formal
> comments ( e.g. #demolishion , #new_construction ,etc)

Changeset comments/tags are very problematic because they're not fixable 
once you realize you made a mistake.
 
> An alternative could be, e.g. for a building that was demolished, to
> explicitly "map" this. Given an object tagged with building=yes we
> could change the tag to building=demolished, upload to the server, and
> in a second step delete the object and upload again. The deletion and
> second upload could even be automated easily in the editors, if we
> could agree on something like this.
> 
> As an advantage with the second method you would not need to structure
> your edits and changesets in a special way, I'd expect to get more
> reliable results and less oversight with this approach.
> 
> Is someone already using a scheme for this kind of information?

was: prefixes and keeping geomtery which also helps to prevent somebody 
too eager from redrawing from imagery (which ahs certainly happened 
multiple times around here). :)

-- 
 i.


From frederik at remote.org  Fri Apr 20 21:14:49 2012
From: frederik at remote.org (Frederik Ramm)
Date: Fri, 20 Apr 2012 22:14:49 +0200
Subject: [Tagging] demolished buildings, temporal component of data
In-Reply-To: <CABPTjTDanxKaR-tPr_FRKq+ff0Sg11wxdo+Bg2nW3ZVBbQwR3A@mail.gmail.com>
References: <CABPTjTDanxKaR-tPr_FRKq+ff0Sg11wxdo+Bg2nW3ZVBbQwR3A@mail.gmail.com>
Message-ID: <4F91C3B9.7060806@remote.org>

Hi,

On 04/20/2012 06:31 PM, Martin Koppenhoefer wrote:
> Since the introduction of API 0.6 we have in theory one powerful tool
> where this detail can already be associated to the edit: the changeset
> comments. The only missing link for effective automated evaluation
> would be an agreement on a formal way of storing information there

The changeset *comment* is just that, a comment that should be 
human-readable. But many people forget that changesets can have any 
number of tags, so instead of adding machine-readable hash tags into the 
comment field, just invent new tags for the changeset, e.g.

type_of_edit={initial|geometry_fix|change_in_real_world|revert|...}

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49?00'09" E008?23'33"


From neroute2 at gmail.com  Sat Apr 21 00:23:43 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Fri, 20 Apr 2012 19:23:43 -0400
Subject: [Tagging] highway=services/rest_area
In-Reply-To: <CABPTjTCp6xvYoyad9ZQG52CWRM+VHxLrkcKuADiW_YcJbyXTuQ@mail.gmail.com>
References: <4F912254.9030405@gmail.com> <4F913174.4090902@bavarianmallet.de>
	<4F913DBE.3040402@gmail.com> <1334924463.12429.5.camel@marvin>
	<CABPTjTCudZawnDKU8Zoi7v3WC0s_JQznAhLoAMb4UTJ4xh7d9Q@mail.gmail.com>
	<bb46a286-73e4-4279-b1f2-f93d0fe05ac4@email.android.com>
	<CABPTjTCp6xvYoyad9ZQG52CWRM+VHxLrkcKuADiW_YcJbyXTuQ@mail.gmail.com>
Message-ID: <4F91EFFF.90601@gmail.com>

What's the correct tag for something like this, on a surface road and 
operated by a private company (chain)?
http://www.openstreetmap.org/browse/way/99634310


From baloo at ursamundi.org  Sat Apr 21 00:30:23 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Fri, 20 Apr 2012 16:30:23 -0700
Subject: [Tagging] How to tag disputed names in the same language?
In-Reply-To: <5.1.0.14.2.20120420085457.044daae0@mail.earthlink.net>
References: <5.1.0.14.2.20120420085457.044daae0@mail.earthlink.net>
Message-ID: <CAMPM96oLsH=EroqYHXmrV7yQxEZT=SbC1PVzRTh_sotj89=00w@mail.gmail.com>

On Apr 20, 2012 9:04 AM, "Alan Mintz" <Alan_Mintz+OSM at earthlink.net> wrote:

> I would go with name:en-PH=* or name:en:PH=* to mimic the standard IETF
language tag format.

en-PH feels more correct, since it's specifying dialect in a standard
format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120420/acf9bcc9/attachment-0001.html>

From baloo at ursamundi.org  Sat Apr 21 00:30:23 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Fri, 20 Apr 2012 16:30:23 -0700
Subject: [Tagging] highway=services/rest_area
In-Reply-To: <bb46a286-73e4-4279-b1f2-f93d0fe05ac4@email.android.com>
References: <4F912254.9030405@gmail.com> <4F913174.4090902@bavarianmallet.de>
	<4F913DBE.3040402@gmail.com> <1334924463.12429.5.camel@marvin>
	<CABPTjTCudZawnDKU8Zoi7v3WC0s_JQznAhLoAMb4UTJ4xh7d9Q@mail.gmail.com>
	<bb46a286-73e4-4279-b1f2-f93d0fe05ac4@email.android.com>
Message-ID: <CAMPM96oDhd62mzGD7fEkXr525eqst=yF_oqw_vexoDL6Ub5PKg@mail.gmail.com>

On Apr 20, 2012 7:18 AM, "John F. Eldredge" <john at jfeldredge.com> wrote:

> In the USA, you have the same distinction between service areas and rest
areas.  In addition, there will sometimes be "parking areas", meaning that
there will be a parking lot but no restrooms or other amenities.
 Fortunately, "parking areas" are rare.

Oklahoma seems to use "picnic area" and "rest area" interchangeably, though
picnic areas always only have picnic tables and trash cans.  You're often
miles from a toilet (located at the next concessions plaza ("services")),
and it seems like as often as not, shade.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120420/ebdb809e/attachment.html>

From imagic.osm at gmail.com  Sat Apr 21 07:42:31 2012
From: imagic.osm at gmail.com (Martin Vonwald (Imagic))
Date: Sat, 21 Apr 2012 08:42:31 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
Message-ID: <EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>



Am 20.04.2012 um 16:58 schrieb Jason Cunningham <jamicuosm at googlemail.com>:

> On 20 April 2012 14:35, Philip Barnes <phil at trigpoint.me.uk> wrote:
> Which prompts another question, do we have a tag for a 'passing place'?
> There is a photo of one on this page
> http://en.wikipedia.org/wiki/Single-track_road
> 
> Tag info shows it does highway=passing_place does get used
> http://taginfo.openstreetmap.org/search?q=highway%3Dpassing
> And there is a page on the wiki for it.

Thanks for that. I would add a recommendation not to count such places for the lanes-count, but instead use the passing-tag. I will add a link to its article.

> 
> And here's another question.
> A twoway single lane highway implies that if you meet a vehicle coming in the other direction the road is blocked. Hence the the common of existence, at least in the UK, of 'Passing Places' mentioned by Philip.
> A twoway two lane highway implies that common road vehicles can drive down the road each within their own lane?
> But there is a third situation that in my area is arguably more common than implied single lane status, and that is a road which is wide enough for cars to pass each other at at crawl, but which would be blocked if a large vehicle meets another vehicle. This I assume is impotant information, especially for routing, because these are roads a car owner would wish to avoid if there is an alternative 'true' 2 lane road, and which a lorry or van should avoid unless they must use the road.
> 
> A while back I went through a period of trying to add lanes, speed limits, and lighting info. This was prompted by the excellent "tools" produced by ITO map eg www.itoworld.com/map/179
> While trying to sort through the confusing speed limit laws in my country, I stumbled across a document advising that roads where two cars could pass slowly or with care, but wider vehciles could not, the road should be considered to consist of  1.5 lanes. Didn't bother to save the document at the time and search engines can't track it down. Does the idea of lanes=1.5 seem acceptable for roads where cars can pass slowly, but wider vehicles will block the road. There is an obvious problem that the decision to label a road as lanes=1.5 is subjective.

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 width (which is also objective rather than subjective as 1.5 is).

Opinions?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120421/5ee28333/attachment.html>

From chaoschaos0909 at googlemail.com  Sat Apr 21 09:19:38 2012
From: chaoschaos0909 at googlemail.com (Ronnie Soak)
Date: Sat, 21 Apr 2012 10:19:38 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
Message-ID: <CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>

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 width (which is also objective rather than subjective as 1.5 is).
>

+1

The width-tag is widely used, is more general and part of the standard set
of fields for many highway-categories in JOSM and Potlatch.
It may be harder to estimate a width in meters instead of a lanes count,
but I think it's possible within +/- 1m, especially for narrow ways.
(I personally only use it with either rather narrow or rather wide ways out
of the norm.)

The lanes tag is used with integral numbers, most tools won't recognize
fractions. And even if they do, it's still highly subjective if it's
lanes=1 or lanes=1.5 or lanes=2 if there are no road markings. (If you have
to slow down to pass depends on your type of car, the road (and
weather/sight) conditions and your bravery/insanity.)

I would only use a lanes value other than 2 if there are clear road
markings, signs or it is otherwise very clear that two cars are supposed to
go in one direction at a time (>=3) or there is no way for two cars to pass
without a special (signed) passing place (1).

my two cents,

Chaos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120421/0c1ac502/attachment.html>

From chaoschaos0909 at googlemail.com  Sat Apr 21 09:25:47 2012
From: chaoschaos0909 at googlemail.com (Ronnie Soak)
Date: Sat, 21 Apr 2012 10:25:47 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
Message-ID: <CALKj2D8E5nTQB+cWf=s_4n7ja50=CSZmbb0keTrQNboWt59rmA@mail.gmail.com>

Anecdotal backstory:

I've been passed by busses in very narrow, walled streets in Cornwall at
full speed, where I thought even careful passing would not be physically
possible. (For the record: The bus drove full speed, I cowardly stopped
with my side-mirror touching the wall)

So this was clearly a lanes=2 for the bus driver, where I would have
thought about a lanes=1; width=3.

Estimations differ ...

Chaos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120421/99779cde/attachment.html>

From phil at trigpoint.me.uk  Sat Apr 21 12:23:05 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Sat, 21 Apr 2012 12:23:05 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
Message-ID: <1335007385.12429.48.camel@marvin>

On Sat, 2012-04-21 at 10:19 +0200, Ronnie Soak wrote:

> I would only use a lanes value other than 2 if there are clear road
> markings, signs or it is otherwise very clear that two cars are
> supposed to go in one direction at a time (>=3) 
I am not aware of any special signage on 3 lane roads in the UK. It is
just a knowledge of the highway code that gives you the rules.

        1. Solid double lines on your side mean do not cross, traffic in
        the opposite direction has solo use of the centre lane.
        Also broken line on your side and solid double lines on the
        other side mean your direction has exclusive use of the centre
        lane.

        2. Broken and solid line on your side, traffic in the opposite
        direction has priority use of centre lane but you can overtake
        if it is clear and nobody is signalling their intent to pull
        out. Usually uphill traffic will have priority in this case.
        
        3. Both sides have a broken line and have equal priority to use
        the centre lane to overtake. Have not seen one of these for
        years.
        
        However OSM does not allow anything other than tagging as 3
        lanes, so the above is probably irrelevant to OSM tagging.
  

> or there is no way for two cars to pass without a special (signed)
> passing place (1).
There is always a way. There are lots of single track minor roads, that
have no passing places and high hedges close to the road. Passing can
involve a long reverse and squeeze into a gateway or pull onto any bit
of grass verge that may be there.

Official passing places are also supposed to be used to allow faster
traffic to pass, a rule many city dwellers are totally unaware of, much
to the annoyance of locals. I can remember a public information film, in
the 70s http://www.youtube.com/watch?v=BQZownCGnYg

Phil




From ilpo.jarvinen at helsinki.fi  Sat Apr 21 12:34:56 2012
From: ilpo.jarvinen at helsinki.fi (=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=)
Date: Sat, 21 Apr 2012 14:34:56 +0300 (EEST)
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>

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 width (which is also objective
>       rather than subjective as 1.5 is).
>
> +1
> 
> The width-tag is widely used, is more general and part of the standard set
> of fields for many highway-categories in JOSM and Potlatch.
> It may be harder to estimate a width in meters instead of a lanes count, but
> I think it's possible within +/- 1m, especially for narrow ways.

This difficulty is very true and it disallows collecting more than few of 
them at a time since you'd have to remember/note those estimates until you 
have a computer with which you can put that into the db.

> (I personally only use it with either rather narrow or rather wide ways out
> of the norm.)
> 
> The lanes tag is used with integral numbers, most tools won't recognize
> fractions. And even if they do, it's still highly subjective if it's lanes=1
> or lanes=1.5 or lanes=2 if there are no road markings. (If you have to slow
> down to pass depends on your type of car, the road (and weather/sight)
> conditions and your bravery/insanity.)?

I'm not really convinced by the subjectivity fear in this case. It's 
always quite clear when the road is clearly wider than a single lane (and 
that is provable too in many cases as you are able to spot few cars 
passing by ;-)). And on the other end, it is not extremely hard to
estimate that it would be rather challenging to pass an incoming car 
without slowing down.

...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 saying that use lanes=1/2 alone instead I oppose.


-- 
 i.

From imagic.osm at gmail.com  Sat Apr 21 13:08:51 2012
From: imagic.osm at gmail.com (Martin Vonwald (Imagic))
Date: Sat, 21 Apr 2012 14:08:51 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
Message-ID: <BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>

Am 21.04.2012 um 13:34 schrieb "Ilpo J?rvinen" <ilpo.jarvinen at helsinki.fi>:

> ...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 saying that use lanes=1/2 alone instead I oppose.

I would recommend lanes=2 and width=xxx. Maybe give some examples for the widths of some common, "narrow" roads? Can someone provide photos and widths?

From ilpo.jarvinen at helsinki.fi  Sat Apr 21 13:23:21 2012
From: ilpo.jarvinen at helsinki.fi (=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=)
Date: Sat, 21 Apr 2012 15:23:21 +0300 (EEST)
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
Message-ID: <alpine.DEB.2.00.1204211513230.24319@melkinpaasi.cs.helsinki.fi>

On Sat, 21 Apr 2012, Martin Vonwald (Imagic) wrote:

> Am 21.04.2012 um 13:34 schrieb "Ilpo J?rvinen" <ilpo.jarvinen at helsinki.fi>:
> 
> > ...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 saying that use lanes=1/2 alone instead I oppose.
> 
> I would recommend lanes=2 and width=xxx. Maybe give some examples for 
> the widths of some common, "narrow" roads? Can someone provide photos 
> and widths?

!?! ...No! Unfortunately this was exactly what I oppose! Because:

It actually requires a) knowing/estimating and b) storing the width number 
somewhere until you can put that to the particular osm way. Both a) and b) 
make it significantly harder to collect compared with something as simple 
as lanes=1.5 which requires only 1-bit of storage in your memory.

I don't mind if we _eventually_ have width too but I think there needs to 
be some intermediate step in between those to balance ease of collecting 
and time-consuming accuracy, which is probably the reason we have 
lanes=1.5 tags in the db in the first place. ...It highlights there's 
a clear need for this kind of tradeoff (but no assigned tag for it exists 
other than reusing lanes= but that part could be IMHO easily fixed but 
that won't happen as long as width is offered as sole alternative :-().

-- 
 i.

From dieterdreist at gmail.com  Sat Apr 21 14:31:12 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sat, 21 Apr 2012 15:31:12 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <1335007385.12429.48.camel@marvin>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<1335007385.12429.48.camel@marvin>
Message-ID: <995DD1C9-8CCF-49C4-920B-9D0268B70E7A@gmail.com>





Am 21 Apr 2012 um 13:23 schrieb Philip Barnes <phil at trigpoint.me.uk>:

>   However OSM does not allow anything other than tagging as 3
>        lanes, so the above is probably irrelevant to OSM 


You can Tag lanes:forward= and lanes:backward=

Cheers,
Martin


From imagic.osm at gmail.com  Sat Apr 21 15:53:31 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Sat, 21 Apr 2012 16:53:31 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <alpine.DEB.2.00.1204211513230.24319@melkinpaasi.cs.helsinki.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<alpine.DEB.2.00.1204211513230.24319@melkinpaasi.cs.helsinki.fi>
Message-ID: <031138D3-F15B-451B-B16E-9306B2181FEF@gmail.com>

Am 21.04.2012 um 14:23 schrieb "Ilpo J?rvinen" <ilpo.jarvinen at helsinki.fi>:

>> I would recommend lanes=2 and width=xxx. Maybe give some examples for 
>> the widths of some common, "narrow" roads? Can someone provide photos 
>> and widths?
> 
> !?! ...No! Unfortunately this was exactly what I oppose!

Sorry, I misunderstood you there. Let us start again: can we at least agree, that it is the correct solution to use width=xxx, but it is difficult to obtain a correct value?
If so, how about recommending to use lanes=2 and est_width=4? Or maybe width=4 and source:width=estimated, because application support for est_width is even worse than for width?

Martin

From phil at trigpoint.me.uk  Sat Apr 21 17:08:54 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Sat, 21 Apr 2012 17:08:54 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <995DD1C9-8CCF-49C4-920B-9D0268B70E7A@gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<1335007385.12429.48.camel@marvin>
	<995DD1C9-8CCF-49C4-920B-9D0268B70E7A@gmail.com>
Message-ID: <1335024534.12429.50.camel@marvin>

On Sat, 2012-04-21 at 15:31 +0200, Martin Koppenhoefer wrote:
> 
> 
> 
> Am 21 Apr 2012 um 13:23 schrieb Philip Barnes <phil at trigpoint.me.uk>:
> 
> >   However OSM does not allow anything other than tagging as 3
> >        lanes, so the above is probably irrelevant to OSM 
> 
> 
> You can Tag lanes:forward= and lanes:backward=
Would this make sense?
Lanes=3
Lanes:forward=2
Lanes:backward=2

Phil



From phil at trigpoint.me.uk  Sat Apr 21 18:11:46 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Sat, 21 Apr 2012 18:11:46 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
Message-ID: <1335028306.12429.59.camel@marvin>

On Sat, 2012-04-21 at 14:08 +0200, Martin Vonwald (Imagic) wrote:
> Am 21.04.2012 um 13:34 schrieb "Ilpo J?rvinen" <ilpo.jarvinen at helsinki.fi>:
> 
> > ...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 saying that use lanes=1/2 alone instead I oppose.
> 
> I would recommend lanes=2 and width=xxx. Maybe give some examples for the widths of some common, "narrow" roads? Can someone provide photos and widths?

The distinction used by OS is width is more than 4m or less than 4m.

Phil



From imagic.osm at gmail.com  Sat Apr 21 19:02:14 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Sat, 21 Apr 2012 20:02:14 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <1335028306.12429.59.camel@marvin>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
Message-ID: <74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>

Am 21.04.2012 um 19:11 schrieb Philip Barnes <phil at trigpoint.me.uk>:

> The distinction used by OS is width is more than 4m or less than 4m.

And what happens if width IS 4m?


From phil at trigpoint.me.uk  Sat Apr 21 19:03:12 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Sat, 21 Apr 2012 19:03:12 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
Message-ID: <1335031392.12429.66.camel@marvin>

On Sat, 2012-04-21 at 14:08 +0200, Martin Vonwald (Imagic) wrote:
> Am 21.04.2012 um 13:34 schrieb "Ilpo J?rvinen" <ilpo.jarvinen at helsinki.fi>:
> 
> > ...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 saying that use lanes=1/2 alone instead I oppose.
> 
> I would recommend lanes=2 and width=xxx. Maybe give some examples for the widths of some common, "narrow" roads? Can someone provide photos and widths?

Without going too far from home.

This one is 4.4m
http://t.co/UcFtIpkx
http://osm.org/go/eu0E92UlP-
 
and complete with grass up the middle. This one is, I think 2.3m. Easy
to forget such things as others have said.
http://t.co/4DK09ahQ 
http://osm.org/go/eu0Fswir

Phil



From phil at trigpoint.me.uk  Sat Apr 21 19:09:43 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Sat, 21 Apr 2012 19:09:43 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
Message-ID: <1335031783.12429.70.camel@marvin>

On Sat, 2012-04-21 at 20:02 +0200, Martin Vonwald wrote:
> Am 21.04.2012 um 19:11 schrieb Philip Barnes <phil at trigpoint.me.uk>:
> 
> > The distinction used by OS is width is more than 4m or less than 4m.
> 
> And what happens if width IS 4m?
The words the use are 'generally more than 4m wide' and 'generally less
than 4m wide'. Roads of this width will vary in width, they are almost
never the same width throughout.

Phil



From baloo at ursamundi.org  Sat Apr 21 20:20:49 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Sat, 21 Apr 2012 12:20:49 -0700
Subject: [Tagging] highway=services/rest_area
In-Reply-To: <4F91EFFF.90601@gmail.com>
References: <4F912254.9030405@gmail.com> <4F913174.4090902@bavarianmallet.de>
	<4F913DBE.3040402@gmail.com> <1334924463.12429.5.camel@marvin>
	<CABPTjTCudZawnDKU8Zoi7v3WC0s_JQznAhLoAMb4UTJ4xh7d9Q@mail.gmail.com>
	<bb46a286-73e4-4279-b1f2-f93d0fe05ac4@email.android.com>
	<CABPTjTCp6xvYoyad9ZQG52CWRM+VHxLrkcKuADiW_YcJbyXTuQ@mail.gmail.com>
	<4F91EFFF.90601@gmail.com>
Message-ID: <CAMPM96qUD-Defnq+dC7_DY503GGAhMSpLpR3YFpO2Gb+hbt1HA@mail.gmail.com>

On Fri, Apr 20, 2012 at 4:23 PM, Nathan Edgars II <neroute2 at gmail.com> wrote:
> What's the correct tag for something like this, on a surface road and
> operated by a private company (chain)?
> http://www.openstreetmap.org/browse/way/99634310

I don't think there's a single tag that covers a truck stop, though I
wouldn't be opposed to highway=services for this, since they almost
always include exactly the same amenities as a concessions plaza
anyway; they're just not on public land.


From richard.mann.westoxford at gmail.com  Sat Apr 21 20:59:10 2012
From: richard.mann.westoxford at gmail.com (Richard Mann)
Date: Sat, 21 Apr 2012 20:59:10 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <1335031783.12429.70.camel@marvin>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
Message-ID: <CAMLmWVvd2QvcAar9P=s9x_-Dov-Vz3j8GoYu_HcjYqqHfU4d1g@mail.gmail.com>

If it's <4m, you will be able to see continuous wear on the verge where
people drive off the edge of the tarmac. At >4m there will only be wear for
occasional large vehicles (tractor tracks, typically). At 6m there's
usually a centre line.

I'd quite like some tags for these subtleties, but I wouldn't use the lanes
tag (so not lanes=1.5)

A few "standard" widths might not come amiss: maybe 3, 3.6, 4.2, 6?

Some of you may remember that the OS criteria used to be 14ft (4.2m).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120421/856bceff/attachment.html>

From seav80 at gmail.com  Sat Apr 21 22:24:22 2012
From: seav80 at gmail.com (Eugene Alvin Villar)
Date: Sun, 22 Apr 2012 05:24:22 +0800
Subject: [Tagging] How to tag disputed names in the same language?
In-Reply-To: <CABPTjTADQj_ovvAjC9PukwnXwYV0gkAWYb92QBM1LVCdhoNMSQ@mail.gmail.com>
References: <CAPhqi6KyBnqpdkRJssUE61vDHsLWavPheKrSS29mFeAJO377gA@mail.gmail.com>
	<CABPTjTADQj_ovvAjC9PukwnXwYV0gkAWYb92QBM1LVCdhoNMSQ@mail.gmail.com>
Message-ID: <CAPhqi6+3LDuvbS7jLKRSRwXeP3pxG+OV22v4QcwFyjz-tK-z2g@mail.gmail.com>

In my opinion, nobody is in actual control of the atoll, though both
China and the Philippines both claim that it controls it.


On Fri, Apr 20, 2012 at 11:47 PM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
> Who is in actual control of the atoll? Are there people living there?
>
> cheers,
> Martin
>


From seav80 at gmail.com  Sat Apr 21 22:28:54 2012
From: seav80 at gmail.com (Eugene Alvin Villar)
Date: Sun, 22 Apr 2012 05:28:54 +0800
Subject: [Tagging] How to tag disputed names in the same language?
In-Reply-To: <CAMPM96oLsH=EroqYHXmrV7yQxEZT=SbC1PVzRTh_sotj89=00w@mail.gmail.com>
References: <5.1.0.14.2.20120420085457.044daae0@mail.earthlink.net>
	<CAMPM96oLsH=EroqYHXmrV7yQxEZT=SbC1PVzRTh_sotj89=00w@mail.gmail.com>
Message-ID: <CAPhqi6JaWqRCQCxuREdcF1pOUmqkz-HjJag2vuk8v=id9GC23g@mail.gmail.com>

On Sat, Apr 21, 2012 at 7:30 AM, Paul Johnson <baloo at ursamundi.org> wrote:
>
> On Apr 20, 2012 9:04 AM, "Alan Mintz" <Alan_Mintz+OSM at earthlink.net> wrote:
>
>> I would go with name:en-PH=* or name:en:PH=* to mimic the standard IETF
>> language tag format.
>
> en-PH feels more correct, since it's specifying dialect in a standard
> format.

This seems workable. But I don't think that these differing names that
are proper nouns can be considered as a difference in dialect.


From janjko at gmail.com  Sun Apr 22 00:52:06 2012
From: janjko at gmail.com (=?UTF-8?Q?Janko_Miheli=C4=87?=)
Date: Sat, 21 Apr 2012 23:52:06 +0000
Subject: [Tagging] School tag
Message-ID: <CAA=vpS8bXr3czomvp9gcrW3ZFkPRpgzFGHCB61J5=dnwxvSGdw@mail.gmail.com>

Right now we have
amenity=school<http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dschool>,
amenity=college <http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcollege>and
amenity=university<http://wiki.openstreetmap.org/wiki/Tag:amenity%3Duniversity>.
Then we have isced:xxx=value
<http://wiki.openstreetmap.org/wiki/Key:isced>for determining the
level of a school by the International Standard
Classification of Education.


What about the general subject of a school? There are music schools, law
schools, medicine schools, and so on. I would describe them in a tag *
school=**. So we would have school=music, school=law etc..
Primary and middle schools that have no specific subject could be
school=general.

A university is mapped with a polygon that has amenity=university, but
individual buildings could have school tags, like school=law or
school=economics.

This could also be used with:

   - driving schools (amenity=school + school=driving instead of
   amenity=driving_school)
   - foreign language schools (amenity=school + school=language +
   language=en;fr;de)
   - pottery workshops (amenity=school + school=pottery)
   - karate schools (amenity=school + school=sport + sport=karate)


There are a lot of possible values for this tag, some of them are:

Agriculture, Architecture, Biology, Chemistry, Design, Driving, Economics,
Electronics, Geodesy, Geography, Geology, Language, Law, Mathematics,
Medicine, Music, Painting, Physics, Sport, etc..

Thanks for your opinions,

Janko Miheli?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120421/0a276dec/attachment.html>

From pvm at isnet.ru  Sun Apr 22 05:17:50 2012
From: pvm at isnet.ru (=?KOI8-R?B?98zBxMnNydIg8M/L18HMydTP1w==?=)
Date: Sun, 22 Apr 2012 10:17:50 +0600
Subject: [Tagging] School tag
In-Reply-To: <CAA=vpS8bXr3czomvp9gcrW3ZFkPRpgzFGHCB61J5=dnwxvSGdw@mail.gmail.com>
References: <CAA=vpS8bXr3czomvp9gcrW3ZFkPRpgzFGHCB61J5=dnwxvSGdw@mail.gmail.com>
Message-ID: <CAOnh4TxhwGEw1XErFxyh7YuD0MFurx4__GiVdNTJZFCFMTnqBg@mail.gmail.com>

> This could also be used with:
>
> driving schools (amenity=school + school=driving instead of
> amenity=driving_school)
> foreign language schools (amenity=school + school=language +
> language=en;fr;de)
> pottery workshops (amenity=school + school=pottery)
> karate schools (amenity=school + school=sport + sport=karate)

I think we shouldn't mix general education institutions with hobby
skill trainings and short-term professional trainings.

I would leave amenity=school for general education secondary schools
only. And introduce the new tag "amenity=training" for driving
schools, dance schools, sport schools, sysadmin or Cisco courses.

Or make the new high-level tag "education=*" and put there all the
tags about education: education=school, education=university,
education=college, education=training.

In any way of tagging general education and skill training must be put
in different tag values.


From baloo at ursamundi.org  Sun Apr 22 07:36:30 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Sat, 21 Apr 2012 23:36:30 -0700
Subject: [Tagging] How to tag disputed names in the same language?
In-Reply-To: <CAPhqi6JaWqRCQCxuREdcF1pOUmqkz-HjJag2vuk8v=id9GC23g@mail.gmail.com>
References: <5.1.0.14.2.20120420085457.044daae0@mail.earthlink.net>
	<CAMPM96oLsH=EroqYHXmrV7yQxEZT=SbC1PVzRTh_sotj89=00w@mail.gmail.com>
	<CAPhqi6JaWqRCQCxuREdcF1pOUmqkz-HjJag2vuk8v=id9GC23g@mail.gmail.com>
Message-ID: <CAMPM96pcANp6T5hvcnhPbk_F5QabpKCuRJuYXcUoL2TQVVFMyQ@mail.gmail.com>

On Apr 21, 2012 2:29 PM, "Eugene Alvin Villar" <seav80 at gmail.com> wrote:
>
> On Sat, Apr 21, 2012 at 7:30 AM, Paul Johnson <baloo at ursamundi.org> wrote:
> >
> > On Apr 20, 2012 9:04 AM, "Alan Mintz" <Alan_Mintz+OSM at earthlink.net>
wrote:
> >
> >> I would go with name:en-PH=* or name:en:PH=* to mimic the standard IETF
> >> language tag format.
> >
> > en-PH feels more correct, since it's specifying dialect in a standard
> > format.
>
> This seems workable. But I don't think that these differing names that
> are proper nouns can be considered as a difference in dialect.

Well, dialect in the sense that the two countries call the same thing by
two differing names in the same language.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120421/fbdbef89/attachment-0001.html>

From dieterdreist at gmail.com  Sun Apr 22 07:46:35 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sun, 22 Apr 2012 08:46:35 +0200
Subject: [Tagging] School tag
In-Reply-To: <CAOnh4TxhwGEw1XErFxyh7YuD0MFurx4__GiVdNTJZFCFMTnqBg@mail.gmail.com>
References: <CAA=vpS8bXr3czomvp9gcrW3ZFkPRpgzFGHCB61J5=dnwxvSGdw@mail.gmail.com>
	<CAOnh4TxhwGEw1XErFxyh7YuD0MFurx4__GiVdNTJZFCFMTnqBg@mail.gmail.com>
Message-ID: <3A0E99E4-78D5-480C-B66C-055C614BC5A2@gmail.com>





Am 22 Apr 2012 um 06:17 schrieb ???????? ?????????? <pvm at isnet.ru>:

>> This could also be used with:
>> 
>> driving schools (amenity=school + school=driving instead of
>> amenity=driving_school)
>> foreign language schools (amenity=school + school=language +
>> language=en;fr;de)
>> pottery workshops (amenity=school + school=pottery)
>> karate schools (amenity=school + school=sport + sport=karate)
> 
> I think we shouldn't mix general education institutions with hobby
> skill trainings and short-term professional trainings.


+1, don't use amenity=school for the latter.

Cheers, 
Martin



From imagic.osm at gmail.com  Sun Apr 22 08:32:28 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Sun, 22 Apr 2012 09:32:28 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <1335024534.12429.50.camel@marvin>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<1335007385.12429.48.camel@marvin>
	<995DD1C9-8CCF-49C4-920B-9D0268B70E7A@gmail.com>
	<1335024534.12429.50.camel@marvin>
Message-ID: <CAKjckyOF3yCahrqNRcNdgkSNu8g0O8ZoNiRj0B7PM7zBxbm2Ng@mail.gmail.com>

2012/4/21 Philip Barnes <phil at trigpoint.me.uk>:
>> You can Tag lanes:forward= and lanes:backward=
> Would this make sense?
> Lanes=3
> Lanes:forward=2
> Lanes:backward=2

No, it wouldn't. This was one of the reasons, why I suggested an
additional suffix "both-ways" in the original version of the lanes
proposal (see [1]). With this suffix you would tag this as follow:
  lanes=3
  lanes:forward=1
  lanes:backward=1
  lanes:both_ways=1

What you are now missing is the information, what exactly can be done
on the both_ways-lane: is it a passing, median or reversible lane?
Originally I suggested an additional tag "reversible" for this.  But
this was ambiguous so when I wrote a proposal for this I changed the
tag to "two_way_lane" (see [2]). Then you could either use the lanes
suffix or the both_ways suffix to specify the kind of lane. Using the
both_ways suffix we would add the following to the aforementioned
tags:
  two_way_lane:both_ways=passing

Now it is defined, that the lane in the middle is a passing lane. But
there are two reasons, why I think, that two_way_lane is not a good
solution:
1) "two_way_lane:both_ways" is awful and two_way_lane makes only sense
with both_ways, but not with forward or backward.
2) A more generic tag could be better readable and at the same time
provide more information with amore compact style.

So I am thinking of renaming two_way_lane to lane_kind. This tag then
should specify the kind of lane, e.g. passing, reversible, median but
also directional for "normal" lanes, and some more. If we have a road
with four lanes and two of them are reversibles, we would tag them as
follows:
  lanes=4
  lanes:forward=1
  lanes:backward=1
  lanes:both_ways=2
  lanes_kind:both_ways=reversible

We would need the tags with the lanes suffix then only in such cases,
where we really need the layout of the lanes, e.g. on junctions. In
this context the values of lane_kind for "normal" lanes then would be
helpful.


But this all is off-topic right now: for the lanes article I will add
a statement, that this issue is currently unresolved.

Martin


[1] http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension/ProposalPreVoting#Center.2Fmedian_turn_lanes
[2] http://wiki.openstreetmap.org/wiki/Proposed_features/two_way_lane


From imagic.osm at gmail.com  Sun Apr 22 08:37:55 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Sun, 22 Apr 2012 09:37:55 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <1335031392.12429.66.camel@marvin>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335031392.12429.66.camel@marvin>
Message-ID: <CAKjckyMgTx_F13icrLDHfTWhnKDNn1mgk0SYNDXxv1+t+RnzUA@mail.gmail.com>

> This one is 4.4m
> http://t.co/UcFtIpkx
> http://osm.org/go/eu0E92UlP-

I would tag this as lanes=2, width=4.4 and if necessary
source:width=estimated  (or est_width=4.4).

> This one is, I think 2.3m. Easy
> to forget such things as others have said.
> http://t.co/4DK09ahQ
> http://osm.org/go/eu0Fswir

I would tag this as lanes=1.

Martin


From imagic.osm at gmail.com  Sun Apr 22 08:41:27 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Sun, 22 Apr 2012 09:41:27 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <1335031783.12429.70.camel@marvin>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
Message-ID: <CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>

2012/4/21 Philip Barnes <phil at trigpoint.me.uk>:
> The words the use are 'generally more than 4m wide' and 'generally less
> than 4m wide'. Roads of this width will vary in width, they are almost
> never the same width throughout.

Can we agree on that for narrow roads, where one can not determine the
width exactly we would recommend:
  lanes=2
  width=4
  source:width=estimated
or
  lanes=2
  est_width=4

Or any better estimation of the width.

Martin


From Alan_Mintz+OSM at Earthlink.Net  Sun Apr 22 12:31:18 2012
From: Alan_Mintz+OSM at Earthlink.Net (Alan Mintz)
Date: Sun, 22 Apr 2012 04:31:18 -0700
Subject: [Tagging] How to tag disputed names in the same language?
In-Reply-To: <CAMPM96pcANp6T5hvcnhPbk_F5QabpKCuRJuYXcUoL2TQVVFMyQ@mail.g
	mail.com>
References: <CAPhqi6JaWqRCQCxuREdcF1pOUmqkz-HjJag2vuk8v=id9GC23g@mail.gmail.com>
	<5.1.0.14.2.20120420085457.044daae0@mail.earthlink.net>
	<CAMPM96oLsH=EroqYHXmrV7yQxEZT=SbC1PVzRTh_sotj89=00w@mail.gmail.com>
	<CAPhqi6JaWqRCQCxuREdcF1pOUmqkz-HjJag2vuk8v=id9GC23g@mail.gmail.com>
Message-ID: <5.1.0.14.2.20120422041651.045624d0@mail.earthlink.net>

An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120422/d4711ab7/attachment.html>

From jamicuosm at googlemail.com  Sun Apr 22 15:43:00 2012
From: jamicuosm at googlemail.com (Jason Cunningham)
Date: Sun, 22 Apr 2012 15:43:00 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
Message-ID: <CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>

On 22 April 2012 08:41, Martin Vonwald <imagic.osm at gmail.com> wrote:

> Can we agree on that for narrow roads, where one can not determine the
> width exactly we would recommend:
>  lanes=2
>  width=4
>  source:width=estimated
> or
>  lanes=2
>  est_width=4
>

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 figure of 4m for two lanes makes sense.

But saloon cars are no longer the 'standard' car, in the uk they've more or
less been replaced by hatchbacks & 4x4's. If we look at best selling cars
in the UK (and I assume Europe) we have to assume car widths (with mirrors)
are now just over 2m, which I'd round up to 2.1m. Therefore I believe a
road with a width of 4m should be mapped as a single lane. I'd argue you'd
need at least 4.3m before a road could now be considered narrow, or car
only, 2 lanes. Though I'd think a road 4.3m wide would fall under the
'lanes=1.5' idea

Following image was taken from a uk guidance document, although as I've
said above it appears to rely on the now incorrect idea that car widths can
be assumed to be 1.8m. I think it's good advice if you add on 0.2m for each
car lane.
http://bit.ly/IkVv9B

Realising this is a far more complex issue that I first thought. Personally
I don't I'll be adding widths. I'll simply add the lanes based on what
seems obvious to me.
After reading through these emails I'm beginning to think the lanes=1.5
would less confusing for narrow two lane roads.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120422/8daee247/attachment.html>

From imagic.osm at gmail.com  Sun Apr 22 19:57:31 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Sun, 22 Apr 2012 20:57:31 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
Message-ID: <CAKjckyNsgEb9oF+qwFPAgKb+6pfKFTVmeHM=6UEwyiKU0Z4M8w@mail.gmail.com>

2012/4/22 Jason Cunningham <jamicuosm at googlemail.com>:
> After reading through these emails I'm beginning to think the lanes=1.5
> would less confusing for narrow two lane roads.

The problem with lanes=1.5 stays: data consumers might not be able to
handle this correctly.

What we need right now is a recommendation how to handle this "narrow
road"-problem, without using a tag, that might cause more problems
than it solves. What is the problem with the following:
__________
If a two-way road is so narrow, that passing cars have to slow down,
then besides lanes=2 either 1) measure the width and set the tag
accordingly (preferable, but usually much too difficult) or 2) simply
use est_width=4 (or width together with source:width).
__________

Instead of one problematic tag (lanes=1.5) we would use well established tags.

Martin


From osm-martinq at fantasymail.de  Sun Apr 22 20:03:19 2012
From: osm-martinq at fantasymail.de (martinq)
Date: Sun, 22 Apr 2012 21:03:19 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
Message-ID: <4F9455F7.2090107@fantasymail.de>

> 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 figure of 4m for two lanes
> makes sense.

I am not sure we should base the lanes tag value on typical car width.
IMO the lanes tag should *not* be another kind of estimate for the width.

A further problem is the definition: For example the "euro track" has a 
maximum allowed width of 2.55m without mirrors (refrigerated ones even 
2.60m). This would be as fair as basis as a "average" car in UK or a UK 
guide. And in US or India we may find another situation again.

My opinion:
If the width of the road can be estimated and no lanes are marked: We 
should tag the width (of the carriageway(*)) only (or est_width or 
width+source:width) and no lanes tag.
(*) Sadly the width itself is pretty ambiguous tag at the moment (e.g. 
is it the width of the complete street or just the carriageway, etc.). 
But this is a topic for its own.

When you look at following example:
http://wiki.openstreetmap.org/wiki/File:Bangalore_India_traffic.jpg
then I conclude: If there are no marked lanes, it lanes gets simply too 
subjective.

My current practice:
On non-residential areas (tertiary, etc.) I typically tag lanes=2 only 
if the road allows *two* trucks (that don't require police escort 
because they are wider than allowed, means >2.6m) to pass. In my area 
this means >5.2m.

In residential areas/streets I omit lanes if they are not marked. 
Parking allowance and parking cars on the street/carriageway make the 
situation very complicated. Look here:

http://bit.ly/I2hna7
While the carriageway in this example is more than 6m wide and allows 
two trucks to pass, you also see parking cars in this street (I don't 
know the German law, but they might be allowed to do that). What would 
you do now? And if the parking allowance is time limited? For me lanes 
is simply not applicable here.
--> I would tag the parking information with parking:lane, width, but 
not lanes.

What I also propose: If lanes are marked, but narrow for trucks (e.g. 
just 2m each), I would tag them width:lanes=2.0|2.0 now. If there is a 
dedicated maximum width road sign --> maxwidth.

> Though I'd think a road 4.3m wide would
> fall under the 'lanes=1.5' idea
[...]
> After reading through these emails I'm beginning to think the
> lanes=1.5 would less confusing for narrow two lane roads.

-1

1.5 makes no sense. If we can agree that a lane is a "strip, which is 
wide enough for one moving line of motor vehicles other than motor 
cycles" (from the Vienna Convention of Road Signs, used as basis for 
local law in many countries all over the world) -- then either one line 
of vehicles can move -- or two.

--> For me this lanes=1.5 is a clear indication for an attempt to turn 
the lanes tag into a rough width-estimate. I think the width tag is the 
better tag for width-estimates.

martinq


From a.errington at lancaster.ac.uk  Mon Apr 23 00:51:55 2012
From: a.errington at lancaster.ac.uk (Andrew Errington)
Date: Mon, 23 Apr 2012 08:51:55 +0900 (KST)
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyNsgEb9oF+qwFPAgKb+6pfKFTVmeHM=6UEwyiKU0Z4M8w@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
	<CAKjckyNsgEb9oF+qwFPAgKb+6pfKFTVmeHM=6UEwyiKU0Z4M8w@mail.gmail.com>
Message-ID: <22232.125.248.153.122.1335138715.squirrel@webmail01.lancs.ac.uk>

On Mon, April 23, 2012 03:57, Martin Vonwald wrote:
> 2012/4/22 Jason Cunningham <jamicuosm at googlemail.com>:
>
>> After reading through these emails I'm beginning to think the lanes=1.5
>>  would less confusing for narrow two lane roads.
>
> The problem with lanes=1.5 stays: data consumers might not be able to
> handle this correctly.
>
> What we need right now is a recommendation how to handle this "narrow
> road"-problem, without using a tag, that might cause more problems than it
> solves. What is the problem with the following: __________
> If a two-way road is so narrow, that passing cars have to slow down,
> then besides lanes=2 either 1) measure the width and set the tag
> accordingly (preferable, but usually much too difficult) or 2) simply use
> est_width=4 (or width together with source:width). __________
>
>
> Instead of one problematic tag (lanes=1.5) we would use well established
> tags.


I agree.

I think lanes=* should record the total number of marked lanes (i.e. road
markings must be present to indicate the lanes).  lanes=1.5 is subjective,
and anything subjective should be avoided.  Instead, record width=*
(estimated or actual) then the onus of interpretation falls on the user,
not the mapper.

Best wishes,

Andrew




From john at jfeldredge.com  Mon Apr 23 01:16:45 2012
From: john at jfeldredge.com (John F. Eldredge)
Date: Sun, 22 Apr 2012 19:16:45 -0500
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <22232.125.248.153.122.1335138715.squirrel@webmail01.lancs.ac.uk>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
	<CAKjckyNsgEb9oF+qwFPAgKb+6pfKFTVmeHM=6UEwyiKU0Z4M8w@mail.gmail.com>
	<22232.125.248.153.122.1335138715.squirrel@webmail01.lancs.ac.uk>
Message-ID: <e4e24c1d-5ae8-495e-b558-0ba031547fdc@email.android.com>

Andrew Errington <a.errington at lancaster.ac.uk> wrote:

> On Mon, April 23, 2012 03:57, Martin Vonwald wrote:
> > 2012/4/22 Jason Cunningham <jamicuosm at googlemail.com>:
> >
> >> After reading through these emails I'm beginning to think the
> lanes=1.5
> >>  would less confusing for narrow two lane roads.
> >
> > The problem with lanes=1.5 stays: data consumers might not be able
> to
> > handle this correctly.
> >
> > What we need right now is a recommendation how to handle this
> "narrow
> > road"-problem, without using a tag, that might cause more problems
> than it
> > solves. What is the problem with the following: __________
> > If a two-way road is so narrow, that passing cars have to slow down,
> > then besides lanes=2 either 1) measure the width and set the tag
> > accordingly (preferable, but usually much too difficult) or 2)
> simply use
> > est_width=4 (or width together with source:width). __________
> >
> >
> > Instead of one problematic tag (lanes=1.5) we would use well
> established
> > tags.
> 
> 
> I agree.
> 
> I think lanes=* should record the total number of marked lanes (i.e.
> road
> markings must be present to indicate the lanes).  lanes=1.5 is
> subjective,
> and anything subjective should be avoided.  Instead, record width=*
> (estimated or actual) then the onus of interpretation falls on the
> user,
> not the mapper.
> 
> Best wishes,
> 
> Andrew
> 

I agree that having the actual width helps.  I once encountered a country road that had a center line painted, so that, officially, it was two lanes wide.  Unfortunately, the total road width was only about three meters, so only bicycles or motorcycles would have been able to use it in both directions simultaneously.  For anything four-wheeled, it was only one lane wide.

-- 
John F. Eldredge --  john at jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria


From imagic.osm at gmail.com  Mon Apr 23 09:35:57 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Mon, 23 Apr 2012 10:35:57 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <4F9455F7.2090107@fantasymail.de>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
	<4F9455F7.2090107@fantasymail.de>
Message-ID: <CAKjckyMOO5UD0F8+F4qW8ZEz712HL5biOe2+Am=2V1ypKneZtg@mail.gmail.com>

Very good thoughts and examples - thanks for that.

I fully support you, that the lanes tag should not be another
estimation of width. I also agree, that we should not tag lanes, when
they are not obvious in some way.

Regarding the example with the parked cars: I think this case should
be handled by the parking-tags. If we start to reason "ok, there are
two lanes, but as cars are parking here, I dont tag this" it's getting
more complicated than necessary. I always recommend "clean" tags:
"lanes" count the lanes. End of story. Otherwise we put more meaning
in the value as there should be and just like it is right now with
lanes=1.5 (-> "there are two lanes, but they are narrow so I don't tag
this").

Regarding width:lanes=2.0|2.0 . I don't agree. If the width is
evenly(!) distributed over the existing lanes, don't use the lanes
suffix, simply tag: lanes=2 and width=4. But if the width is NOT
evenly distributed, one has to use the lanes suffix, so
width:lanes=2.0|2.75 should never-ever be tagged (only) as width=4.75.

One last question: what would you recommend for estimations of the
width? width=x together with source:width=estimated or only est_width?

Martin


2012/4/22 martinq <osm-martinq at fantasymail.de>:
>> 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 figure of 4m for two lanes
>> makes sense.
>
>
> I am not sure we should base the lanes tag value on typical car width.
> IMO the lanes tag should *not* be another kind of estimate for the width.
>
> A further problem is the definition: For example the "euro track" has a
> maximum allowed width of 2.55m without mirrors (refrigerated ones even
> 2.60m). This would be as fair as basis as a "average" car in UK or a UK
> guide. And in US or India we may find another situation again.
>
> My opinion:
> If the width of the road can be estimated and no lanes are marked: We should
> tag the width (of the carriageway(*)) only (or est_width or
> width+source:width) and no lanes tag.
> (*) Sadly the width itself is pretty ambiguous tag at the moment (e.g. is it
> the width of the complete street or just the carriageway, etc.). But this is
> a topic for its own.
>
> When you look at following example:
> http://wiki.openstreetmap.org/wiki/File:Bangalore_India_traffic.jpg
> then I conclude: If there are no marked lanes, it lanes gets simply too
> subjective.
>
> My current practice:
> On non-residential areas (tertiary, etc.) I typically tag lanes=2 only if
> the road allows *two* trucks (that don't require police escort because they
> are wider than allowed, means >2.6m) to pass. In my area this means >5.2m.
>
> In residential areas/streets I omit lanes if they are not marked. Parking
> allowance and parking cars on the street/carriageway make the situation very
> complicated. Look here:
>
> http://bit.ly/I2hna7
> While the carriageway in this example is more than 6m wide and allows two
> trucks to pass, you also see parking cars in this street (I don't know the
> German law, but they might be allowed to do that). What would you do now?
> And if the parking allowance is time limited? For me lanes is simply not
> applicable here.
> --> I would tag the parking information with parking:lane, width, but not
> lanes.
>
> What I also propose: If lanes are marked, but narrow for trucks (e.g. just
> 2m each), I would tag them width:lanes=2.0|2.0 now. If there is a dedicated
> maximum width road sign --> maxwidth.
>
>
>> Though I'd think a road 4.3m wide would
>> fall under the 'lanes=1.5' idea
>
> [...]
>
>> After reading through these emails I'm beginning to think the
>> lanes=1.5 would less confusing for narrow two lane roads.
>
>
> -1
>
> 1.5 makes no sense. If we can agree that a lane is a "strip, which is wide
> enough for one moving line of motor vehicles other than motor cycles" (from
> the Vienna Convention of Road Signs, used as basis for local law in many
> countries all over the world) -- then either one line of vehicles can move
> -- or two.
>
> --> For me this lanes=1.5 is a clear indication for an attempt to turn the
> lanes tag into a rough width-estimate. I think the width tag is the better
> tag for width-estimates.
>
> martinq
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging


From imagic.osm at gmail.com  Mon Apr 23 10:28:41 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Mon, 23 Apr 2012 11:28:41 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
Message-ID: <CAKjckyN6zpQYGpZUt=-usoO3bLQvxS4f7RC=XbEpKzjpE=ekog@mail.gmail.com>

2012/4/22 Jason Cunningham <jamicuosm at googlemail.com>:
> Following image was taken from a uk guidance document, although as I've said
> above it appears to rely on the now incorrect idea that car widths can be
> assumed to be 1.8m. I think it's good advice if you add on 0.2m for each car
> lane.
> http://bit.ly/IkVv9B

What is the license of this image? Can it be used in the wiki?


From imagic.osm at gmail.com  Mon Apr 23 10:31:16 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Mon, 23 Apr 2012 11:31:16 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <1335031392.12429.66.camel@marvin>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335031392.12429.66.camel@marvin>
Message-ID: <CAKjckyMza9zmDZ2e7bvJH+_sVhgx2G+FkpoLKQk2cDTwkpHQ+g@mail.gmail.com>

> Without going too far from home.
>
> This one is 4.4m
> http://t.co/UcFtIpkx
> http://osm.org/go/eu0E92UlP-
>
> and complete with grass up the middle. This one is, I think 2.3m. Easy
> to forget such things as others have said.
> http://t.co/4DK09ahQ
> http://osm.org/go/eu0Fswir

Can those photographs be used in the wiki? License?


From dieterdreist at gmail.com  Mon Apr 23 12:05:46 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Mon, 23 Apr 2012 13:05:46 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
Message-ID: <CABPTjTAuUP=Vm5VgRcOAn3DF4o=qtVby=E7rxQ6NZR69tmLt1w@mail.gmail.com>

Am 22. April 2012 16:43 schrieb Jason Cunningham <jamicuosm at googlemail.com>:
> 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 figure of 4m for two lanes makes sense.
>
> But saloon cars are no longer the 'standard' car, in the uk they've more or
> less been replaced by hatchbacks & 4x4's. If we look at best selling cars in
> the UK (and I assume Europe) we have to assume car widths (with mirrors) are
> now just over 2m, which I'd round up to 2.1m.


-1, fortunately this isn't true and cars are usually not larger then
1.8 metres, actually the best selling cars are usually smaller than
that. E.g. have a look here (I didn't check it extensively, but I
guess it is true):
http://en.wikipedia.org/wiki/User:DeLarge/Top_10_best_selling_cars_in_Britain

Anyways, I think researching the average car width shouldn't be
required for mapping lanes.


> assumed to be 1.8m. I think it's good advice if you add on 0.2m for each car
> lane.


-1, doubt it.


> Realising this is a far more complex issue that I first thought. Personally
> I don't I'll be adding widths.


that's a pity, because this seems to be the only (or at least the
easiest) way to have objective data on this, as nobody will know what
you did assume for the average car width when you tagged lanes=1.78

cheers,
Martin


From ohrosm at googlemail.com  Mon Apr 23 12:23:58 2012
From: ohrosm at googlemail.com (=?ISO-8859-1?Q?Michael_Kr=E4mer?=)
Date: Mon, 23 Apr 2012 13:23:58 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CABPTjTAuUP=Vm5VgRcOAn3DF4o=qtVby=E7rxQ6NZR69tmLt1w@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
	<CABPTjTAuUP=Vm5VgRcOAn3DF4o=qtVby=E7rxQ6NZR69tmLt1w@mail.gmail.com>
Message-ID: <CADuOafXLODESp3C3L564vyEJ9hSC9U5prHdde_dtf+3iN_Fqzw@mail.gmail.com>

Am 23. April 2012 13:05 schrieb Martin Koppenhoefer <dieterdreist at gmail.com>
:

> Am 22. April 2012 16:43 schrieb Jason Cunningham <jamicuosm at googlemail.com
> >:
> > But saloon cars are no longer the 'standard' car, in the uk they've more
> or
> > less been replaced by hatchbacks & 4x4's. If we look at best selling
> cars in
> > the UK (and I assume Europe) we have to assume car widths (with mirrors)
> are
> > now just over 2m, which I'd round up to 2.1m.
>
>
> -1, fortunately this isn't true and cars are usually not larger then
> 1.8 metres, actually the best selling cars are usually smaller than
> that. E.g. have a look here (I didn't check it extensively, but I
> guess it is true):
>
> http://en.wikipedia.org/wiki/User:DeLarge/Top_10_best_selling_cars_in_Britain
>

Well, I think quite a number of those are more than 2 m wide. I also didn't
check extensively, but I am quite sure that the widths given in Wikipedia
are usually *without* mirrors.

Not to long ago there has been some amount of news coverage in Germany
about cars being wider than 2 m including mirrors and for this reason not
being allowed on the fast lane in many highway construction zones. A famous
example is the current Golf with approx. 2.05 m. So I would also assume car
widths above 2 m as a rule of thumb.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120423/c737972a/attachment.html>

From ilpo.jarvinen at helsinki.fi  Mon Apr 23 12:31:57 2012
From: ilpo.jarvinen at helsinki.fi (=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=)
Date: Mon, 23 Apr 2012 14:31:57 +0300 (EEST)
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <4F9455F7.2090107@fantasymail.de>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
	<4F9455F7.2090107@fantasymail.de>
Message-ID: <alpine.DEB.2.00.1204231338320.735@wel-95.cs.helsinki.fi>

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 figure of 4m for two lanes
> > makes sense.
> 
> I am not sure we should base the lanes tag value on typical car width.
> IMO the lanes tag should *not* be another kind of estimate for the width.

However, trying to decouple lanes fully from width also decouples you from 
reality where they are in some kind of relation (albeit somewhat loose 
one here and there).

> A further problem is the definition: For example the "euro track" has a
> maximum allowed width of 2.55m without mirrors (refrigerated ones even 2.60m).
> This would be as fair as basis as a "average" car in UK or a UK guide. And in
> US or India we may find another situation again.

...There's one law detail here somewhat interesting in this context. It's 
illegal to park/stop here when there's yellow don't-cross-line and you'd 
block the available room so so that less than 3m remains available 
(IMHO it's not far that this 3m width could be thought to be kind of 
minimum "lane" width which is not, at least directly, bound to anything in 
the realms of "typical/maximum allowed width").

> In residential areas/streets I omit lanes if they are not marked. Parking
> allowance and parking cars on the street/carriageway make the situation very
> complicated. Look here:
> 
> http://bit.ly/I2hna7
> While the carriageway in this example is more than 6m wide and allows two
> trucks to pass, you also see parking cars in this street (I don't know the
> German law, but they might be allowed to do that). What would you do now? And
> if the parking allowance is time limited? For me lanes is simply not
> applicable here.
>
> --> I would tag the parking information with parking:lane, width, but not
> lanes.

But then it would well be possible to have even the lanes=2 marked for 
that street (at least around here), so essentially one of the marked 
lanes would be quite much blocked by the legal parking (it would be 
illegal to park on both sides so close to each other that the others 
could not get through anymore).

--> so I don't see how it would be any less problem by not applying lanes 
at all if parking is allowed but on the same time marking lanes only if 
marked to the street because both would be true!?!

In general I agree with you here though that the parking makes it 
much more complicated.

> > After reading through these emails I'm beginning to think the
> > lanes=1.5 would less confusing for narrow two lane roads.
> 
> -1
> 
> 1.5 makes no sense. If we can agree that a lane is a "strip, which is wide
> enough for one moving line of motor vehicles other than motor cycles" (from
> the Vienna Convention of Road Signs, used as basis for local law in many
> countries all over the world) -- then either one line of vehicles can move --
> or two.

"wide enough", isn't that about the same as "has enough width"?

> --> For me this lanes=1.5 is a clear indication for an attempt to turn the
> lanes tag into a rough width-estimate. I think the width tag is the better
> tag for width-estimates.

No, I don't agree it's a width estimate. ...I think it's more an attempt 
to put something more meaningful to the lanes tag than 1 or 2. That is, 
clearly such street is not plain lanes=1 because it's possible to traffic 
both directions at the same time, nor is it lanes=2 in the sense that you 
cannot just pass incoming car without interference like you could on "a 
real lanes=2" road (or at least most people wouldn't, it's legal though 
up to maxspeed like it would be to pass a traffic_calming=choker too but 
usually people won't try that :-)).


-- 
 i.


From imagic.osm at gmail.com  Mon Apr 23 12:45:29 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Mon, 23 Apr 2012 13:45:29 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CADuOafXLODESp3C3L564vyEJ9hSC9U5prHdde_dtf+3iN_Fqzw@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
	<CABPTjTAuUP=Vm5VgRcOAn3DF4o=qtVby=E7rxQ6NZR69tmLt1w@mail.gmail.com>
	<CADuOafXLODESp3C3L564vyEJ9hSC9U5prHdde_dtf+3iN_Fqzw@mail.gmail.com>
Message-ID: <CAKjckyNMaq_35iUEHeTxNLxthY98=QDrnB+hF5--NdvsE==NYg@mail.gmail.com>

> On April 23rd 2012 13:05 many people wrote
> .... something about car width .....

The only reason we started discussing about the width of vehicles was
a recommendation for "narrow roads with two lanes" to replace the
lanes=1.5: if someone can not or does not want to measure the width of
the road, we need some recommend value for est_width. If we agree on,
that most cars have a width of something around 2 meters, a good value
for the estimated(!) width of "a road with two lanes, which is so
narrow, that vehicles most slow down to pass each other" is about 4
meters - therefore the recommendation to use est_width=4.

Is everyone fine with that?

I would also like to get some more opinions on either 1) est_width or
2) width and source:width=estimated should be used.

Martin


From dieterdreist at gmail.com  Mon Apr 23 12:51:55 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Mon, 23 Apr 2012 13:51:55 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyNMaq_35iUEHeTxNLxthY98=QDrnB+hF5--NdvsE==NYg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
	<CABPTjTAuUP=Vm5VgRcOAn3DF4o=qtVby=E7rxQ6NZR69tmLt1w@mail.gmail.com>
	<CADuOafXLODESp3C3L564vyEJ9hSC9U5prHdde_dtf+3iN_Fqzw@mail.gmail.com>
	<CAKjckyNMaq_35iUEHeTxNLxthY98=QDrnB+hF5--NdvsE==NYg@mail.gmail.com>
Message-ID: <CABPTjTA1L3khoOk1uybgrm6a7kFAE+afpGv_t8ie3azwX+W=MQ@mail.gmail.com>

Am 23. April 2012 13:45 schrieb Martin Vonwald <imagic.osm at gmail.com>:
> the road, we need some recommend value for est_width. If we agree on,
> that most cars have a width of something around 2 meters, a good value
> for the estimated(!) width of "a road with two lanes, which is so
> narrow, that vehicles most slow down to pass each other" is about 4
> meters - therefore the recommendation to use est_width=4.
>
> Is everyone fine with that?


+1


> I would also like to get some more opinions on either 1) est_width or
> 2) width and source:width=estimated should be used.


I prefer the second form. You will never have widths with cm
precision, so they will always be somehow estimates, because even if
you measure them precisely they won't probably be exactly the same 10
or 100 meters away from this spot.

cheers,
Martin


From pieren3 at gmail.com  Mon Apr 23 12:54:09 2012
From: pieren3 at gmail.com (Pieren)
Date: Mon, 23 Apr 2012 13:54:09 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
Message-ID: <CAPT3zJrL_1WTU+gjU6rZW0-QDRyABc7-sFdTXV86bFLgFSq_5A@mail.gmail.com>

On Sat, Apr 21, 2012 at 10:19 AM, Ronnie Soak
<chaoschaos0909 at googlemail.com> wrote:

> It may be harder to estimate a width in meters instead of a lanes count, but
> I think it's possible within +/- 1m, especially for narrow ways.
> (I personally only use it with either rather narrow or rather wide ways out
> of the norm.)

Okay. Then we tag the "objective" width instead of imprecise amount of lanes !
But one question : the doc ([1]) does not specify what is counted in
the width: shoulders, sidewalks, bicycle lanes, parking lanes, psv
lanes ? And what is width if the way contains a "cycleway=track" ? And
since almost nobody reads the doc, the tag "width" will have as much
(mis)interpretations as the tag "lanes" does...

[1] http://wiki.openstreetmap.org/wiki/Key:width

Pieren


From pieren3 at gmail.com  Mon Apr 23 12:58:08 2012
From: pieren3 at gmail.com (Pieren)
Date: Mon, 23 Apr 2012 13:58:08 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CABPTjTA1L3khoOk1uybgrm6a7kFAE+afpGv_t8ie3azwX+W=MQ@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
	<CABPTjTAuUP=Vm5VgRcOAn3DF4o=qtVby=E7rxQ6NZR69tmLt1w@mail.gmail.com>
	<CADuOafXLODESp3C3L564vyEJ9hSC9U5prHdde_dtf+3iN_Fqzw@mail.gmail.com>
	<CAKjckyNMaq_35iUEHeTxNLxthY98=QDrnB+hF5--NdvsE==NYg@mail.gmail.com>
	<CABPTjTA1L3khoOk1uybgrm6a7kFAE+afpGv_t8ie3azwX+W=MQ@mail.gmail.com>
Message-ID: <CAPT3zJrjHoPK-4_=x8+LX2TqCgiacNL+dLjrJEaxUyTAm+buOA@mail.gmail.com>

On Mon, Apr 23, 2012 at 1:51 PM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:

> I prefer the second form. You will never have widths with cm
> precision, so they will always be somehow estimates, because even if
> you measure them precisely they won't probably be exactly the same 10
> or 100 meters away from this spot.

Finally. Someone else who think that "width" and "est_width" are the
same if it's tagging a way...

Pieren


From jamicuosm at googlemail.com  Mon Apr 23 14:03:05 2012
From: jamicuosm at googlemail.com (Jason Cunningham)
Date: Mon, 23 Apr 2012 14:03:05 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CABPTjTAuUP=Vm5VgRcOAn3DF4o=qtVby=E7rxQ6NZR69tmLt1w@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
	<CABPTjTAuUP=Vm5VgRcOAn3DF4o=qtVby=E7rxQ6NZR69tmLt1w@mail.gmail.com>
Message-ID: <CAK7S3dM1+xc2YGsq4h_qu=8xWovZ8iJvnTYxM_JzZVXM8veOEg@mail.gmail.com>

On 23 April 2012 12:05, Martin Koppenhoefer <dieterdreist at gmail.com> wrote:

> Am 22. April 2012 16:43 schrieb Jason Cunningham <jamicuosm at googlemail.com
> >:
> > 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 figure of 4m for two lanes makes sense.
> >
> > But saloon cars are no longer the 'standard' car, in the uk they've more
> or
> > less been replaced by hatchbacks & 4x4's. If we look at best selling
> cars in
> > the UK (and I assume Europe) we have to assume car widths (with mirrors)
> are
> > now just over 2m, which I'd round up to 2.1m.
>
>
> -1, fortunately this isn't true and cars are usually not larger then
> 1.8 metres, actually the best selling cars are usually smaller than
> that. E.g. have a look here (I didn't check it extensively, but I
> guess it is true):
>
> http://en.wikipedia.org/wiki/User:DeLarge/Top_10_best_selling_cars_in_Britain
>

What I said about car widths is true. A quick search confirms the current
models of the 'Ford Focus', 'Volkswagon Golf' and ' Vauxhall Astra' are all
wider than 2m (common width for these type of "family" cars appears to be
2.010m). Note that I said "with mirrors". The wing mirrors can be folded
back to make the cars narrower, but you don't have your wing mirrors folded
back when driving.


> Anyways, I think researching the average car width shouldn't be
> required for mapping lanes.
>

That's a fair point. But my response about car widths was meant to be
linked to the solution Martin Vonwald is suggesting for narrow 2 lanes
roads currently being tagged as lane=1.5 (a tag not documented but being
used for roads that two cars can pass at a crawl, and clearly important
info)
Martin implied the wiki should suggest not using the lanes=1.5 but instead
people should use lane=2; width=4 (or est_width=4)
What I was trying to point out, and maybe should have made clearer, is that
I thought suggestion was acceptable in principle, but that width=4 was
wrong. Common cars now have widths greater than 2m, I felt Martins
suggested advice for dealing with lanes=1.5 should be lanes=2, width=4.3

Problem with that, and why I am said this is far more complex than I first
thought, is some people responding to lanes=1.5 by saying 'computers' only
like whole numbers. This suggests width=4.3 would need to be rounded to
either width=4 or width=5 neither of which would help with solving the
lanes=1.5 problem, because 4m is to narrow for two 2.010m cars, and 5m
arguably doesn't require you to significantly slow down.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120423/878fdc87/attachment.html>

From lauri.kytomaa at aalto.fi  Mon Apr 23 14:24:00 2012
From: lauri.kytomaa at aalto.fi (=?iso-8859-1?Q?Kyt=F6maa_Lauri?=)
Date: Mon, 23 Apr 2012 13:24:00 +0000
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>,
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
Message-ID: <D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>

>Am 21.04.2012 um 13:34 schrieb "Ilpo J?rvinen" <ilpo.jarvinen at helsinki.fi>:
>> ...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 saying that use lanes=1/2 alone instead I oppose.
>
>I would recommend lanes=2 and width=xxx. Maybe give some examples for the widths of some common, "narrow" roads? Can someone provide photos and widths?

There are a few things to this, that haven't yet been mentioned. I've
been writing this as the discussion has progressed, so this got a bit
long, but I tried to rearrange it to a comprehensible presentation of
the issues.

All this discussion is taking place, because there are roads where
lanes=2 would be wrong part of the time, or for some motorized road 
users, and lanes=1 would be wrong on that same road at some other 
times. IMO we should not omit the lanes tag altogether on these 
roads, when the "between 1 and 2" tells us something significant of
the attainable speeds and the layout of that road. Even if the
actual width is measured and entered.


First: I give you two clear examples why we must not limit the
lanes tag to roads with a painted line:

Urban road 9 meters wide (measured from aerial images), parked cars 
on one side (always), no markings. Definitively lanes=2 - that's 3,5 
meter wide lanes, enough for the bus that runs here.
http://g.co/maps/9pvjn

Rural road less than 5.7 meters(*), probably 5.5m. No markings. Low 
traffic, passenger car and a hgv can pass even if most drivers slow 
down a bit because they have to drive so close to the edge. Has 
passing places for the easier driving in the rare case of oncoming 
hgv's, even if they can fit side by side with only few cm margin.
Passing places are also in place for winter time, when the snowplowed
road edge has too much snow for driving safely in a straight line,
when a bus and a passenger car need to fit side by side. In winter 
two passenger cars would most of the time disregard the passing 
places.
I'd still say lanes=2:
http://g.co/maps/c7p3h

*) Here the road marking rules state that "generally" no center line
markings are used on roads less than 5.7 meters wide; even that is 
2.8 meters per lane, i.e. enough for the widest road legal hgv's to 
pass. I'd believe the point being, that a center line on a road 
narrower than that would make it impossible for the hgv to stay 
within the lane it is supposed be driving in. 


About car widths: typical European car widths are 1.80 meters, give 
or take 5 cm. That does not include mirrors. That is why a row of 
parked cars takes up 2 meters from the road width. (Also, not 
everybody can park every time less than 5 cm from the road edge.)
The widths have grown some 20 cm between the 1970's and present day.
Likewise, the 2.55/2.60 meters for trucks and buses does not include
mirrors.

Second point: often we would, I believe, assume that a road tagged 
as having two lanes "generally always" allows unimpeded traffic flow
in both directions. Where it's 4.2-4.4 meters wide, that holds for 
passenger cars. A case I often see, especially in urban areas built
between 1920 and 1960, are residential roads that are 5.5 to 6 
meters wide without a center line, but allow parking on one side of
the road carriageway - and they're generally often full of parked 
cars. It's not a "parking lane", but part of the road reserved for
traffic; when there are no parked cars, even hgv's could pass each
other with care. On 5.5 meters wide roads, many passenger car 
drivers will wait at a random free space between the parked cars, 
but on a 6 m wide road people will just slow to a crawl (or halt) 
when passing oncoming cars. The wider one could be lanes=2, but the
narrower one hardly. See below for streetview examples, the last two
example links.


Third point: were we to estimate widths visually (not all areas
have good enough aerial imagery), there would be lots of "relative
errors" between nearby roads: IMO it's bad if such measures are
recorded that claim that a road is narrower than the next, when it's
the other way round - especially when the claimed-to-be narrower
road might have two clear lanes, whereas the lane count isn't that 
unambigous on the other road. With lanes=1.5 we have a rough scale, 
but one that's correct relative to nearby roads with definitively 
1 or 2 lanes.

Examples, both clear cases and ones that are to date without a 
lanes tag, or with lanes=1.5. None of the examples below are oneway
roads. Only now did I measure the width from Bing aerials. 
One can take the phrase "Generally always" below to mean that if you 
were to go there on 10 different days, on 8 or 9 days the situation 
would be as depicted.

Clear cases of lanes=2:

Rural road 7.5 meters wide (+shoulders), marked lanes, lots of margin
within the lanes for the widest of vehicles. 
http://g.co/maps/zjjx2

Rural road about 6.5 to 7 meters, marked lanes, even a hgv still has 
lots of margin within their own lane.
lanes=2
http://g.co/maps/xfs7c


Not so clear cases:

8 meters wide residential road, parking allowed on both sides 
(roughly always half of the allowed space is in use), no markings: 
Where cars are parked on both sides, only 4 meters is very tight but
possibly manageable for passenger cars. I have long ago tagged this 
as lanes=2
http://g.co/maps/bpwqc

7 meters wide, parked cars generally always on both sides. That's 3 
meters of free road. Can that be lanes=1? What if there were most of
the time much fewer parked cars?
http://g.co/maps/wngjc

6.7 meters wide, parked cars always on one side. Should be 4.7
meters free for traffic, ample room for two passenger cars. Here the 
cars parked on the left side are illegally half on the curb so that 
they leave the required 3 meters of road free for traffic - there's
is no formal parking restriction on either side of the road.
http://g.co/maps/b3whr

Urban unpaved residential, width between the fences is about 5.2 to
5.7 meters - hard to measure from the aerial images because of the 
trees - and the carriageway itself a bit (up to 1.5 meters) narrower.
As you can see from the parked car, a hgv (say, a garbage truck) 
could just barely get past it, and even passenger cars need to use 
the very edge of the road in case of oncoming vehicles. This one I 
have long ago tagged as lanes=1.5; it's not one lane road, but you 
couldn't call it two lanes either.
http://g.co/maps/m7y4a

5.5 meters, parking allowed actually on both sides but everybody
parks on one side of the road, less than half of the allowed space 
normally used by parking, no markings. I can't say if this is 
lanes=1 or lanes=2 - if parking were forbidden totally forbidden, 
it would be 2. Quite often you have to wait for a few seconds for 
the lane to clear.
http://g.co/maps/pf2gb

5 meters wide, otherwise just as above.
http://g.co/maps/bt5tq

Either 
* some of these roads can't have a lanes tag at all,
* or they're misleadingly tagged as lanes=1
* or misleadingly as lanes=2
* or tagged with lanes=1.5. And not all of those are 4 to 4.2 meters
wide, but even wider.

I'll still have to dig to find a case where such a border case narrow
road has dedicated (painted) parking spaces, which excludes them from
the width usable for traffic.

-- 
Alv

From imagic.osm at gmail.com  Mon Apr 23 14:24:23 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Mon, 23 Apr 2012 15:24:23 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAK7S3dM1+xc2YGsq4h_qu=8xWovZ8iJvnTYxM_JzZVXM8veOEg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335028306.12429.59.camel@marvin>
	<74BD170A-E19B-49A9-A5DC-079A5D9C348E@gmail.com>
	<1335031783.12429.70.camel@marvin>
	<CAKjckyNf3jyMWMZ94temV7iofNLNR_hG6dTzGcKy10CnQ74e6Q@mail.gmail.com>
	<CAK7S3dM6LJNXjBNfRc3h7DzumXfFGVEsnewtuN-wV1sf4rsHPA@mail.gmail.com>
	<CABPTjTAuUP=Vm5VgRcOAn3DF4o=qtVby=E7rxQ6NZR69tmLt1w@mail.gmail.com>
	<CAK7S3dM1+xc2YGsq4h_qu=8xWovZ8iJvnTYxM_JzZVXM8veOEg@mail.gmail.com>
Message-ID: <CAKjckyP1pFfBDOSm_BEPcijgMkAHwLo4OywF4DhTTeYVRbDQMQ@mail.gmail.com>

2012/4/23 Jason Cunningham <jamicuosm at googlemail.com>:
> Problem with that, and why I am said this is far more complex than I first
> thought, is some people responding to lanes=1.5 by saying 'computers' only
> like whole numbers. This suggests width=4.3 would need to be rounded to
> either width=4 or width=5 neither of which would help with solving the
> lanes=1.5 problem, because 4m is to narrow for two 2.010m cars, and 5m
> arguably doesn't require you to significantly slow down.

1) The "whole numbers" referred to the lanes tag. Width of course can
have fractional digits.
2) The width=4 should be a recommendation if the width - for whatever
reason - is not measured exactly. The recommend width should have two
properties: a) easy to remember, and b) for any data consumer it
should be clear, that this is "narrow". Because of a) I would take 4
and not 4.3 and because of b) we can not take 5.

Martin


From a.errington at lancaster.ac.uk  Mon Apr 23 14:41:43 2012
From: a.errington at lancaster.ac.uk (Andrew Errington)
Date: Mon, 23 Apr 2012 22:41:43 +0900
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAK7S3dM1+xc2YGsq4h_qu=8xWovZ8iJvnTYxM_JzZVXM8veOEg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CABPTjTAuUP=Vm5VgRcOAn3DF4o=qtVby=E7rxQ6NZR69tmLt1w@mail.gmail.com>
	<CAK7S3dM1+xc2YGsq4h_qu=8xWovZ8iJvnTYxM_JzZVXM8veOEg@mail.gmail.com>
Message-ID: <201204232241.43755.a.errington@lancaster.ac.uk>

On Mon, 23 Apr 2012 22:03:05 Jason Cunningham wrote:
> Problem with that, and why I am said this is far more complex than I first
> thought, is some people responding to lanes=1.5 by saying 'computers' only
> like whole numbers. This suggests width=4.3 would need to be rounded to
> either width=4 or width=5 neither of which would help with solving the
> lanes=1.5 problem, because 4m is to narrow for two 2.010m cars, and 5m
> arguably doesn't require you to significantly slow down.

No, lanes=* is an integer and width=* is a real number.  Furthermore, as an 
integer, lanes=* can be counted, so it's verifiable, and not subject to 
someone's guess, or dependent on the type of car they were driving.  width=* 
is measured in metres, and can be fractional.  It can be estimated, but 
everyone makes their estimate based on a standard unit of measurement.  
Later, the measurement can be refined, but the refinement doesn't depend on 
which car you are driving.

If we record the number of physically painted lanes, or an assumption based on 
whether the road is oneway or not, and we record the width, then anyone can 
download the data and figure out if the road is wide enough for *their* 
vehicle[1].

And really, if a road is 4.3 m wide it doesn't matter how wide your car is, 
you should probably slow down.

Best wishes,

Andrew

[1] However, you don't know the width of the oncoming vehicles.


From imagic.osm at gmail.com  Mon Apr 23 14:55:25 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Mon, 23 Apr 2012 15:55:25 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
Message-ID: <CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>

In my opinion, parked cars should not be considered.  Keep it simple!
The tag lanes should give you the number of lanes. The tag width gives
you the width. And if cars usually park on the road, we should use a
tag - maybe parking:lanes or similar - for that one.
What we not should do is put a completely different meaning into a tag
-> "Actually it is lanes=3  but I only tag lanes=1 because cars are
parking here".

Martin

2012/4/23 Kyt?maa Lauri <lauri.kytomaa at aalto.fi>:
>>Am 21.04.2012 um 13:34 schrieb "Ilpo J?rvinen" <ilpo.jarvinen at helsinki.fi>:
>>> ...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 saying that use lanes=1/2 alone instead I oppose.
>>
>>I would recommend lanes=2 and width=xxx. Maybe give some examples for the widths of some common, "narrow" roads? Can someone provide photos and widths?
>
> There are a few things to this, that haven't yet been mentioned. I've
> been writing this as the discussion has progressed, so this got a bit
> long, but I tried to rearrange it to a comprehensible presentation of
> the issues.
>
> All this discussion is taking place, because there are roads where
> lanes=2 would be wrong part of the time, or for some motorized road
> users, and lanes=1 would be wrong on that same road at some other
> times. IMO we should not omit the lanes tag altogether on these
> roads, when the "between 1 and 2" tells us something significant of
> the attainable speeds and the layout of that road. Even if the
> actual width is measured and entered.
>
>
> First: I give you two clear examples why we must not limit the
> lanes tag to roads with a painted line:
>
> Urban road 9 meters wide (measured from aerial images), parked cars
> on one side (always), no markings. Definitively lanes=2 - that's 3,5
> meter wide lanes, enough for the bus that runs here.
> http://g.co/maps/9pvjn
>
> Rural road less than 5.7 meters(*), probably 5.5m. No markings. Low
> traffic, passenger car and a hgv can pass even if most drivers slow
> down a bit because they have to drive so close to the edge. Has
> passing places for the easier driving in the rare case of oncoming
> hgv's, even if they can fit side by side with only few cm margin.
> Passing places are also in place for winter time, when the snowplowed
> road edge has too much snow for driving safely in a straight line,
> when a bus and a passenger car need to fit side by side. In winter
> two passenger cars would most of the time disregard the passing
> places.
> I'd still say lanes=2:
> http://g.co/maps/c7p3h
>
> *) Here the road marking rules state that "generally" no center line
> markings are used on roads less than 5.7 meters wide; even that is
> 2.8 meters per lane, i.e. enough for the widest road legal hgv's to
> pass. I'd believe the point being, that a center line on a road
> narrower than that would make it impossible for the hgv to stay
> within the lane it is supposed be driving in.
>
>
> About car widths: typical European car widths are 1.80 meters, give
> or take 5 cm. That does not include mirrors. That is why a row of
> parked cars takes up 2 meters from the road width. (Also, not
> everybody can park every time less than 5 cm from the road edge.)
> The widths have grown some 20 cm between the 1970's and present day.
> Likewise, the 2.55/2.60 meters for trucks and buses does not include
> mirrors.
>
> Second point: often we would, I believe, assume that a road tagged
> as having two lanes "generally always" allows unimpeded traffic flow
> in both directions. Where it's 4.2-4.4 meters wide, that holds for
> passenger cars. A case I often see, especially in urban areas built
> between 1920 and 1960, are residential roads that are 5.5 to 6
> meters wide without a center line, but allow parking on one side of
> the road carriageway - and they're generally often full of parked
> cars. It's not a "parking lane", but part of the road reserved for
> traffic; when there are no parked cars, even hgv's could pass each
> other with care. On 5.5 meters wide roads, many passenger car
> drivers will wait at a random free space between the parked cars,
> but on a 6 m wide road people will just slow to a crawl (or halt)
> when passing oncoming cars. The wider one could be lanes=2, but the
> narrower one hardly. See below for streetview examples, the last two
> example links.
>
>
> Third point: were we to estimate widths visually (not all areas
> have good enough aerial imagery), there would be lots of "relative
> errors" between nearby roads: IMO it's bad if such measures are
> recorded that claim that a road is narrower than the next, when it's
> the other way round - especially when the claimed-to-be narrower
> road might have two clear lanes, whereas the lane count isn't that
> unambigous on the other road. With lanes=1.5 we have a rough scale,
> but one that's correct relative to nearby roads with definitively
> 1 or 2 lanes.
>
> Examples, both clear cases and ones that are to date without a
> lanes tag, or with lanes=1.5. None of the examples below are oneway
> roads. Only now did I measure the width from Bing aerials.
> One can take the phrase "Generally always" below to mean that if you
> were to go there on 10 different days, on 8 or 9 days the situation
> would be as depicted.
>
> Clear cases of lanes=2:
>
> Rural road 7.5 meters wide (+shoulders), marked lanes, lots of margin
> within the lanes for the widest of vehicles.
> http://g.co/maps/zjjx2
>
> Rural road about 6.5 to 7 meters, marked lanes, even a hgv still has
> lots of margin within their own lane.
> lanes=2
> http://g.co/maps/xfs7c
>
>
> Not so clear cases:
>
> 8 meters wide residential road, parking allowed on both sides
> (roughly always half of the allowed space is in use), no markings:
> Where cars are parked on both sides, only 4 meters is very tight but
> possibly manageable for passenger cars. I have long ago tagged this
> as lanes=2
> http://g.co/maps/bpwqc
>
> 7 meters wide, parked cars generally always on both sides. That's 3
> meters of free road. Can that be lanes=1? What if there were most of
> the time much fewer parked cars?
> http://g.co/maps/wngjc
>
> 6.7 meters wide, parked cars always on one side. Should be 4.7
> meters free for traffic, ample room for two passenger cars. Here the
> cars parked on the left side are illegally half on the curb so that
> they leave the required 3 meters of road free for traffic - there's
> is no formal parking restriction on either side of the road.
> http://g.co/maps/b3whr
>
> Urban unpaved residential, width between the fences is about 5.2 to
> 5.7 meters - hard to measure from the aerial images because of the
> trees - and the carriageway itself a bit (up to 1.5 meters) narrower.
> As you can see from the parked car, a hgv (say, a garbage truck)
> could just barely get past it, and even passenger cars need to use
> the very edge of the road in case of oncoming vehicles. This one I
> have long ago tagged as lanes=1.5; it's not one lane road, but you
> couldn't call it two lanes either.
> http://g.co/maps/m7y4a
>
> 5.5 meters, parking allowed actually on both sides but everybody
> parks on one side of the road, less than half of the allowed space
> normally used by parking, no markings. I can't say if this is
> lanes=1 or lanes=2 - if parking were forbidden totally forbidden,
> it would be 2. Quite often you have to wait for a few seconds for
> the lane to clear.
> http://g.co/maps/pf2gb
>
> 5 meters wide, otherwise just as above.
> http://g.co/maps/bt5tq
>
> Either
> * some of these roads can't have a lanes tag at all,
> * or they're misleadingly tagged as lanes=1
> * or misleadingly as lanes=2
> * or tagged with lanes=1.5. And not all of those are 4 to 4.2 meters
> wide, but even wider.
>
> I'll still have to dig to find a case where such a border case narrow
> road has dedicated (painted) parking spaces, which excludes them from
> the width usable for traffic.
>
> --
> Alv
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging


From lauri.kytomaa at aalto.fi  Mon Apr 23 15:28:24 2012
From: lauri.kytomaa at aalto.fi (=?iso-8859-1?Q?Kyt=F6maa_Lauri?=)
Date: Mon, 23 Apr 2012 14:28:24 +0000
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>,
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
Message-ID: <D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>


If one does not consider parked cars _at all_, the first example
of my previous post (at the end) with a 9 meter wide 
carriageway and no markings would have to be lanes=3, but 
it's not a three lane road. Likewise, this oneway street 
(5.9-6.0 meters wide) with cars always on one side would have 
to be lanes=2, which seems wrong, don't you think?

http://wiki.openstreetmap.org/wiki/File:Parkingonstreetdedicatedlanes1oneway.png

>In my opinion, parked cars should not be considered.  Keep it simple!
>The tag lanes should give you the number of lanes. The tag width gives
>you the width. And if cars usually park on the road, we should use a
>tag - maybe parking:lanes or similar - for that one.

We already do use parking:lane:right/both/left=*, a lot. :)

>> Urban road 9 meters wide (measured from aerial images), parked cars
>> on one side (always), no markings. Definitively lanes=2 - that's 3,5
>> meter wide lanes, enough for the bus that runs here.
>> http://g.co/maps/9pvjn

-- 
Alv

From phil at trigpoint.me.uk  Mon Apr 23 18:21:13 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Mon, 23 Apr 2012 18:21:13 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyMza9zmDZ2e7bvJH+_sVhgx2G+FkpoLKQk2cDTwkpHQ+g@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<1335031392.12429.66.camel@marvin>
	<CAKjckyMza9zmDZ2e7bvJH+_sVhgx2G+FkpoLKQk2cDTwkpHQ+g@mail.gmail.com>
Message-ID: <1335201673.2013.4.camel@marvin>

On Mon, 2012-04-23 at 11:31 +0200, Martin Vonwald wrote:
> > Without going too far from home.
> >
> > This one is 4.4m
> > http://t.co/UcFtIpkx
> > http://osm.org/go/eu0E92UlP-
> >
> > and complete with grass up the middle. This one is, I think 2.3m. Easy
> > to forget such things as others have said.
> > http://t.co/4DK09ahQ
> > http://osm.org/go/eu0Fswir
> 
> Can those photographs be used in the wiki? License?
Sure they can be used, I took them so guess I own the copyright.

I have the original full sized, geotagged versions if that helps.

I did the measurements by running a steel tape measure across the road,
but as others have said, go 10m in either direction and the width will
be different.

Phil




From alex at mapbox.com  Mon Apr 23 23:56:06 2012
From: alex at mapbox.com (Alex Barth)
Date: Mon, 23 Apr 2012 18:56:06 -0400
Subject: [Tagging] Block names (vs street names) in Brasilia
Message-ID: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>

Last week we've done some walking papers work in Brasilia and there are now some questions on how to enter data.

Brasilia and its satellites do not use street names, but an elaborate block numbering system. Before we start entering data, I'd like to propose a proper way to enter blocks. 

We're seeing right now two main ways how these block numbers are being added into OpenStreetMap:

1) as street name [1]
2) as place name (floating node) for a suburb or a neighborhood [2]

Neither seems to be satisfactory. Street names are ambiguous when streets run between blocks (as they frequently do). Place names aren't accurate and don't have proper tags (i. e. there is no place=block).

I wanted to get some opinions before I start data entry. After discussing this issue with AJ Ashton and Ian Villeda over here we've come to the conclusion that polygons would be the most accurate way to depict the situation on the ground. Here is how we would proceed: 

- draw blocks as polygons
- tag with `landuse=residential` or `landuse=commercial`
- name with block number

Screenshot [3] shows a concrete example of a typical blocks in Taguatinga. On OpenStreetMap.org these changes appear like so [4] (obviously the appearance on OSM.org shouldn't have much of an influence on the decision).

- Any comments or suggestions?
- Any previous discussions or existing practices I should be reading up on? Brasilia is not the only place where block names are used instead of street names. To my knowledge, other examples are some parts of Sofia/Bulgaria (I see street names here [5]) and Japan (not sure where to look).

[1] https://skitch.com/alexbarth/8i8em/java-openstreetmap-editor
[2] https://skitch.com/alexbarth/8i8g9/java-openstreetmap-editor
[3] https://skitch.com/alexbarth/8i8gj/java-openstreetmap-editor 
[4] http://osm.org/go/NuPiCKvIF-
[5] http://osm.org/go/x1DQhC5e

/bcc to talk@

Alex Barth
http://twitter.com/lxbarth
tel (202) 250-3633





From baloo at ursamundi.org  Tue Apr 24 01:18:27 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Mon, 23 Apr 2012 17:18:27 -0700
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
Message-ID: <CAMPM96rvWKk0aTwEPMUeeii7GXLX4RA0iJ3REyA=t37sgJMCvg@mail.gmail.com>

On Apr 23, 2012 3:57 PM, "Alex Barth" <alex at mapbox.com> wrote:

> Brasilia and its satellites do not use street names, but an elaborate
block numbering system. Before we start entering data, I'd like to propose
a proper way to enter blocks.

I would strongly consider taking a look at towns and cities in the American
west.  There seems to be a positive correlation between the predominance of
the Latter Day Saints and this style of addressing in the US.  Salt Lake
City is a good example, though I'm not sure how complete the address
tagging is in the area.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120423/e1f3c6ef/attachment.html>

From imagic.osm at gmail.com  Tue Apr 24 07:56:37 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Tue, 24 Apr 2012 08:56:37 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
Message-ID: <CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>

2012/4/23 Kyt?maa Lauri <lauri.kytomaa at aalto.fi>:
> If one does not consider parked cars _at all_, the first example
> of my previous post (at the end) with a 9 meter wide
> carriageway and no markings would have to be lanes=3

Of course not. It would be lanes=2. The width isn't decisive for the
lane count, but markings or usage. I doubt, that anyone would consider
this to be a road with three lanes.

>, but
> it's not a three lane road. Likewise, this oneway street
> (5.9-6.0 meters wide) with cars always on one side would have
> to be lanes=2, which seems wrong, don't you think?

Same argument as before.


>>In my opinion, parked cars should not be considered. ?Keep it simple!
>>The tag lanes should give you the number of lanes. The tag width gives
>>you the width. And if cars usually park on the road, we should use a
>>tag - maybe parking:lanes or similar - for that one.
>
> We already do use parking:lane:right/both/left=*, a lot. :)

Perfect :-)


Martin


From ohrosm at googlemail.com  Tue Apr 24 07:57:13 2012
From: ohrosm at googlemail.com (=?ISO-8859-1?Q?Michael_Kr=E4mer?=)
Date: Tue, 24 Apr 2012 08:57:13 +0200
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
Message-ID: <CADuOafXmbU=t6n7_cma2LV2oSmeO0m9JRE31eJwrd+SDKQhKxA@mail.gmail.com>

Am 24. April 2012 00:56 schrieb Alex Barth <alex at mapbox.com>:

> - Any previous discussions or existing practices I should be reading up
> on? Brasilia is not the only place where block names are used instead of
> street names. To my knowledge, other examples are some parts of
> Sofia/Bulgaria (I see street names here [5]) and Japan (not sure where to
> look).
>

The city center of Mannheim in Germany also uses blocks although there are
some named streets (example:
http://www.openstreetmap.org/?lat=49.487123&lon=8.464508&zoom=18&layers=M).

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120424/ec03b1f2/attachment.html>

From lion at netngine.hu  Tue Apr 24 09:34:51 2012
From: lion at netngine.hu (Ferenc Veres)
Date: Tue, 24 Apr 2012 10:34:51 +0200
Subject: [Tagging] Feature Proposal - Voting - Key:second_hand
Message-ID: <4F9665AB.3020503@netngine.hu>

Hi all,

A very simple indication whether a shop sells second hand items too.
Please place your votes.

Someone already created a final page for it, with different wording, so
please let's also re-vote on the value "second_hand=yes", despite that
my page really reflects what we discussed: no "yes" value due to
ambiguity. To avoid longer discussion, I would accept "yes" = "both" as
final page suggests.

http://wiki.openstreetmap.org/wiki/Proposed_features/Second_Hand_Shops

Thanks all,
Ferenc
[[User:kempelen]]

-- 
Ferenc Veres
http://www.wpsnet.com

To send GPG encrypted message please use this key
http://lion.xaraya.hu/images/ferenc_veres_gpg.txt
and a program like this:  http://www.gpg4win.org/


From pieren3 at gmail.com  Tue Apr 24 10:18:30 2012
From: pieren3 at gmail.com (Pieren)
Date: Tue, 24 Apr 2012 11:18:30 +0200
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
Message-ID: <CAPT3zJoc7Yfuh8P2mrSMhryD_1f=e=GmxDeUbq3aJwOXrFYYZw@mail.gmail.com>

On Tue, Apr 24, 2012 at 12:56 AM, Alex Barth

We had a similar discussion from a contributor working in Peru and
their "cuadra" system. My proposal was to create a new tag
"addr:block" (+ a name or a number) which could be attached on a
parallel way along the street (like the addr:interpolation). But in
your case, the "addr:block" could be set to a polygone (with the
additional tags from "addr" as usual).

Pieren


From janjko at gmail.com  Tue Apr 24 10:51:40 2012
From: janjko at gmail.com (=?UTF-8?Q?Janko_Miheli=C4=87?=)
Date: Tue, 24 Apr 2012 11:51:40 +0200
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
Message-ID: <CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>

2012/4/24 Alex Barth <alex at mapbox.com>

>
> - draw blocks as polygons
> - tag with `landuse=residential` or `landuse=commercial`
> - name with block number
>
>
I don't like the "landuse" tag for this purpose. There could be two
landuses on one block, there could be an empty block with no landuse but
with a block name, and so on.. That tag isn't used for that. I would use
place=neighbourhood for the polygon.

Janko Miheli?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120424/f9f8dc1f/attachment-0001.html>

From a.errington at lancaster.ac.uk  Tue Apr 24 10:59:23 2012
From: a.errington at lancaster.ac.uk (Andrew Errington)
Date: Tue, 24 Apr 2012 18:59:23 +0900
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
Message-ID: <201204241859.23985.a.errington@lancaster.ac.uk>

What do they do in Japan?  Japan has a block-oriented addressing system.  I 
don't know how this is implemented in OSM, but maybe it can be used in 
Brasilia.

Best wishes,

Andrew


From alex at mapbox.com  Tue Apr 24 14:59:35 2012
From: alex at mapbox.com (Alex Barth)
Date: Tue, 24 Apr 2012 09:59:35 -0400
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <CADuOafXmbU=t6n7_cma2LV2oSmeO0m9JRE31eJwrd+SDKQhKxA@mail.gmail.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CADuOafXmbU=t6n7_cma2LV2oSmeO0m9JRE31eJwrd+SDKQhKxA@mail.gmail.com>
Message-ID: <D7C4CB73-D8BF-4AE9-8CB2-C0E6CD414DE6@mapbox.com>


Interesting. Mannheim uses for a block named C2:

area=yes
name=C2

On Apr 24, 2012, at 2:57 AM, Michael Kr?mer wrote:

> Am 24. April 2012 00:56 schrieb Alex Barth <alex at mapbox.com>:
> - Any previous discussions or existing practices I should be reading up on? Brasilia is not the only place where block names are used instead of street names. To my knowledge, other examples are some parts of Sofia/Bulgaria (I see street names here [5]) and Japan (not sure where to look).
> 
> The city center of Mannheim in Germany also uses blocks although there are some named streets (example: http://www.openstreetmap.org/?lat=49.487123&lon=8.464508&zoom=18&layers=M). 
> 
> Michael
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging

Alex Barth
http://twitter.com/lxbarth
tel (202) 250-3633





From alex at mapbox.com  Tue Apr 24 15:02:07 2012
From: alex at mapbox.com (Alex Barth)
Date: Tue, 24 Apr 2012 10:02:07 -0400
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <CAPT3zJoc7Yfuh8P2mrSMhryD_1f=e=GmxDeUbq3aJwOXrFYYZw@mail.gmail.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAPT3zJoc7Yfuh8P2mrSMhryD_1f=e=GmxDeUbq3aJwOXrFYYZw@mail.gmail.com>
Message-ID: <B3F0B108-2D50-4079-9C97-5C5E8F7B6D90@mapbox.com>


I think I've seen the addr:block proposal (what's the link?)

My understanding is that addr: fields would be attached to entities that are actually being addressed, i. e. buildings. Is this correct?

That said. addr:block would indeed be useful for addresses on buildings in Brasilia.

On Apr 24, 2012, at 5:18 AM, Pieren wrote:

> On Tue, Apr 24, 2012 at 12:56 AM, Alex Barth
> 
> We had a similar discussion from a contributor working in Peru and
> their "cuadra" system. My proposal was to create a new tag
> "addr:block" (+ a name or a number) which could be attached on a
> parallel way along the street (like the addr:interpolation). But in
> your case, the "addr:block" could be set to a polygone (with the
> additional tags from "addr" as usual).
> 
> Pieren
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging

Alex Barth
http://twitter.com/lxbarth
tel (202) 250-3633





From alex at mapbox.com  Tue Apr 24 15:04:25 2012
From: alex at mapbox.com (Alex Barth)
Date: Tue, 24 Apr 2012 10:04:25 -0400
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
Message-ID: <49018950-E1EB-4AD3-A74D-535941CF2C82@mapbox.com>


I see your point. While Brasilia has indeed in many places single purpose blocks, this is likely not the case in all cities. However, place=neighbourhood is misleading as there are many blocks in a neighbourhood.

I'm liking the `area=yes` as seen in Mannheim [1] better than `place=neighbourhood`. Thoughts?

[1] https://skitch.com/alexbarth/8i8em/java-openstreetmap-editor

On Apr 24, 2012, at 5:51 AM, Janko Miheli? wrote:

> 
> 
> 2012/4/24 Alex Barth <alex at mapbox.com>
> 
> - draw blocks as polygons
> - tag with `landuse=residential` or `landuse=commercial`
> - name with block number
> 
> 
> I don't like the "landuse" tag for this purpose. There could be two landuses on one block, there could be an empty block with no landuse but with a block name, and so on.. That tag isn't used for that. I would use place=neighbourhood for the polygon.
> 
> Janko Miheli?
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging

Alex Barth
http://twitter.com/lxbarth
tel (202) 250-3633





From alex at mapbox.com  Tue Apr 24 15:06:49 2012
From: alex at mapbox.com (Alex Barth)
Date: Tue, 24 Apr 2012 10:06:49 -0400
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <CAMPM96rvWKk0aTwEPMUeeii7GXLX4RA0iJ3REyA=t37sgJMCvg@mail.gmail.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAMPM96rvWKk0aTwEPMUeeii7GXLX4RA0iJ3REyA=t37sgJMCvg@mail.gmail.com>
Message-ID: <576EB75F-F2E8-4EAF-8CA8-CB8004E3EA61@mapbox.com>


Thanks - any links? A quick look at Salt Lake City gives me street names. 

On Apr 23, 2012, at 8:18 PM, Paul Johnson wrote:

> 
> On Apr 23, 2012 3:57 PM, "Alex Barth" <alex at mapbox.com> wrote:
> 
> > Brasilia and its satellites do not use street names, but an elaborate block numbering system. Before we start entering data, I'd like to propose a proper way to enter blocks.
> 
> I would strongly consider taking a look at towns and cities in the American west.  There seems to be a positive correlation between the predominance of the Latter Day Saints and this style of addressing in the US.  Salt Lake City is a good example, though I'm not sure how complete the address tagging is in the area.
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging

Alex Barth
http://twitter.com/lxbarth
tel (202) 250-3633





From pieren3 at gmail.com  Tue Apr 24 15:12:31 2012
From: pieren3 at gmail.com (Pieren)
Date: Tue, 24 Apr 2012 16:12:31 +0200
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <49018950-E1EB-4AD3-A74D-535941CF2C82@mapbox.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
	<49018950-E1EB-4AD3-A74D-535941CF2C82@mapbox.com>
Message-ID: <CAPT3zJpWhh72z2x-50nAdcHRhxcktVHMp5cdzwtE1kToXLUxpg@mail.gmail.com>

On Tue, Apr 24, 2012 at 4:04 PM, Alex Barth <alex at mapbox.com> wrote:

> I'm liking the `area=yes` as seen in Mannheim [1] better than `place=neighbourhood`. Thoughts?

Oh no, please. area=yes has been created to distinguish highway loops
and highway areas. For me, a tag "area=yes" not combined with a
"highway" is a mistake. Then better use "place=neighbourhood".

Pieren


From dieterdreist at gmail.com  Tue Apr 24 15:20:38 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Tue, 24 Apr 2012 16:20:38 +0200
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <49018950-E1EB-4AD3-A74D-535941CF2C82@mapbox.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
	<49018950-E1EB-4AD3-A74D-535941CF2C82@mapbox.com>
Message-ID: <CABPTjTBWG6njSBQ9uiJfYkofXkF4MD9R415-Cqu5T3NoWEjVNA@mail.gmail.com>

Am 24. April 2012 16:04 schrieb Alex Barth <alex at mapbox.com>:
>
> I see your point. While Brasilia has indeed in many places single purpose blocks, this is likely not the case in all cities. However, place=neighbourhood is misleading as there are many blocks in a neighbourhood.


if neighbourhood is missleading, you could invent a place=block below
neighbourhood. "neighbourhood" seems to be interpreted differently in
different cultural backgrounds. Personally I always saw it as a
relatively small entity, smaller than a quarter which would be smaller
than a suburb.

cheers,
Martin


From pieren3 at gmail.com  Tue Apr 24 15:44:12 2012
From: pieren3 at gmail.com (Pieren)
Date: Tue, 24 Apr 2012 16:44:12 +0200
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <CABPTjTBWG6njSBQ9uiJfYkofXkF4MD9R415-Cqu5T3NoWEjVNA@mail.gmail.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
	<49018950-E1EB-4AD3-A74D-535941CF2C82@mapbox.com>
	<CABPTjTBWG6njSBQ9uiJfYkofXkF4MD9R415-Cqu5T3NoWEjVNA@mail.gmail.com>
Message-ID: <CAPT3zJoqTP9O0P7Mj22Sek_NpK7LaS2vYbtE2QR3Y9oY_ETang@mail.gmail.com>

On Tue, Apr 24, 2012 at 4:20 PM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:

> if neighbourhood is missleading, you could invent a place=block below
> neighbourhood. "neighbourhood" seems to be interpreted differently in
> different cultural backgrounds. Personally I always saw it as a
> relatively small entity, smaller than a quarter which would be smaller
> than a suburb.

It seems that neighbourhood/district/quarter are very closed and hard
to translate (as you say, it's cultural). But the "block" seems to be
easy to define since it is the smallest area defined by a street grid.

Pieren


From alex at mapbox.com  Tue Apr 24 19:13:49 2012
From: alex at mapbox.com (Alex Barth)
Date: Tue, 24 Apr 2012 14:13:49 -0400
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <CAPT3zJpWhh72z2x-50nAdcHRhxcktVHMp5cdzwtE1kToXLUxpg@mail.gmail.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
	<49018950-E1EB-4AD3-A74D-535941CF2C82@mapbox.com>
	<CAPT3zJpWhh72z2x-50nAdcHRhxcktVHMp5cdzwtE1kToXLUxpg@mail.gmail.com>
Message-ID: <F306FECE-F3CB-4315-B5C7-3F60ED919D34@mapbox.com>


Pieren - thanks for pointing out that "area=yes" is highway only. How could the documentation for it be clearer [1]?

Seems to me then that starting to use a value "block" for the "place" [2] key would be an appropriate solution.

Examples:

So for a block QNB12 in Brasilia, the tagging would be:

place=block
name=QNB12

For a block C2 in Mannheim, the tagging would be:

place=block
name=C1

(right now I find area=yes instead of place=block in Mannheim)

Comments?

[1] http://wiki.openstreetmap.org/wiki/Key:area
[2] http://wiki.openstreetmap.org/wiki/Key:place


On Apr 24, 2012, at 10:12 AM, Pieren wrote:

> On Tue, Apr 24, 2012 at 4:04 PM, Alex Barth <alex at mapbox.com> wrote:
> 
>> I'm liking the `area=yes` as seen in Mannheim [1] better than `place=neighbourhood`. Thoughts?
> 
> Oh no, please. area=yes has been created to distinguish highway loops
> and highway areas. For me, a tag "area=yes" not combined with a
> "highway" is a mistake. Then better use "place=neighbourhood".
> 
> Pieren
> 
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging

Alex Barth
http://twitter.com/lxbarth
tel (202) 250-3633





From sanderd17 at gmail.com  Tue Apr 24 22:19:34 2012
From: sanderd17 at gmail.com (Sander Deryckere)
Date: Tue, 24 Apr 2012 23:19:34 +0200
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <CAPT3zJoqTP9O0P7Mj22Sek_NpK7LaS2vYbtE2QR3Y9oY_ETang@mail.gmail.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
	<49018950-E1EB-4AD3-A74D-535941CF2C82@mapbox.com>
	<CABPTjTBWG6njSBQ9uiJfYkofXkF4MD9R415-Cqu5T3NoWEjVNA@mail.gmail.com>
	<CAPT3zJoqTP9O0P7Mj22Sek_NpK7LaS2vYbtE2QR3Y9oY_ETang@mail.gmail.com>
Message-ID: <CABUOUO-jrSLTdehGVX+n+cgDi7ya-R+Kqa_CD6VsV3nDTDkSfQ@mail.gmail.com>

Op 24 april 2012 16:44 schreef Pieren <pieren3 at gmail.com> het volgende:

> On Tue, Apr 24, 2012 at 4:20 PM, Martin Koppenhoefer
> <dieterdreist at gmail.com> wrote:
>
> > if neighbourhood is missleading, you could invent a place=block below
> > neighbourhood. "neighbourhood" seems to be interpreted differently in
> > different cultural backgrounds. Personally I always saw it as a
> > relatively small entity, smaller than a quarter which would be smaller
> > than a suburb.
>
> It seems that neighbourhood/district/quarter are very closed and hard
> to translate (as you say, it's cultural). But the "block" seems to be
> easy to define since it is the smallest area defined by a street grid.
>
> Pieren
>

It isn't always that easy to define. It's possible that paths or maybe
service roads run through blocks. And it's also possible that a block on
the outside of a town is only surrounded with 3 streets.

I would go for relations which define the boundaries. As most of the time,
the boundaries are streets, almost no extra ways are needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120424/ffbab940/attachment-0001.html>

From neroute2 at gmail.com  Wed Apr 25 02:46:35 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Tue, 24 Apr 2012 21:46:35 -0400
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <F306FECE-F3CB-4315-B5C7-3F60ED919D34@mapbox.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
	<49018950-E1EB-4AD3-A74D-535941CF2C82@mapbox.com>
	<CAPT3zJpWhh72z2x-50nAdcHRhxcktVHMp5cdzwtE1kToXLUxpg@mail.gmail.com>
	<F306FECE-F3CB-4315-B5C7-3F60ED919D34@mapbox.com>
Message-ID: <4F97577B.5010303@gmail.com>

On 4/24/2012 2:13 PM, Alex Barth wrote:
>
> Pieren - thanks for pointing out that "area=yes" is highway only. How could the documentation for it be clearer [1]?

It's not highway only. For example, it can be used on railway=platform: 
http://www.openstreetmap.org/browse/way/94063273
or man_made=pier: http://www.openstreetmap.org/browse/way/71124853


From elena.valhalla at gmail.com  Wed Apr 25 07:58:15 2012
From: elena.valhalla at gmail.com (Elena ``of Valhalla'')
Date: Wed, 25 Apr 2012 08:58:15 +0200
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <4F97577B.5010303@gmail.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
	<49018950-E1EB-4AD3-A74D-535941CF2C82@mapbox.com>
	<CAPT3zJpWhh72z2x-50nAdcHRhxcktVHMp5cdzwtE1kToXLUxpg@mail.gmail.com>
	<F306FECE-F3CB-4315-B5C7-3F60ED919D34@mapbox.com>
	<4F97577B.5010303@gmail.com>
Message-ID: <20120425065815.GA8634@home.home.trueelena.org>

On 2012-04-24 at 21:46:35 -0400, Nathan Edgars II wrote:
> On 4/24/2012 2:13 PM, Alex Barth wrote:
> >Pieren - thanks for pointing out that "area=yes" is highway only. How could the documentation for it be clearer [1]?
> It's not highway only. For example, it can be used on
> railway=platform: http://www.openstreetmap.org/browse/way/94063273
> or man_made=pier: http://www.openstreetmap.org/browse/way/71124853

but in both cases the meaning is "contrary to the default for 
the main tag, this feature has not been described by tracing 
its center line, but its perimeter"

-- 
Elena ``of Valhalla''
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120425/e4d1deb9/attachment.pgp>

From pieren3 at gmail.com  Wed Apr 25 08:39:27 2012
From: pieren3 at gmail.com (Pieren)
Date: Wed, 25 Apr 2012 09:39:27 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
Message-ID: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>

On Wed, Apr 25, 2012 at 3:46 AM, Nathan Edgars II <neroute2 at gmail.com> wrote:

> It's not highway only. For example, it can be used on railway=platform:
> http://www.openstreetmap.org/browse/way/94063273
> or man_made=pier: http://www.openstreetmap.org/browse/way/71124853

Thanks for pointing that out. I see that silently, the meaning of the
tag area has been modified by certain people on the wiki. I modified
the wiki about "platform":
http://wiki.openstreetmap.org/wiki/Tag:railway%3Dplatform

We cannot accept that the tag "area=yes" is required for all polygons.
This has never been the case. It was introduced only when the main tag
about a closed loop was non-deterministic (tracing a centre line or a
perimeter). We don't do that for car parks, buildings, etc. I don't
see why we should create an exception for railway platforms.

Pieren


From imagic.osm at gmail.com  Wed Apr 25 08:58:19 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Wed, 25 Apr 2012 09:58:19 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
Message-ID: <CAKjckyP0VQ9U72GdqfJOboygVkrmctJuyoSrKL4tq8HAtUL2Zg@mail.gmail.com>

The german article still has the recommendation of adding area=yes.

One of the biggest problems in the wiki is the fact, that very often
articles in different languages are not really translations, but
different articles.

As the tag railway=platform is applicable to areas as well, according
to articles in all languages, and therefore area=yes shouldn't be
necessary on closed ways, I will update this note in the german
article in accordance with the updated english article.

Martin

2012/4/25 Pieren <pieren3 at gmail.com>:
> On Wed, Apr 25, 2012 at 3:46 AM, Nathan Edgars II <neroute2 at gmail.com> wrote:
>
>> It's not highway only. For example, it can be used on railway=platform:
>> http://www.openstreetmap.org/browse/way/94063273
>> or man_made=pier: http://www.openstreetmap.org/browse/way/71124853
>
> Thanks for pointing that out. I see that silently, the meaning of the
> tag area has been modified by certain people on the wiki. I modified
> the wiki about "platform":
> http://wiki.openstreetmap.org/wiki/Tag:railway%3Dplatform
>
> We cannot accept that the tag "area=yes" is required for all polygons.
> This has never been the case. It was introduced only when the main tag
> about a closed loop was non-deterministic (tracing a centre line or a
> perimeter). We don't do that for car parks, buildings, etc. I don't
> see why we should create an exception for railway platforms.
>
> Pieren
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging


From imagic.osm at gmail.com  Wed Apr 25 09:28:57 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Wed, 25 Apr 2012 10:28:57 +0200
Subject: [Tagging] OSMI layers in JOSM
Message-ID: <CAKjckyO=hCEXpARdFkg=dh44ZzVUwndbfNiH0weSCeqgUDAmDA@mail.gmail.com>

Hi all!

I'm trying to view the OSMI layers in JOSM. The all-knowing,
all-seeing trash heap pointed me to this (german) article:
http://forum.openstreetmap.org/viewtopic.php?id=9315

There it is recommended to use the following link in JOSM:
http://tools.geofabrik.de/osmi/view/routing/wxs?REQUEST=GetMap&SERVICE=wms&VERSION=1.1.1&FORMAT=image/png&SRS=EPSG:4326&STYLES=&LAYERS=unconnected_minor1,unconnected_minor2,unconnected_minor5,unconnected_major1,unconnected_major2,unconnected_major5&

This works like a charm, but with the limitations, that one has to
adjust the resolution manually. Also I seem to be unable to get this
layer transparent. In the article one wrote to add TRANSPARENT=TRUE to
the link, but I can't get this working.

Has anyone a hint for me how to get this layer transparent? Is there
any possibility to autoadjust the resolution?

Martin


From neroute2 at gmail.com  Wed Apr 25 09:43:14 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Wed, 25 Apr 2012 04:43:14 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
Message-ID: <4F97B922.4070002@gmail.com>

On 4/25/2012 3:39 AM, Pieren wrote:
> On Wed, Apr 25, 2012 at 3:46 AM, Nathan Edgars II<neroute2 at gmail.com>  wrote:
>
>> It's not highway only. For example, it can be used on railway=platform:
>> http://www.openstreetmap.org/browse/way/94063273
>> or man_made=pier: http://www.openstreetmap.org/browse/way/71124853
>
> Thanks for pointing that out. I see that silently, the meaning of the
> tag area has been modified by certain people on the wiki. I modified
> the wiki about "platform":
> http://wiki.openstreetmap.org/wiki/Tag:railway%3Dplatform
>
> We cannot accept that the tag "area=yes" is required for all polygons.
> This has never been the case. It was introduced only when the main tag
> about a closed loop was non-deterministic (tracing a centre line or a
> perimeter). We don't do that for car parks, buildings, etc. I don't
> see why we should create an exception for railway platforms.

Because a railway platform is usually drawn as a single line (as is a 
pier). Omitting area=yes gives a hole in the middle.


From pieren3 at gmail.com  Wed Apr 25 09:53:39 2012
From: pieren3 at gmail.com (Pieren)
Date: Wed, 25 Apr 2012 10:53:39 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F97B922.4070002@gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
Message-ID: <CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>

On Wed, Apr 25, 2012 at 10:43 AM, Nathan Edgars II <neroute2 at gmail.com> wrote:

> Because a railway platform is usually drawn as a single line (as is a pier).
> Omitting area=yes gives a hole in the middle.

Sounds "tagging for the renderer"...

Pieren


From me at komzpa.net  Wed Apr 25 10:05:26 2012
From: me at komzpa.net (=?UTF-8?Q?Kom=D1=8Fpa?=)
Date: Wed, 25 Apr 2012 12:05:26 +0300
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
Message-ID: <CAC8Q8t+tr91b9y42GroyH_7j3hipjjd+1ga-dXrER=y6EqciRw@mail.gmail.com>

miau.

OSM does not have "area" object, thus it needs something to mark
object as polygon.

There are some tags that insist that a line/relation is filled inside.
These are area=yes and type=multipolygon.

All the other tags may mean either line or a polygon depending on
context. Sometimes context isn't clear. (Is a circular highway a
roundabout or a filled square?..)

It is rather distinct that highway=*, railway=* are linear usually,
and that landuse=*, amenity=*, shop=*, natural=*, area:highway=* are
polygonal. However, there are some cases when it's not true, like the
platform.

We either need a complete machine-readable list of tags that are
polygons or lines, or need to tag each object separately. For now I
see just the second approach being used; telling that is't invalid
without providing any reasonable fallback is a bad idea.

Currently used list can be found at
http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/default.style

-- 
Darafei "Kom?pa" Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:me at komzpa.net mailto:me at komzpa.net


From neroute2 at gmail.com  Wed Apr 25 10:17:37 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Wed, 25 Apr 2012 05:17:37 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
Message-ID: <4F97C131.5060300@gmail.com>

On 4/25/2012 4:53 AM, Pieren wrote:
> On Wed, Apr 25, 2012 at 10:43 AM, Nathan Edgars II<neroute2 at gmail.com>  wrote:
>
>> Because a railway platform is usually drawn as a single line (as is a pier).
>> Omitting area=yes gives a hole in the middle.
>
> Sounds "tagging for the renderer"...

Where did I mention a renderer? If you draw a closed polygon with 
railway=platform, that's a continuous platform with a hole in the 
middle. There may be a few cases of such in real life at a complicated 
junction.


From pieren3 at gmail.com  Wed Apr 25 11:08:25 2012
From: pieren3 at gmail.com (Pieren)
Date: Wed, 25 Apr 2012 12:08:25 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAC8Q8t+tr91b9y42GroyH_7j3hipjjd+1ga-dXrER=y6EqciRw@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<CAC8Q8t+tr91b9y42GroyH_7j3hipjjd+1ga-dXrER=y6EqciRw@mail.gmail.com>
Message-ID: <CAPT3zJpzLSQH+wEsK6iJD2c7AaC-oURCuVNSoqcnD3WT3JO5rg@mail.gmail.com>

On Wed, Apr 25, 2012 at 11:05 AM, Kom?pa <me at komzpa.net> wrote:

> OSM does not have "area" object,

not yet (maybe in API0.7)

> thus it needs something to mark
> object as polygon.

No. Most of the polygons do not require a tag "area" (amenity,
building, landuse, leisure, landuse).

> There are some tags that insist that a line/relation is filled inside.
> These are area=yes and type=multipolygon.

Sorry, I don't understand what you try to say here.
"type=multipolygon" is about relations or I miss something ?

> Sometimes context isn't clear. (Is a circular highway a
> roundabout or a filled square?..)

Agree. This case is why the tag area has been created.

> It is rather distinct that highway=*, railway=* are linear usually,

Hmm... "railway" yes, "platform" not sure. As many other features,
platform can be represented by a node, a line or a polygon. This just
depends on the contributor and his mapping level (and source accuracy
and/or motivation). Same issue with people symbolizing rivers with a
line and others with a polygon (and a centre line).

> We either need a complete machine-readable list of tags that are
> polygons or lines, or need to tag each object separately. For now I
> see just the second approach being used; telling that is't invalid
> without providing any reasonable fallback is a bad idea.
>
> Currently used list can be found at
> http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/default.style

A closed loop tagged "highway" requires an additional information.
Until a new element type "polygon" is created in the futur, the
"area=yes" makes sens here. But a closed loop for "railway=platform"
does not require any thing more than the geometry (a closed way tagged
"railway=platform" is always a polygon. Are you asking contributors to
specially tag an object just to avoid some work in osm2pgsql (detect
if the way tagged "railway=platform" is closed or not) ?

Pieren


From osm at bavarianmallet.de  Wed Apr 25 11:25:04 2012
From: osm at bavarianmallet.de (Georg Feddern)
Date: Wed, 25 Apr 2012 12:25:04 +0200
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <20120425065815.GA8634@home.home.trueelena.org>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
	<49018950-E1EB-4AD3-A74D-535941CF2C82@mapbox.com>
	<CAPT3zJpWhh72z2x-50nAdcHRhxcktVHMp5cdzwtE1kToXLUxpg@mail.gmail.com>
	<F306FECE-F3CB-4315-B5C7-3F60ED919D34@mapbox.com>
	<4F97577B.5010303@gmail.com>
	<20120425065815.GA8634@home.home.trueelena.org>
Message-ID: <4F97D100.6050900@bavarianmallet.de>

Am 25.04.2012 08:58, schrieb Elena ``of Valhalla'':
> On 2012-04-24 at 21:46:35 -0400, Nathan Edgars II wrote:
>> On 4/24/2012 2:13 PM, Alex Barth wrote:
>>> Pieren - thanks for pointing out that "area=yes" is highway only. How could the documentation for it be clearer [1]?
>> It's not highway only. For example, it can be used on
>> railway=platform: http://www.openstreetmap.org/browse/way/94063273
>> or man_made=pier: http://www.openstreetmap.org/browse/way/71124853
> but in both cases the meaning is "contrary to the default for
> the main tag, this feature has not been described by tracing
> its center line, but its perimeter"

as far as I know and always have considered, that is the meaning in 
_all_ cases - because area was invented to differentiate between the 
linear and area meaning of a tag, if it is ambiguous.
And it is documented - at least actually - for the use in both 
directions, so even to distinguish a linear feature from a default area 
feature (area=no).

But back to the "block name" question, I do not think area=yes is in 
anyway necessary there:

If you consider block as an address feature, addr:block should be used 
at the address itself, not at the block area in total.
If you consider to describe just the block area - just the perimeter - 
to name it, I think place=locality on a closed polygon would be sufficient.
Only if you need to describe the block as an entity - as an 
'administrative object' or something like that - you need a special 
place= block value.

Georg



From dieterdreist at gmail.com  Wed Apr 25 11:29:09 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Wed, 25 Apr 2012 12:29:09 +0200
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <4F97D100.6050900@bavarianmallet.de>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
	<49018950-E1EB-4AD3-A74D-535941CF2C82@mapbox.com>
	<CAPT3zJpWhh72z2x-50nAdcHRhxcktVHMp5cdzwtE1kToXLUxpg@mail.gmail.com>
	<F306FECE-F3CB-4315-B5C7-3F60ED919D34@mapbox.com>
	<4F97577B.5010303@gmail.com>
	<20120425065815.GA8634@home.home.trueelena.org>
	<4F97D100.6050900@bavarianmallet.de>
Message-ID: <CABPTjTCVEd4HSZ3jm-R9neu8ZLSfPWrbkM9sZ=6YZHqxd7rMPg@mail.gmail.com>

Am 25. April 2012 12:25 schrieb Georg Feddern <osm at bavarianmallet.de>:
> as far as I know and always have considered, that is the meaning in _all_
> cases - because area was invented to differentiate between the linear and
> area meaning of a tag, if it is ambiguous.
> And it is documented - at least actually - for the use in both directions,
> so even to distinguish a linear feature from a default area feature
> (area=no).


+1


> If you consider block as an address feature, addr:block should be used at
> the address itself, not at the block area in total.
> If you consider to describe just the block area - just the perimeter - to
> name it, I think place=locality on a closed polygon would be sufficient.
> Only if you need to describe the block as an entity - as an 'administrative
> object' or something like that - you need a special place= block value.


-1, place=locality shouldn't be used here, because according to the
wiki it is not to be used for settlements or parts of them.

cheers,
Martin


From osm at bavarianmallet.de  Wed Apr 25 15:07:31 2012
From: osm at bavarianmallet.de (Georg Feddern)
Date: Wed, 25 Apr 2012 16:07:31 +0200
Subject: [Tagging] Block names (vs street names) in Brasilia
In-Reply-To: <CABPTjTCVEd4HSZ3jm-R9neu8ZLSfPWrbkM9sZ=6YZHqxd7rMPg@mail.gmail.com>
References: <8BE2E61B-B42F-429F-B6C8-4CA39BCD252A@mapbox.com>
	<CAA=vpS9QJ43Vh3tupdf9U_Y6GXMt60jbyTOT3=dB65Zt3rZWyw@mail.gmail.com>
	<49018950-E1EB-4AD3-A74D-535941CF2C82@mapbox.com>
	<CAPT3zJpWhh72z2x-50nAdcHRhxcktVHMp5cdzwtE1kToXLUxpg@mail.gmail.com>
	<F306FECE-F3CB-4315-B5C7-3F60ED919D34@mapbox.com>
	<4F97577B.5010303@gmail.com>
	<20120425065815.GA8634@home.home.trueelena.org>
	<4F97D100.6050900@bavarianmallet.de>
	<CABPTjTCVEd4HSZ3jm-R9neu8ZLSfPWrbkM9sZ=6YZHqxd7rMPg@mail.gmail.com>
Message-ID: <4F980523.90602@bavarianmallet.de>

Am 25.04.2012 12:29, schrieb Martin Koppenhoefer:
> -1, place=locality shouldn't be used here, because according to the 
> wiki it is not to be used for settlements or parts of them

Objection granted!
I abandon this question, Your Honour! ;-)



From baloo at ursamundi.org  Wed Apr 25 18:31:58 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Wed, 25 Apr 2012 10:31:58 -0700
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
Message-ID: <CAMPM96qQMa8-4F4FvhWWr-tUpnLFeu_t62kWwnZfX9uwEDoDzA@mail.gmail.com>

On Apr 25, 2012 1:54 AM, "Pieren" <pieren3 at gmail.com> wrote:
>
> On Wed, Apr 25, 2012 at 10:43 AM, Nathan Edgars II <neroute2 at gmail.com>
wrote:
>
> > Because a railway platform is usually drawn as a single line (as is a
pier).
> > Omitting area=yes gives a hole in the middle.
>
> Sounds "tagging for the renderer"...

If it's not incorrect, and is more specific than omission would be, is that
a bad thing?  In this instance specifically, I'm inclined to say no.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120425/a4e8b6f3/attachment.html>

From sanderd17 at gmail.com  Wed Apr 25 22:23:48 2012
From: sanderd17 at gmail.com (Sander Deryckere)
Date: Wed, 25 Apr 2012 23:23:48 +0200
Subject: [Tagging] OSMI layers in JOSM
In-Reply-To: <CAKjckyO=hCEXpARdFkg=dh44ZzVUwndbfNiH0weSCeqgUDAmDA@mail.gmail.com>
References: <CAKjckyO=hCEXpARdFkg=dh44ZzVUwndbfNiH0weSCeqgUDAmDA@mail.gmail.com>
Message-ID: <CABUOUO8jHbBOqk-jukuDrnaoUuKydidSi57sm4L2z9Jy7frSPQ@mail.gmail.com>

To make it transparent, you can use one of the buttons under the JOSM layer
pane. The pane, by default in the upper right corner, where you can move
layers up and down etc.

I don't have a clue about the resolution.


Op 25 april 2012 10:28 schreef Martin Vonwald <imagic.osm at gmail.com> het
volgende:

> Hi all!
>
> I'm trying to view the OSMI layers in JOSM. The all-knowing,
> all-seeing trash heap pointed me to this (german) article:
> http://forum.openstreetmap.org/viewtopic.php?id=9315
>
> There it is recommended to use the following link in JOSM:
>
> http://tools.geofabrik.de/osmi/view/routing/wxs?REQUEST=GetMap&SERVICE=wms&VERSION=1.1.1&FORMAT=image/png&SRS=EPSG:4326&STYLES=&LAYERS=unconnected_minor1,unconnected_minor2,unconnected_minor5,unconnected_major1,unconnected_major2,unconnected_major5&
>
> This works like a charm, but with the limitations, that one has to
> adjust the resolution manually. Also I seem to be unable to get this
> layer transparent. In the article one wrote to add TRANSPARENT=TRUE to
> the link, but I can't get this working.
>
> Has anyone a hint for me how to get this layer transparent? Is there
> any possibility to autoadjust the resolution?
>
> Martin
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120425/957bf502/attachment.html>

From imagic.osm at gmail.com  Thu Apr 26 08:23:25 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Thu, 26 Apr 2012 09:23:25 +0200
Subject: [Tagging] OSMI layers in JOSM
In-Reply-To: <CABUOUO8jHbBOqk-jukuDrnaoUuKydidSi57sm4L2z9Jy7frSPQ@mail.gmail.com>
References: <CAKjckyO=hCEXpARdFkg=dh44ZzVUwndbfNiH0weSCeqgUDAmDA@mail.gmail.com>
	<CABUOUO8jHbBOqk-jukuDrnaoUuKydidSi57sm4L2z9Jy7frSPQ@mail.gmail.com>
Message-ID: <CAKjckyNwmzeuXJAqRzMuysuFmYxvsv44MopaZA4Kcrx-DZi5ow@mail.gmail.com>

Sorry, I didn't make myself clear. I don't want to make the whole
layer transparent (I know how to do that), but only the background,
i.e. I only want to see the errors. I thought that this
TRANSPARENT=TRUE will achieve this, but either I applied it wrong or
it simply doesn't work this way.

Martin

2012/4/25 Sander Deryckere <sanderd17 at gmail.com>:
> To make it transparent, you can use one of the buttons under the JOSM layer
> pane. The pane, by default in the upper right corner, where you can move
> layers up and down etc.
>
> I don't have a clue about the resolution.
>
>
> Op 25 april 2012 10:28 schreef Martin Vonwald <imagic.osm at gmail.com> het
> volgende:
>>
>> Hi all!
>>
>> I'm trying to view the OSMI layers in JOSM. The all-knowing,
>> all-seeing trash heap pointed me to this (german) article:
>> http://forum.openstreetmap.org/viewtopic.php?id=9315
>>
>> There it is recommended to use the following link in JOSM:
>>
>> http://tools.geofabrik.de/osmi/view/routing/wxs?REQUEST=GetMap&SERVICE=wms&VERSION=1.1.1&FORMAT=image/png&SRS=EPSG:4326&STYLES=&LAYERS=unconnected_minor1,unconnected_minor2,unconnected_minor5,unconnected_major1,unconnected_major2,unconnected_major5&
>>
>> This works like a charm, but with the limitations, that one has to
>> adjust the resolution manually. Also I seem to be unable to get this
>> layer transparent. In the article one wrote to add TRANSPARENT=TRUE to
>> the link, but I can't get this working.
>>
>> Has anyone a hint for me how to get this layer transparent? Is there
>> any possibility to autoadjust the resolution?
>>
>> Martin
>>
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/tagging
>
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
>


From imagic.osm at gmail.com  Thu Apr 26 10:30:26 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Thu, 26 Apr 2012 11:30:26 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
Message-ID: <CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>

To give you an advance warning: the updated article is finished and
currently available here:
http://wiki.openstreetmap.org/wiki/User:Imagic/Werkstatt

If there are no major objections I will update the lanes article
tomorrow. Minor objections we can further discuss after the update -
otherwise it wouldn't be updated any time soon ;-) Although I hope,
that I was able to respect most issues. Thanks for all your input
during this discussion.

Please take a look at the section "Lanes reserved for specific
vehicles". While writing the update I became aware of a difference
regarding the lanes for various types of vehicles.

Also take a look at the section "Assumptions". I added there a row for
motorways/trunks. I'm not 100% sure if this is valid for all trunks.

As I'm not a native speaker any corrections are welcome.

Martin


From phil at trigpoint.me.uk  Thu Apr 26 11:43:37 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Thu, 26 Apr 2012 10:43:37 +0000
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
Message-ID: <kev2fx.m331t8.2xs3qu-qmf@auth.smtp.oneandone.co.uk>

Please could someone confirm what Spitsstrook is? It looks like use of the hard shoulder on managed sections of motorway, but I cannot read dutch.

We have these on the M6 and M42.

Thanks Phil


On 26/04/2012 10:30 Martin Vonwald wrote:

To give you an advance warning: the updated article is finished and
currently available here:

http://wiki.openstreetmap.org/wiki/User:Imagic/Werkstatt


If there are no major objections I will update the lanes article
tomorrow. Minor objections we can further discuss after the update -
otherwise it wouldn't be updated any time soon ;-) Although I hope,
that I was able to respect most issues. Thanks for all your input
during this discussion.


Please take a look at the section "Lanes reserved for specific
vehicles". While writing the update I became aware of a difference
regarding the lanes for various types of vehicles.


Also take a look at the section "Assumptions". I added there a row for
motorways/trunks. I'm not 100% sure if this is valid for all trunks.


As I'm not a native speaker any corrections are welcome.


Martin

_______________________________________________

Tagging mailing list

Tagging at openstreetmap.org
http://wiki.openstreetmap.org/wiki/User:Imagic/Werkstatt



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120426/704015b6/attachment.html>

From imagic.osm at gmail.com  Thu Apr 26 11:51:05 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Thu, 26 Apr 2012 12:51:05 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <kev2fx.m331t8.2xs3qu-qmf@auth.smtp.oneandone.co.uk>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<kev2fx.m331t8.2xs3qu-qmf@auth.smtp.oneandone.co.uk>
Message-ID: <CAKjckyP=cxsV27oNx4jE0_s9x8kZJk5PAyXjWN2tO8hvtq15PA@mail.gmail.com>

It is an additional lane that will be opened for the general traffic
during rush hours. What I have seen in the Netherlands it is used as
emergency lanes at other times.

Martin

2012/4/26 Philip Barnes <phil at trigpoint.me.uk>:
> Please could someone confirm what Spitsstrook is? It looks like use of the
> hard shoulder on managed sections of motorway, but I cannot read dutch.
>
>
> We have these on the M6 and M42.
>
>
> Thanks Phil
>
>
> On 26/04/2012 10:30 Martin Vonwald wrote:
>
> To give you an advance warning: the updated article is finished and
> currently available here:
> http://wiki.openstreetmap.org/wiki/User:Imagic/Werkstatt
>
> If there are no major objections I will update the lanes article
> tomorrow. Minor objections we can further discuss after the update -
> otherwise it wouldn't be updated any time soon ;-) Although I hope,
> that I was able to respect most issues. Thanks for all your input
> during this discussion.
>
> Please take a look at the section "Lanes reserved for specific
> vehicles". While writing the update I became aware of a difference
> regarding the lanes for various types of vehicles.
>
> Also take a look at the section "Assumptions". I added there a row for
> motorways/trunks. I'm not 100% sure if this is valid for all trunks.
>
> As I'm not a native speaker any corrections are welcome.
>
> Martin
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://wiki.openstreetmap.org/wiki/User:Imagic/Werkstatt
>
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
>


From colin.smale at xs4all.nl  Thu Apr 26 12:07:06 2012
From: colin.smale at xs4all.nl (Colin Smale)
Date: Thu, 26 Apr 2012 13:07:06 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyP=cxsV27oNx4jE0_s9x8kZJk5PAyXjWN2tO8hvtq15PA@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<kev2fx.m331t8.2xs3qu-qmf@auth.smtp.oneandone.co.uk>
	<CAKjckyP=cxsV27oNx4jE0_s9x8kZJk5PAyXjWN2tO8hvtq15PA@mail.gmail.com>
Message-ID: <4F992C5A.2030906@xs4all.nl>

There are three cases in NL, all referred to as "spitsstrook" 
(literally, rush-hour lane):

1) the hard shoulder is sometimes opened to traffic, creating an extra 
lane on the right
2) the left-most lane is sometimes open (if traffic is heavier), and 
sometimes closed (if the extra capacity is not needed). When it is 
closed, it is not designated as an "emergency" lane, but as emergency 
vehicles can do what they like anyway, they don't hesitate to use it. I 
am not sure if a normal driver is allowed to "park" there in case of a 
breakdown. Even if it is allowed, I would most definitely advise against 
it...
3) there is one case of a reversible centre lane which is either closed, 
open in one direction (morning peak) or open in the other direction 
(evening peak). Of course there are barriers on both sides to insulate 
it from the main carriageways on either side.

Colin

On 26/04/2012 12:51, Martin Vonwald wrote:
> It is an additional lane that will be opened for the general traffic
> during rush hours. What I have seen in the Netherlands it is used as
> emergency lanes at other times.
>
> Martin
>
> 2012/4/26 Philip Barnes<phil at trigpoint.me.uk>:
>> Please could someone confirm what Spitsstrook is? It looks like use of the
>> hard shoulder on managed sections of motorway, but I cannot read dutch.
>>
>>



From lowflight66 at googlemail.com  Thu Apr 26 12:37:05 2012
From: lowflight66 at googlemail.com (fly)
Date: Thu, 26 Apr 2012 13:37:05 +0200
Subject: [Tagging] OSMI layers in JOSM
In-Reply-To: <CAKjckyNwmzeuXJAqRzMuysuFmYxvsv44MopaZA4Kcrx-DZi5ow@mail.gmail.com>
References: <CAKjckyO=hCEXpARdFkg=dh44ZzVUwndbfNiH0weSCeqgUDAmDA@mail.gmail.com>
	<CABUOUO8jHbBOqk-jukuDrnaoUuKydidSi57sm4L2z9Jy7frSPQ@mail.gmail.com>
	<CAKjckyNwmzeuXJAqRzMuysuFmYxvsv44MopaZA4Kcrx-DZi5ow@mail.gmail.com>
Message-ID: <4F993361.7060302@googlemail.com>

Hey Martin

Sorry I am neither an expert in WMS, but

as JOSM has changed a lot and if you do not find it in any documentation it
would be the best to ask at josm-dev@ and either document it yourself or open a
ticket about missing documentation.

Cheers fly


From pieren3 at gmail.com  Thu Apr 26 13:47:43 2012
From: pieren3 at gmail.com (Pieren)
Date: Thu, 26 Apr 2012 14:47:43 +0200
Subject: [Tagging] "contact:phone" or "phone" to combine with
	"amenity=telephone"
Message-ID: <CAPT3zJoJYjgVCCAHOOr7Wks0KTM96zvrfk6H3qmacwkjGJ2h8w@mail.gmail.com>

http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dtelephone
is saying that the phone box number has to be tagged with "contact:phone".

The "contact:" namespace has been discussed here
(http://lists.openstreetmap.org/pipermail/tagging/2011-May/007631.html)
and some good arguments have been raised against it.
Unfortunatelly, nothing really happend excepted some minor remarks and
the namespace is spreading in the wiki like in "amenity=telephone"
page but not in the database where it is only combined with "phone"
(http://taginfo.openstreetmap.org/tags/?key=amenity&value=telephone#combinations),
not "contact:phone".

I'm asking because the question why we don't use "phone" instead of
"contact:phone" is now asked on one of the translated version
(http://wiki.openstreetmap.org/wiki/FR_talk:Tag:amenity%3Dtelephone).

Can we use the taginfo stats to revert the change made the 2nd may
2010 where "phone" has been replaced by "contact:phone" and add a big
"deprecate" notice on the "contact:" namespace wiki ? (overall, we
still have 10 times more "phone" than "contact:phone", 20 times more
"website" than "contact:website", etc)

Pieren


From dieterdreist at gmail.com  Thu Apr 26 13:51:01 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Thu, 26 Apr 2012 14:51:01 +0200
Subject: [Tagging] "contact:phone" or "phone" to combine with
	"amenity=telephone"
In-Reply-To: <CAPT3zJoJYjgVCCAHOOr7Wks0KTM96zvrfk6H3qmacwkjGJ2h8w@mail.gmail.com>
References: <CAPT3zJoJYjgVCCAHOOr7Wks0KTM96zvrfk6H3qmacwkjGJ2h8w@mail.gmail.com>
Message-ID: <CABPTjTD9-qviqf1XxCXhU7HAPQBqgLjC++U8zmb1XaSFqV+p3w@mail.gmail.com>

Am 26. April 2012 14:47 schrieb Pieren <pieren3 at gmail.com>:
> Can we use the taginfo stats to revert the change made the 2nd may
> 2010 where "phone" has been replaced by "contact:phone" and add a big
> "deprecate" notice on the "contact:" namespace wiki ? (overall, we
> still have 10 times more "phone" than "contact:phone", 20 times more
> "website" than "contact:website", etc)


+1 from me, but I know there are other mappers opposing this and
trying to push the "contact:" prefix.

cheers,
Martin


From osm at bavarianmallet.de  Thu Apr 26 14:24:50 2012
From: osm at bavarianmallet.de (Georg Feddern)
Date: Thu, 26 Apr 2012 15:24:50 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <4F992C5A.2030906@xs4all.nl>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<kev2fx.m331t8.2xs3qu-qmf@auth.smtp.oneandone.co.uk>
	<CAKjckyP=cxsV27oNx4jE0_s9x8kZJk5PAyXjWN2tO8hvtq15PA@mail.gmail.com>
	<4F992C5A.2030906@xs4all.nl>
Message-ID: <4F994CA2.1090008@bavarianmallet.de>

Am 26.04.2012 13:07, schrieb Colin Smale:
> 1) the hard shoulder is sometimes opened to traffic, creating an extra 
> lane on the right

this case is used in Germany in several regions

e.g.
http://www.staufreieshessen2015.hessen.de/irj/servlet/prt/portal/prtroot/slimp.CMReader/HMWVL_15/Staufrei_Internet/med/c6f/c6f50ce6-66e7-3e21-79cd-aae2389e4818,22222222-2222-2222-2222-222222222222

and this leads very fast to the question:

Shall this lane
- be counted - because it is a managed lane, but that it is only sometimes
- or not - because it is most of the time an emergency lane

The article is ambiguous here.

Georg



From imagic.osm at gmail.com  Thu Apr 26 14:37:42 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Thu, 26 Apr 2012 15:37:42 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <4F994CA2.1090008@bavarianmallet.de>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<kev2fx.m331t8.2xs3qu-qmf@auth.smtp.oneandone.co.uk>
	<CAKjckyP=cxsV27oNx4jE0_s9x8kZJk5PAyXjWN2tO8hvtq15PA@mail.gmail.com>
	<4F992C5A.2030906@xs4all.nl> <4F994CA2.1090008@bavarianmallet.de>
Message-ID: <CAKjckyMfUot6eExngTFruf8Mu3VxSYjp78F9V3j0eynrmWb44A@mail.gmail.com>

2012/4/26 Georg Feddern <osm at bavarianmallet.de>:
> Shall this lane
> - be counted - because it is a managed lane, but that it is only sometimes
> - or not - because it is most of the time an emergency lane

Yes, it shall be counted, because it is all the time a managed lane,
that is sometimes open for traffic and sometimes not.

> The article is ambiguous here.

Managed lanes shall be counted.

Martin


From dieterdreist at gmail.com  Thu Apr 26 14:50:32 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Thu, 26 Apr 2012 15:50:32 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyMfUot6eExngTFruf8Mu3VxSYjp78F9V3j0eynrmWb44A@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<kev2fx.m331t8.2xs3qu-qmf@auth.smtp.oneandone.co.uk>
	<CAKjckyP=cxsV27oNx4jE0_s9x8kZJk5PAyXjWN2tO8hvtq15PA@mail.gmail.com>
	<4F992C5A.2030906@xs4all.nl> <4F994CA2.1090008@bavarianmallet.de>
	<CAKjckyMfUot6eExngTFruf8Mu3VxSYjp78F9V3j0eynrmWb44A@mail.gmail.com>
Message-ID: <CABPTjTCbR-iThFJTGQoQkjwdogieWPLCH-d2+Aatz_J9J7+OOQ@mail.gmail.com>

Am 26. April 2012 15:37 schrieb Martin Vonwald <imagic.osm at gmail.com>:
> 2012/4/26 Georg Feddern <osm at bavarianmallet.de>:
>> Shall this lane
>> - be counted - because it is a managed lane, but that it is only sometimes
>> - or not - because it is most of the time an emergency lane
>
> Yes, it shall be counted, because it is all the time a managed lane,
> that is sometimes open for traffic and sometimes not.


+1

cheers,
Martin


From imagic.osm at gmail.com  Thu Apr 26 15:10:31 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Thu, 26 Apr 2012 16:10:31 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <4F994CA2.1090008@bavarianmallet.de>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<kev2fx.m331t8.2xs3qu-qmf@auth.smtp.oneandone.co.uk>
	<CAKjckyP=cxsV27oNx4jE0_s9x8kZJk5PAyXjWN2tO8hvtq15PA@mail.gmail.com>
	<4F992C5A.2030906@xs4all.nl> <4F994CA2.1090008@bavarianmallet.de>
Message-ID: <CAKjckyO_JU5gjJaaOVdRGVFHmr6GweiMCsgQ7FUiY0Ecj5dhaA@mail.gmail.com>

I added a sentence explaining what a "managed lane" is. Understandable now?


2012/4/26 Georg Feddern <osm at bavarianmallet.de>:
> Am 26.04.2012 13:07, schrieb Colin Smale:
>
>> 1) the hard shoulder is sometimes opened to traffic, creating an extra
>> lane on the right
>
>
> this case is used in Germany in several regions
>
> e.g.
> http://www.staufreieshessen2015.hessen.de/irj/servlet/prt/portal/prtroot/slimp.CMReader/HMWVL_15/Staufrei_Internet/med/c6f/c6f50ce6-66e7-3e21-79cd-aae2389e4818,22222222-2222-2222-2222-222222222222
>
> and this leads very fast to the question:
>
> Shall this lane
> - be counted - because it is a managed lane, but that it is only sometimes
> - or not - because it is most of the time an emergency lane
>
> The article is ambiguous here.
>
> Georg
>
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging


From osm at inbox.org  Thu Apr 26 15:36:02 2012
From: osm at inbox.org (Anthony)
Date: Thu, 26 Apr 2012 10:36:02 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F97C131.5060300@gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
Message-ID: <CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>

On Wed, Apr 25, 2012 at 5:17 AM, Nathan Edgars II <neroute2 at gmail.com> wrote:
> Where did I mention a renderer? If you draw a closed polygon with
> railway=platform, that's a continuous platform with a hole in the middle.
> There may be a few cases of such in real life at a complicated junction.

If so, they should be tagged with area=no.


From niceman at att.net  Thu Apr 26 17:07:18 2012
From: niceman at att.net (Mike N)
Date: Thu, 26 Apr 2012 12:07:18 -0400
Subject: [Tagging] "contact:phone" or "phone" to combine with
	"amenity=telephone"
In-Reply-To: <CABPTjTD9-qviqf1XxCXhU7HAPQBqgLjC++U8zmb1XaSFqV+p3w@mail.gmail.com>
References: <CAPT3zJoJYjgVCCAHOOr7Wks0KTM96zvrfk6H3qmacwkjGJ2h8w@mail.gmail.com>
	<CABPTjTD9-qviqf1XxCXhU7HAPQBqgLjC++U8zmb1XaSFqV+p3w@mail.gmail.com>
Message-ID: <4F9972B6.8050703@att.net>

On 4/26/2012 8:51 AM, Martin Koppenhoefer wrote:
>> Can we use the taginfo stats to revert the change made the 2nd may
>> >  2010 where "phone" has been replaced by "contact:phone" and add a big
>> >  "deprecate" notice on the "contact:" namespace wiki ? (overall, we
>> >  still have 10 times more "phone" than "contact:phone", 20 times more
>> >  "website" than "contact:website", etc)
>
> +1 from me, but I know there are other mappers opposing this and
> trying to push the "contact:" prefix.

    I agree with those wanting the 'contact:' format that it is 
unambiguous and might be easier to use and analyze, but since no data 
consumers use it (that I know of), 'phone' is preferred.    I know of 
several data consumers on mobile apps that use 'phone'.


From jamicuosm at googlemail.com  Thu Apr 26 19:03:39 2012
From: jamicuosm at googlemail.com (Jason Cunningham)
Date: Thu, 26 Apr 2012 19:03:39 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
Message-ID: <CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>

On 26 April 2012 10:30, Martin Vonwald <imagic.osm at gmail.com> wrote:

> To give you an advance warning: the updated article is finished and
> currently available here:
> http://wiki.openstreetmap.org/wiki/User:Imagic/Werkstatt
>
> If there are no major objections I will update the lanes article
> tomorrow.
>

I suppose I've got a few "major objections", and a few minor

*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 lanes tag and forget about it.

The example given for the 'narrow' road, which you advise should be tagged
as lanes=2 looks more like lanes=1 especially as there is a need for a
passing place.

*Major Problem:* The Assumptions section, I think, is a very bad idea. The
'Remark' for everything other than motorways/trunk suggests not to add the
lane data, but rely on the assumption. If you do not know how many lanes
are present the Assumptions table is good idea to what might be present.
But surveyed data is superior to an assumption, and we must not encourage
people not to add the data.

highway=path is considered not to be for motor vehicles, but the assumption
is correct if the path has been tagged accessible to a type of vehicle.

Assumptions for mortorway/trunk need to be clarified because these
highways  are commonly considered to consist of two carriageways? and
mapping guidance has always stated the the carriageways should be mapped as
two separate way? I'd simply remove the "4 or more" and leave that box
blank.

Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120426/b232b9b6/attachment.html>

From dieterdreist at gmail.com  Thu Apr 26 20:40:58 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Thu, 26 Apr 2012 21:40:58 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
Message-ID: <CABPTjTBFP0AN3zaBdxRfrdcyEqXFrvpSNeCfrrDfs7gHG0WDfg@mail.gmail.com>

Am 26. April 2012 20:03 schrieb Jason Cunningham <jamicuosm at googlemail.com>:
> 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 lanes tag and forget about it.


IMHO it would be a good idea to remove fractional lanes amounts and
forget about them. They are too subjective.

What do you think of lanes=3.5? I have an example here:

http://maps.google.it/maps?hl=en&ll=41.899274,12.464333&spn=0.008497,0.021136&t=h&z=16&layer=c&cbll=41.899391,12.464289&panoid=O8BHrnM_gTAW2XQUWqxcXg&cbp=12,353.6,,0,4.57

Not sure, how many lanes these are, could be 5 or even 5.5? Depends on
the car widths and the experience of the drivers:

http://maps.google.it/maps?hl=en&ll=41.876836,12.481943&spn=0.000378,0.00066&t=h&z=21

if we start entering fractional lanes counts, mapping will get more
complicated, with no real benefit: Every street has an unambiguous
width, which is a more helpful information to determine how many
vehicles can pass at the same time, lanes=1.5 doesn't really help you,
it will always remain unclear which width is the street.

cheers,
Martin


From imagic.osm at gmail.com  Thu Apr 26 21:09:05 2012
From: imagic.osm at gmail.com (Martin Vonwald (Imagic))
Date: Thu, 26 Apr 2012 22:09:05 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
Message-ID: <1984FFA7-94BD-4A55-B6C9-6DD4CB12AF45@gmail.com>

Am 26.04.2012 um 20:03 schrieb Jason Cunningham <jamicuosm at googlemail.com>:

> 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 lanes tag and forget about it.

Actually I thought it was solved by specifying the width. And I can't cleanse it from the database by - for the first time as far as I can see - mention lanes=1.5 in the wiki.


> Major Problem: The Assumptions section, I think, is a very bad idea. The 'Remark' for everything other than motorways/trunk suggests not to add the lane data, but rely on the assumption. If you do not know how many lanes are present the Assumptions table is good idea to what might be present. But surveyed data is superior to an assumption, and we must not encourage people not to add the data.

In the remarks I wrote "... is usually not tagged...", which afaik is the truth. I also had the impression, that we don't want the lanes-tag on every residential road. If this is not the case I could remove the "none" from the residential-road-example and rephrase the assumptions.

Martin

From john at jfeldredge.com  Thu Apr 26 21:44:22 2012
From: john at jfeldredge.com (John F. Eldredge)
Date: Thu, 26 Apr 2012 15:44:22 -0500
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CABPTjTBFP0AN3zaBdxRfrdcyEqXFrvpSNeCfrrDfs7gHG0WDfg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
	<CABPTjTBFP0AN3zaBdxRfrdcyEqXFrvpSNeCfrrDfs7gHG0WDfg@mail.gmail.com>
Message-ID: <8076ad16-5150-4ec0-abff-c794d8efd66a@email.android.com>

Martin Koppenhoefer <dieterdreist at gmail.com> wrote:

> Am 26. April 2012 20:03 schrieb Jason Cunningham
> <jamicuosm at googlemail.com>:
> > 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 lanes tag and forget about it.
> 
> 
> IMHO it would be a good idea to remove fractional lanes amounts and
> forget about them. They are too subjective.
> 
> What do you think of lanes=3.5? I have an example here:
> 
> http://maps.google.it/maps?hl=en&ll=41.899274,12.464333&spn=0.008497,0.021136&t=h&z=16&layer=c&cbll=41.899391,12.464289&panoid=O8BHrnM_gTAW2XQUWqxcXg&cbp=12,353.6,,0,4.57
> 
> Not sure, how many lanes these are, could be 5 or even 5.5? Depends on
> the car widths and the experience of the drivers:
> 
> http://maps.google.it/maps?hl=en&ll=41.876836,12.481943&spn=0.000378,0.00066&t=h&z=21
> 
> if we start entering fractional lanes counts, mapping will get more
> complicated, with no real benefit: Every street has an unambiguous
> width, which is a more helpful information to determine how many
> vehicles can pass at the same time, lanes=1.5 doesn't really help you,
> it will always remain unclear which width is the street.
> 
> cheers,
> Martin
> 

For that matter, even if the number of lanes remains constant, the actual width of the street, and of the individual lanes, may vary from point to point.  Routing software that takes into account road width needs to retrieve and check the width for the entire route.

-- 
John F. Eldredge --  john at jfeldredge.com
"Reserve your right to think, for even to think wrongly is better than not to think at all." -- Hypatia of Alexandria


From osm at tobias-knerr.de  Fri Apr 27 01:53:48 2012
From: osm at tobias-knerr.de (Tobias Knerr)
Date: Fri, 27 Apr 2012 02:53:48 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
Message-ID: <4F99EE1C.1020807@tobias-knerr.de>

Anthony wrote:
> On Wed, Apr 25, 2012 at 5:17 AM, Nathan Edgars II <neroute2 at gmail.com> wrote:
>> Where did I mention a renderer? If you draw a closed polygon with
>> railway=platform, that's a continuous platform with a hole in the middle.
>> There may be a few cases of such in real life at a complicated junction.
> 
> If so, they should be tagged with area=no.

"area=no" can be considered a "sic!", but that tag should never have any
actual effect.

If a feature can be either a closed way or an area, the default
interpretation should always be the closed way. Otherwise, you'd have to
know arbitrary defaults for each type of object.

Tobias


From imagic.osm at gmail.com  Fri Apr 27 08:18:49 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Fri, 27 Apr 2012 09:18:49 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
Message-ID: <CAKjckyMdb8ChSQCktkBHuRxkq4NV-vsXv2r73MmzucDZSNNSnQ@mail.gmail.com>

The "narrow road" example was clearly the wrong image. I changed that
to lanes=1 and added a photo from Philip Barnes as example for a
narrow two-lane road.

Further I removed the assumptions for two-way motorways/trunks, as it
is recommend to map their carriageways as two separate way.

Anyone else has a problem with the suggested solution to the lanes=1.5
problem? And should I add a recommendation to always tag the lane
count, also e.g. for residentials?

Martin


From ilpo.jarvinen at helsinki.fi  Fri Apr 27 08:23:09 2012
From: ilpo.jarvinen at helsinki.fi (=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=)
Date: Fri, 27 Apr 2012 10:23:09 +0300 (EEST)
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CABPTjTBFP0AN3zaBdxRfrdcyEqXFrvpSNeCfrrDfs7gHG0WDfg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
	<CABPTjTBFP0AN3zaBdxRfrdcyEqXFrvpSNeCfrrDfs7gHG0WDfg@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204270957010.9350@melkinpaasi.cs.helsinki.fi>

On Thu, 26 Apr 2012, Martin Koppenhoefer wrote:

> Am 26. April 2012 20:03 schrieb Jason Cunningham <jamicuosm at googlemail.com>:
> > 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 lanes tag and forget about it.
> 
> 
> IMHO it would be a good idea to remove fractional lanes amounts and
> forget about them. They are too subjective.

...Like I said, this is pretty much verifiable by observing cars (but in 
practice there would be quite few cases where even that would be 
necessary, and the impact of mistagging in such case is anyway negligible).
I'm afraid that osm community starts enforce more and more this "too 
subjective" argument (which seems "too subjective" itself btw ;-)) to 
undermine osm map from its strength by _preventing use of local 
knowledge_(!) to produce _useful_ map instead of "correct by 
specification" one, eventually that leads to cycleways going though bus 
station crowds just because it's officially legal to cycle there 
(instead of highway=footway with proper access tags, uh-oh, I mentioned 
another subjective monster :-)), etc.

> What do you think of lanes=3.5? I have an example here:
> 
> Not sure, how many lanes these are, could be 5 or even 5.5? Depends on
> the car widths and the experience of the drivers:

Heheh... :-) ...there's one major difference between 1.5 and >=2.5, ie., 
whether the traffic in one direction almost always interferes with the 
opposite direction of the traffic, in the latter case it shouldn't happen 
(at least on the quieter hours with just two cars). I suppose you knew 
this though but just are in "opposing mode" so any argument is good
enough ;-).


-- 
 i.


From pieren3 at gmail.com  Fri Apr 27 08:37:23 2012
From: pieren3 at gmail.com (Pieren)
Date: Fri, 27 Apr 2012 09:37:23 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyMdb8ChSQCktkBHuRxkq4NV-vsXv2r73MmzucDZSNNSnQ@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
	<CAKjckyMdb8ChSQCktkBHuRxkq4NV-vsXv2r73MmzucDZSNNSnQ@mail.gmail.com>
Message-ID: <CAPT3zJoS6pwszBNda_o4CPfH3r6V_zJPCJavcFO1_a4LbXWcWQ@mail.gmail.com>

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 applications). I still don't
know if 1.5 means "an intermediate status between 2 lanes and 1 lane
segments" or "a wide single lane" or "a normal lane plus a half size
lane" or "two narrow lanes".

Pieren


From ilpo.jarvinen at helsinki.fi  Fri Apr 27 08:58:10 2012
From: ilpo.jarvinen at helsinki.fi (=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=)
Date: Fri, 27 Apr 2012 10:58:10 +0300 (EEST)
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAPT3zJoS6pwszBNda_o4CPfH3r6V_zJPCJavcFO1_a4LbXWcWQ@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
	<CAKjckyMdb8ChSQCktkBHuRxkq4NV-vsXv2r73MmzucDZSNNSnQ@mail.gmail.com>
	<CAPT3zJoS6pwszBNda_o4CPfH3r6V_zJPCJavcFO1_a4LbXWcWQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204271054090.9350@melkinpaasi.cs.helsinki.fi>

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 applications). I still don't
> know if 1.5 means 

> "an intermediate status between 2 lanes and 1 lane segments"
> "a wide single lane"
> "a normal lane plus a half size lane"
> "two narrow lanes"

...While I didn't fully understand the first definition. ...I don't find 
much different between those definitions but perhaps you can enlighten me 
if there's anything else than some fancy wordsmithing looking into the 
very same road from different angles? :-)


-- 
 i.


From ilpo.jarvinen at helsinki.fi  Fri Apr 27 09:06:58 2012
From: ilpo.jarvinen at helsinki.fi (=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=)
Date: Fri, 27 Apr 2012 11:06:58 +0300 (EEST)
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <alpine.DEB.2.00.1204271054090.9350@melkinpaasi.cs.helsinki.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
	<CAKjckyMdb8ChSQCktkBHuRxkq4NV-vsXv2r73MmzucDZSNNSnQ@mail.gmail.com>
	<CAPT3zJoS6pwszBNda_o4CPfH3r6V_zJPCJavcFO1_a4LbXWcWQ@mail.gmail.com>
	<alpine.DEB.2.00.1204271054090.9350@melkinpaasi.cs.helsinki.fi>
Message-ID: <alpine.DEB.2.00.1204271102590.9350@melkinpaasi.cs.helsinki.fi>

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 we should simply recommend to not use fractions since they can
> > be misinterpreted by any one (not only applications). I still don't
> > know if 1.5 means 
> 
> > "an intermediate status between 2 lanes and 1 lane segments"
> > "a wide single lane"
> > "a normal lane plus a half size lane"
> > "two narrow lanes"
> 
> ...While I didn't fully understand the first definition. ...I don't find 
> much different between those definitions but perhaps you can enlighten me 
> if there's anything else than some fancy wordsmithing looking into the 
> very same road from different angles? :-)

Btw, IMHO these plurar definitions you gave for the same thing is one 
of the reasons why lanes=1.5 appears in the db in the first place.
The width alternative hardly conveys all the same meaning as it cannot 
say lanes=1+wide and lanes=2+narrow at the same time!

-- 
 i.

From pieren3 at gmail.com  Fri Apr 27 09:12:11 2012
From: pieren3 at gmail.com (Pieren)
Date: Fri, 27 Apr 2012 10:12:11 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F99EE1C.1020807@tobias-knerr.de>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
Message-ID: <CAPT3zJpNbpcgV9h6Lu5YrU+ACr5z1qKeDqOPY911sU7zb4EyGg@mail.gmail.com>

On Fri, Apr 27, 2012 at 2:53 AM, Tobias Knerr <osm at tobias-knerr.de> wrote:

> If a feature can be either a closed way or an area, the default
> interpretation should always be the closed way. Otherwise, you'd have to
> know arbitrary defaults for each type of object.

You have to know anyway if your feature can be either a closed way or
an area and therefore need some special handling in your apps. The
question is then more to consider certain features as "area" or
"closed way" by default. On this point, I'm always standing on the
contributors side and wont ask them to add an unnecessary tag for
99.99% of the cases.

Pieren


From pieren3 at gmail.com  Fri Apr 27 09:30:51 2012
From: pieren3 at gmail.com (Pieren)
Date: Fri, 27 Apr 2012 10:30:51 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <alpine.DEB.2.00.1204271054090.9350@melkinpaasi.cs.helsinki.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
	<CAKjckyMdb8ChSQCktkBHuRxkq4NV-vsXv2r73MmzucDZSNNSnQ@mail.gmail.com>
	<CAPT3zJoS6pwszBNda_o4CPfH3r6V_zJPCJavcFO1_a4LbXWcWQ@mail.gmail.com>
	<alpine.DEB.2.00.1204271054090.9350@melkinpaasi.cs.helsinki.fi>
Message-ID: <CAPT3zJo9PpEyDY2+St4Gp6QShxHu4gzcj_pBr1UXcNevVKRr_Q@mail.gmail.com>

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 something in between.
Sometimes it is related to the width, sometimes only about the
painting on the road. It is bit more than "fancy wordsmithing". It is
simply impossible to interpret. As Martin said, it is too subjective
and should be avoided.

Pieren


From ilpo.jarvinen at helsinki.fi  Fri Apr 27 09:57:44 2012
From: ilpo.jarvinen at helsinki.fi (=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=)
Date: Fri, 27 Apr 2012 11:57:44 +0300 (EEST)
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAPT3zJo9PpEyDY2+St4Gp6QShxHu4gzcj_pBr1UXcNevVKRr_Q@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
	<CAKjckyMdb8ChSQCktkBHuRxkq4NV-vsXv2r73MmzucDZSNNSnQ@mail.gmail.com>
	<CAPT3zJoS6pwszBNda_o4CPfH3r6V_zJPCJavcFO1_a4LbXWcWQ@mail.gmail.com>
	<alpine.DEB.2.00.1204271054090.9350@melkinpaasi.cs.helsinki.fi>
	<CAPT3zJo9PpEyDY2+St4Gp6QShxHu4gzcj_pBr1UXcNevVKRr_Q@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204271147560.9350@melkinpaasi.cs.helsinki.fi>

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 something in between.

- If it would be lanes=1 it would be tagged as such, but it's not lanes=1.
- If it would be real lanes=2 it would be tagges as such, but it's not 
  lanes=2.

...So it's something in between always!

> Sometimes it is related to the width, sometimes only about the
> painting on the road.

??? There's no painting in any of those I would have seen. ...Perhaps
you have some example where there's lanes=1.5 in OSM tagged and there's 
painted center line? Otherwise I assume you just want to make it 
"impossible to interpret" to yourself using such imaginary trick.

> It is bit more than "fancy wordsmithing". It is simply impossible to 
> interpret.

...Sure, noone can convince you otherwise? :-)


-- 
 i.

From a.errington at lancaster.ac.uk  Fri Apr 27 10:29:15 2012
From: a.errington at lancaster.ac.uk (Andrew Errington)
Date: Fri, 27 Apr 2012 18:29:15 +0900
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <alpine.DEB.2.00.1204271147560.9350@melkinpaasi.cs.helsinki.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAPT3zJo9PpEyDY2+St4Gp6QShxHu4gzcj_pBr1UXcNevVKRr_Q@mail.gmail.com>
	<alpine.DEB.2.00.1204271147560.9350@melkinpaasi.cs.helsinki.fi>
Message-ID: <201204271829.16224.a.errington@lancaster.ac.uk>

I'm quite happy with lanes=n where n is an integer.

I am very happy to assume that a one-way road without lanes=* has only one 
lane.

I am also happy to assume that a not-one-way road without lanes=* has two 
lanes (one in each direction).

I am extremely happy to see a width=* tag that I can use in conjunction with 
the lane count (even if the lane count is assumed).  It tells me the width of 
each lane.

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?  It's 
more useful to tell me width of the road.  Then, if there is one lane I can 
see maybe it's very wide, or if two lanes I can see maybe they are very 
narrow.  It's okay to let me assume the number of lanes because the 
assumption is safe, and if it's really wrong then someone will tag it 
properly later.

In summary, I think simpler is better.  A non-integer lane count is useless.  
Use the width tag.

Best wishes,

Andrew


From osm at bavarianmallet.de  Fri Apr 27 10:45:04 2012
From: osm at bavarianmallet.de (Georg Feddern)
Date: Fri, 27 Apr 2012 11:45:04 +0200
Subject: [Tagging] "contact:phone" or "phone" to combine with
	"amenity=telephone"
In-Reply-To: <4F9972B6.8050703@att.net>
References: <CAPT3zJoJYjgVCCAHOOr7Wks0KTM96zvrfk6H3qmacwkjGJ2h8w@mail.gmail.com>
	<CABPTjTD9-qviqf1XxCXhU7HAPQBqgLjC++U8zmb1XaSFqV+p3w@mail.gmail.com>
	<4F9972B6.8050703@att.net>
Message-ID: <4F9A6AA0.9080001@bavarianmallet.de>

Am 26.04.2012 18:07, schrieb Mike N:
> On 4/26/2012 8:51 AM, Martin Koppenhoefer wrote:
>>> Can we use the taginfo stats to revert the change made the 2nd may
>>> >  2010 where "phone" has been replaced by "contact:phone" and add a 
>>> big
>>> >  "deprecate" notice on the "contact:" namespace wiki ? (overall, we
>>> >  still have 10 times more "phone" than "contact:phone", 20 times more
>>> >  "website" than "contact:website", etc)
>>
>> +1 from me, but I know there are other mappers opposing this and
>> trying to push the "contact:" prefix.
>
>    I agree with those wanting the 'contact:' format that it is 
> unambiguous and might be easier to use and analyze, but since no data 
> consumers use it (that I know of), 'phone' is preferred.    I know of 
> several data consumers on mobile apps that use 'phone'.

well, I too appreciate the namespaces if they avoid ambiguity - but is 
there really any ambiguity with phone, fax, email, website, webcam?
contact: is a mere categorisation than distinction - and so it is just 
stuffing for me.

Georg



From ilpo.jarvinen at helsinki.fi  Fri Apr 27 10:54:26 2012
From: ilpo.jarvinen at helsinki.fi (=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=)
Date: Fri, 27 Apr 2012 12:54:26 +0300 (EEST)
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <201204271829.16224.a.errington@lancaster.ac.uk>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAPT3zJo9PpEyDY2+St4Gp6QShxHu4gzcj_pBr1UXcNevVKRr_Q@mail.gmail.com>
	<alpine.DEB.2.00.1204271147560.9350@melkinpaasi.cs.helsinki.fi>
	<201204271829.16224.a.errington@lancaster.ac.uk>
Message-ID: <alpine.DEB.2.00.1204271242230.9350@melkinpaasi.cs.helsinki.fi>

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 _something_ between "normal" lanes=1 and "normal" 
lanes=2.

> It's more useful to tell me width of the road.  Then, if there is one 
> lane I can see maybe it's very wide, or if two lanes I can see maybe 
> they are very narrow. 

...But how can I tag you this: A road which is lanes=1+wide _AND_ 
lanes=2+narrow at the same time? ...You ask me to provide width and select 
one of those two, and that is what I oppose, unless you give me some real 
tag that is not width to tell that 'hey, there really isn't lanes marked 
(which makes it kind of lanes=1) but two can somewhat fit (which makes 
it kind of lanes=2 but not really because it's only "somewhat")'!

...What I would not want to do is to tag those lanes=1 because that's 
certainly a lie as anyone can clearly see after observing some 
bidirectional traffic there.

> In summary, I think simpler is better.  A non-integer lane count is useless.  
> Use the width tag.

I oppose using width tag (at least alone) for this because it won't 
convey the double meaning. Some other tag than width and tagging with 
lanes=2 perhaps (like I already suggested much earlier)?


-- 
 i.


From phil at trigpoint.me.uk  Fri Apr 27 11:01:37 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Fri, 27 Apr 2012 10:01:37 +0000
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <201204271829.16224.a.errington@lancaster.ac.uk>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAPT3zJo9PpEyDY2+St4Gp6QShxHu4gzcj_pBr1UXcNevVKRr_Q@mail.gmail.com>
	<alpine.DEB.2.00.1204271147560.9350@melkinpaasi.cs.helsinki.fi>
	<201204271829.16224.a.errington@lancaster.ac.uk>
Message-ID: <xtszpk.m34uiw.1di6qyj-qmf@auth.smtp.oneandone.co.uk>

Through observations I can see that there is a minimum width for lane marking in the UK. I am not sure what the value is, but have seen sections of road where lines end where the road narrows.
Will try to find an example.

I am not sure I would want to add a lanes tag where the width falls below this minimum, and would tend to prefer the width tag.

Whilst following cars, it has occurred to me that knowing their width would be a reasonable yardstick for estimating the width of a road.

Phil


On 27/04/2012 10:29 Andrew Errington wrote:

I'm quite happy with lanes=n where n is an integer.


I am very happy to assume that a one-way road without lanes=* has only one 
lane.


I am also happy to assume that a not-one-way road without lanes=* has two 
lanes (one in each direction).


I am extremely happy to see a width=* tag that I can use in conjunction with 
the lane count (even if the lane count is assumed). It tells me the width of 
each lane.


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? It's 
more useful to tell me width of the road. Then, if there is one lane I can 
see maybe it's very wide, or if two lanes I can see maybe they are very 
narrow. It's okay to let me assume the number of lanes because the 
assumption is safe, and if it's really wrong then someone will tag it 
properly later.


In summary, I think simpler is better. A non-integer lane count is useless. 
Use the width tag.


Best wishes,


Andrew

_______________________________________________

Tagging mailing list

Tagging at openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120427/8d85a362/attachment.html>

From dieterdreist at gmail.com  Fri Apr 27 11:15:00 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Fri, 27 Apr 2012 12:15:00 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <xtszpk.m34uiw.1di6qyj-qmf@auth.smtp.oneandone.co.uk>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAPT3zJo9PpEyDY2+St4Gp6QShxHu4gzcj_pBr1UXcNevVKRr_Q@mail.gmail.com>
	<alpine.DEB.2.00.1204271147560.9350@melkinpaasi.cs.helsinki.fi>
	<201204271829.16224.a.errington@lancaster.ac.uk>
	<xtszpk.m34uiw.1di6qyj-qmf@auth.smtp.oneandone.co.uk>
Message-ID: <CABPTjTCXQy94S8Y5RCPJbK3OZKQk7reaT7fGbEaajBB17=o+8Q@mail.gmail.com>

Am 27. April 2012 12:01 schrieb Philip Barnes <phil at trigpoint.me.uk>:
> I am not sure I would want to add a lanes tag where the width falls below
> this minimum, and would tend to prefer the width tag.


+1


> Whilst following cars, it has occurred to me that knowing their width would
> be a reasonable yardstick for estimating the width of a road.


for "regular" cars, 1,60-1,90 might be a good (European)
approximation, add ~25-30cm for 2 mirrors. Minivans (e.g. Mercedes
Sprinter) are around 2 m without mirrors, trucks are around 2,50).
http://www.mercedes-benz.com.cy/content/cyprus/mpc/mpc_cyprus_website/enng/home_mpc/trucks_/home/long_distance/actros_long_distance_haulage/Cabs.0004.html

cheers,
Martin


From lauri.kytomaa at aalto.fi  Fri Apr 27 11:18:50 2012
From: lauri.kytomaa at aalto.fi (=?iso-8859-1?Q?Kyt=F6maa_Lauri?=)
Date: Fri, 27 Apr 2012 10:18:50 +0000
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CABPTjTBFP0AN3zaBdxRfrdcyEqXFrvpSNeCfrrDfs7gHG0WDfg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>,
	<CABPTjTBFP0AN3zaBdxRfrdcyEqXFrvpSNeCfrrDfs7gHG0WDfg@mail.gmail.com>
Message-ID: <D312F9ED2DBBD8479518C8D52CD16973B0A38DA6@EXMDB01.org.aalto.fi>

>IMHO it would be a good idea to remove fractional lanes amounts and
>forget about them. They are too subjective.
>What do you think of lanes=3.5? I have an example here:
>http://maps.google.it/maps?hl=en&ll=41.899274,12.464333&spn=0.008497,0.021136&t=h&z=16&layer=c&cbll=41.899391,12.464289&panoid=O8BHrnM_gTAW2XQUWqxcXg&cbp=12,353.6,,0,4.57

When the lanes are marked on the ground, it ought to be an 
offence to drive continuously on the lines separating lanes;
hence, there are only three lanes in the link above, even if 
some or many drivers think they can get away with it.

>Not sure, how many lanes these are, could be 5 or even 5.5? Depends on
>the car widths and the experience of the drivers:
>http://maps.google.it/maps?hl=en&ll=41.876836,12.481943&spn=0.000378,0.00066&t=h&z=21

Changing lanes and overtaking within an intersection ought to
be an offence in developed countries, so from the modelling point
of view there can only be as many lanes as there are on any of 
the incoming or outgoing carriageways.

>vehicles can pass at the same time, lanes=1.5 doesn't really help you,
>it will always remain unclear which width is the street.

There are those roads (yes, roughly 4 meters wide) that, based
on the overall setting, can not be called two lane roads, but it 
would be misleading to tag them with lanes=1, either. 

Aren't we supposed to safely assume that every road can be 
tagged with some correct lanes tag?

-- 
Alv

From osm at bavarianmallet.de  Fri Apr 27 11:23:07 2012
From: osm at bavarianmallet.de (Georg Feddern)
Date: Fri, 27 Apr 2012 12:23:07 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <alpine.DEB.2.00.1204270957010.9350@melkinpaasi.cs.helsinki.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
	<CABPTjTBFP0AN3zaBdxRfrdcyEqXFrvpSNeCfrrDfs7gHG0WDfg@mail.gmail.com>
	<alpine.DEB.2.00.1204270957010.9350@melkinpaasi.cs.helsinki.fi>
Message-ID: <4F9A738B.4060600@bavarianmallet.de>

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 these are, could be 5 or even 5.5? Depends on
>> the car widths and the experience of the drivers:
> Heheh... :-) ...there's one major difference between 1.5 and>=2.5, ie.,
> whether the traffic in one direction almost always interferes with the
> opposite direction of the traffic, in the latter case it shouldn't happen

So you mean 1.5 is the same as 1 regarding the "almost always 
interfere"? ;-)

Georg
in the mood too - but in jolly springtime mood ;-)


From dieterdreist at gmail.com  Fri Apr 27 11:28:56 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Fri, 27 Apr 2012 12:28:56 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <D312F9ED2DBBD8479518C8D52CD16973B0A38DA6@EXMDB01.org.aalto.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
	<CABPTjTBFP0AN3zaBdxRfrdcyEqXFrvpSNeCfrrDfs7gHG0WDfg@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A38DA6@EXMDB01.org.aalto.fi>
Message-ID: <CABPTjTAdaTeRE_-Yc3TKzOOfePq3A8Gn0PC5Ehq6PXVJ_+bYUA@mail.gmail.com>

Am 27. April 2012 12:18 schrieb Kyt?maa Lauri <lauri.kytomaa at aalto.fi>:
>>IMHO it would be a good idea to remove fractional lanes amounts and
>>forget about them. They are too subjective.
>>What do you think of lanes=3.5? I have an example here:
>>http://maps.google.it/maps?hl=en&ll=41.899274,12.464333&spn=0.008497,0.021136&t=h&z=16&layer=c&cbll=41.899391,12.464289&panoid=O8BHrnM_gTAW2XQUWqxcXg&cbp=12,353.6,,0,4.57
>
> When the lanes are marked on the ground, it ought to be an
> offence to drive continuously on the lines separating lanes;
> hence, there are only three lanes in the link above, even if
> some or many drivers think they can get away with it.


It's not that they think they get away with it: they _do_ get away
with it. If everybody in this area drives in a certain style, and
police doesn't enforce the official rules, then there are factually
more lanes on the ground than painted on the road.


>>Not sure, how many lanes these are, could be 5 or even 5.5? Depends on
>>the car widths and the experience of the drivers:
>>http://maps.google.it/maps?hl=en&ll=41.876836,12.481943&spn=0.000378,0.00066&t=h&z=21
>
> Changing lanes and overtaking within an intersection ought to
> be an offence in developed countries, so from the modelling point
> of view there can only be as many lanes as there are on any of
> the incoming or outgoing carriageways.


not sure, this is a point where _several_ (4) carriageways meet, each
of them with at least 2 lanes, and they don't go all in one direction
but in two, where for one of these it is also unclear how many lanes
there are (the other are 2.4 I'd say ;-) ).


>>vehicles can pass at the same time, lanes=1.5 doesn't really help you,
>>it will always remain unclear which width is the street.
> There are those roads (yes, roughly 4 meters wide) that, based
> on the overall setting, can not be called two lane roads, but it
> would be misleading to tag them with lanes=1, either.


yes, and even lanes=1.4 or 1.6 will be unclear. In these cases (which
usually also don't have painted lanes) the best thing to do is omit
the lanes tag and go for width. See also above in this thread.


> Aren't we supposed to safely assume that every road can be
> tagged with some correct lanes tag?


IMHO no, but if you insist on setting them, what about lanes=1,
oneway=no, width=4?

cheers,
Martin


From ilpo.jarvinen at helsinki.fi  Fri Apr 27 11:50:34 2012
From: ilpo.jarvinen at helsinki.fi (=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=)
Date: Fri, 27 Apr 2012 13:50:34 +0300 (EEST)
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <4F9A738B.4060600@bavarianmallet.de>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
	<CABPTjTBFP0AN3zaBdxRfrdcyEqXFrvpSNeCfrrDfs7gHG0WDfg@mail.gmail.com>
	<alpine.DEB.2.00.1204270957010.9350@melkinpaasi.cs.helsinki.fi>
	<4F9A738B.4060600@bavarianmallet.de>
Message-ID: <alpine.DEB.2.00.1204271333450.9350@melkinpaasi.cs.helsinki.fi>

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 these are, could be 5 or even 5.5? Depends on
> > > the car widths and the experience of the drivers:
> >
> > Heheh... :-) ...there's one major difference between 1.5 and>=2.5, ie.,
> > whether the traffic in one direction almost always interferes with the
> > opposite direction of the traffic, in the latter case it shouldn't happen
> 
> So you mean 1.5 is the same as 1 regarding the "almost always interfere"? ;-)

...A more appropriate word would be somewhat stronger "prevents" for real 
lanes=1 I suppose, but I'm not native so I might be wrong? ;-) (Or 
alternatively one needs a road excursion / passing place).

...Besides, this distinction based on interfering is mostly mean to 
differentiate from "normal" lanes=2 road, not from lanes=1 one.

-- 
 i.

From colin.smale at xs4all.nl  Fri Apr 27 12:08:29 2012
From: colin.smale at xs4all.nl (Colin Smale)
Date: Fri, 27 Apr 2012 13:08:29 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CABPTjTCXQy94S8Y5RCPJbK3OZKQk7reaT7fGbEaajBB17=o+8Q@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAPT3zJo9PpEyDY2+St4Gp6QShxHu4gzcj_pBr1UXcNevVKRr_Q@mail.gmail.com>
	<alpine.DEB.2.00.1204271147560.9350@melkinpaasi.cs.helsinki.fi>
	<201204271829.16224.a.errington@lancaster.ac.uk>
	<xtszpk.m34uiw.1di6qyj-qmf@auth.smtp.oneandone.co.uk>
	<CABPTjTCXQy94S8Y5RCPJbK3OZKQk7reaT7fGbEaajBB17=o+8Q@mail.gmail.com>
Message-ID: <4F9A7E2D.2050509@xs4all.nl>

Wouldn't this discussion benefit from a summary of the use cases we are 
trying to address? I see multiple semantics being suggested for the 
lanes tag, and at the end of the day we will have to choose one.

* Renderers such as mapnik might want to reflect the number of lanes in 
the width of the line
* Routers might use the lane count (along with many other attributes) in 
heuristics for the road capacity and travel time
* Other renderers might try to derive a "picture" of the road or junction

Sometimes it's about "what is painted on the road"; sometimes it's "how 
many vehicles fit across the road"; sometimes it's something else.

If we choose one definition for the lanes tag, and allow the other 
definition to be derived by combining lanes=* with something else, then 
everyone could be happy. To choose one definition above the other 
options we should look at which is likely to be the most useful to the 
most users (in the broadest sense). The minority use cases will then be 
able to derive what they need by combining tags.

As a simple example, on a motorway with 3 normal lanes plus a hard 
shoulder, we could have lanes=3 and shoulder=yes in one model, or 
lanes=4 shoulder=yes in another model. In either case, provided the 
semantics of the tags are applied consistently, one can satisfy all the 
use cases I listed above. If there are narrower lane

This is a classic case of a discussion dragging on for hundreds of posts 
discussing different points of view (and there's nothing wrong with that 
of course) without a common cause to allow the discussion to converge. 
If we only discuss how to put things INTO the data without a view of how 
we (and others) might want to USE that data, we will end up with nobody 
being happy. If this situation arose on my project I would be having 
SERIOUS discussions with the customer - maybe the project should never 
have been started.

Colin


From osm at bavarianmallet.de  Fri Apr 27 12:25:32 2012
From: osm at bavarianmallet.de (Georg Feddern)
Date: Fri, 27 Apr 2012 13:25:32 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <alpine.DEB.2.00.1204271242230.9350@melkinpaasi.cs.helsinki.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAPT3zJo9PpEyDY2+St4Gp6QShxHu4gzcj_pBr1UXcNevVKRr_Q@mail.gmail.com>
	<alpine.DEB.2.00.1204271147560.9350@melkinpaasi.cs.helsinki.fi>
	<201204271829.16224.a.errington@lancaster.ac.uk>
	<alpine.DEB.2.00.1204271242230.9350@melkinpaasi.cs.helsinki.fi>
Message-ID: <4F9A822C.9020807@bavarianmallet.de>

Am 27.04.2012 11:54, schrieb Ilpo J?rvinen:
> ...But how can I tag you this: A road which is lanes=1+wide _AND_
> lanes=2+narrow at the same time? ...You ask me to provide width and select
> one of those two, and that is what I oppose, unless you give me some real
> tag that is not width to tell that 'hey, there really isn't lanes marked
> (which makes it kind of lanes=1) but two can somewhat fit (which makes
> it kind of lanes=2 but not really because it's only "somewhat")'!
>

I think I understand what you mean, because I see that in many rural 
cases here

Perhaps just to clarify at least my observations / understanding
which will hopefully match your differentiation:

A) lanes=1
Means no chance to pass but on special passing points.

B) lanes=2
You can always pass without leaving the tarmac and without special 
precautings (like driving very slow on the outer side)
Well, the latter may depend on experience and spatial sense! ;-)
And I talk about lorries / busses, not a special 
"passenger-cars-only-2-lane-road" (see C).
But I am afraid this is already ambiguous in the data too ...

C) lanes=1.5
To pass you may have to leave the tarmac depending on the oncomming 
vehicle, but there is always enough place to do so.

I have to admit, that I would tag C) as lanes=1, because even there is 
always enough space
- you have to leave the tarmac and so you have to leave 'your  lane'
- you never know what's beside the tarmac, which will lead to special 
precautions.

For me C) has simply the same driving limitations as A):
Always expect oncomming traffic you cannot pass without precautions.

Together with width it is possible to refine your capabilities depending 
on your own vehicle and driving characteristics then.
Then you may know, if your small vehicle can pass every oncomming lorry.
But lanes=1.5 has no benefit or information here - not even for a 
cyclist, if you mean a 1.5 passenger car width - and the lorry is coming 
...

Georg


From imagic.osm at gmail.com  Fri Apr 27 12:33:17 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Fri, 27 Apr 2012 13:33:17 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <4F9A822C.9020807@bavarianmallet.de>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAPT3zJo9PpEyDY2+St4Gp6QShxHu4gzcj_pBr1UXcNevVKRr_Q@mail.gmail.com>
	<alpine.DEB.2.00.1204271147560.9350@melkinpaasi.cs.helsinki.fi>
	<201204271829.16224.a.errington@lancaster.ac.uk>
	<alpine.DEB.2.00.1204271242230.9350@melkinpaasi.cs.helsinki.fi>
	<4F9A822C.9020807@bavarianmallet.de>
Message-ID: <CAKjckyNfzKNyQ-VqR43P36p0ZOsfQ1_ERotU7x1q-NDcAY8d9A@mail.gmail.com>

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=<integer>+width, that is solved with lanes=1.5 ?

Martin


From a.errington at lancaster.ac.uk  Fri Apr 27 12:52:35 2012
From: a.errington at lancaster.ac.uk (Andrew Errington)
Date: Fri, 27 Apr 2012 20:52:35 +0900
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <alpine.DEB.2.00.1204271242230.9350@melkinpaasi.cs.helsinki.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<201204271829.16224.a.errington@lancaster.ac.uk>
	<alpine.DEB.2.00.1204271242230.9350@melkinpaasi.cs.helsinki.fi>
Message-ID: <201204272052.36107.a.errington@lancaster.ac.uk>

On Fri, 27 Apr 2012 18:54:26 Ilpo J?rvinen wrote:
> 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 _something_ between "normal" lanes=1 and "normal"
> lanes=2.

But the width=* tag tells you this.  Specifically, the width tag tells you if 
there will be a problem *for you*.  Since I have never met you and I don't 
know what vehicle you are using it would be presumptious of me to tell you 
that there are 1.5 lanes.  Also, it doesn't make sense to allow lanes=1.5 but 
deny 1.55, 1.4, 1.68 or any other fractional value.  What you are doing is 
introducing a 'special' value with a special meaning.  I think we should try 
to avoid having to interpret special cases.

> > It's more useful to tell me width of the road.  Then, if there is one
> > lane I can see maybe it's very wide, or if two lanes I can see maybe
> > they are very narrow.
>
> ...But how can I tag you this: A road which is lanes=1+wide _AND_
> lanes=2+narrow at the same time? ...You ask me to provide width and select
> one of those two, and that is what I oppose, unless you give me some real
> tag that is not width to tell that 'hey, there really isn't lanes marked
> (which makes it kind of lanes=1) but two can somewhat fit (which makes
> it kind of lanes=2 but not really because it's only "somewhat")'!
>
> ...What I would not want to do is to tag those lanes=1 because that's
> certainly a lie as anyone can clearly see after observing some
> bidirectional traffic there.

It's not a lie.  A single lane may be bidirectional.  In fact, in this case 
you *should* tag it lanes=1.  If oneway=yes is not present then it means one 
bidirectional lane.

> > In summary, I think simpler is better.  A non-integer lane count is
> > useless. Use the width tag.
>
> I oppose using width tag (at least alone) for this because it won't
> convey the double meaning. Some other tag than width and tagging with
> lanes=2 perhaps (like I already suggested much earlier)?

I don't think there is a double meaning.

lanes=1 tells me there is one lane.  It does not mean one direction, nor 
should anyone assume that.  I *think* you are saying that lanes=1.5 tells 
me "this road is not really wide enough for two-way traffic, but there *is* 
two-way traffic so if there is a car coming the other way you have to 
wait"[1].

For the purpose of discussion, let us assume that a road of 2.5 m width is too 
narrow for cars to pass.

lanes=1 width=2.5 tells me the same thing (one narrow lane, cars travel both 
directions, but only one direction at a time).

lanes=2 width=2.5 tells me the same thing (two very narrow lanes, cars travel 
both directions, but only one direction at a time).

lanes=1 tells me the same thing (one lane implies cars cannot travel both 
directions at the same time, but no oneway=yes tag implies cars can travel in 
both directions.  We don't know the width but there must have been a reason 
for a mapper to tag it with lanes=1).

width=2.5 tells me the same thing (no lanes=* tag and no oneway=yes tag 
implies two lanes, but both must be very narrow therefore cars can only 
travel one direction at a time).

I don't think any of these assumptions are unreasonable, and they don't alter 
the existing meaning of the tags, which I believe are already quite clear, so 
we should use them and not alter them with special cases.

Best wishes,

Andrew

[1] I have made this sentence to interpret what lanes=1.5 means.  If my 
understanding is incorrect please state what lanes=1.5 actually means.


From ilpo.jarvinen at helsinki.fi  Fri Apr 27 14:15:50 2012
From: ilpo.jarvinen at helsinki.fi (=?ISO-8859-15?Q?Ilpo_J=E4rvinen?=)
Date: Fri, 27 Apr 2012 16:15:50 +0300 (EEST)
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyNfzKNyQ-VqR43P36p0ZOsfQ1_ERotU7x1q-NDcAY8d9A@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAPT3zJo9PpEyDY2+St4Gp6QShxHu4gzcj_pBr1UXcNevVKRr_Q@mail.gmail.com>
	<alpine.DEB.2.00.1204271147560.9350@melkinpaasi.cs.helsinki.fi>
	<201204271829.16224.a.errington@lancaster.ac.uk>
	<alpine.DEB.2.00.1204271242230.9350@melkinpaasi.cs.helsinki.fi>
	<4F9A822C.9020807@bavarianmallet.de>
	<CAKjckyNfzKNyQ-VqR43P36p0ZOsfQ1_ERotU7x1q-NDcAY8d9A@mail.gmail.com>
Message-ID: <alpine.DEB.2.00.1204271605050.9350@melkinpaasi.cs.helsinki.fi>

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=<integer>+width, that is solved with lanes=1.5 ?

Please pick the integer first so we can discuss more. ...Although I think 
I've already explained it multiple times for both possible values :-).

-- 
 i.


From baloo at ursamundi.org  Fri Apr 27 16:08:37 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Fri, 27 Apr 2012 08:08:37 -0700
Subject: [Tagging] lanes=* on cycleways
Message-ID: <CAMPM96r0vanmkru+ESEPE2LCPYxCS1GmRVtg_BW7HqL5RYK4eg@mail.gmail.com>

How do we handle lane counts where there's more than one bicycle lane?
 How do we count lanes on cycleways?  Since these lanes are narrower
than what cars can fit down, things like Gresham segments of the
Springwater Corridor (4 lanes) and situations like 12th Avenue (which
has a couple spots with bike lanes on both sides of a one-way street)
or the Hawthorne Bridge (two car lanes, two bicycle lanes on the
westbound approach; two bike lanes on the one-way cycleways) would all
count as lanes=0 or only count car lanes under the existing lanes=*
proposal.  I imagine the Dutch have a similar problem, given that I
have a sneaking suspicion multilane cycleways are somewhat more common
there.


From osm at inbox.org  Fri Apr 27 19:14:05 2012
From: osm at inbox.org (Anthony)
Date: Fri, 27 Apr 2012 14:14:05 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F99EE1C.1020807@tobias-knerr.de>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
Message-ID: <CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>

On Thu, Apr 26, 2012 at 8:53 PM, Tobias Knerr <osm at tobias-knerr.de> wrote:
> Anthony wrote:
>> On Wed, Apr 25, 2012 at 5:17 AM, Nathan Edgars II <neroute2 at gmail.com> wrote:
>>> Where did I mention a renderer? If you draw a closed polygon with
>>> railway=platform, that's a continuous platform with a hole in the middle.
>>> There may be a few cases of such in real life at a complicated junction.
>>
>> If so, they should be tagged with area=no.
>
> "area=no" can be considered a "sic!", but that tag should never have any
> actual effect.

Effect on what?  If I were writing a renderer, I would assume that a
closed way railway=platform represented an area unless it was tagged
area=no.  So that's an effect.

> If a feature can be either a closed way or an area, the default
> interpretation should always be the closed way. Otherwise, you'd have to
> know arbitrary defaults for each type of object.

A default set to the value which is correct 99.999999999999999999999%
of the time is not arbitrary.

Should defaults be documented somewhere?  Absolutely.  Should users of
the data ignore reality because someone wrote something somewhere in
the wiki?  Absolutely not.


From phil at trigpoint.me.uk  Fri Apr 27 19:21:11 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Fri, 27 Apr 2012 19:21:11 +0100
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <xtszpk.m34uiw.1di6qyj-qmf@auth.smtp.oneandone.co.uk>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAPT3zJo9PpEyDY2+St4Gp6QShxHu4gzcj_pBr1UXcNevVKRr_Q@mail.gmail.com>
	<alpine.DEB.2.00.1204271147560.9350@melkinpaasi.cs.helsinki.fi>
	<201204271829.16224.a.errington@lancaster.ac.uk>
	<xtszpk.m34uiw.1di6qyj-qmf@auth.smtp.oneandone.co.uk>
Message-ID: <1335550871.2032.18.camel@marvin>

On Fri, 2012-04-27 at 10:01 +0000, Philip Barnes wrote:
> Through observations I can see that there is a minimum width for lane
> marking in the UK. I am not sure what the value is, but have seen
> sections of road where lines end where the road narrows.
> 
> Will try to find an example.
> 
Sorry its been too wet to go out and take photos.

An example where the road become too narrow for lane markings as it
crosses a bridge, the lines recommence on the other side when the road
becomes wide enough.

http://g.co/maps/7svgs

Again lines end where the road becomes too narrow, cars can pass but you
have to wait for anything much larger.

http://g.co/maps/3y7ja

Maybe this one is silly, http://g.co/maps/atszn
The road is a lot less than 3m wide, the lines indicate a warning for
the give way as it reaches the trunk road ahead. It is still a single
lane.

Phil





From osm at inbox.org  Fri Apr 27 19:37:21 2012
From: osm at inbox.org (Anthony)
Date: Fri, 27 Apr 2012 14:37:21 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPT3zJpNbpcgV9h6Lu5YrU+ACr5z1qKeDqOPY911sU7zb4EyGg@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPT3zJpNbpcgV9h6Lu5YrU+ACr5z1qKeDqOPY911sU7zb4EyGg@mail.gmail.com>
Message-ID: <CAPreJLRBmuTrYrwCpwyhxCy3eE5OCRa-RhTbk4dWA5BnPkM00A@mail.gmail.com>

On Fri, Apr 27, 2012 at 4:12 AM, Pieren <pieren3 at gmail.com> wrote:
> On Fri, Apr 27, 2012 at 2:53 AM, Tobias Knerr <osm at tobias-knerr.de> wrote:
>
>> If a feature can be either a closed way or an area, the default
>> interpretation should always be the closed way. Otherwise, you'd have to
>> know arbitrary defaults for each type of object.
>
> You have to know anyway if your feature can be either a closed way or
> an area and therefore need some special handling in your apps. The
> question is then more to consider certain features as "area" or
> "closed way" by default. On this point, I'm always standing on the
> contributors side and wont ask them to add an unnecessary tag for
> 99.99% of the cases.

I don't mind asking them to (hence I don't mind the wiki saying that
they *should* do so).  But I do mind if people take the fact that the
wiki asks them to as an excuse not to add area=no in the other 0.01%
of cases.

Or, in RFC-speak.  I would be fine with "Users SHOULD add area=yes
when mapping a railway platform as an area.  Users MUST add area=no
when mapping a railway platform with a closed way which does not
represent an area."  I'd prefer "Users MAY add area=yes when mapping a
railway platform as an area.  Users MUST add area=no when mapping a
railway platform with a closed way which does not represent an area."
though.

If the (nonexistent) specs say that area=no is the default for
railway=platform closed ways, the (nonexistent) specs are broken.


From dieterdreist at gmail.com  Fri Apr 27 19:40:27 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Fri, 27 Apr 2012 20:40:27 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
Message-ID: <CABPTjTD5B1u65ia5TOHmfAZKJ1ZqFeL2tLtYBq7x7kKpEZs9Vg@mail.gmail.com>

Am 27. April 2012 20:14 schrieb Anthony <osm at inbox.org>:
> A default set to the value which is correct 99.999999999999999999999%
> of the time is not arbitrary.


how would you distinguish between default values and incomplete
data/missing information?

We could have a tag

defaults_checked=area;surface;lanes;oneway;lit;width;...

to show which defaults have been checked, and maybe have different
default-schemes maintained by different people or for different
topics. We could define default sets in the wiki,
default_set_garry:version2=yes, with Versioning, so we can later amend
the defaults_sets without bothering...

But for simplicity when in doubt I'd set the tag explicitly.

According to your estimations every "default" that is tagged
explicitly is at least 0.000000000000000000001% better than not having
it. ;-)

cheers,
Martin


From sanderd17 at gmail.com  Fri Apr 27 19:45:04 2012
From: sanderd17 at gmail.com (Sander Deryckere)
Date: Fri, 27 Apr 2012 20:45:04 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CABPTjTD5B1u65ia5TOHmfAZKJ1ZqFeL2tLtYBq7x7kKpEZs9Vg@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<CABPTjTD5B1u65ia5TOHmfAZKJ1ZqFeL2tLtYBq7x7kKpEZs9Vg@mail.gmail.com>
Message-ID: <CABUOUO9EJyAY5U+-7T7n6sphcKFPa-YH4kkTix3UCt9FMk-+FQ@mail.gmail.com>

Op 27 apr. 2012 20:41 schreef "Martin Koppenhoefer" <dieterdreist at gmail.com>
het volgende:
>
> Am 27. April 2012 20:14 schrieb Anthony <osm at inbox.org>:
> > A default set to the value which is correct 99.999999999999999999999%
> > of the time is not arbitrary.
>
>
> how would you distinguish between default values and incomplete
> data/missing information?
>

The same way as you distinguish between old and current data: just not.
Wait until some mapper sees that it's wrong.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120427/7e91de7c/attachment.html>

From osm at tobias-knerr.de  Fri Apr 27 20:06:09 2012
From: osm at tobias-knerr.de (Tobias Knerr)
Date: Fri, 27 Apr 2012 21:06:09 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
Message-ID: <4F9AEE21.2080707@tobias-knerr.de>

Anthony wrote:
>
>> "area=no" can be considered a "sic!", but that tag should never have any
>> actual effect.
> 
> Effect on what?

On renderers or any other applications working with OSM data.

>  If I were writing a renderer, I would assume that a
> closed way railway=platform represented an area unless it was tagged
> area=no.  So that's an effect.

If I were writing a renderer (actually, I am), I would assume that a
closed way does not represent an area unless it
a) has an always-area tag such as landuse
or
b) is tagged with area=yes.

Your idea that some tags should make a closed way into an area by
default, unless there's also a certain other tag (like area=no) present,
is not established mapping style as far as I can tell.

Currently, tags are either unambiguous, or the default assumption is
"not an area".

Tobias


From osm at inbox.org  Fri Apr 27 20:10:14 2012
From: osm at inbox.org (Anthony)
Date: Fri, 27 Apr 2012 15:10:14 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CABPTjTD5B1u65ia5TOHmfAZKJ1ZqFeL2tLtYBq7x7kKpEZs9Vg@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<CABPTjTD5B1u65ia5TOHmfAZKJ1ZqFeL2tLtYBq7x7kKpEZs9Vg@mail.gmail.com>
Message-ID: <CAPreJLQSAH+mWjjtZRAUpJcMQJ0YFn3nBVSKM3MsH+MmwR6r_g@mail.gmail.com>

On Fri, Apr 27, 2012 at 2:40 PM, Martin Koppenhoefer
<dieterdreist at gmail.com> wrote:
> Am 27. April 2012 20:14 schrieb Anthony <osm at inbox.org>:
>> A default set to the value which is correct 99.999999999999999999999%
>> of the time is not arbitrary.
>
> how would you distinguish between default values and incomplete
> data/missing information?

You can't distinguish between them.  That's why defaults should be set
to the value that's right most of the time.  At least, they usually
should (sometimes other considerations come into play, for example if
the cost of guessing wrong on one side is much higher than the cost of
guessing wrong on the other side).

Note that I'm talking here about situations where presenting the
end-user with "unknown" is not reasonable.  I wouldn't suggest for a
map to show default speed limits when nothing was provided.  (On the
other hand, a routing program probably is going to have to provide
default speed limits when calculating the fastest path, and this is a
situation where "the value that's right most of the time" might not be
the best one to use.)

> We could have a tag
>
> defaults_checked=area;surface;lanes;oneway;lit;width;...
>
> to show which defaults have been checked, and maybe have different
> default-schemes maintained by different people or for different
> topics. We could define default sets in the wiki,
> default_set_garry:version2=yes, with Versioning, so we can later amend
> the defaults_sets without bothering...

This doesn't sound reasonable.

> But for simplicity when in doubt I'd set the tag explicitly.

I think that's probably a good idea for most tags, where the split is
80/20, or 60/40, or 90/10, or where the cost of getting it wrong is
very high.  For something like railway=platform I wouldn't bother.


From osm at inbox.org  Fri Apr 27 20:11:49 2012
From: osm at inbox.org (Anthony)
Date: Fri, 27 Apr 2012 15:11:49 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F9AEE21.2080707@tobias-knerr.de>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
Message-ID: <CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>

On Fri, Apr 27, 2012 at 3:06 PM, Tobias Knerr <osm at tobias-knerr.de> wrote:
> Anthony wrote:
>> ?If I were writing a renderer, I would assume that a
>> closed way railway=platform represented an area unless it was tagged
>> area=no. ?So that's an effect.
>
> If I were writing a renderer (actually, I am), I would assume that a
> closed way does not represent an area unless it
> a) has an always-area tag such as landuse
> or
> b) is tagged with area=yes.
>
> Your idea that some tags should make a closed way into an area by
> default, unless there's also a certain other tag (like area=no) present,
> is not established mapping style as far as I can tell.
>
> Currently, tags are either unambiguous, or the default assumption is
> "not an area".

Well that's a mistake that should be fixed.


From neroute2 at gmail.com  Fri Apr 27 20:25:10 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Fri, 27 Apr 2012 15:25:10 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
Message-ID: <4F9AF296.20804@gmail.com>

While this is ongoing, Pieren continues to remove area=yes from 
railway=platform, which has been on the page since it was created in 
2008: 
http://wiki.openstreetmap.org/w/index.php?title=Tag:railway%3Dplatform&action=history


From osm-marl at gmx.com  Sat Apr 28 09:06:04 2012
From: osm-marl at gmx.com (Marl)
Date: Sat, 28 Apr 2012 09:06:04 +0100
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
Message-ID: <4F9BA4EC.2020201@gmx.com>

On 27/04/12 20:11, Anthony wrote:
> On Fri, Apr 27, 2012 at 3:06 PM, Tobias Knerr <osm at tobias-knerr.de> wrote:
>> Anthony wrote:
>> If I were writing a renderer (actually, I am), I would assume that a
>> closed way does not represent an area unless it a) has an always-area
>> tag such as landuse or b) is tagged with area=yes. Your idea that
>> some tags should make a closed way into an area by default, unless
>> there's also a certain other tag (like area=no) present, is not
>> established mapping style as far as I can tell. Currently, tags are
>> either unambiguous, or the default assumption is "not an area". 
> Well that's a mistake that should be fixed.
>
> _______________________________________________
>
I think that it's not a mistake.

The idea of having different defaults for area= would not only keep
programmers busy (they can do more beneficial things during the time
wasted for this), it also confuses mappers. I (as a mapper) don't want
to look up the default for every tag.

Another point: A platform is a usually footway. They often work as
footways as well, so I think that in this case they should be tagged
highway=footway anyway. Different defaults for the area tag would create
an ambiguity. This is just the first example of this inconsistency that
comes to my mind.

By the way - why are you tagging railway=platform? The public transport
scheme has changed this to public_transport=platform more than a year ago.

That's my two cents

Marl


From neroute2 at gmail.com  Sat Apr 28 10:17:21 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Sat, 28 Apr 2012 05:17:21 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F9BA4EC.2020201@gmx.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
	<4F9BA4EC.2020201@gmx.com>
Message-ID: <4F9BB5A1.3060104@gmail.com>

On 4/28/2012 4:06 AM, Marl wrote:
> By the way - why are you tagging railway=platform? The public transport
> scheme has changed this to public_transport=platform more than a year ago.

Because old habits die hard, especially when the new standard is 
convoluted as all hell.


From neroute2 at gmail.com  Sat Apr 28 10:24:05 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Sat, 28 Apr 2012 05:24:05 -0400
Subject: [Tagging] Waterway directionality in drainage canals
Message-ID: <4F9BB735.9020504@gmail.com>

It's the standard to draw a waterway in the direction of flow. I've 
questioned this several times, but it's an ingrained default.

My question is more specific: what happens to a drainage canal that 
reverses direction? I offer the Everglades and surrounding agricultural 
land as an example. There are huge "water conservation areas" that store 
water. When it rains, gates are closed and opened to direct water into 
these. During a drought, gates send water back out into the canals for 
local use. When there's a big storm, water will instead go directly out 
to sea.

So there are a lot of major canals that have no fixed direction. How 
should these be mapped? Is there any existing scheme that can show how 
water flows under different conditions?


From sanderd17 at gmail.com  Sat Apr 28 10:32:43 2012
From: sanderd17 at gmail.com (Sander Deryckere)
Date: Sat, 28 Apr 2012 11:32:43 +0200
Subject: [Tagging] lanes=* on cycleways
In-Reply-To: <CAMPM96r0vanmkru+ESEPE2LCPYxCS1GmRVtg_BW7HqL5RYK4eg@mail.gmail.com>
References: <CAMPM96r0vanmkru+ESEPE2LCPYxCS1GmRVtg_BW7HqL5RYK4eg@mail.gmail.com>
Message-ID: <CABUOUO-tUKSuNimbxkcvFrgfY=40LtWr6H=wLZXZZnopDaoAaQ@mail.gmail.com>

Can you give a picture of multi-lane cycleways (or coordinates, so we can
see it in aerial pics or via streetview)?

The only multi-lane cycleways I know are two-direction cycleways, where the
lines are only a suggestion. So it doesn't really matter whether it's a
two-way cycleway with one or two lanes.

What does matter is the width of the entire cycleway, as that gives you an
idea of how easy it is to cross each other, or to drive next to each other.

So I wouldn't tag the number of lanes, only whether it's one- or two-way,
and the width.

The above is based on what I see regarding cycling-infrastructure in
Belgium. You might know that Belgians also like cycling, but the Belgian
infrastructure is often aged.

Cheers, Sander

Op 27 april 2012 17:08 schreef Paul Johnson <baloo at ursamundi.org> het
volgende:

> How do we handle lane counts where there's more than one bicycle lane?
>  How do we count lanes on cycleways?  Since these lanes are narrower
> than what cars can fit down, things like Gresham segments of the
> Springwater Corridor (4 lanes) and situations like 12th Avenue (which
> has a couple spots with bike lanes on both sides of a one-way street)
> or the Hawthorne Bridge (two car lanes, two bicycle lanes on the
> westbound approach; two bike lanes on the one-way cycleways) would all
> count as lanes=0 or only count car lanes under the existing lanes=*
> proposal.  I imagine the Dutch have a similar problem, given that I
> have a sneaking suspicion multilane cycleways are somewhat more common
> there.
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120428/daf890fa/attachment.html>

From wendorff at uni-paderborn.de  Sat Apr 28 10:34:50 2012
From: wendorff at uni-paderborn.de (Peter Wendorff)
Date: Sat, 28 Apr 2012 11:34:50 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F9BA4EC.2020201@gmx.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
	<4F9BA4EC.2020201@gmx.com>
Message-ID: <4F9BB9BA.5090804@uni-paderborn.de>

Let's consider two well known examples:

building=* => usually by default area=yes, a non-closed way may be 
considered as invalid(?)
highway=* => usually by default area=no, even if a closed way

A common default value would lead to either
~56M area=yes on buildings
or
~52M area=no on highways

while both could be done by useful, well thought, but different default 
assumptions.
About your example, Marl:

Am 28.04.2012 10:06, schrieb Marl:
> Another point: A platform is a usually footway. They often work as 
> footways as well, so I think that in this case they should be tagged 
> highway=footway anyway. Different defaults for the area tag would 
> create an ambiguity. 
Yes, and in this special example, I would say, area=yes is required for 
correct tagging, as even the highway=footway should be interpreted as an 
area (it's not a footway around the platform).

On the other hand, a fenced field is landuse=* (and in this respect 
implicitly area=yes) and barrier=fence (and here implicitly area=no), 
and that's fine.
If you would use one common default value, tagging would require to 
override that, and therefore use two ways, as area=yes and area=no are 
not possible on the same way - and not possible to match to the correct 
tags they refer to.

regards
Peter


From voschix at gmail.com  Sat Apr 28 11:01:15 2012
From: voschix at gmail.com (Volker Schmidt)
Date: Sat, 28 Apr 2012 12:01:15 +0200
Subject: [Tagging] Waterway directionality in drainage canals
In-Reply-To: <4F9BB735.9020504@gmail.com>
References: <4F9BB735.9020504@gmail.com>
Message-ID: <CALQ-OR7yKmLO-yT4nnf=6b3DBct+ofR_a1sZ+kxiuedRfoi1fw@mail.gmail.com>

Interesting question.
I do have do navigable canals that can have the water flow in either
direction, under operator control. I think there must be many of them.
I so far have not bothered about the flow direction, as boat traffic goes
both ways independently of the actual flow of the water, but you have a
point here.

Volker
Padova, Italy

On 28 April 2012 11:24, Nathan Edgars II <neroute2 at gmail.com> wrote:

> It's the standard to draw a waterway in the direction of flow. I've
> questioned this several times, but it's an ingrained default.
>
> My question is more specific: what happens to a drainage canal that
> reverses direction? I offer the Everglades and surrounding agricultural
> land as an example. There are huge "water conservation areas" that store
> water. When it rains, gates are closed and opened to direct water into
> these. During a drought, gates send water back out into the canals for
> local use. When there's a big storm, water will instead go directly out to
> sea.
>
> So there are a lot of major canals that have no fixed direction. How
> should these be mapped? Is there any existing scheme that can show how
> water flows under different conditions?
>
> ______________________________**_________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/tagging<http://lists.openstreetmap.org/listinfo/tagging>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120428/74a13022/attachment.html>

From osm at tobias-knerr.de  Sat Apr 28 11:04:59 2012
From: osm at tobias-knerr.de (Tobias Knerr)
Date: Sat, 28 Apr 2012 12:04:59 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F9BB9BA.5090804@uni-paderborn.de>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
	<4F9BA4EC.2020201@gmx.com> <4F9BB9BA.5090804@uni-paderborn.de>
Message-ID: <4F9BC0CB.4060103@tobias-knerr.de>

28.04.2012 11:34, Peter Wendorff wrote:
> Let's consider two well known examples:
> 
> building=* => usually by default area=yes, a non-closed way may be
> considered as invalid(?)

Yes, it would be invalid. As documented in the wiki, the building key
(ignoring building=entrance and the like) is for areas only. And this
means that it isn't really a relevant example here.

> A common default value would lead to either
> ~56M area=yes on buildings
> or
> ~52M area=no on highways

I assume that this is a misunderstanding, because I don't think anybody
was suggesting that area=yes should be used together with tags that are
unambiguous anyway. My suggestion, and current practice as far as I can
tell, is:

* If a tag can only be used on areas, or only on ways, you don't need an
area tag.
* If a tag can be used on both areas and ways, the default
interpretation is that it is a way, and area=yes is required to make it
an area.

> On the other hand, a fenced field is landuse=* (and in this respect
> implicitly area=yes) and barrier=fence (and here implicitly area=no),
> and that's fine.

Actually, that particular style of using barrier=fence has always been a
bit of a hack and it's probably not the best example of clean tagging.

But since landuse cannot be used on ways, and barrier=fence cannot be
used on areas (well, it can, but then it is treated as a "this area is
fenced" attribute and not as a very wide fence), this is again not an
example where area=yes or area=no is required at all.

Tobias


From dieterdreist at gmail.com  Sat Apr 28 11:06:39 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sat, 28 Apr 2012 12:06:39 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F9BB9BA.5090804@uni-paderborn.de>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
	<4F9BA4EC.2020201@gmx.com> <4F9BB9BA.5090804@uni-paderborn.de>
Message-ID: <CABPTjTCoPqD4VnXVMSYp5NWrDuzXPGRyhsw8VLc61e612SFcbw@mail.gmail.com>

Am 28. April 2012 11:34 schrieb Peter Wendorff <wendorff at uni-paderborn.de>:
> On the other hand, a fenced field is landuse=* (and in this respect
> implicitly area=yes) and barrier=fence (and here implicitly area=no), and
> that's fine.


I'd tag the way barrier=fence and create a multipolygon for the
landuse with this way as outer.

cheers,
Martin


From voschix at gmail.com  Sat Apr 28 11:08:14 2012
From: voschix at gmail.com (Volker Schmidt)
Date: Sat, 28 Apr 2012 12:08:14 +0200
Subject: [Tagging] lanes=* on cycleways
In-Reply-To: <CABUOUO-tUKSuNimbxkcvFrgfY=40LtWr6H=wLZXZZnopDaoAaQ@mail.gmail.com>
References: <CAMPM96r0vanmkru+ESEPE2LCPYxCS1GmRVtg_BW7HqL5RYK4eg@mail.gmail.com>
	<CABUOUO-tUKSuNimbxkcvFrgfY=40LtWr6H=wLZXZZnopDaoAaQ@mail.gmail.com>
Message-ID: <CALQ-OR7JJGpTgR-4VZSw09crh6zfpy5o=6yq0QYUdkgvhvuX8w@mail.gmail.com>

On 28 April 2012 11:32, Sander Deryckere <sanderd17 at gmail.com> wrote:

> Can you give a picture of multi-lane cycleways (or coordinates, so we can
> see it in aerial pics or via streetview)?
>
>
https://maps.google.com/maps?q=Copenhagen,+Denmark&hl=en&ll=55.671836,12.575965&spn=0.000243,0.00108&sll=49.232898,6.991044&sspn=0.00124,0.003181&oq=copenhgen&t=k&hnear=Copenhagen,+Denmark&z=20&layer=c&cbll=55.671836,12.575965&panoid=B-OHnVJpkuQbGM970L7okw&cbp=11,335.72,,0,8.94

Volker
(Padova, Italy)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120428/2c9687de/attachment.html>

From osm at tobias-knerr.de  Sat Apr 28 11:15:44 2012
From: osm at tobias-knerr.de (Tobias Knerr)
Date: Sat, 28 Apr 2012 12:15:44 +0200
Subject: [Tagging] Waterway directionality in drainage canals
In-Reply-To: <4F9BB735.9020504@gmail.com>
References: <4F9BB735.9020504@gmail.com>
Message-ID: <4F9BC350.6020107@tobias-knerr.de>

28.04.2012 11:24, Nathan Edgars II wrote:
> So there are a lot of major canals that have no fixed direction. How
> should these be mapped? Is there any existing scheme that can show how
> water flows under different conditions?

We have this abandoned proposal for explicitly mapping flow directions:
http://wiki.openstreetmap.org/wiki/Proposed_features/directional
It has only a "tidal" value, though. Maybe additional values would solve
the problem?

That being said, it's not actually in use. So defining a new proposal
for something like flow_direction=* with appropriate values would work
just as well.

Tobias


From dieterdreist at gmail.com  Sat Apr 28 12:03:49 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sat, 28 Apr 2012 13:03:49 +0200
Subject: [Tagging] Chaos and uncertainty in "bridge"
In-Reply-To: <1326817797256-7196975.post@n2.nabble.com>
References: <CABPTjTCkOfCwk6QpT1zxObz1VarULqRQhms+A-gss3HTxHH1Fg@mail.gmail.com>
	<1326817797256-7196975.post@n2.nabble.com>
Message-ID: <CABPTjTBXHLTgohw9cWQY_vP=pk7X-Ey0ed9jCRfE3cZVv6sT3w@mail.gmail.com>

Am 17. Januar 2012 17:29 schrieb sylvain letuffe <liste at letuffe.org>:
>> Last but not least I'd like to ask you for comments on 3 new values:
>> N1. a bridge made of few ropes where you walk on a rope:
>> http://bauwiki.tugraz.at/pub/Baulexikon/HaengeSeilBrueckeB/Kaiserschild_1.jpg
>> http://www.gruppenstunden-freizeit-programme.de/ferienlager-freizeiten-erlebnisse/freizeit-bilder/seilbruecke/Piratenlager-05-262.JPG
>> http://www.bergsteigen.at/pic/d6025434-21f9-4d93-9ce9-42aba5cf00db.jpg
>>
>> additionally we could tag the amount of ropes (or even more precisely
>> the amount of "upper" and "lower" ropes)
> Juste an comment to let you know that your "border line ;-)" bridges are
> somehow described in this proposal :
> http://wiki.openstreetmap.org/wiki/Proposed_features/via_ferrata


thank you for noting this. The proposal currently suggests:

bridge=yes for "An unspecified bridge type along the via ferrata route"
and
cable_number=>1 for "For cable bridges the total number of cables, in
addition to bridge=yes"

I'd suggest to specify the bridge value more detailed than "yes".
bridge=cable or cable_bridge doesn't seem reasonable though, as it
seems to be a different bridge type:
http://en.wikipedia.org/wiki/Cable-stayed_bridge

zip_line as you point out isn't the correct term either.

Any suggestions what we could use?

cheers,
Martin


From osm at inbox.org  Sat Apr 28 12:27:15 2012
From: osm at inbox.org (Anthony)
Date: Sat, 28 Apr 2012 07:27:15 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F9BA4EC.2020201@gmx.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
	<4F9BA4EC.2020201@gmx.com>
Message-ID: <CAPreJLQCnXw8RL70tq6m5qv3Q45asZktViy3fzf5+FUGOXH9pg@mail.gmail.com>

On Sat, Apr 28, 2012 at 4:06 AM, Marl <osm-marl at gmx.com> wrote:
> On 27/04/12 20:11, Anthony wrote:
>> On Fri, Apr 27, 2012 at 3:06 PM, Tobias Knerr <osm at tobias-knerr.de> wrote:
>>> Anthony wrote:
>>> If I were writing a renderer (actually, I am), I would assume that a
>>> closed way does not represent an area unless it a) has an always-area
>>> tag such as landuse or b) is tagged with area=yes. Your idea that
>>> some tags should make a closed way into an area by default, unless
>>> there's also a certain other tag (like area=no) present, is not
>>> established mapping style as far as I can tell. Currently, tags are
>>> either unambiguous, or the default assumption is "not an area".
>> Well that's a mistake that should be fixed.
>>
>> _______________________________________________
>>
> I think that it's not a mistake.
>
> The idea of having different defaults for area= would not only keep
> programmers busy (they can do more beneficial things during the time
> wasted for this), it also confuses mappers. I (as a mapper) don't want
> to look up the default for every tag.

I think we should decide the better way to map first, and then let the
programmers prioritize the fix.  Since programmers are already
checking for always-area, it doesn't seem like a difficult fix.  Are
patches welcome?


From neroute2 at gmail.com  Sat Apr 28 12:28:04 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Sat, 28 Apr 2012 07:28:04 -0400
Subject: [Tagging] lanes=* on cycleways
In-Reply-To: <CABUOUO-tUKSuNimbxkcvFrgfY=40LtWr6H=wLZXZZnopDaoAaQ@mail.gmail.com>
References: <CAMPM96r0vanmkru+ESEPE2LCPYxCS1GmRVtg_BW7HqL5RYK4eg@mail.gmail.com>
	<CABUOUO-tUKSuNimbxkcvFrgfY=40LtWr6H=wLZXZZnopDaoAaQ@mail.gmail.com>
Message-ID: <4F9BD444.4000102@gmail.com>

On 4/28/2012 5:32 AM, Sander Deryckere wrote:
> Can you give a picture of multi-lane cycleways (or coordinates, so we
> can see it in aerial pics or via streetview)?

Not quite what you're looking for, but here's another weird edge case 
with a "pedestrian lane" rather than a sidewalk: 
http://maps.google.com/maps?hl=en&ll=26.588978,-81.928134&spn=0.000755,0.001032&gl=us&t=k&z=21&layer=c&cbll=26.588978,-81.928134&panoid=ctM_XMtsJnYDzsUigfyhew&cbp=12,281.1,,1,8.92


From me at komzpa.net  Sat Apr 28 12:38:13 2012
From: me at komzpa.net (=?UTF-8?Q?Kom=D1=8Fpa?=)
Date: Sat, 28 Apr 2012 14:38:13 +0300
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPreJLQCnXw8RL70tq6m5qv3Q45asZktViy3fzf5+FUGOXH9pg@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
	<4F9BA4EC.2020201@gmx.com>
	<CAPreJLQCnXw8RL70tq6m5qv3Q45asZktViy3fzf5+FUGOXH9pg@mail.gmail.com>
Message-ID: <CAC8Q8t+XC7GqhMQMF8R-8Hf4WE3QT5KhxVgVB3JNBJBk0XU-Tw@mail.gmail.com>

> I think we should decide the better way to map first, and then let the
> programmers prioritize the fix. ?Since programmers are already
> checking for always-area, it doesn't seem like a difficult fix. ?Are
> patches welcome?

Patches welcome.

As programmers, we need a complete machine-readable list of
always-area keys and key=value's.


-- 
Darafei "Kom?pa" Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:me at komzpa.net mailto:me at komzpa.net


From osm at inbox.org  Sat Apr 28 12:42:03 2012
From: osm at inbox.org (Anthony)
Date: Sat, 28 Apr 2012 07:42:03 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F9BC0CB.4060103@tobias-knerr.de>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
	<4F9BA4EC.2020201@gmx.com> <4F9BB9BA.5090804@uni-paderborn.de>
	<4F9BC0CB.4060103@tobias-knerr.de>
Message-ID: <CAPreJLSexjaiXAehWZsBQH0ekwDb3DCVV21+Td9ZOYPstF2yCA@mail.gmail.com>

On Sat, Apr 28, 2012 at 6:04 AM, Tobias Knerr <osm at tobias-knerr.de> wrote:
> I assume that this is a misunderstanding, because I don't think anybody
> was suggesting that area=yes should be used together with tags that are
> unambiguous anyway. My suggestion, and current practice as far as I can
> tell, is:
>
> * If a tag can only be used on areas, or only on ways, you don't need an
> area tag.
> * If a tag can be used on both areas and ways, the default
> interpretation is that it is a way, and area=yes is required to make it
> an area.

>> On the other hand, a fenced field is landuse=* (and in this respect
>> implicitly area=yes) and barrier=fence (and here implicitly area=no),
>> and that's fine.
>
> Actually, that particular style of using barrier=fence has always been a
> bit of a hack and it's probably not the best example of clean tagging.
>
> But since landuse cannot be used on ways, and barrier=fence cannot be
> used on areas (well, it can, but then it is treated as a "this area is
> fenced" attribute and not as a very wide fence), this is again not an
> example where area=yes or area=no is required at all.

Now I'm confused.  The wiki says that almost all the barrier=* types
can be used on areas.  So applying your rules above they would also
require area=no.  But this seems to be an exception?

So it seems we're already at the point where we have to "look up the
default for every tag".  And I'm not even sure where we can look up
this default (apparently we have to look for an always-area tag
somewhere in the code for your renderer?


From osm at inbox.org  Sat Apr 28 12:59:55 2012
From: osm at inbox.org (Anthony)
Date: Sat, 28 Apr 2012 07:59:55 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAC8Q8t+XC7GqhMQMF8R-8Hf4WE3QT5KhxVgVB3JNBJBk0XU-Tw@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
	<4F9BA4EC.2020201@gmx.com>
	<CAPreJLQCnXw8RL70tq6m5qv3Q45asZktViy3fzf5+FUGOXH9pg@mail.gmail.com>
	<CAC8Q8t+XC7GqhMQMF8R-8Hf4WE3QT5KhxVgVB3JNBJBk0XU-Tw@mail.gmail.com>
Message-ID: <CAPreJLTYzhQvd=pZNyJ-umfU23hREVP5a2oxVX4FZWGv-+c9Rw@mail.gmail.com>

On Sat, Apr 28, 2012 at 7:38 AM, Kom?pa <me at komzpa.net> wrote:
>> I think we should decide the better way to map first, and then let the
>> programmers prioritize the fix. ?Since programmers are already
>> checking for always-area, it doesn't seem like a difficult fix. ?Are
>> patches welcome?
>
> Patches welcome.
>
> As programmers, we need a complete machine-readable list of
> always-area keys and key=value's.

What specific program or programs are we looking at?

Scanning the wiki it looks like usually-not-area would be less of a
moving target.  Otherwise almost every time someone adds a new amenity
you have to add a new always-area tag.  The usually-not-area would be
junction=roundabout, barrier=*, highway=pedestrian, leisure=track,
man_made=breakwater, man_made=groyne, man_made=pier, natural=cliff,
and waterway=dam.

I wouldn't even include public_transport=platform.  In those few cases
where you want a hole in the middle, use a multipolygon.

Not sure what to make of sport=toboggan, sport=water_ski, or
tourism=artwork.  That would require more research.


From osm at inbox.org  Sat Apr 28 13:02:00 2012
From: osm at inbox.org (Anthony)
Date: Sat, 28 Apr 2012 08:02:00 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPreJLTYzhQvd=pZNyJ-umfU23hREVP5a2oxVX4FZWGv-+c9Rw@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
	<4F9BA4EC.2020201@gmx.com>
	<CAPreJLQCnXw8RL70tq6m5qv3Q45asZktViy3fzf5+FUGOXH9pg@mail.gmail.com>
	<CAC8Q8t+XC7GqhMQMF8R-8Hf4WE3QT5KhxVgVB3JNBJBk0XU-Tw@mail.gmail.com>
	<CAPreJLTYzhQvd=pZNyJ-umfU23hREVP5a2oxVX4FZWGv-+c9Rw@mail.gmail.com>
Message-ID: <CAPreJLRgK75Vumsp6f-guuW6tSXv8iKtkVsRpKLxO-rDp5Vc1Q@mail.gmail.com>

On Sat, Apr 28, 2012 at 7:59 AM, Anthony <osm at inbox.org> wrote:
> Scanning the wiki it looks like usually-not-area would be less of a
> moving target. ?Otherwise almost every time someone adds a new amenity
> you have to add a new always-area tag. ?The usually-not-area would be
> junction=roundabout, barrier=*, highway=pedestrian, leisure=track,
> man_made=breakwater, man_made=groyne, man_made=pier, natural=cliff,
> and waterway=dam.

Make that highway=*.


From me at komzpa.net  Sat Apr 28 13:17:49 2012
From: me at komzpa.net (=?UTF-8?Q?Kom=D1=8Fpa?=)
Date: Sat, 28 Apr 2012 15:17:49 +0300
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPreJLTYzhQvd=pZNyJ-umfU23hREVP5a2oxVX4FZWGv-+c9Rw@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
	<4F9BA4EC.2020201@gmx.com>
	<CAPreJLQCnXw8RL70tq6m5qv3Q45asZktViy3fzf5+FUGOXH9pg@mail.gmail.com>
	<CAC8Q8t+XC7GqhMQMF8R-8Hf4WE3QT5KhxVgVB3JNBJBk0XU-Tw@mail.gmail.com>
	<CAPreJLTYzhQvd=pZNyJ-umfU23hREVP5a2oxVX4FZWGv-+c9Rw@mail.gmail.com>
Message-ID: <CAC8Q8tK47DgehVwnwZe2Ysok4mV1UcgBmwtce4e_vp8mYbekqA@mail.gmail.com>

> What specific program or programs are we looking at?

Any program that needs to go from OSM data model to OGC-compatible
one, having "area" object.
That basically lists any database backend (osm2pgsql, osm2sqlite,
nominatim...) and any converter like osm2shp/osm2ogr.
The list of software that depends on these is significantly lareger,
like nominatim, Mapnik, KothicJS, wikipedia integration project WIWOSM
and most data consumers.

> tourism=artwork. ?That would require more research.

The only problem that it requires research. Every coder that wants
just to take OSM data has to do that research. Months of digging the
wiki, basically.

De facto list of always-area tags is present on
http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/default.style

Anyone whining "software authors should have a better always-area
list" or "then software should be fixed" should make that better list.
Period.


-- 
Darafei "Kom?pa" Praliaskouski
OSM BY Team - http://openstreetmap.by/
xmpp:me at komzpa.net mailto:me at komzpa.net


From osm at inbox.org  Sat Apr 28 13:36:07 2012
From: osm at inbox.org (Anthony)
Date: Sat, 28 Apr 2012 08:36:07 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAC8Q8tK47DgehVwnwZe2Ysok4mV1UcgBmwtce4e_vp8mYbekqA@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
	<4F9BA4EC.2020201@gmx.com>
	<CAPreJLQCnXw8RL70tq6m5qv3Q45asZktViy3fzf5+FUGOXH9pg@mail.gmail.com>
	<CAC8Q8t+XC7GqhMQMF8R-8Hf4WE3QT5KhxVgVB3JNBJBk0XU-Tw@mail.gmail.com>
	<CAPreJLTYzhQvd=pZNyJ-umfU23hREVP5a2oxVX4FZWGv-+c9Rw@mail.gmail.com>
	<CAC8Q8tK47DgehVwnwZe2Ysok4mV1UcgBmwtce4e_vp8mYbekqA@mail.gmail.com>
Message-ID: <CAPreJLRbz+pe3gAn_dB7NEJy41RQfQtxKF3nK=LXJ4yJk+K5RA@mail.gmail.com>

On Sat, Apr 28, 2012 at 8:17 AM, Kom?pa <me at komzpa.net> wrote:
>> What specific program or programs are we looking at?
>
> Any program that needs to go from OSM data model to OGC-compatible
> one, having "area" object.

Well, my question is what program or programs are you requesting
patches for.  Presumably these are programs which you are maintaining,
otherwise it's not your place to request patches for them.

I certainly don't feel like doing work making a patch which winds up
not being accepted.

>> tourism=artwork. ?That would require more research.
>
> The only problem that it requires research. Every coder that wants
> just to take OSM data has to do that research. Months of digging the
> wiki, basically.
>
> De facto list of always-area tags is present on
> http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/default.style
>
> Anyone whining "software authors should have a better always-area
> list" or "then software should be fixed" should make that better list.
> Period.

First we need to agree on what needs to be fixed.  Tobias says that no
renderers or other applications working on OSM data should ever
consider area=no.  So obviously I wouldn't want to work on a patch for
a program that he is maintaining, to fix it so that it considers
area=no.


From osm at tobias-knerr.de  Sat Apr 28 14:16:49 2012
From: osm at tobias-knerr.de (Tobias Knerr)
Date: Sat, 28 Apr 2012 15:16:49 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPT3zJpNbpcgV9h6Lu5YrU+ACr5z1qKeDqOPY911sU7zb4EyGg@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPT3zJpNbpcgV9h6Lu5YrU+ACr5z1qKeDqOPY911sU7zb4EyGg@mail.gmail.com>
Message-ID: <4F9BEDC1.9020200@tobias-knerr.de>

On 27.04.2012 10:12, Pieren wrote:
> You have to know anyway if your feature can be either a closed way or
> an area and therefore need some special handling in your apps.

Unfortunately, yes. I wish we already had a proper area primitive so
this whole discussion would be obsolete.

> The question is then more to consider certain features as "area" or
> "closed way" by default. On this point, I'm always standing on the
> contributors side and wont ask them to add an unnecessary tag for
> 99.99% of the cases.

Having to type "area=yes" less frequently is in the contributors'
interest, sure. But having simple rules for defaults is also in the
contributors' interest.

Right now, we already have to distinguish three types of tags:
* always area
* always way
* way unless area=yes is present.

I simply do not think that the possibility to decrease of the number of
tags is worth introducing "area unless area=no is present" in addition
to these. Particularly because whether area or way is the default would
depend on what is assumed to be more likely in reality. And people might
easily have different assumptions here, making that kind of default
non-obvious.

Tobias


From neroute2 at gmail.com  Sat Apr 28 14:17:34 2012
From: neroute2 at gmail.com (Nathan Edgars II)
Date: Sat, 28 Apr 2012 09:17:34 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPreJLTYzhQvd=pZNyJ-umfU23hREVP5a2oxVX4FZWGv-+c9Rw@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPreJLR7SMygOfZA5pqMUhkYe6_9vsXL57FtNr5+36cXUGt03A@mail.gmail.com>
	<4F9AEE21.2080707@tobias-knerr.de>
	<CAPreJLRve9zar=xJDp_u-h8iFne+WviR9sYqe4AeP6Y8qVwBPw@mail.gmail.com>
	<4F9BA4EC.2020201@gmx.com>
	<CAPreJLQCnXw8RL70tq6m5qv3Q45asZktViy3fzf5+FUGOXH9pg@mail.gmail.com>
	<CAC8Q8t+XC7GqhMQMF8R-8Hf4WE3QT5KhxVgVB3JNBJBk0XU-Tw@mail.gmail.com>
	<CAPreJLTYzhQvd=pZNyJ-umfU23hREVP5a2oxVX4FZWGv-+c9Rw@mail.gmail.com>
Message-ID: <4F9BEDEE.6000302@gmail.com>

On 4/28/2012 7:59 AM, Anthony wrote:
> Scanning the wiki it looks like usually-not-area would be less of a
> moving target.  Otherwise almost every time someone adds a new amenity
> you have to add a new always-area tag.  The usually-not-area would be
> junction=roundabout, barrier=*, highway=pedestrian, leisure=track,
> man_made=breakwater, man_made=groyne, man_made=pier, natural=cliff,
> and waterway=dam.

There are also issues with multiple tags. For example tourism=attraction 
is usually an area, but on a railway=preserved that goes in a loop it's 
probably not. I don't think Mapnik handles an explicit area=no correctly 
here.


From osm at inbox.org  Sat Apr 28 14:39:21 2012
From: osm at inbox.org (Anthony)
Date: Sat, 28 Apr 2012 09:39:21 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F9BEDC1.9020200@tobias-knerr.de>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPT3zJpNbpcgV9h6Lu5YrU+ACr5z1qKeDqOPY911sU7zb4EyGg@mail.gmail.com>
	<4F9BEDC1.9020200@tobias-knerr.de>
Message-ID: <CAPreJLRr=ibJiK_8LZEpofhdZKNAXX4Fy0=bqzNmR-FRoNRVCQ@mail.gmail.com>

On Sat, Apr 28, 2012 at 9:16 AM, Tobias Knerr <osm at tobias-knerr.de> wrote:
> Right now, we already have to distinguish three types of tags:
> * always area
> * always way
> * way unless area=yes is present.
>
> I simply do not think that the possibility to decrease of the number of
> tags is worth introducing "area unless area=no is present" in addition
> to these. Particularly because whether area or way is the default would
> depend on what is assumed to be more likely in reality. And people might
> easily have different assumptions here, making that kind of default
> non-obvious.

I don't see how we'd be adding any more confusion by adding a fourth
type.  Right now if someone tags something as railway=platform they
have to figure out whether it is "always area" (*) or "way unless
area=yes is present", and this is not at all obvious.

Even more confusing are the barrier=* tags.  I think they are of the
type "always way", but I'm not 100% sure about that.  The wiki lists
barrier=city_wall as being a way or an area.  But I think by area they
just mean closed way.  Is barrier=city_wall "always area" (*), "always
way" or "way unless area=yes is present"?  How is someone supposed to
figure this out?

Allowing area=no provides a simple method of dealing with cases where
you are unsure: just tag area=yes/no explicitly.

(*) I note, here, that "always area" doesn't mean "the way always
represents an area", it means "the way always represents an area when
it is closed".


From osm at inbox.org  Sat Apr 28 14:45:29 2012
From: osm at inbox.org (Anthony)
Date: Sat, 28 Apr 2012 09:45:29 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPreJLRr=ibJiK_8LZEpofhdZKNAXX4Fy0=bqzNmR-FRoNRVCQ@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPT3zJpNbpcgV9h6Lu5YrU+ACr5z1qKeDqOPY911sU7zb4EyGg@mail.gmail.com>
	<4F9BEDC1.9020200@tobias-knerr.de>
	<CAPreJLRr=ibJiK_8LZEpofhdZKNAXX4Fy0=bqzNmR-FRoNRVCQ@mail.gmail.com>
Message-ID: <CAPreJLQZyu5VoP9xf7=UKqfCAwF3V_-t9mJM35py5DTbx=+gHA@mail.gmail.com>

Another example is amenity=marketplace.  How am I supposed to know if
this is "always way", "always area", or "way unless area=yes is
present"?  Which one is it?


From wendorff at uni-paderborn.de  Sat Apr 28 15:10:40 2012
From: wendorff at uni-paderborn.de (Peter Wendorff)
Date: Sat, 28 Apr 2012 16:10:40 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPreJLRr=ibJiK_8LZEpofhdZKNAXX4Fy0=bqzNmR-FRoNRVCQ@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPT3zJpNbpcgV9h6Lu5YrU+ACr5z1qKeDqOPY911sU7zb4EyGg@mail.gmail.com>
	<4F9BEDC1.9020200@tobias-knerr.de>
	<CAPreJLRr=ibJiK_8LZEpofhdZKNAXX4Fy0=bqzNmR-FRoNRVCQ@mail.gmail.com>
Message-ID: <4F9BFA60.8070304@uni-paderborn.de>

For the barrier=city_wall I in fact see way AND area as possible:
A mid-age city wall of a bigger city may have walls of several meters 
width sometimes, that include corridors, stairways and more, as another 
building would.
If I map a strip of grass as an area with a width of 1m, a city wall 
with 5m width is an area, too - that's sometimes similar in size than a 
usual house.

I think, we should (!) introduce an area tag in the next API version, 
that allows the strict distinction between area and way by type, 
independent of tags.

regards
Peter

Am 28.04.2012 15:39, schrieb Anthony:
> On Sat, Apr 28, 2012 at 9:16 AM, Tobias Knerr<osm at tobias-knerr.de>  wrote:
>> Right now, we already have to distinguish three types of tags:
>> * always area
>> * always way
>> * way unless area=yes is present.
>>
>> I simply do not think that the possibility to decrease of the number of
>> tags is worth introducing "area unless area=no is present" in addition
>> to these. Particularly because whether area or way is the default would
>> depend on what is assumed to be more likely in reality. And people might
>> easily have different assumptions here, making that kind of default
>> non-obvious.
> I don't see how we'd be adding any more confusion by adding a fourth
> type.  Right now if someone tags something as railway=platform they
> have to figure out whether it is "always area" (*) or "way unless
> area=yes is present", and this is not at all obvious.
>
> Even more confusing are the barrier=* tags.  I think they are of the
> type "always way", but I'm not 100% sure about that.  The wiki lists
> barrier=city_wall as being a way or an area.  But I think by area they
> just mean closed way.  Is barrier=city_wall "always area" (*), "always
> way" or "way unless area=yes is present"?  How is someone supposed to
> figure this out?
>
> Allowing area=no provides a simple method of dealing with cases where
> you are unsure: just tag area=yes/no explicitly.
>
> (*) I note, here, that "always area" doesn't mean "the way always
> represents an area", it means "the way always represents an area when
> it is closed".
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
>



From malcolm.herring at btinternet.com  Sat Apr 28 15:14:20 2012
From: malcolm.herring at btinternet.com (Malcolm Herring)
Date: Sat, 28 Apr 2012 15:14:20 +0100
Subject: [Tagging] Waterway directionality in drainage canals
In-Reply-To: <4F9BB735.9020504@gmail.com>
References: <4F9BB735.9020504@gmail.com>
Message-ID: <jngtvs$c0h$1@dough.gmane.org>

In many European canals, the convention is for the waterway authorities 
to arbitrarily define a direction so that a 'left' and 'right' bank can 
be defined and the appropriate navigational marks installed. So in those 
cases, where you see red on one side and green on the other, the 
nominated 'direction' can be deduced. If you face in the direction that 
places the red marks on your right & green marks on your left, then you 
are facing downstream.

Of course, that does not help you in the case of non-navigable or 
unmarked waterways.



From voschix at gmail.com  Sat Apr 28 15:29:53 2012
From: voschix at gmail.com (Volker Schmidt)
Date: Sat, 28 Apr 2012 16:29:53 +0200
Subject: [Tagging] Waterway directionality in drainage canals
In-Reply-To: <jngtvs$c0h$1@dough.gmane.org>
References: <4F9BB735.9020504@gmail.com>
	<jngtvs$c0h$1@dough.gmane.org>
Message-ID: <CALQ-OR6BByyXVkqngX2i56vPGF2Lze8OSR10qaFTuaTMApF5Kw@mail.gmail.com>

On 28 April 2012 16:14, Malcolm Herring <malcolm.herring at btinternet.com>wrote:

> In many European canals, the convention is for the waterway authorities to
> arbitrarily define a direction so that a 'left' and 'right' bank can be
> defined and the appropriate navigational marks installed. So in those
> cases, where you see red on one side and green on the other, the nominated
> 'direction' can be deduced. If you face in the direction that places the
> red marks on your right & green marks on your left, then you are facing
> downstream.
>
> That's a good point. I never checked the navigational marks, to be honest.
I only know from what is written in Wikipedia or similar sources that they
are bidirectional. The purpose is that they can direct the water according
to need, in particular for irrigation purposes.

Volker
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120428/f3cf2297/attachment-0001.html>

From baloo at ursamundi.org  Sat Apr 28 20:26:55 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Sat, 28 Apr 2012 12:26:55 -0700
Subject: [Tagging] lanes=* on cycleways
In-Reply-To: <CABUOUO-tUKSuNimbxkcvFrgfY=40LtWr6H=wLZXZZnopDaoAaQ@mail.gmail.com>
References: <CAMPM96r0vanmkru+ESEPE2LCPYxCS1GmRVtg_BW7HqL5RYK4eg@mail.gmail.com>
	<CABUOUO-tUKSuNimbxkcvFrgfY=40LtWr6H=wLZXZZnopDaoAaQ@mail.gmail.com>
Message-ID: <CAMPM96oWHg9QMsv8X+byLK3ZXPT3oO+2hYVPg-oPJtyjXHDeCg@mail.gmail.com>

On Sat, Apr 28, 2012 at 2:32 AM, Sander Deryckere <sanderd17 at gmail.com> wrote:
> Can you give a picture of multi-lane cycleways (or coordinates, so we can
> see it in aerial pics or via streetview)?

http://g.co/maps/eyfz7 (Westbound Hawthorne Bridge, the passing lane
for bikes is the left one; that lane ends at the top of the hill, then
once on the bridge proper, the left lane is the through lane and the
right lane is the passing lane, shared with pedestrians).

http://g.co/maps/v4u5v  Northbound 14th Avenue, bike lane on left ends
as lane on right begins.

Galloping Goose in Victoria is marked as multilane last time I rode on
it, though I can't find a clear aerial.

> The only multi-lane cycleways I know are two-direction cycleways, where the
> lines are only a suggestion. So it doesn't really matter whether it's a
> two-way cycleway with one or two lanes.

Unless your area violates the Vienna Convention, the lines aren't a
suggestion. ;o)


From dieterdreist at gmail.com  Sat Apr 28 20:59:12 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sat, 28 Apr 2012 21:59:12 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F9BFA60.8070304@uni-paderborn.de>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPT3zJpNbpcgV9h6Lu5YrU+ACr5z1qKeDqOPY911sU7zb4EyGg@mail.gmail.com>
	<4F9BEDC1.9020200@tobias-knerr.de>
	<CAPreJLRr=ibJiK_8LZEpofhdZKNAXX4Fy0=bqzNmR-FRoNRVCQ@mail.gmail.com>
	<4F9BFA60.8070304@uni-paderborn.de>
Message-ID: <CABPTjTC6aDJGccbjy6LvEouD-JGXtL8f3KRdgGW1xYHzXh0OGw@mail.gmail.com>

Am 28. April 2012 16:10 schrieb Peter Wendorff <wendorff at uni-paderborn.de>:
> For the barrier=city_wall I in fact see way AND area as possible:
> A mid-age city wall of a bigger city may have walls of several meters width
> sometimes, that include corridors, stairways and more, as another building
> would.
> If I map a strip of grass as an area with a width of 1m, a city wall with 5m
> width is an area, too - that's sometimes similar in size than a usual house.


+1,
look here for example:
http://maps.google.it/maps?q=roma+colombo&ll=41.874093,12.493483&spn=0.000751,0.001321&client=ubuntu&channel=cs&fb=1&gl=it&hq=roma+colombo&radius=15000&t=h&z=20

cheers,
Martin


From osm at inbox.org  Sat Apr 28 22:00:37 2012
From: osm at inbox.org (Anthony)
Date: Sat, 28 Apr 2012 17:00:37 -0400
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F9BFA60.8070304@uni-paderborn.de>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPT3zJpNbpcgV9h6Lu5YrU+ACr5z1qKeDqOPY911sU7zb4EyGg@mail.gmail.com>
	<4F9BEDC1.9020200@tobias-knerr.de>
	<CAPreJLRr=ibJiK_8LZEpofhdZKNAXX4Fy0=bqzNmR-FRoNRVCQ@mail.gmail.com>
	<4F9BFA60.8070304@uni-paderborn.de>
Message-ID: <CAPreJLQ7SrHywF654wvme9GjTgoiAWktd78VYSb9Sz+V5YduzQ@mail.gmail.com>

On Sat, Apr 28, 2012 at 10:10 AM, Peter Wendorff
<wendorff at uni-paderborn.de> wrote:
> For the barrier=city_wall I in fact see way AND area as possible:

Isn't area always possible?

> I think, we should (!) introduce an area tag in the next API version, that
> allows the strict distinction between area and way by type, independent of
> tags.

Eh, you wouldn't even need a new API version.  Just require all areas
to be done as multipolygon relations.


From Alan_Mintz+OSM at Earthlink.Net  Sun Apr 29 04:42:20 2012
From: Alan_Mintz+OSM at Earthlink.Net (Alan Mintz)
Date: Sat, 28 Apr 2012 20:42:20 -0700
Subject: [Tagging] Waterway directionality in drainage canals
In-Reply-To: <4F9BB735.9020504@gmail.com>
Message-ID: <5.1.0.14.2.20120428204048.03c23a40@mail.earthlink.net>

At 2012-04-28 02:24, Nathan Edgars II wrote:
>It's the standard to draw a waterway in the direction of flow. I've 
>questioned this several times, but it's an ingrained default.
>
>My question is more specific: what happens to a drainage canal that 
>reverses direction? I offer the Everglades and surrounding agricultural 
>land as an example. There are huge "water conservation areas" that store 
>water. When it rains, gates are closed and opened to direct water into 
>these. During a drought, gates send water back out into the canals for 
>local use. When there's a big storm, water will instead go directly out to sea.
>
>So there are a lot of major canals that have no fixed direction. How 
>should these be mapped? Is there any existing scheme that can show how 
>water flows under different conditions?

oneway=no would make sense, since the (unusual) default assumption for this 
type of object appears to be oneway=yes.

--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>



From baloo at ursamundi.org  Sun Apr 29 05:51:10 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Sat, 28 Apr 2012 21:51:10 -0700
Subject: [Tagging] Waterway directionality in drainage canals
In-Reply-To: <5.1.0.14.2.20120428204048.03c23a40@mail.earthlink.net>
References: <4F9BB735.9020504@gmail.com>
	<5.1.0.14.2.20120428204048.03c23a40@mail.earthlink.net>
Message-ID: <CAMPM96q1+dtwhgBaxw7aPMbQ7S_MDPVbBMaykfkvbj8Wiyvv6A@mail.gmail.com>

On Apr 28, 2012 8:43 PM, "Alan Mintz" <Alan_Mintz+OSM at earthlink.net> wrote:

> oneway=no would make sense, since the (unusual) default assumption for
this type of object appears to be oneway=yes.

It's possible that there are places where the waterway is legally
restricted to travel in one direction.  oneway:flow=* may be better.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120428/f1d3274b/attachment.html>

From imagic.osm at gmail.com  Sun Apr 29 10:41:05 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Sun, 29 Apr 2012 11:41:05 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <1335007385.12429.48.camel@marvin>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<1335007385.12429.48.camel@marvin>
Message-ID: <CAKjckyMX5v_W9j9Vsez1i+T911AkuWvbWY=4KEsxQA-KAAfLUw@mail.gmail.com>

Those examples are very good. Any chance we could get some
license-compatible photos in the near future?

2012/4/21 Philip Barnes <phil at trigpoint.me.uk>:
> On Sat, 2012-04-21 at 10:19 +0200, Ronnie Soak wrote:
>
>> I would only use a lanes value other than 2 if there are clear road
>> markings, signs or it is otherwise very clear that two cars are
>> supposed to go in one direction at a time (>=3)
> I am not aware of any special signage on 3 lane roads in the UK. It is
> just a knowledge of the highway code that gives you the rules.
>
> ? ? ? ?1. Solid double lines on your side mean do not cross, traffic in
> ? ? ? ?the opposite direction has solo use of the centre lane.
> ? ? ? ?Also broken line on your side and solid double lines on the
> ? ? ? ?other side mean your direction has exclusive use of the centre
> ? ? ? ?lane.
>
> ? ? ? ?2. Broken and solid line on your side, traffic in the opposite
> ? ? ? ?direction has priority use of centre lane but you can overtake
> ? ? ? ?if it is clear and nobody is signalling their intent to pull
> ? ? ? ?out. Usually uphill traffic will have priority in this case.
>
> ? ? ? ?3. Both sides have a broken line and have equal priority to use
> ? ? ? ?the centre lane to overtake. Have not seen one of these for
> ? ? ? ?years.
>
> ? ? ? ?However OSM does not allow anything other than tagging as 3
> ? ? ? ?lanes, so the above is probably irrelevant to OSM tagging.
>
>
>> or there is no way for two cars to pass without a special (signed)
>> passing place (1).
> There is always a way. There are lots of single track minor roads, that
> have no passing places and high hedges close to the road. Passing can
> involve a long reverse and squeeze into a gateway or pull onto any bit
> of grass verge that may be there.
>
> Official passing places are also supposed to be used to allow faster
> traffic to pass, a rule many city dwellers are totally unaware of, much
> to the annoyance of locals. I can remember a public information film, in
> the 70s http://www.youtube.com/watch?v=BQZownCGnYg
>
> Phil
>
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging


From imagic.osm at gmail.com  Sun Apr 29 10:49:38 2012
From: imagic.osm at gmail.com (Martin Vonwald)
Date: Sun, 29 Apr 2012 11:49:38 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyMX5v_W9j9Vsez1i+T911AkuWvbWY=4KEsxQA-KAAfLUw@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<1335007385.12429.48.camel@marvin>
	<CAKjckyMX5v_W9j9Vsez1i+T911AkuWvbWY=4KEsxQA-KAAfLUw@mail.gmail.com>
Message-ID: <CAKjckyOMEoWdFJJW8uWNyifzCH8TPFt3dVHJNQt0tizUtniEvg@mail.gmail.com>

As no further issues were raised with the updated article I will
replace the current lanes-article with my current version.

Before that I added a point in the Open issues section about lanes=1.5
and modified the note at the end of the section Narrow road. As
lanes=1.5 wasn't documented before and is used very rarely (0.05% of
all lanes tags) it shouldn't delay the update of the lanes-article.

I also removed the "none" value in the first example, so that people
are not encouraged to not explicitly tag the lanes value.

I hope that most people are happy with this update. I'll translate the
article into german and maybe into russian, when I got the time.

Martin


From phil_g at pobox.com  Sun Apr 29 13:34:22 2012
From: phil_g at pobox.com (Phil! Gold)
Date: Sun, 29 Apr 2012 08:34:22 -0400
Subject: [Tagging] OSMI layers in JOSM
In-Reply-To: <CAKjckyO=hCEXpARdFkg=dh44ZzVUwndbfNiH0weSCeqgUDAmDA@mail.gmail.com>
References: <CAKjckyO=hCEXpARdFkg=dh44ZzVUwndbfNiH0weSCeqgUDAmDA@mail.gmail.com>
Message-ID: <20120429123421.GO29037@aperiodic.net>

* Martin Vonwald <imagic.osm at gmail.com> [2012-04-25 10:28 +0200]:
> I'm trying to view the OSMI layers in JOSM. The all-knowing,
> all-seeing trash heap pointed me to this (german) article:
> http://forum.openstreetmap.org/viewtopic.php?id=9315
> 
> There it is recommended to use the following link in JOSM:
> http://tools.geofabrik.de/osmi/view/routing/wxs?REQUEST=GetMap&SERVICE=wms&VERSION=1.1.1&FORMAT=image/png&SRS=EPSG:4326&STYLES=&LAYERS=unconnected_minor1,unconnected_minor2,unconnected_minor5,unconnected_major1,unconnected_major2,unconnected_major5&
> 
> This works like a charm, but with the limitations, that one has to
> adjust the resolution manually. Also I seem to be unable to get this
> layer transparent. In the article one wrote to add TRANSPARENT=TRUE to
> the link, but I can't get this working.

Not sure tagging@ is the best list for this, but...

Here's what I use for my OSM Inspector WTFE view:

    wms:http://tools.geofabrik.de/osmi/views/wtfe/wxs?FORMAT=image/png&transparent=true&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&Layers=wtfe_line_created,wtfe_line_modified,wtfe_line_created_cp,wtfe_point_created,wtfe_line_modified_cp,wtfe_point_modified,overview_low,overview&SRS={proj}&WIDTH={width}&HEIGHT={height}&BBOX={bbox}

In particular, my URL contains "/osmi/views/", while yous has
"/osmi/view/".  That might be a source of problems.

> Has anyone a hint for me how to get this layer transparent? Is there
> any possibility to autoadjust the resolution?

You can't automatically adjust the resolution, but you can right-click on
the layer in the "Layers" window and select "Change resolution".  What I
often do is work at two (or sometimes three) specific resolutions, set two
layers of the same WMS to the two different resolutions, and switch
between them with "Zoom to native resolution" from the same right-click
menu.

As the mapping resources I use become more available in either tiles or
AcGIS REST (which I can turn into tiles with tilestache), I've been
transitioning more to using tiled backgrounds, which do change resolutions
automatically (though there are still glitches there).

-- 
...computer contrarian of the first order... / http://aperiodic.net/phil/
PGP: 026A27F2  print: D200 5BDB FC4B B24A 9248  9F7A 4322 2D22 026A 27F2
--- --
If there's nothing wrong with me, there must be something wrong with the
universe.
                       -- Beverly Crusher ("Star Trek")
---- --- --


From ewoerner at kde.org  Sun Apr 29 16:08:05 2012
From: ewoerner at kde.org (Eckhart =?ISO-8859-1?Q?W=F6rner?=)
Date: Sun, 29 Apr 2012 17:08:05 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <4F915751.30002@infoware.de>
References: <2170714.HYHGOC0Ss3@obiwan> <4F915751.30002@infoware.de>
Message-ID: <1910233.Etq374qYjW@obiwan>

Hi everybody,

based on the changes I believe are important I added a modified proposal to the wiki:
http://wiki.openstreetmap.org/wiki/DE_talk:Proposed_features/New_TMC_scheme#Neues_Proposal

Changes:
* Versions are an (optional) part of the proposal. If they are not needed, they can be left out, so this does not complicate tagging.
* TABCD is enclosed by ":" on both sides now.
* Directions of ways are properly taken into account. Ignoring the direction makes TMC information useless on non-oneway ways (which I already argued for in a previous mail).
* Point locations may have an extent.
* Added some informational notes about error checking.

Eckhart


From lauri.kytomaa at aalto.fi  Sun Apr 29 16:29:52 2012
From: lauri.kytomaa at aalto.fi (=?iso-8859-1?Q?Kyt=F6maa_Lauri?=)
Date: Sun, 29 Apr 2012 15:29:52 +0000
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CAKjckyOMEoWdFJJW8uWNyifzCH8TPFt3dVHJNQt0tizUtniEvg@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<1335007385.12429.48.camel@marvin>
	<CAKjckyMX5v_W9j9Vsez1i+T911AkuWvbWY=4KEsxQA-KAAfLUw@mail.gmail.com>,
	<CAKjckyOMEoWdFJJW8uWNyifzCH8TPFt3dVHJNQt0tizUtniEvg@mail.gmail.com>
Message-ID: <D312F9ED2DBBD8479518C8D52CD16973B0A39021@EXMDB01.org.aalto.fi>

>Before that I added a point in the Open issues section about lanes=1.5
>and modified the note at the end of the section Narrow road. As

So, today I got a chance to revisit an unpaved residential road 
I've tagged as lanes=1.5 in the distant past. Here's two 
pictures of it (in one)

Above, usual traffic drives almost in the center of the road,
as if it were lanes=1.

Below, the car in picture has it's right side mirror almost
touching the fence, and there's 2.2 meters of the 
carriageway free for oncoming traffic, 2.6-2.7 meters 
of space to the fence on the other side of the road.
Oncoming cars can get past each other, so it's not
lanes=1. Yet all driveers will slow to a crawl, or at least 
to a jogging speed, so IMO it can't be lanes=2,
either.

http://i46.tinypic.com/2cfqivn.png

Which value would people use for the lanes=*?

-- 
Alv

From dieterdreist at gmail.com  Sun Apr 29 16:39:48 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sun, 29 Apr 2012 17:39:48 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <D312F9ED2DBBD8479518C8D52CD16973B0A39021@EXMDB01.org.aalto.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<1335007385.12429.48.camel@marvin>
	<CAKjckyMX5v_W9j9Vsez1i+T911AkuWvbWY=4KEsxQA-KAAfLUw@mail.gmail.com>
	<CAKjckyOMEoWdFJJW8uWNyifzCH8TPFt3dVHJNQt0tizUtniEvg@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A39021@EXMDB01.org.aalto.fi>
Message-ID: <CABPTjTB6JdMD3joB50EitTp0NrUzfR-iDapn17-QYMM5RX+Pmw@mail.gmail.com>

2012/4/29 Kyt?maa Lauri <lauri.kytomaa at aalto.fi>:
> http://i46.tinypic.com/2cfqivn.png
>
> Which value would people use for the lanes=*?


I think I wouldn't tag any lanes explicitly here. Looks like a
residential road. I wouldn't expect many trucks in this zone, but if I
were to map more detail I'd add a width-tag. Looks as if 2 cars can
pass each other without big problems.

cheers,
Martin


From lauri.kytomaa at aalto.fi  Sun Apr 29 17:12:04 2012
From: lauri.kytomaa at aalto.fi (=?iso-8859-1?Q?Kyt=F6maa_Lauri?=)
Date: Sun, 29 Apr 2012 16:12:04 +0000
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CABPTjTB6JdMD3joB50EitTp0NrUzfR-iDapn17-QYMM5RX+Pmw@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<1335007385.12429.48.camel@marvin>
	<CAKjckyMX5v_W9j9Vsez1i+T911AkuWvbWY=4KEsxQA-KAAfLUw@mail.gmail.com>
	<CAKjckyOMEoWdFJJW8uWNyifzCH8TPFt3dVHJNQt0tizUtniEvg@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A39021@EXMDB01.org.aalto.fi>,
	<CABPTjTB6JdMD3joB50EitTp0NrUzfR-iDapn17-QYMM5RX+Pmw@mail.gmail.com>
Message-ID: <D312F9ED2DBBD8479518C8D52CD16973B0A39057@EXMDB01.org.aalto.fi>

>Looks as if 2 cars can pass each other without big problems.

Only in the utopia where all drivers can confidently 
manouver their cars at speed to gaps only 10-20 cm 
wider than their car. Most people don't.

The white car already has it's right hand wheels
outside the normal driving surface. And this is
early spring, there are no tree/scrub branches
delineating the fences, or any snow limiting
such attempts at scraping the fences with the 
side mirror.

-- 
Alv

From lauri.kytomaa at aalto.fi  Sun Apr 29 17:14:37 2012
From: lauri.kytomaa at aalto.fi (=?iso-8859-1?Q?Kyt=F6maa_Lauri?=)
Date: Sun, 29 Apr 2012 16:14:37 +0000
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CABPTjTAdaTeRE_-Yc3TKzOOfePq3A8Gn0PC5Ehq6PXVJ_+bYUA@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
	<CABPTjTBFP0AN3zaBdxRfrdcyEqXFrvpSNeCfrrDfs7gHG0WDfg@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A38DA6@EXMDB01.org.aalto.fi>,
	<CABPTjTAdaTeRE_-Yc3TKzOOfePq3A8Gn0PC5Ehq6PXVJ_+bYUA@mail.gmail.com>
Message-ID: <D312F9ED2DBBD8479518C8D52CD16973B0A39067@EXMDB01.org.aalto.fi>

>police doesn't enforce the official rules, then there are factually
>more lanes on the ground than painted on the road.

Isn't that equal to cycling on sidewalks: we shouldn't tag 
sidewalks with bicycle=yes (in coutries where cyclists may 
not use them), even if only a dozen or so get a fine each year. 

-- 
Alv

From osm at bavarianmallet.de  Sun Apr 29 17:27:17 2012
From: osm at bavarianmallet.de (Georg Feddern OSM)
Date: Sun, 29 Apr 2012 18:27:17 +0200 (CEST)
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CABPTjTB6JdMD3joB50EitTp0NrUzfR-iDapn17-QYMM5RX+Pmw@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<1335007385.12429.48.camel@marvin>
	<CAKjckyMX5v_W9j9Vsez1i+T911AkuWvbWY=4KEsxQA-KAAfLUw@mail.gmail.com>
	<CAKjckyOMEoWdFJJW8uWNyifzCH8TPFt3dVHJNQt0tizUtniEvg@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A39021@EXMDB01.org.aalto.fi>
	<CABPTjTB6JdMD3joB50EitTp0NrUzfR-iDapn17-QYMM5RX+Pmw@mail.gmail.com>
Message-ID: <1067759399.485115.1335716837200.JavaMail.open-xchange@email.1und1.de>

Martin Koppenhoefer <dieterdreist at gmail.com> hat am 29. April 2012 um 17:39
geschrieben:

> 2012/4/29 Kyt?maa Lauri <lauri.kytomaa at aalto.fi>:
> > http://i46.tinypic.com/2cfqivn.png
> >
> > Which value would people use for the lanes=*?

> >
> I think I wouldn't tag any lanes explicitly here. Looks like a
> residential road. I wouldn't expect many trucks in this zone, but if I
> were to map more detail I'd add a width-tag.


+1
Any 'default' assumption of any user of the data would give a value between
1 and 2 anyway.
As you can see, an assumption of 2 may be the better one here - if you take
passenger cars into account.
As you can see, an assumption of 1 would be the better one here - if you
take lorries into account.

Independently of 1, 1.5 or 2 any router would consider this road with
nearly the same value for the traffic considerations.
Any renderer has a better info with width.

What info do you think has lanes=1.5 then?
What do you think a user can derive from this info?





Looks as if 2 cars can pass each other without big problems.


+1
At least no problems regarding traffic time or the mere usage to reach the
point you want.

But look at the pole right behind - I think they won't try to pass
everywhere without advanced caution.

Georg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120429/2815838c/attachment.html>

From lowflight66 at googlemail.com  Sun Apr 29 17:49:39 2012
From: lowflight66 at googlemail.com (fly)
Date: Sun, 29 Apr 2012 18:49:39 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <1910233.Etq374qYjW@obiwan>
References: <2170714.HYHGOC0Ss3@obiwan> <4F915751.30002@infoware.de>
	<1910233.Etq374qYjW@obiwan>
Message-ID: <4F9D7123.4000601@googlemail.com>

On 29/04/12 17:08, Eckhart W?rner wrote:

Hi everybody + Eckhart

> 
> based on the changes I believe are important I added a modified proposal to the wiki:
> http://wiki.openstreetmap.org/wiki/DE_talk:Proposed_features/New_TMC_scheme#Neues_Proposal
> 
> Changes:
> * Versions are an (optional) part of the proposal. If they are not needed, they can be left out, so this does not complicate tagging.
> * TABCD is enclosed by ":" on both sides now.
> * Directions of ways are properly taken into account. Ignoring the direction makes TMC information useless on non-oneway ways (which I already argued for in a previous mail).
> * Point locations may have an extent.
> * Added some informational notes about error checking.

Thanks for your work ! It looks really good.

I have only one point left:
 What to do with more than on TMC route on one way. Do we still need relations
for that ?

Cheers
Colliar





From ewoerner at kde.org  Sun Apr 29 17:57:56 2012
From: ewoerner at kde.org (Eckhart =?ISO-8859-1?Q?W=F6rner?=)
Date: Sun, 29 Apr 2012 18:57:56 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <4F9D7123.4000601@googlemail.com>
References: <2170714.HYHGOC0Ss3@obiwan> <1910233.Etq374qYjW@obiwan>
	<4F9D7123.4000601@googlemail.com>
Message-ID: <2337245.AgGo7Yv93m@obiwan>

Hi Colliar,

Am Sonntag, 29. April 2012, 18:49:39 schrieb fly:
> I have only one point left:
>  What to do with more than on TMC route on one way. Do we still need relations
> for that ?

no, we don't. My modified proposal skipped over that section (since I changed nothing in it), but the original proposal talks about this:
http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme#Mehrere_Locations_an_einem_Way

Eckhart


From lowflight66 at googlemail.com  Sun Apr 29 18:03:46 2012
From: lowflight66 at googlemail.com (fly)
Date: Sun, 29 Apr 2012 19:03:46 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <2337245.AgGo7Yv93m@obiwan>
References: <2170714.HYHGOC0Ss3@obiwan> <1910233.Etq374qYjW@obiwan>
	<4F9D7123.4000601@googlemail.com> <2337245.AgGo7Yv93m@obiwan>
Message-ID: <4F9D7472.5090801@googlemail.com>

On 29/04/12 18:57, Eckhart W?rner wrote:

> 
> Am Sonntag, 29. April 2012, 18:49:39 schrieb fly:
>> I have only one point left:
>>  What to do with more than on TMC route on one way. Do we still need relations
>> for that ?
> 
> no, we don't. My modified proposal skipped over that section (since I changed nothing in it), but the original proposal talks about this:
> http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme#Mehrere_Locations_an_einem_Way

Sorry, was a bit fast in reading and did not remember all points of original
proposal.

Thanks
Colliar


From dieterdreist at gmail.com  Sun Apr 29 18:44:17 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Sun, 29 Apr 2012 19:44:17 +0200
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <D312F9ED2DBBD8479518C8D52CD16973B0A39067@EXMDB01.org.aalto.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
	<CABPTjTBFP0AN3zaBdxRfrdcyEqXFrvpSNeCfrrDfs7gHG0WDfg@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A38DA6@EXMDB01.org.aalto.fi>
	<CABPTjTAdaTeRE_-Yc3TKzOOfePq3A8Gn0PC5Ehq6PXVJ_+bYUA@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A39067@EXMDB01.org.aalto.fi>
Message-ID: <CABPTjTAGDXxKc3msaMM-xT-xDUQuunWh38P=UUgRQM_OaAkmjw@mail.gmail.com>

2012/4/29 Kyt?maa Lauri <lauri.kytomaa at aalto.fi>:
>>police doesn't enforce the official rules, then there are factually
>>more lanes on the ground than painted on the road.
>
> Isn't that equal to cycling on sidewalks: we shouldn't tag
> sidewalks with bicycle=yes (in coutries where cyclists may
> not use them), even if only a dozen or so get a fine each year.


It is indeed similar, and I do indeed tag these places with bicycle=permissive

cheers,
Martin


From baloo at ursamundi.org  Sun Apr 29 20:29:20 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Sun, 29 Apr 2012 12:29:20 -0700
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <CABPTjTAGDXxKc3msaMM-xT-xDUQuunWh38P=UUgRQM_OaAkmjw@mail.gmail.com>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyNK8j=xPjHeOcHfpzQh9vf5diJe7cKAJrRDfGO-7eFG+g@mail.gmail.com>
	<1334928905.12429.24.camel@marvin>
	<CAK7S3dM1cfYVUtaaXSiz+K_yQTHt7kkUho-p2TRwNb1uh_sMDQ@mail.gmail.com>
	<EA81E0EA-55E3-4D1C-B024-D96C2C831E2F@gmail.com>
	<CALKj2D_3hpKwToH1_qkVqu2x04btqhTQmnpnOujWxPVGV6vtWg@mail.gmail.com>
	<alpine.DEB.2.00.1204211418010.24319@melkinpaasi.cs.helsinki.fi>
	<BB5A16DB-AA55-4101-A38C-46F3BE0153A9@gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37DF0@EXMDB01.org.aalto.fi>
	<CAKjckyOKJ7=KLiAa_UsycJug1mFVWGtLTXXmF+H50B+2huuS5Q@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A37E2D@EXMDB01.org.aalto.fi>
	<CAKjckyNYg4x3mjCb8JftaUvCSjweERsorzbB-Yb8p94b6OLEnA@mail.gmail.com>
	<CAKjckyNKMJLXVG_j_Ee+DNie6eg-Vf45K9K9xwLRM4rpXuPC0w@mail.gmail.com>
	<CAK7S3dMDHM15Er8OcEVrnNqej7mCnmLmSeNaHZai1+H5iqDYOg@mail.gmail.com>
	<CABPTjTBFP0AN3zaBdxRfrdcyEqXFrvpSNeCfrrDfs7gHG0WDfg@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A38DA6@EXMDB01.org.aalto.fi>
	<CABPTjTAdaTeRE_-Yc3TKzOOfePq3A8Gn0PC5Ehq6PXVJ_+bYUA@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A39067@EXMDB01.org.aalto.fi>
	<CABPTjTAGDXxKc3msaMM-xT-xDUQuunWh38P=UUgRQM_OaAkmjw@mail.gmail.com>
Message-ID: <CAMPM96r2hZeSgJWkY7=bt9vMCSrTZCY6msdS8EoF7D1+x9_47Q@mail.gmail.com>

On Apr 29, 2012 10:44 AM, "Martin Koppenhoefer" <dieterdreist at gmail.com>
wrote:
>
> 2012/4/29 Kyt?maa Lauri <lauri.kytomaa at aalto.fi>:
> >>police doesn't enforce the official rules, then there are factually
> >>more lanes on the ground than painted on the road.
> >
> > Isn't that equal to cycling on sidewalks: we shouldn't tag
> > sidewalks with bicycle=yes (in coutries where cyclists may
> > not use them), even if only a dozen or so get a fine each year.
>
>
> It is indeed similar, and I do indeed tag these places with
bicycle=permissive

If bicycles aren't allowed, but it's not consistently enforced, how is this
not bicycle=no?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120429/5acda8f3/attachment.html>

From ewoerner at kde.org  Sun Apr 29 22:57:02 2012
From: ewoerner at kde.org (Eckhart =?ISO-8859-1?Q?W=F6rner?=)
Date: Sun, 29 Apr 2012 23:57:02 +0200
Subject: [Tagging] Feature Proposal - TMC - New tagging scheme for TMC
In-Reply-To: <1910233.Etq374qYjW@obiwan>
References: <2170714.HYHGOC0Ss3@obiwan> <4F915751.30002@infoware.de>
	<1910233.Etq374qYjW@obiwan>
Message-ID: <3646986.3zSFNWKy4B@obiwan>

Am Sonntag, 29. April 2012, 17:08:05 schrieb Eckhart W?rner:
> based on the changes I believe are important I added a modified proposal to the wiki:
> http://wiki.openstreetmap.org/wiki/DE_talk:Proposed_features/New_TMC_scheme#Neues_Proposal
> 
> Changes:
> * Versions are an (optional) part of the proposal. If they are not needed, they can be left out, so this does not complicate tagging.
> * TABCD is enclosed by ":" on both sides now.
> * Directions of ways are properly taken into account. Ignoring the direction makes TMC information useless on non-oneway ways (which I already argued for in a previous mail).
> * Point locations may have an extent.
> * Added some informational notes about error checking.

I forgot to mention another change:
* 20+5 now means going from LCD 20 to LCD 5, which is way more intuitive (the original proposal maps 20+5 to going from LCD 5 to LCD 20)

Eckhart


From alex.rollin at gmail.com  Mon Apr 30 09:07:46 2012
From: alex.rollin at gmail.com (Alex Rollin)
Date: Mon, 30 Apr 2012 15:07:46 +0700
Subject: [Tagging] Fwd: Ojeq Stand
In-Reply-To: <CACOVVBGk9b+XPzUNvmMjWsZuqQH5y_XSNiTi4Fm1dz9wtXUKAQ@mail.gmail.com>
References: <CACOVVBGk9b+XPzUNvmMjWsZuqQH5y_XSNiTi4Fm1dz9wtXUKAQ@mail.gmail.com>
Message-ID: <CACOVVBF=KNCp2f0m39ty5R676LD_8fpk60G=ucfek7+Sjc_kxA@mail.gmail.com>

OK, So i make bad (formatting and approach) proposal for tag ojeq
stand.  It is a motorcycle taxi stand.

http://wiki.openstreetmap.org/wiki/Indonesia/adaptation/ojeq_stand

Help requested with proposal, please, for formatting, placement, generalization.

Alex


From dieterdreist at gmail.com  Mon Apr 30 09:28:12 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Mon, 30 Apr 2012 10:28:12 +0200
Subject: [Tagging] Fwd: Ojeq Stand
In-Reply-To: <CACOVVBF=KNCp2f0m39ty5R676LD_8fpk60G=ucfek7+Sjc_kxA@mail.gmail.com>
References: <CACOVVBGk9b+XPzUNvmMjWsZuqQH5y_XSNiTi4Fm1dz9wtXUKAQ@mail.gmail.com>
	<CACOVVBF=KNCp2f0m39ty5R676LD_8fpk60G=ucfek7+Sjc_kxA@mail.gmail.com>
Message-ID: <CABPTjTBR+Nnu7tCFKPBo5jA7rnvinqR_-YTvBournrzbXCUQtg@mail.gmail.com>

2012/4/30 Alex Rollin <alex.rollin at gmail.com>:
> OK, So i make bad (formatting and approach) proposal for tag ojeq
> stand. ?It is a motorcycle taxi stand.
>
> http://wiki.openstreetmap.org/wiki/Indonesia/adaptation/ojeq_stand


You put this into the Indonesia-namespace of the wiki, but proposals
like this, which describe potentially useful features for the whole
world, should better go into the proposal namespace. This is probably
not an "Indonesia-only-feature".

Have a look here for the established proposal process:
http://wiki.openstreetmap.org/wiki/Creating_a_proposal

usually you do first a draft, then you ask for comments on this list
(tagging) by sending a message beginning with "RFC". After a
reasonable time for other mappers to comment and discuss (usually at
least 14 days), you can go to voting.

cheers,
Martin


From pieren3 at gmail.com  Mon Apr 30 09:53:42 2012
From: pieren3 at gmail.com (Pieren)
Date: Mon, 30 Apr 2012 10:53:42 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <4F9BEDC1.9020200@tobias-knerr.de>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPT3zJpNbpcgV9h6Lu5YrU+ACr5z1qKeDqOPY911sU7zb4EyGg@mail.gmail.com>
	<4F9BEDC1.9020200@tobias-knerr.de>
Message-ID: <CAPT3zJqZjWpZ_UCe-9yLzVFYtw9MaF2E35xRmV8DzOobZcH3yA@mail.gmail.com>

On Sat, Apr 28, 2012 at 3:16 PM, Tobias Knerr <osm at tobias-knerr.de> wrote:

> Right now, we already have to distinguish three types of tags:
> * always area
> * always way
> * way unless area=yes is present.
>
> I simply do not think that the possibility to decrease of the number of
> tags is worth introducing "area unless area=no is present" in addition
> to these. Particularly because whether area or way is the default would
> depend on what is assumed to be more likely in reality. And people might
> easily have different assumptions here, making that kind of default
> non-obvious.

I'm always standing in the contributor point of view. It is not the
wiki (or better said "our recommendations") to follow the osm2pqsql
style file but the opposite. I was asking myself why I accept so
easily a 2nd tag for the highway closed loop and not for the railway
platform. And this is because my assumption is coming form my own
experience like all other mappers. Adding a 2nd tag is acceptable if
we all meet at least some substantial examples IRL. Adding a 2nd tag
just to fix a theoritical issue is much less acceptable, especially
when the main reaction is to say that mapnik/osm2pgsql will fail
because the assumption is done on a key, not a key/value pair.
Here we speak about a non-obvious assumption for the 0.0000000000001% cases ...

Pieren


From erringtona at gmail.com  Mon Apr 30 10:30:40 2012
From: erringtona at gmail.com (Andrew Errington)
Date: Mon, 30 Apr 2012 18:30:40 +0900
Subject: [Tagging] Dispute prevention: meaning of lanes tag
In-Reply-To: <D312F9ED2DBBD8479518C8D52CD16973B0A39021@EXMDB01.org.aalto.fi>
References: <5.1.0.14.2.20120419121456.04a81ec0@mail.earthlink.net>
	<CAKjckyOMEoWdFJJW8uWNyifzCH8TPFt3dVHJNQt0tizUtniEvg@mail.gmail.com>
	<D312F9ED2DBBD8479518C8D52CD16973B0A39021@EXMDB01.org.aalto.fi>
Message-ID: <201204301830.40922.erringtona@gmail.com>

On Mon, 30 Apr 2012 00:29:52 Kyt?maa Lauri wrote:
> >Before that I added a point in the Open issues section about lanes=1.5
> >and modified the note at the end of the section Narrow road. As
>
> So, today I got a chance to revisit an unpaved residential road
> I've tagged as lanes=1.5 in the distant past. Here's two
> pictures of it (in one)
>
> Above, usual traffic drives almost in the center of the road,
> as if it were lanes=1.
>
> Below, the car in picture has it's right side mirror almost
> touching the fence, and there's 2.2 meters of the
> carriageway free for oncoming traffic, 2.6-2.7 meters
> of space to the fence on the other side of the road.
> Oncoming cars can get past each other, so it's not
> lanes=1. Yet all driveers will slow to a crawl, or at least
> to a jogging speed, so IMO it can't be lanes=2,
> either.
>
> http://i46.tinypic.com/2cfqivn.png
>
> Which value would people use for the lanes=*?

Sometimes the answer is "It doesn't matter."

If you tagged it with lanes=1, but not oneway=yes, then it's clearly a 
bottleneck and should be avoided by routers.

If you didn't tag lanes=* at all and you didn't have oneway=yes then my 
assumption would be lanes=2 (because it's not one way).  Or you could tag it 
explicitly with lanes=2. Either way, map users would probably complain that 
it's too narrow for certain types of vehicle, so it should be re-tagged 
lanes=1.

If you tagged the width then it wouldn't matter if it was lanes=1 or lanes=2 
because we can see the overall width and use heuristics to decide if it's a 
slow road or 'normal' road.

Furthermore, if it's classified as highway=residential that would be a hint 
that it's a narrow road not to be driven too fast.

Any of these factors, either assumed, or explicit, should be used by a route 
planner to make this road unattractive for routing.

It's very tempting to add explicit values for every tag, but I really think 
sometimes it just doesn't matter, and we can get the same meaning for 
combinations of other tags (even if the tags are absent).

Best wishes,

Andrew


From erringtona at gmail.com  Mon Apr 30 10:48:39 2012
From: erringtona at gmail.com (Andrew Errington)
Date: Mon, 30 Apr 2012 18:48:39 +0900
Subject: [Tagging] Dispute prevention: meaning of lanes tag
Message-ID: <201204301848.40216.erringtona@gmail.com>

On Mon, 30 Apr 2012 00:29:52 Kyt?maa Lauri wrote:
> >Before that I added a point in the Open issues section about lanes=1.5
> >and modified the note at the end of the section Narrow road. As
>
> So, today I got a chance to revisit an unpaved residential road
> I've tagged as lanes=1.5 in the distant past. Here's two
> pictures of it (in one)
>
> Above, usual traffic drives almost in the center of the road,
> as if it were lanes=1.
>
> Below, the car in picture has it's right side mirror almost
> touching the fence, and there's 2.2 meters of the
> carriageway free for oncoming traffic, 2.6-2.7 meters
> of space to the fence on the other side of the road.
> Oncoming cars can get past each other, so it's not
> lanes=1. Yet all driveers will slow to a crawl, or at least
> to a jogging speed, so IMO it can't be lanes=2,
> either.
>
> http://i46.tinypic.com/2cfqivn.png
>
> Which value would people use for the lanes=*?

Sometimes the answer is "It doesn't matter."

If you tagged it with lanes=1, but not oneway=yes, then it's clearly a 
bottleneck and should be avoided by routers.

If you didn't tag lanes=* at all and you didn't have oneway=yes then my 
assumption would be lanes=2 (because it's not one way).  Or you could tag it 
explicitly with lanes=2. Either way, map users would probably complain that 
it's too narrow for certain types of vehicle, so it should be re-tagged 
lanes=1.

If you tagged the width then it wouldn't matter if it was lanes=1 or lanes=2 
because we can see the overall width and use heuristics to decide if it's a 
slow road or 'normal' road.

Furthermore, if it's classified as highway=residential that would be a hint 
that it's a narrow road not to be driven too fast.

Any of these factors, either assumed, or explicit, should be used by a route 
planner to make this road unattractive for routing.

It's very tempting to add explicit values for every tag, but I really think 
sometimes it just doesn't matter, and we can get the same meaning for 
combinations of other tags (even if the tags are absent).

Best wishes,

Andrew

_______________________________________________
Tagging mailing list
Tagging at openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging


From dieterdreist at gmail.com  Mon Apr 30 11:09:04 2012
From: dieterdreist at gmail.com (Martin Koppenhoefer)
Date: Mon, 30 Apr 2012 12:09:04 +0200
Subject: [Tagging] area=yes on polygones (was Block names)
In-Reply-To: <CAPT3zJqZjWpZ_UCe-9yLzVFYtw9MaF2E35xRmV8DzOobZcH3yA@mail.gmail.com>
References: <CAPT3zJpOcudwwYuVEUxsm7ouLU-VvJyK-9GPFezUE3bAtPgJkw@mail.gmail.com>
	<4F97B922.4070002@gmail.com>
	<CAPT3zJra=+bat397VcK8HBtzpBqivqQ+6jT0y=tUi_2MaKgvCQ@mail.gmail.com>
	<4F97C131.5060300@gmail.com>
	<CAPreJLRO5o7-RjJXUSqUMsxQFv9UvRzyEHNGpwjmKdNw=hCpOw@mail.gmail.com>
	<4F99EE1C.1020807@tobias-knerr.de>
	<CAPT3zJpNbpcgV9h6Lu5YrU+ACr5z1qKeDqOPY911sU7zb4EyGg@mail.gmail.com>
	<4F9BEDC1.9020200@tobias-knerr.de>
	<CAPT3zJqZjWpZ_UCe-9yLzVFYtw9MaF2E35xRmV8DzOobZcH3yA@mail.gmail.com>
Message-ID: <CABPTjTDRuP27N85tLQfHy90tOdLpmi5MEoP5j4N8uquxBTSTnQ@mail.gmail.com>

2012/4/30 Pieren <pieren3 at gmail.com>:
> I'm always standing in the contributor point of view. It is not the
> wiki (or better said "our recommendations") to follow the osm2pqsql
> style file but the opposite.


+1


> especially
> when the main reaction is to say that mapnik/osm2pgsql will fail
> because the assumption is done on a key, not a key/value pair.


+1, besides from the already named tags in this thread there is also
leisure=track which is a nice example. Even it's wiki page says
explicitly that it is not clear, whether this is an area or a linear
feature, but there are asumptions that mapnik renders this as an area
because the rest of the leisure tags are all areas (or nodes):
http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dtrack

cheers,
Martin


From Alan_Mintz+OSM at Earthlink.Net  Mon Apr 30 15:05:02 2012
From: Alan_Mintz+OSM at Earthlink.Net (Alan Mintz)
Date: Mon, 30 Apr 2012 07:05:02 -0700
Subject: [Tagging] Fwd: Ojeq Stand
In-Reply-To: <CACOVVBF=KNCp2f0m39ty5R676LD_8fpk60G=ucfek7+Sjc_kxA@mail.g
	mail.com>
References: <CACOVVBGk9b+XPzUNvmMjWsZuqQH5y_XSNiTi4Fm1dz9wtXUKAQ@mail.gmail.com>
	<CACOVVBGk9b+XPzUNvmMjWsZuqQH5y_XSNiTi4Fm1dz9wtXUKAQ@mail.gmail.com>
Message-ID: <5.1.0.14.2.20120430065908.04659e00@mail.earthlink.net>

At 2012-04-30 01:07, Alex Rollin wrote:
>OK, So i make bad (formatting and approach) proposal for tag ojeq
>stand.  It is a motorcycle taxi stand.

Why not first search for existing usage? Taxi stands are common all over 
the world. Searching the wiki for "taxi" yields: 
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dtaxi . Add 
taxi=motorcycle;car;hov or maybe individual tags like motorcycle=yes, etc. 
in the style of 
http://wiki.openstreetmap.org/wiki/Access#Transport_mode_restrictions .

--
Alan Mintz <Alan_Mintz+OSM at Earthlink.net>



From alex.rollin at gmail.com  Mon Apr 30 15:26:58 2012
From: alex.rollin at gmail.com (Alex Rollin)
Date: Mon, 30 Apr 2012 21:26:58 +0700
Subject: [Tagging] Fwd: Ojeq Stand
In-Reply-To: <5.1.0.14.2.20120430065908.04659e00@mail.earthlink.net>
References: <CACOVVBGk9b+XPzUNvmMjWsZuqQH5y_XSNiTi4Fm1dz9wtXUKAQ@mail.gmail.com>
	<5.1.0.14.2.20120430065908.04659e00@mail.earthlink.net>
Message-ID: <CACOVVBFuKcZfmzWw5W+iotWTxO-ouwmcq0zuiQFf-9jQg3qvhw@mail.gmail.com>

On Mon, Apr 30, 2012 at 9:05 PM, Alan Mintz
<Alan_Mintz+OSM at earthlink.net> wrote:
> At 2012-04-30 01:07, Alex Rollin wrote:
>>
>> OK, So i make bad (formatting and approach) proposal for tag ojeq
>> stand. ?It is a motorcycle taxi stand.
>
>
> Why not first search for existing usage? Taxi stands are common all over the
> world. Searching the wiki for "taxi" yields:
> http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dtaxi . Add
> taxi=motorcycle;car;hov or maybe individual tags like motorcycle=yes, etc.
> in the style of
> http://wiki.openstreetmap.org/wiki/Access#Transport_mode_restrictions .
>

Thank you to Martin for pointing out the generalization, and for
telling me where to find the process.

Thank you to Alan for noticing that uses exist.

Alan, indeed the text of the page read "motorcycle=yes" and I am SO
NEW to this that I didn't actually know if it's ok to just add
"motorcylce=yes" or if I needed to make a proposal.

Can I just do that?

So far I have followed what I read to the letter, so, I'm trying play
along. I did have to search to figure that out.

Alex


From rm87 at hot.ee  Mon Apr 30 16:36:25 2012
From: rm87 at hot.ee (=?ISO-8859-1?Q?Mihkel_R=E4mmel?=)
Date: Mon, 30 Apr 2012 18:36:25 +0300
Subject: [Tagging] roundhouses tagging
Message-ID: <CABSjAfjhMeOgh9HXLi0SvRbWvB494rjhKBLLO4pywyBQnXc6Uw@mail.gmail.com>

Should railway roundhouses be tagged railway=roundhouse (as suggested on
http://wiki.openstreetmap.org/wiki/Tag:railway%3Droundhouse)
or as building=roundhouse? Or both?
And how would you tag an old roundhouse that is nowadays used for something
else (building=warehouse)?


Mihkel R?mmel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120430/debc874a/attachment.html>

From baloo at ursamundi.org  Mon Apr 30 16:44:13 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Mon, 30 Apr 2012 08:44:13 -0700
Subject: [Tagging] roundhouses tagging
In-Reply-To: <CABSjAfjhMeOgh9HXLi0SvRbWvB494rjhKBLLO4pywyBQnXc6Uw@mail.gmail.com>
References: <CABSjAfjhMeOgh9HXLi0SvRbWvB494rjhKBLLO4pywyBQnXc6Uw@mail.gmail.com>
Message-ID: <CAMPM96pftdvrLS_Gc+K96OoCV=E+pAc00LP0BC=7EVqG_RgEig@mail.gmail.com>

On Mon, Apr 30, 2012 at 8:36 AM, Mihkel R?mmel <rm87 at hot.ee> wrote:

> Should railway roundhouses be tagged railway=roundhouse (as suggested on
> http://wiki.openstreetmap.org/wiki/Tag:railway%3Droundhouse)
> or as building=roundhouse? Or both?
> And how would you tag an old roundhouse that is nowadays used for
> something else (building=warehouse)?
>
>
building=yes, railway=roundhouse?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120430/a7a043f1/attachment.html>

From rm87 at hot.ee  Mon Apr 30 17:19:52 2012
From: rm87 at hot.ee (=?ISO-8859-1?Q?Mihkel_R=E4mmel?=)
Date: Mon, 30 Apr 2012 19:19:52 +0300
Subject: [Tagging] roundhouses tagging
In-Reply-To: <CAMPM96pftdvrLS_Gc+K96OoCV=E+pAc00LP0BC=7EVqG_RgEig@mail.gmail.com>
References: <CABSjAfjhMeOgh9HXLi0SvRbWvB494rjhKBLLO4pywyBQnXc6Uw@mail.gmail.com>
	<CAMPM96pftdvrLS_Gc+K96OoCV=E+pAc00LP0BC=7EVqG_RgEig@mail.gmail.com>
Message-ID: <CABSjAfiGH2QnPq5+9RxHWYpXVEOBc9QedfnK9ekXRVn0KFzOGg@mail.gmail.com>

Would soon lead to building=roundhouse, railway=roundhouse . Which is
information duplication.

On Mon, Apr 30, 2012 at 6:44 PM, Paul Johnson <baloo at ursamundi.org> wrote:

> On Mon, Apr 30, 2012 at 8:36 AM, Mihkel R?mmel <rm87 at hot.ee> wrote:
>
>> Should railway roundhouses be tagged railway=roundhouse (as suggested on
>> http://wiki.openstreetmap.org/wiki/Tag:railway%3Droundhouse)
>> or as building=roundhouse? Or both?
>> And how would you tag an old roundhouse that is nowadays used for
>> something else (building=warehouse)?
>>
>>
> building=yes, railway=roundhouse?
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20120430/948dcd14/attachment.html>

From baloo at ursamundi.org  Mon Apr 30 17:29:26 2012
From: baloo at ursamundi.org (Paul Johnson)
Date: Mon, 30 Apr 2012 09:29:26 -0700
Subject: [Tagging] roundhouses tagging
In-Reply-To: <CABSjAfiGH2QnPq5+9RxHWYpXVEOBc9QedfnK9ekXRVn0KFzOGg@mail.gmail.com>
References: <CABSjAfjhMeOgh9HXLi0SvRbWvB494rjhKBLLO4pywyBQnXc6Uw@mail.gmail.com>
	<CAMPM96pftdvrLS_Gc+K96OoCV=E+pAc00LP0BC=7EVqG_RgEig@mail.gmail.com>
	<CABSjAfiGH2QnPq5+9RxHWYpXVEOBc9QedfnK9ekXRVn0KFzOGg@mail.gmail.com>
Message-ID: <CAMPM96pT4smg=KD_dsp4jbBU-2pBOHY=CXHscvfLUgYf3N5fGA@mail.gmail.com>

On Mon, Apr 30, 2012 at 9:19 AM, Mihkel R?mmel <rm87 at hot.ee> wrote:

> On Mon, Apr 30, 2012 at 6:44 PM, Paul Johnson <baloo at ursamundi.org> wrote:
>>
>> On Mon, Apr 30, 2012 at 8:36 AM, Mihkel R?mmel <rm87 at hot.ee> wrote:
>>>
>>> Should railway roundhouses be tagged railway=roundhouse (as suggested on
>>> http://wiki.openstreetmap.org/wiki/Tag:railway%3Droundhouse)
>>> or as building=roundhouse? Or both?
>>> And how would you tag an old roundhouse that is nowadays used for
>>> something else (building=warehouse)?
>>>
>>
>> building=yes, railway=roundhouse?
>
> Would soon lead to building=roundhouse, railway=roundhouse . Which is
> information duplication.

I don't see why building would have to duplicate the railway tag.
building=yes asks "Is there a building of any kind?" and answers it
with "yes."  Pretty commonly accepted practice.


From phil at trigpoint.me.uk  Mon Apr 30 20:02:07 2012
From: phil at trigpoint.me.uk (Philip Barnes)
Date: Mon, 30 Apr 2012 20:02:07 +0100
Subject: [Tagging] roundhouses tagging
In-Reply-To: <CABSjAfjhMeOgh9HXLi0SvRbWvB494rjhKBLLO4pywyBQnXc6Uw@mail.gmail.com>
References: <CABSjAfjhMeOgh9HXLi0SvRbWvB494rjhKBLLO4pywyBQnXc6Uw@mail.gmail.com>
Message-ID: <1335812527.2298.3.camel@marvin>

On Mon, 2012-04-30 at 18:36 +0300, Mihkel R?mmel wrote:
> Should railway roundhouses be tagged railway=roundhouse (as suggested
> on http://wiki.openstreetmap.org/wiki/Tag:railway%3Droundhouse)
> or as building=roundhouse? Or both?
> And how would you tag an old roundhouse that is nowadays used for
> something else (building=warehouse)?

Am not aware of any in the UK still in railway use, the most famous one
is here http://osm.org/go/euu4dDLW7-- and tagged as a theatre.

Phil