Re: [Tagging] Highway barrier

[Martin Koppenhoefer]

2015-04-15 6:57 GMT+02:00 Bryce Nesbitt :

> I think this does it:
>
>
> *barrier=spikes*
> *oneway=yes*
> *access=yes*
>
>


-1, these tags do not distinguish between directional spikes and those
active in all directions. It also doesn't make sense to have a oneway tag
on a node (nodes do not have a direction), and if the spikes are mapped as
a way, this way will be orthogonal to the road so a oneway tag makes even
less sense on a way like this. Access=yes is about legal access, it doesn't
tell you anything about physical obstacles. You may be allowed to cross the
spikes, but they will break your tires nonetheless ;-)

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Highway barrier

[Martin Koppenhoefer]

2015-04-15 8:00 GMT+02:00 Colin Smale :

> Are there any other ways of having oneway:physical? Maybe a lifting
> barrier with a sensor on one side only?



In reality this would only apply to certain vehicles though. A bicycle or a
battle tank, even an armored car might be physically able to travel the
road in the opposite direction (as opposed to other barriers like these:
http://www.panzersperre.com/panzersperre.jpg ). I would prefer describing
the barrier rather than the implications one might see, i.e. I am in favour
of the tag mentioned above: barrier=oneway_spikes (and eventually the
additional "direction" tag or a more literal way of saying which direction
you can (or can't) travel over it, e.g. barrier:conditional=no @
(direction=NW) ).

http://wiki.openstreetmap.org/wiki/Conditional_restrictions  // please note
that this has another reference for direction in it, which is not the way I
believe we should tag a node (forward/backward).
http://wiki.openstreetmap.org/wiki/Key:direction

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Money transfer amenities

[Martin Koppenhoefer]

2015-04-15 7:37 GMT+02:00 Jan van Bekkum :

> Alternatively you could use brand=moneygram;western_union;orlandi_valuta
>


the most common key for "Western Union" according to taginfo is "name"
(346) followed by operator (24) and "money_transfer" (12) plus some
variations in name: http://taginfo.osm.org/search?q=%3DWestern+Union

main tags for the name instances are (not strictly ordered):
amenity=bureau_de_change (used very often)
amenity=bank (used quite often)
shop=money_transfer
amenity=money_transfer
services=money_transfer
shop=money_sending (IMHO bad tag, because the same quantity of "sending"
will be "receiving", no?)
amenity=post_office
amenity=post_box (maybe  a typo, 1 time only)
amenity=business_center (AE orthography!)
amenity=commercial (unspecific)
tourism=information
shop=pawnshop
amenity=Telegram


There is also a proposal by the threadstarter, dating back to 2012:
http://wiki.osm.org/wiki/Proposed_features/Money_transfer

cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Defacto: man_made=storage_tank

[Martin Koppenhoefer]

2015-04-15 6:15 GMT+02:00 johnw :

> we have building=farm_auxiliary, shed, and roof, so I think it is broader
> than the german definition.
>


please note I wrote _also_ in the German definition, the English definition
is the same.


>
> People put building=* on any structure
>


+1, and I am fine with it, just wanted to comment on "not all tanks are
buildings" and point out that in OSM all structures are "buildings".


cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Highway barrier

[phil]

On Wed Apr 15 05:32:13 2015 GMT+0100, Bryce Nesbitt wrote:
> On Mon, Apr 13, 2015 at 11:29 PM, Dave Swarthout 
> wrote:
> 
> > I don't think they are all that common Bryce but I have seen them. And
> > that is a controlled situation. This is a normal street! It would be good
> > to be able to alert drivers about something like this when using a GPS for
> > guidance but I'm not sure there's a good way to do that.
> >
> 
> I can think of two dozen off the top of my head, within local parks and
> parking lots.  There are probably thousands
> in just the city I live in.
> 
> But I agree that on a normal road that's kind of extreme!
>

-- 
Sent from my Jolla
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Highway barrier

[phil]

On Wed Apr 15 05:32:13 2015 GMT+0100, Bryce Nesbitt wrote:
> On Mon, Apr 13, 2015 at 11:29 PM, Dave Swarthout 
> wrote:
> 
> > I don't think they are all that common Bryce but I have seen them. And
> > that is a controlled situation. This is a normal street! It would be good
> > to be able to alert drivers about something like this when using a GPS for
> > guidance but I'm not sure there's a good way to do that.
> >
> 
> I can think of two dozen off the top of my head, within local parks and
> parking lots.  There are probably thousands
> in just the city I live in.
> 
> But I agree that on a normal road that's kind of extreme!

I agree it is extreme as it prevents emergency vehicles using the road in the 
opposite direction and affects wheelchairs, which are pedestrians and not 
normally affected by a oneway. As for reversing into a parking space..

Phil (trigpoint )
-- 
Sent from my Jolla
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Ambiguous translations of waterway=dam - should be moved to man_made=dam

[Lists]

Hi

We have problems in Brazil with the abiguity of translation of the word “dam”, 
resulting in new users tagging the waterbody as waterway=dam (translates 
represa), instead of the dam structure (translates represa). It seems like both 
the namespace (waterway) and the fact that iD only shows tags as labels are 
adding to this confusion

Since the dam structure is a man_made construction, I suggest that the tag 
should be moved into that namespace. Currently we should abandon (deprecate) 
the tag waterway=dam to avoid conflicts with existing tagging scheme, and maybe 
in the future allow this tag to mean the waterbody of the dam. Today I had to 
explain to a user why he couldn’t use waterway=dam on the waterbody, and he 
seemed confused about using landuse=reservior (which also should translate to 
represa). I do not know how these things are translated in iD, maybe some of 
this confusion could be solved with improved translations?

Anyway, since the dam is a man_made structure I think it is about time this is 
corrected in the tagging namespace also. This tag is quite old, and have many 
uses, so a transition from waterway=dam to man_made=dam will be a timely long 
process. If consensus is that the man_made namespace is more propitiate, the 
new tag should be added (maybe in a mechanical edit) to existing tags, let data 
consumers get sufficient time to update stylesheets, etc, before removing the 
old tag from the database.

Aun Johnsen


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ambiguous translations of waterway=dam - should be moved to man_made=dam

[Bryan Housel]

The iD translations are handled through Transifex 
https://www.transifex.com/organization/ideditor/dashboard/id-editor 


So if there is an issue with the way the translations appear in Brazil, you 
should be able to log in to transifex and fix it there.
Thanks, Bryan



> On Apr 15, 2015, at 11:35 AM, Lists  wrote:
> 
> Hi
> 
> We have problems in Brazil with the abiguity of translation of the word 
> “dam”, resulting in new users tagging the waterbody as waterway=dam 
> (translates represa), instead of the dam structure (translates represa). It 
> seems like both the namespace (waterway) and the fact that iD only shows tags 
> as labels are adding to this confusion
> 
> Since the dam structure is a man_made construction, I suggest that the tag 
> should be moved into that namespace. Currently we should abandon (deprecate) 
> the tag waterway=dam to avoid conflicts with existing tagging scheme, and 
> maybe in the future allow this tag to mean the waterbody of the dam. Today I 
> had to explain to a user why he couldn’t use waterway=dam on the waterbody, 
> and he seemed confused about using landuse=reservior (which also should 
> translate to represa). I do not know how these things are translated in iD, 
> maybe some of this confusion could be solved with improved translations?
> 
> Anyway, since the dam is a man_made structure I think it is about time this 
> is corrected in the tagging namespace also. This tag is quite old, and have 
> many uses, so a transition from waterway=dam to man_made=dam will be a timely 
> long process. If consensus is that the man_made namespace is more propitiate, 
> the new tag should be added (maybe in a mechanical edit) to existing tags, 
> let data consumers get sufficient time to update stylesheets, etc, before 
> removing the old tag from the database.
> 
> Aun Johnsen
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Money transfer amenities

[Bryce Nesbitt]

 "Western Union" is a branded money transfer service offered at many other
types of businesses -- including convenience stores, some banks, pawn shops
and in some countries post offices.


*The generic services seem to be:*
* Currency exchange (e.g. Dollars for CN ¥)
* Low Income Lending (e.g. Payday loans, Tax refund anticipation loans,
Auto Title Loans, Generic Unsecured Loan Sharking).
* Check cashing (for people without access to a bank).
* Money Transfer (e.g. Western Union, TransferWise).
* Pawn (borrow money against value of goods left at the store).



*A local check cashing place may offer a mix:*
shop=money_transfer
services=Western Union;Payday Loans;Currency Exchange;MoneyGram;TransferWise




*We'd then have the following "top level symbols":*
* bank
* money_services (non-bank money services mostly for low income people)
* bureau_de_change (restricted to only currency exchange for wealthy
travelers)
* pawnshop


This is clear case where some mechanical retagging can help make the data
more rational.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - trailhead

[Friedrich Volkmann]

On 14.04.2015 23:32, Gmail wrote:
> role=start is used for crosscountry ski routes relations.

I like the idea to include trailheads as members of route relations.

It's a more versatile approach than highway=trailhead.

-- 
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - obligatory usage - bicycle=obligatory

[Hubert]

Hi,

thanks for the replies. I hope I don't bug you to much.

> > 1) Picture 1 with the blue traffic sign
> >
> > My answer:
> > highway=path; foot=designated; bicycle=designated; segregated=yes.
> > In addition you may want to specify which side is the footway and
> > which side is the cycleway by lanes=2 and bicycle:lanes=yes|no and
> > foot:lanes=no|yes You may also add colour:lanes=red|grey
> 
> Please, use the proper access tags with :lanes highway=path 
> bicycle=designated
> foot=designated segregated=yes bicycle:lanes=designated|no
> foot:lanes=no|designated vehicle=no

+1. That's what I'd tag in general, too. However, maybe not with all the 
details.

> >> 2) Picture 1 without the blue traffic sign
> >>
> >
> > My answer:
> > Anything of the following, depending on context:
> > highway=unclassified/track/pedestrian/cycleway/...
> > But none of foot/bicycle=designated/official/yes
> 
> +1
> would use highway=unclassified/service/track/path

You can't see this on the picture, but that way isn't connected to the main 
street directly but only to a road adjacent segregated foot and cycle path 
which is in turn separated from the roadway by a grass area.
So the way in picture 1 would be a highway=path.
 
The problem I see is, that the foot path (gray part) stays designated for 
pedestrians and the cycle path (red part) stays designated for cyclist under 
german law (Judges rulings and highway code), even if the traffic sign is not 
present.
Therefore, I believe that one should tag 
bicycle=designated
foot=designated
segregated=yes
in addition to highway=path for that way in picture 1 without the traffic sign.

> >> 3) Picture 2 with the blue traffic sign
> >>
> >
> > My answer:
> > exactly as in case (1) for the cycle-and-foot-way and in addition
> > bicycle=use_sidepath on the street
> 
> Would not tag the sidewalk as separate object
> 
> highway=*
> cycleway=track
> segregated=yes
> sidewalk=both

OK

> alternatively as separate objects three ways
> main:
> 
> highway=*
> bicyle=use_sidepath
> sidewalk=sidepath
> 
> and on both sides
> 
> as 1) with additional
> oneway=yes
> path=sidewalk

+1, but I'm not sure if "path=sidewalk" is enough, since there are two ways 
represented by one highway=path. Maybe something like "path=sidetrack;sidewalk" 
or "path=sideway" or "footway=sidewalk + cycleway=sidetrack" or ... But that's 
another story.

> >> 4) Picture 2 without the blue traffic sign
> >>
> >
> > My answers:
> >
> > Alternative (a)
> > highway=residential
> > sidewalk=both
> > Reason: If there is no sign whatsoever, I would consider both sides as
> > sidewalk (Buergersteig in German).
> 
> +1
> 
> Well, in Germany bicycles are legally allowed to use the sidewalk in this 
> case but it is not compulsory.

Actually, from my understanding of the applicable laws, sidewalks are 
designated to pedestrians and exclusive. They may only be used by cyclists if 
there is a special traffic sign combination [1]. However in the case of picture 
2, right hand side, one can clearly identify the cycle track (red) on the 
sidepath between the carriageway and the sidewalk. In this case the use of the 
cycle track is optional. See below.

> As the German bicycle club (ADFC) advises its member not to use it anymore
> (after the blue signs where removed) and my personal observation are that
> other people riding on the former cycle track higher the chances that car
> driver honk and even riskily overtake when I correctly ride one meter left > 
> of the curb on the street.
> 
> Therefor everyone using this former cycle track is lifting the risk of
> accidents and there are usually more than one reason why the signs where
> removed.

Further more:

> All together I can understand others using
> 
> sidewalk:bicycle=yes
> 
> but would not tag it. Instead I usually add a note=* to tell others that 
> the signes where removed.

I would interpret "sidewalk:bicycle=yes" as [1].

> > Alternative (b)
> > Use separate ways on both sides of the street with: highway=footway,
> > but none of foot/bicycle=designated/official Without additional signs
> > the paths on both sides of the road are sidewalks (i.e. pedestrian
> > use)
> 
> highway=*
> sidewalk=sidepath
> 
> plus on both sides
> 
> highway=path
> foot=designated
> bicyles=yes
> oneway=yes
> path=sidewalk

In my understanding this would be equal to [1]:
highway=footway
footway=sidewalk
bicyles=yes
oneway=yes

I would tag Picture 2 as 

highway>=residential
bicycle=use_sidepath (with the blue traffic sign)
bicycle=yes/"empty"  (without the blue traffic sign)
(foot=use_sidepath)
cycleway=sidepath
sidewalk=sidepath

and for both cases:

highway=path
(path=?)
bicycle=designated
foot=designated
segregated=yes
(+ surface, etc.)

So, the sidepath would be tagged identically for  both cases (with and without 
the traffic sign). While this is no problem for a router (thanks for 
*=use_sidepath) a renderer can't distinguish between a mandatory cycle track 
and an optional one. 
That's w

Re: [Tagging] Ambiguous translations of waterway=dam - should be moved to man_made=dam

[David Bannon]

On Wed, 2015-04-15 at 12:35 -0300, Lists wrote:
...
> 
> Since the dam structure is a man_made construction, I suggest that the
> tag should be moved into that namespace. Currently we should abandon
> (deprecate) the tag waterway=dam to avoid conflicts with existing
> tagging scheme, and maybe in the future allow this tag to mean the
> waterbody of the dam. 

Hi, in Australia, the noun 'dam' refers to the whole water body, wall
included. Generally, the man made part, the wall, is referred to as the
dam wall. But not exclusively...

David

> Today I had to explain to a user why he couldn’t use waterway=dam on
> the waterbody, and he seemed confused about using landuse=reservior
> (which also should translate to represa). I do not know how these
> things are translated in iD, maybe some of this confusion could be
> solved with improved translations?
> 
> Anyway, since the dam is a man_made structure I think it is about time
> this is corrected in the tagging namespace also. This tag is quite
> old, and have many uses, so a transition from waterway=dam to
> man_made=dam will be a timely long process. If consensus is that the
> man_made namespace is more propitiate, the new tag should be added
> (maybe in a mechanical edit) to existing tags, let data consumers get
> sufficient time to update stylesheets, etc, before removing the old
> tag from the database.
> 
> Aun Johnsen
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ambiguous translations of waterway=dam - should be moved to man_made=dam

[Dave Swarthout]

I think redefining waterway=dam is gonna be a hard sell for most Americans.
But now thanks to this list I understand why some reservoirs I've worked
with in Thailand have had the name of the dam applied to the water behind
them as well. As you probably know, many reservoirs in the U.S. have names
that are different from the names of the dam that formed them, Lake Mead
and the Hoover Dam, Lake Roosevelt and the Grand Coolee Dam, are just two
of the better known ones. The dam and the water impounded behind it usually
have different names.

Even though I can agree that dams are man_made there are roughly 200K uses
of the waterway=dam tag. You have a lot of convincing ahead of you.

Dave

On Thu, Apr 16, 2015 at 1:19 AM, David Bannon 
wrote:

> On Wed, 2015-04-15 at 12:35 -0300, Lists wrote:
> ...
> >
> > Since the dam structure is a man_made construction, I suggest that the
> > tag should be moved into that namespace. Currently we should abandon
> > (deprecate) the tag waterway=dam to avoid conflicts with existing
> > tagging scheme, and maybe in the future allow this tag to mean the
> > waterbody of the dam.
>
> Hi, in Australia, the noun 'dam' refers to the whole water body, wall
> included. Generally, the man made part, the wall, is referred to as the
> dam wall. But not exclusively...
>
> David
>
> > Today I had to explain to a user why he couldn’t use waterway=dam on
> > the waterbody, and he seemed confused about using landuse=reservior
> > (which also should translate to represa). I do not know how these
> > things are translated in iD, maybe some of this confusion could be
> > solved with improved translations?
> >
> > Anyway, since the dam is a man_made structure I think it is about time
> > this is corrected in the tagging namespace also. This tag is quite
> > old, and have many uses, so a transition from waterway=dam to
> > man_made=dam will be a timely long process. If consensus is that the
> > man_made namespace is more propitiate, the new tag should be added
> > (maybe in a mechanical edit) to existing tags, let data consumers get
> > sufficient time to update stylesheets, etc, before removing the old
> > tag from the database.
> >
> > Aun Johnsen
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - trailhead

[Dave Swarthout]

But I'd be willing to bet that most trails are not part of a network of
other trails or a route but are stand-alone. The trails I once hiked in the
Adirondack Mountains in New York State all have names and trailheads but,
with a couple of exceptions, are not part of any route. I think the mixed
approach is best. If a given trail is part of  a larger system of trails,
or the area where it begins has related amenities, then the relation idea
makes sense. Otherwise, keeping it simple with a named trailhead node where
the transition from highway to footway takes place will suffice.

On Wed, Apr 15, 2015 at 11:06 PM, Friedrich Volkmann  wrote:

> On 14.04.2015 23:32, Gmail wrote:
> > role=start is used for crosscountry ski routes relations.
>
> I like the idea to include trailheads as members of route relations.
>
> It's a more versatile approach than highway=trailhead.
>
> --
> Friedrich K. Volkmann   http://www.volki.at/
> Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - trailhead

[John Willis]

Trials often overlap with other trails, fire roads (tracks) and may actually be 
tracks for most of the path until it turns off near the top of a peak or goes 
away from a restricted access zone. 

The Subashiri route on Mt Fuji is a pedestrian road, steps, trail, track, 
trail.. Etc as it overlaps with a bulldozer road for servicing the "stations", 
and has concrete and stone steps in places. 

Every state park I have been in in California uses pieces of fire roads for 
parts of almost all routes, to the trail is partially partially path and 
partially track. 

I have never made a route relation yet, but as I understand it, to link those 
different parts together would require a route relation. 

Would making the entrance=trailhead part of that (or leisure=trailhead) part of 
that be incorrect? Or are we talking about two different things? 

Javbw

> On Apr 16, 2015, at 1:25 PM, Dave Swarthout  wrote:
> 
> But I'd be willing to bet that most trails are not part of a network of other 
> trails or a route but are stand-alone. The trails I once hiked in the 
> Adirondack Mountains in New York State all have names and trailheads but, 
> with a couple of exceptions, are not part of any route. I think the mixed 
> approach is best. If a given trail is part of  a larger system of trails, or 
> the area where it begins has related amenities, then the relation idea makes 
> sense. Otherwise, keeping it simple with a named trailhead node where the 
> transition from highway to footway takes place will suffice.
> 
>> On Wed, Apr 15, 2015 at 11:06 PM, Friedrich Volkmann  wrote:
>> On 14.04.2015 23:32, Gmail wrote:
>> > role=start is used for crosscountry ski routes relations.
>> 
>> I like the idea to include trailheads as members of route relations.
>> 
>> It's a more versatile approach than highway=trailhead.
>> 
>> --
>> Friedrich K. Volkmann   http://www.volki.at/
>> Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> 
> -- 
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging