Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

[Jean-Marc Liotier]

On 08/25/2014 11:09 PM, Lukas Sommer wrote:
In Ivory Coast, you have addresses like “in front of the XYZ 
crossroad” or “from XYZ crossroad 50 m towards the big fueling 
station”. Rather a sort of instructions for getting somewhere than an 
address in the european sense. Obviously “from XYZ crossroad 50 m 
towards the big fueling station” will be applied to various houses 
(usually, when you have arrived, you make a phone call to the person 
that you want to meet, and the person comes to the road to search you 
and help you with the last part of the way – I can guarantee you that 
this is very time-consuming ;-)


That said, people in quite a few African countries have a postal address 
(PO box in most cases) distinct from the address of their residence, so 
the problem of shoehorning directions in the standard address fields of 
European-designed software is side-stepped more often than not.



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

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

[Lukas Sommer]

@Simon

> are the names of the traffic signals/junctions actually used in
> addresses (and in principal would be a suitable value for addr:place in
> an address)?

Hm, I’m not sure (I’m not familiar with the group of addr:* keys). At least
they are places in the sense that they have a defined location.

In Japan and in Korea, I’m not sure how this is handeled.

In Ivory Coast, you have addresses like “in front of the XYZ crossroad” or
“from XYZ crossroad 50 m towards the big fueling station”. Rather a sort of
instructions for getting somewhere than an address in the european sense.
Obviously “from XYZ crossroad 50 m towards the big fueling station” will be
applied to various houses (usually, when you have arrived, you make a phone
call to the person that you want to meet, and the person comes to the road
to search you and help you with the last part of the way – I can guarantee
you that this is very time-consuming ;-)

Best regards

Lukas Sommer


2014-08-25 15:21 GMT+00:00 Simon Poole :

>
>
> Am 25.08.2014 16:46, schrieb fly:
> .
> >
> > Did you have a look at the three existing proposals about complex
> > junctions ?
> ..
>
> IMHO one of the nice aspects of variant 4 (using an area) is that it
> really doesn't collide with however the routing aspects of the junction
> are mapped.
>
> @Lukas are the names of the traffic signals/junctions actually used in
> addresses (and in principal would be a suitable value for addr:place in
> an address)?
>
> Simon
>
>
> ___
> 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] minus or underscore in attribute values?

[John F. Eldredge]

If the term in question is normally written as two or more words, connected by 
hyphens, then hyphens should be used. If the term is normally written as two or 
more words, separated by spaces, then the spaces should be replaced by 
underscores. Replacing a hyphen by an underscore changes the meaning.


On August 25, 2014 7:46:33 AM CDT, Pieren  wrote:
> On Sat, Aug 23, 2014 at 12:25 PM, Martin Koppenhoefer
>  wrote:
> > the space gets replaced by an underscore
> 
> +1
> The problem is not to have a preference between underscore and hypen
> but to know if our English colleagues can agree on the separator space
> or hyphen.
> 
> Pieren
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

-- 
John F. Eldredge -- j...@jfeldredge.com
"Darkness cannot drive out darkness; only light can do that.  Hate cannot drive 
out hate; only love can do that."
Dr. Martin Luther King, Jr.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RENDER

[André Pirard]

On 2014-08-20 18:07, Peter Wendorff wrote :
> Okay, let me get a bit more verbose.
>
> I want to get Walmarts shown on the map in a different color.
> Before there's a polygon with the following tags:
>
> shop=supermarket
> building=yes
> operator=WalMart
> addr:street=whatever
> addr:housenumber:42
> addr:city=YouLike
> render=blue
>
> Another polygon is tagged
>
> shop=supermarket
> building=yes
> building:levels=2
> operator=WalMart
> addr:street=another street
> addr:city=some city
>
> Let's consider the usual rendering of the osm-carto (default mapnik)
> stylesheet.
>
> without considering the render tag both buildings are drawn as buildings
> (dark outlined polygon filled in slightly lighter gray) and a shopping
> cart icon on top.
>
> Now let's consider the render-tag.
>
> Variant 1: just use it. You get an entirely inconsistent look, as I
> myself wasn't interested in all WalMarts, but probably only those in one
> particular town, so I only added the render tag to some objects.
> Let two others add arbitrary, but different render ideas to other
> objects and the map get's unusable as there's nothing like a map key any
> more: all visuals on the map get more or less meaningless.
>
> Variant 2: Try to use the render tag, but in a consistent way.
> In that case my stylesheet/renderer would have to figure out what is
> meant by the render-tag. It may refer to supermarkets, to WalMarts, to
> stuff in the whatever-street or in the city YouLike. Figuring out a rule
> from that is incredibly hard and very error prone.
>
> Your last sentence might be the misunderstanding:
> "As soon as rendering is defined for an element, it is used instead and
> RENDER is normally ignored".

Yes, this sentence is misunderstood, and by many repliers apparently.
It means that once Mapnik uses a (defined) rendering you cannot change
it (RENDER is ignored).
The main idea behind RENDER is not coloring objects, and I agree it
shouldn't, but showing them.
And the renderer can do that with any single color they like.

André.



> But even that is a tricky strategy. Let's stay at the WalMart-Example.
> I want to have a special (!) rendering for WalMarts, so there is no
> rendering defined for it before (as any rendering defined is a fallback
> to a more generic case: supermarkets or even buildings).
> It would therefore lead to cluttering map objects where it is not
> necessary, or doesn't solve anything at all. Although it would break
> down stylesheet innovation even more as you can render your very own
> tags - as long as it isn't rendered on the map itself.
>
> Put the effort to add rendering for missing objects. This is harder to
> achieve, yes; but it is the straightforward way, not a hack around, with
> major drawbacks and side effects.
>
> regards
> Peter
>
> Am 20.08.2014 um 14:46 schrieb André Pirard:
>> On 2014-08-15 16:31, Peter Wendorff wrote :
>>> not a good idea IMHO.
>>> 1) what is the feature this tag should refer to? Consider a polygon that
>>> is tagged as a building (building=yes) and a shop (shop=supermarked) and
>>> a Walmart (operator=WalMart), and the mapper added RENDER=blue. What is
>>> it that should be rendered blue? This object? Any supermarket? any
>>> Walmart? 
>> I don't understand what you say very well. "added RENDER" to what?
>> As I say RENDER would typically apply to "an area", to one object, not
>> to "any".
>> That is, you have building=yes + render=blue and that building gets blue.
>>
>>> Any building? How should any rendering decide if the default
>>> rendering should be used or the one defined by the tag you propose?
>> Did you read my sentence:
 As soon as rendering is defined for an element, it is used instead
 and RENDER is normally ignored.
>> ?
>> a.s.o. ...
>>
>> André.
>>
>>
>>> 2) I want to get Walmarts shown on the map in a different color, thus
>>> all Walmarts I want to see in the map get
>>> RENDER={mycolor-which-is-not-used-yet-in-the-zoomlevel-I'm-interested-in}.
>>> Now the stylesheet maintainer uses that color for another object -
>>> conflict, damn, fail.
>>> 3) I want to get Walmarts rendered pink on osm-carto, green on HOT,
>>> orange on the cyclemap - what should go to the render-tag (even if the
>>> styles would follow your proposal?
>>>
>>> The only benefit I see in this proposal is just what you said: people
>>> would stop tagging stuff just to get their map to display it the way
>>> they want; but how do you ensure they don't tag stuff to be rendered
>>> with the same style? How do you ensure the map stays usable?
>>>
>>> regards
>>> Peter
>>>
>>> Am 15.08.2014 um 16:12 schrieb André Pirard:
 Hi,

 It's a well known fact that many people complain to tag in vain because
 what they tag doesn't show on the map (e.g. mini-golf vs tennis pitch),
 because they're told to open a rendering ticket which replies that only
 official tags are supported, and because they open a vote for an
 official tag and nobody signs.
 As a result they a

Re: [Tagging] RENDER

[André Pirard]

On 2014-08-15 16:12, André Pirard wrote :
> It's a well known fact that many people complain to tag in vain
> because what they tag doesn't show on the map (e.g. mini-golf vs
> tennis pitch), because they're told to open a rendering ticket which
> replies that only official tags are supported, and because they open a
> vote for an official tag and nobody signs.
> As a result they are accused of "tagging for the renderer" instead of
> 'being forced to tag for the renderer".
>
> The solution is simple however.  A RENDER tag that, typically, would
> assign a color to an area.
> I'll let the rendering specialists define what else it can do.
> ⚠ ⚠ ⚠ RENDER only requests *by default* rendering.
> As soon as rendering is defined for an element, it is used instead and
> RENDER is normally ignored.
As you can read it, my goal is simple: stop people tagging for the
renderer by making their tagging visible on OSM.org standard map despite
a -- hopefully temporary -- lack of rendering definition.
You people focused on the choice of multicolor by the mappers to shoot
this suggestion down while there is no multicolor and not even a choice
needed at all: a single color chosen by the renderers suffices.  Hence,
the applauded smarties box mockery is ridiculous as smarties of the same
color every 50 cm make a funny present box and tagging for the renderer
makes a better looking one regarding color anyway.
On the other hand, to address another critique, RENDER can indicate that
it means that the feature is considered important either only for the
standard map or for some other categories of maps.

Pragmatically, open OSM.org and search for "mini golf"
.  Clicking on a
result will show you the feature highlighted single color. RENDER would
render it much the same way on the normal map, but dim.
Now if the tourist returns to the normal maps, and he can or he cannot
see what he has just found, depending on its tagging for the renderer or
not. Look, dear, they say that showing our mini golfs would "break the
model of decoupling the factual mapping database from the data consumers
and their choices".
Let us try Google or Michelin maps instead, they may copy OSM data and
show it.

On one hand I advocate happy mappers tagging features that RENDER can
show and happy renderers that can make statistics of RENDER usage to see
what rendering definitions are the most needed.  As soon as a new
rendering definition is made, all the features auto-magically use it.
Should abuse of RENDER be found, an invisible rendering can be defined
for the feature.

On the other hand, you advocate unhappy mappers tagging useful features
for the renderer in order to not tag in vain.  The process is much out
of control and, should a rendering definition appear for some or those
features, the tagging already done will remain in the "for renderer",
smarties like state.

You might have a better idea or improve mine instead of disparaging it.
Up to you.
This will probably be my last message.

André.


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

Re: [Tagging] changing wiki , changing definitions

[Pee Wee]

Just to let you know. I got a reply. The change was more a personal wish
then something that was discussed. He reverted the change so everything is
how it was.

I also received a nice tip on how to follow changes in a wiki you're
interested in. I thought it would be good to share even though it might not
be new to all of you.



*"If you are concerned about a wiki page's integrity, it is advisable to
put it into your watchlist, and then turn on email notifications. You can
put them on your watchlist by clicking on the start on the upper right
corner of the page.*
*You can turn on email notifications by going on your settings page

and turn on the checkbox "Email me when a page or file on my watchlist is
changed".*

Cheers
PeeWee32


2014-08-20 8:27 GMT+02:00 Pee Wee :

> Thanks for the comments. I'll play it fair. I've just sent an email to the
> person that changed it even though I find it hard to believe that the next
> sentence was something many mappers would agree on.
> "
> *"Usage in cities*
>
>
> *Barcelona  and London
>  also uses this tag for similar
> and practical reasons: in London, the Great West Road
>  in London is
> among a number of trunk roads where it is practically better to use a
> designated cycleway, because of a high speed limit on the main carriageway
> (40 mph or 64 km/h). "*
>
> I'm also thinking of adding a list of countries that do and do not have
> compulsory cycleways. That should hopefully make things clearer.
>
> Cheers
>
> PeeWee32
>
>
>
>
> 2014-08-19 23:29 GMT+02:00 fly :
>
> Am 19.08.2014 10:38, schrieb Frederik Ramm:
>> > Hi,
>> >
>> > On 08/19/2014 09:04 AM, Pee Wee wrote:
>> >> Sure I could send an email to the person that changed this but what do
>> >> you think is the best way to deal with this changing wiki pages? Or
>> >> should I just accept that these things happen and change it back and
>> >> send an email?
>> >
>> > Well you should certainly *first* find out the motivation behind the
>> > change and *then* think about whether it needs reverting (instead of
>> > first reverting and then asking).
>>
>> Yeah, always play fair, but keep in mind that the edit should have been
>> discussed priorly, too. This way, reverting and then discussing about
>> changes seems to me the right way, otherwise the wrong description is
>> even longer available.
>>
>> > The wiki is a living documentation and not a dead archive of past
>> > discussions. It is quite possible that the use of "bicycle=use_sidepath"
>> > has changed, or is changing, and of course we'd like the wiki to
>> > properly document current practice.
>>
>> This tag is not old enough to have changed already and only for certain
>> situation in countries with compulsory cycleways.
>>
>> cu fly
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
>
> --
> Verbeter de wereld. Word mapper voor Openstreetmap
> .
>



-- 
Verbeter de wereld. Word mapper voor Openstreetmap
.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reproposal of tourism=aquarium

[Janko Mihelić]

2014-08-25 15:53 GMT+02:00 Martin Koppenhoefer :

>
> I also don't like
> man_made=aquarium
> because I'd expect that to describe a single aquarium, i.e. a water filled
> container with fish etc. in it, while here we are discussing a structure
> like a zoo with footways, service ways, a ticket office and lots of
> aquariums + service areas and storage and other backstage space etc.,
> aren't we?
>

I thought we were talking about a single big aquarium. I guess the version
with lots of small aquariums makes more sense because there are probably
not that much aquariums so big they deserve their own point or way.

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

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

[Simon Poole]

Am 25.08.2014 16:46, schrieb fly:
.
> 
> Did you have a look at the three existing proposals about complex
> junctions ?
..

IMHO one of the nice aspects of variant 4 (using an area) is that it
really doesn't collide with however the routing aspects of the junction
are mapped.

@Lukas are the names of the traffic signals/junctions actually used in
addresses (and in principal would be a suitable value for addr:place in
an address)?

Simon



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tagging for complex junctions or traffic signals that are named

[fly]

Am 24.08.2014 13:20, schrieb Lukas Sommer:
> Hello everyone.
> 
> In some countries (Japan, Korea…), people orient themselves in the local
> area using the names of road junctions or traffic signals rather then
> the names of streets.
> 
> I have documented the current tagging practice for simple junctions at
> the following new wiki pages:
> 
> http://wiki.openstreetmap.org/wiki/Named_spots_instead_of_street_names
> 
> http://wiki.openstreetmap.org/wiki/Tag:junction%3Dyes
> 
> Furthermore, some more text has been added here:
> 
> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Named_traffic_signals.2Ftraffic_signal_systems_.28Japan.E2.80.A6.29
> 
> Feedback and/or corrections are welcome.
> 
> The current tagging practice works well for simple junctions, but makes
> problems on complex junctions. Therefore, the proposal
> http://wiki.openstreetmap.org/wiki/Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named
> has been created. Particularly if you are mapping in one of the
> concerned countries please participate at the discussion at
> http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Tagging_for_complex_junctions_or_traffic_signals_that_are_named

Nice summary. Thanks

Did you have a look at the three existing proposals about complex
junctions ?
All are linked under:
https://wiki.openstreetmap.org/wiki/Proposed_features/Junction

Note, that in Germany micromapping is mapping highway=traffic_sign +
crossing=traffic_sign/* on a node at the crossing and not at the
intersection node. I even have found highway=traffic_signal at the road
marking and another highway=crossing for the pedestrian crossing both in
advance of the intersection node.

Personally, I did start to add direction=* to traffic_signals for only
one direction.

Cheers fly

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

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

[Martin Koppenhoefer]

>> On Mon, Aug 25, 2014 at 10:43:36AM +0200, Pieren wrote:
>> ...adding at the end a note saying that a large part of
>> the community consider these two tags -smoothness and
>> maxspeed:practical - too subjective.



I don't think smoothness is too subjective or anyhow comparable to 
maxspeed:practical - it may be badly defined and may have strange proposed 
values, but I think it can still be handled somehow and is generally suitable 
for the db (can be defined objectively) while practical speed is not.


cheers 
Martin


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

Re: [Tagging] Reproposal of tourism=aquarium

[Martin Koppenhoefer]

> Il giorno 25/ago/2014, alle ore 13:14, John Packer  
> ha scritto:
> 
> Now that you mentioned I just remembered.
> There is a proposal that uses the key attraction=* for describring objects 
> from theme parks, zoos, etc.


+1

I also don't like
man_made=aquarium
because I'd expect that to describe a single aquarium, i.e. a water filled 
container with fish etc. in it, while here we are discussing a structure like a 
zoo with footways, service ways, a ticket office and lots of aquariums + 
service areas and storage and other backstage space etc., aren't we?

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

Re: [Tagging] minus or underscore in attribute values?

[Pieren]

On Sat, Aug 23, 2014 at 12:25 PM, Martin Koppenhoefer
 wrote:
> the space gets replaced by an underscore

+1
The problem is not to have a preference between underscore and hypen
but to know if our English colleagues can agree on the separator space
or hyphen.

Pieren

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

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

[Richard Z.]

On Mon, Aug 25, 2014 at 10:43:36AM +0200, Pieren wrote:
> I would modify the section [1] by replacing "it is recommended" by "it
> is suggested" and adding at the end a note saying that a large part of
> the community consider these two tags -smoothness and
> maxspeed:practical - too subjective.

I have rewritten it even a bit more, hope it is better now.
Also changed the old proposal page a bit.


Richard

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

Re: [Tagging] Reproposal of tourism=aquarium

[John Packer]

>
> And I feel like most of the values would better fit with a key like
> amusement _ride=  or amusement _ride:xxx=yes.

Now that you mentioned I just remembered.
There is a proposal that uses the key attraction=* for describring objects
from theme parks, zoos, etc.
See http://wiki.openstreetmap.org/wiki/Proposed_features/Key:attraction

So apparently the key attraction=* is already used for something else.


2014-08-25 7:40 GMT-03:00 Andreas Goss :

> +1, tourism=attraction is a poor scheme from the early days, maybe we
>> should deprecate it all together, either without alternative or in favor of
>> a flag like attraction=yes (or level0 - level 3 etc), or
>> tourist_attraction=*
>>
>
> I also just see it ending up in 2x tagging everything. leisure=waterpark
> tourism=attraction + attraction=waterpark; amenity=restaurant
> tourism=attraction + attraction=restaurant etc.
>
> And I feel like most of the values would better fit with a key like
> amusement _ride=  or amusement _ride:xxx=yes.
> http://en.wikipedia.org/wiki/Amusement_ride
>
> I mean for example a kiddie_ride you find at a supermarket is not a
> (tourist) attraction.
> __
> openstreetmap.org/user/AndiG88
> wiki.openstreetmap.org/wiki/User:AndiG88‎
>
>
>
> ___
> 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] Reproposal of tourism=aquarium

[Andreas Goss]

+1, tourism=attraction is a poor scheme from the early days, maybe we should 
deprecate it all together, either without alternative or in favor of a flag 
like attraction=yes (or level0 - level 3 etc), or tourist_attraction=*


I also just see it ending up in 2x tagging everything. leisure=waterpark 
tourism=attraction + attraction=waterpark; amenity=restaurant 
tourism=attraction + attraction=restaurant etc.


And I feel like most of the values would better fit with a key like 
amusement_ride=  or amusement_ride:xxx=yes.

http://en.wikipedia.org/wiki/Amusement_ride

I mean for example a kiddie_ride you find at a supermarket is not a 
(tourist) attraction.

__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

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

[Pieren]

I would modify the section [1] by replacing "it is recommended" by "it
is suggested" and adding at the end a note saying that a large part of
the community consider these two tags -smoothness and
maxspeed:practical - too subjective.

Pieren
(I also suspect the 12000 coming from some imports. Such numbers do
not say many thing if we don't know how many contributors really used
it).

[1] Marking surface of road with tag surface without adding it to
parallel roads (or adding only tags surface) may lead to unwarranted
understating priority of road relative to surrounding[1]- so it is
recommended to add also proposed tags smoothness=* and
maxspeed:practical=*.

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