Re: [Tagging] proposal - camp_site= Voting on the 28th

[Warin]

On 26/04/2015 10:45 AM, David Bannon wrote:

OK, I think we have talked this topic just about to death.

I propose to turn on voting on Tuesday, 28th April. So please, if you
have some further improvements, get in now !

Thanks folks for all your help with this. Its been a great example of
worrying away at a problem until its as good as it can get.

Lets see if thats good enough ...


I have changed the proposal status to reflect the voting taking place. 
Gets it listed on the voting page


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

Re: [Tagging] Tagging of pitches within a campsite

[Warin]

On 30/04/2015 11:17 AM, Bryce Nesbitt wrote:
On Wed, Apr 29, 2015 at 5:37 PM, John Willis > wrote:



That sounds like “tagging for the renderer” to me.


When rendering lags tagging behavior, there is that temptation.



Rendering will always lag behind tagging.

If tagging is to be rendered then adding another tag to have it rendered 
will lead to the original tag being ignored by renders .. Catch 22.



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

Re: [Tagging] Tagging of pitches within a campsite

[Bryce Nesbitt]

On Wed, Apr 29, 2015 at 5:37 PM, John Willis  wrote:

> That sounds like “tagging for the renderer” to me.
>
> When rendering lags tagging behavior, there is that temptation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-GB] Wiki deprecation of an in-use feature

[Bryce Nesbitt]

On Wed, Apr 29, 2015 at 4:42 PM, Warin <61sundow...@gmail.com> wrote:

> Agreed on the 'control'. But the change of the tagging status? Maybe the
> tagging group (here) is a good place to start a discussion on changing  the
> status of a tag? And it needs to be a formal process with voting on the
> wiki? Thus others outside the tagging group can participate? A 'request for
> status change (RFSC)' followed by 'Status Voting' ?


The core problem for this tag: the people using the tag were not involved
in the deprecation.
The wiki pretends to be the voice of consensus, but it's not.
*http://wiki.openstreetmap.org/wiki/Deprecated_features
*

---
A far better process might be:

*1) Announce an intent to deprecate.*
*2) Issue a notice on changesets involving the old tag (once per mapper ID
to avoid spam).*
*3) Take debate.  Build a retagging plan (as appropriate).*
*4) Take vote, if and only if there is controversy.  Many deprecation
efforts are good proposals and may not need votes.*
*5) Announce the deprecation on a data consumer list.*
*6) Delay for 2-8 weeks.  Execute a retagging.*


Anything short of this leaves out the people who most care about a tag,
and it leaves fragmented tagging which is bad for data consumers and
rendering software.

---
For waterway=water_point, I have an open mechanical edit proposal
(retagging to amenity=water_point in caravan sites).  It's the cleanup that
never happened before, effectively burring dozens of perfectly good places
to get fresh water.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging of pitches within a campsite

[Tod Fitch]

> On Apr 29, 2015, at 4:15 PM, David Bannon  wrote:
> 
> Several months ago we were advised that a camp_site is the larger site
> that contains one or (usually) more pitches. Therefore to say that a
> particular instance of a camp_site is a pitch is just plain silly.
> 
> Except, perhaps, for the rare case of a one pitch camp site ?

The key pitch= is only used a few times and it appears that most or all 
of those should have been tagged with leisure=pitch, sport=. So I guess 
that individual sites/pitches within a campground could use a namespace based 
on pitch. However I suspect that could become confusing to people more 
accustomed to the sport use of the word.

Perhaps “camp_pitch” could be used to avoid confusion. The suggestions at 
http://wiki.openstreetmap.org/wiki/Proposed_features/Extend_camp_site#Tagging_of_individual_pitches
 could then be something like:

camp_pitch:type=tent;caravan;motorhome — The things we can put on this pitch.
camp_pitch:parking=yes/no - You can park next to your tent.
camp_pitch:table=yes/no - There is a table for exclusive use of the pitch 
occupants.
camp_pitch:fire=ring/stove - There is a fireplace or fire ring for exclusive 
use of pitch occupants.
camp_pitch:electric=yes/no - There is an electrical hookup for this pitch.
camp_pitch:water=yes/no - There is a water tap for this pitch.
etc.

camp_pitch=yes Seems a bit lame for identifying the pitch itself, so you could 
actually the pitch number or name under that key instead of using the addr:unit 
tag, so camp_pitch= could be used instead of addr:unit= 
or ref=.

If people are really worried about routing to a specific pitch in a campground 
and believe that addr:unit might be more acceptable to the people doing 
geocoding, then camp_pitch=yes, addr:unit=.



smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging of pitches within a campsite

[Bryce Nesbitt]

On Wed, Apr 29, 2015 at 4:11 PM, Tod Fitch  wrote:
>
> Any reason to avoid a namespace? Seems like tagging things like water
> availability as amenities would show a lot of amenities that are not really
> available to everyone. That is things like the picnic table, fire ring or
> fire place and possible water may be dedicated to the people who are
> occupying the unit/pitch/site.
>

The namespace tags duplicates what can already be done.  This is perfectly
valid:

* camp_site=pitch*
* drinking_water=no*
* picnic_table=yes*

Indicates the individual pitch has a dedicated table but no dedicated
water.  The current namespace tagging uses:

* camp_site=pitch*
* camp_site:water=no*
* camp_site:table=yes*

Which uses newly invited attributes of "water" and "table".  I think it
better not to reinvent that wheel, and use instead:

* camp_site=pitch*
* camp_site:drinking_water=no*
* camp_site:picnic_table=yes*

Or with a more proper namespace:

* camp_site=pitch*
* pitch:drinking_water=no*
* pitch:picnic_table=yes*

But bear in mind pretty soon you'll hear from additional voices wishing to
consolidate tagging, with the opposite opinion.  drinking_water is drinking
water after all, and pretty soon you'll want *caravan_site:drinking_water*,
*areoway:drinking_water* or *waterway:drinking_water*.

The use of the "*addr*" namespace for the pitch number is for routing, and
due to the slow evolution of osm-carto (which makes anything else unlikely
to be rendered in the near future).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging of pitches within a campsite

[John Willis]

> On Apr 30, 2015, at 8:11 AM, Tod Fitch  wrote:
> 
> 
>> I chose addr:housenumber because that's perfectly set up for routers
> 
> That sounds like “tagging for the renderer” to me. I find it distasteful to 
> reuse part of the addr:* namespace for this but if it must be done then 
> addr:unit is far more appropriate than addr:housenumber.

+1

I know there are many camp sites that don't have official housenumbers, and 
that using :housenumber would allow for easy routing. 

But there are a lot of camp sites that do have housenumbers. 

And every single car camping site in Japan (which is a majority of camping 
sites with numbered pitches) will have a housenumber assigned to the camp-site 
*land* regardless of street names, because there are no residential street 
names (they use lot numbers rather than street numbers), and there are no 
housenumbers that are smaller than lot - so tagging in this way would be 
fundamentally against address tagging in Japan. You can't make up your own 
subdivisions. 

Region, city, village, neighborhood (or division #) - subdivision# - lot# 

Ex:

Gunma Region, Kiryu city, Machi village, 4-12 (subdivision 4, lot #12).

You can't just tack on a -23 to show pitch number (4-12-23) because you feel 
like it. 

4-12-23 would then be interpreted as 4 being a large section division inside 
the village (which is common in Tokyo), subdivision 12 lot 23, which is really 
far away from 4-12. 

Even if the routing still worked (as only 23 is on the pitch), if it was 
rendered, then people visually navigating would assume that that is "lot 23" - 
not the address to the campground! And very narrow and tight neighborhoods have 
very tight lot numbers, so it would be thought that this array of camp pitches 
is merely an array of small Japanese houses - not a campground. I have seen 
neighborhoods with houses smaller than US camp pitches. 

Apartments, units, buildings, suites, and other such informal address numbers 
are not part of the housenumber system. 

Even in other countries, where the housenumber would be a tag on the area for 
the campground, why would there be additional housenumbers inside a single 
address!? 

Addr:unit=* is the best fit for what an individual pitch # is inside an 
individual campground, after that, ref=*

Javbw

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

Re: [Tagging] [Talk-GB] Wiki deprecation of an in-use feature

[Warin]

On 29/04/2015 6:34 PM, Bryce Nesbitt wrote:


Regardless: the Wiki is what's out of control.  No group of mappers 
should have their tags yanked out from under them.
Those who want to change tagging should convince the mappers involved, 
not just wikifiddle.




Agreed on the 'control'. But the change of the tagging status? Maybe the 
tagging group (here) is a good place to start a discussion on changing  
the status of a tag? And it needs to be a formal process with voting on 
the wiki? Thus others outside the tagging group can participate? A 
'request for status change (RFSC)' followed by 'Status Voting' ?


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

Re: [Tagging] Tagging of pitches within a campsite

[David Bannon]

> tourism=camp_site (for the site) or tourism=caravan_site
> camp_site=pitch

Bryce, this was discussed some weeks ago.

Several months ago we were advised that a camp_site is the larger site
that contains one or (usually) more pitches. Therefore to say that a
particular instance of a camp_site is a pitch is just plain silly.

Except, perhaps, for the rare case of a one pitch camp site ?

This is what happens when insufficient thought is put into tagging
lexicon. Plan -> design -> implement ! I know it flies in the face of
"free mapping" but it would avoid problems like this one.

David

On Wed, 2015-04-29 at 14:57 -0700, Bryce Nesbitt wrote:
> Ok, lets see if we can land this.
> Existing practice varies:
> 
> 
> 
> tourism=camp_site + name=
> tourism=camp_site + ref=
> tourism=camp_site + addr:unit=
> tourism=camp_site + addr:housenumber=
> camp_site=pitch + name=
> camp_site=pitch + ref=
> camp_site=pitch + addr:unit=
> camp_site=pitch+ addr:housenumber=
> camp_site=
> tourism=caravan_site + name=
> building=cabin + ref=
> name=
> ref=
> 
> 
> 
> 
> There's a lot of activity in the "camp_site" namespace:
> 
> 
> camp_site:water (412)
> camp_site:parking (333)
> camp_site:fire=ring
> 
> 
> 
> 
> 
> The least disruptive tagging seems to be;
> 
> 
> tourism=camp_site (for the site) or tourism=caravan_site
> 
> 
> camp_site=pitch
> camp_site:=yes/no
> addr:unit=
> 
> 
> 
> 
> Tagging that avoids the namespace is: 
> tourism=camp_site (for the site) or tourism=caravan_site
> 
> 
> camp_site=pitch
> =yes/no   (e.g. drinking_water=yes).
> addr:unit=
> 
> 
> 
> 
> 
> If the community is willing to mechanically retag, it could be:
> tourism=camp_site
> =yes/no
> 
> 
> camp_site:pitch=yes
> 
> =yes/no
> addr:housenumber=
> 
> 
> I chose addr:housenumber because that's perfectly set up for routers.
> If a router can find a camp ground mapped as an area,
> it should be able to find the number inside.  It's also unrealistic at
> this time to expect osm-carto to render ref addr:unit or other names.
> ___
> 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] Tagging of pitches within a campsite

[Tod Fitch]

Comments interspersed. . .
> On Apr 29, 2015, at 2:57 PM, Bryce Nesbitt  wrote:
> 
> Ok, lets see if we can land this.
> Existing practice varies:
> 
> tourism=camp_site + name=
> tourism=camp_site + ref=
> tourism=camp_site + addr:unit=
> tourism=camp_site + addr:housenumber=
> camp_site=pitch + name=
> camp_site=pitch + ref=
> camp_site=pitch + addr:unit=
> camp_site=pitch+ addr:housenumber=
> camp_site=
> tourism=caravan_site + name=
> building=cabin + ref=
> name=
> ref=

You found more variations than I’ve noticed. It seems to be a good summary.


> There's a lot of activity in the "camp_site" namespace:
> 
> camp_site:water (412)
> camp_site:parking (333)
> camp_site:fire=ring
> 
> 

I suspect that this is because of the suggested tagging at 
http://wiki.openstreetmap.org/wiki/Proposed_features/Extend_camp_site#Tagging_of_individual_pitches

> 
> The least disruptive tagging seems to be;
> 
> tourism=camp_site (for the site) or tourism=caravan_site
> 
> camp_site=pitch
> camp_site:=yes/no
> addr:unit=

Which, other than addr:unit=, matches the tagging at the 
link above.

> Tagging that avoids the namespace is: 
> tourism=camp_site (for the site) or tourism=caravan_site
> 
> camp_site=pitch
> =yes/no   (e.g. drinking_water=yes).
> addr:unit=

Any reason to avoid a namespace? Seems like tagging things like water 
availability as amenities would show a lot of amenities that are not really 
available to everyone. That is things like the picnic table, fire ring or fire 
place and possible water may be dedicated to the people who are occupying the 
unit/pitch/site.

> If the community is willing to mechanically retag, it could be:
> tourism=camp_site
> =yes/no
> 
> camp_site:pitch=yes
> =yes/no
> addr:housenumber=

Looks like you are strongly in favor of not using a namespace. In the case of 
individual campsite pitches I think there is a strong case to be made for using 
a namespace. Maybe not camp_site:*=* as “camp_site” is, unfortunately, 
established for the overall campground. But there ought to be a way to show 
that a pitch as a number of amenities that are dedicated to that site and not 
to others which a namespace can easily do.

> I chose addr:housenumber because that's perfectly set up for routers.  If a 
> router can find a camp ground mapped as an area,
> it should be able to find the number inside.  It's also unrealistic at this 
> time to expect osm-carto to render ref addr:unit or other names.

That sounds like “tagging for the renderer” to me. I find it distasteful to 
reuse part of the addr:* namespace for this but if it must be done then 
addr:unit is far more appropriate than addr:housenumber.



smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging of pitches within a campsite

[Bryce Nesbitt]

Ok, lets see if we can land this.
Existing practice varies:

tourism=camp_site + name=
tourism=camp_site + ref=
tourism=camp_site + addr:unit=
tourism=camp_site + addr:housenumber=
camp_site=pitch + name=
camp_site=pitch + ref=
camp_site=pitch + addr:unit=
camp_site=pitch+ addr:housenumber=
camp_site=
tourism=caravan_site + name=

building=cabin + ref=

name=

ref=



There's a lot of activity in the "camp_site" namespace:

camp_site:water (412)
camp_site:parking (333)
camp_site:fire=ring




The least disruptive tagging seems to be;

tourism=camp_site (for the site) or tourism=caravan_site

camp_site=pitch
camp_site:=yes/no
addr:unit=



Tagging that avoids the namespace is:

tourism=camp_site (for the site) or tourism=caravan_site

camp_site=pitch
=yes/no   (e.g. drinking_water=yes).
addr:unit=



If the community is willing to mechanically retag, it could be:

tourism=camp_site

=yes/no


camp_site:pitch=yes
=yes/no
addr:housenumber=


I chose *addr:housenumber* because that's perfectly set up for routers.  If
a router can find a camp ground mapped as an area,
it should be able to find the number inside.  It's also unrealistic at this
time to expect osm-carto to render ref addr:unit or other names.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Artist studio?

[althio]

I would re-use coworking_space like:

amenity=coworking_space
craft=artist [/photographer/sculptor/...]

cheers

althio


On 26 April 2015 at 06:58, Dave F.  wrote:

>  On 26/04/2015 09:02, André Pirard wrote:
>
> The major skill of an artist being to be inventive, be prepared for
> diversity ;-)
> I know one who does truly marvelous things
>  (≃en
> ,
> ≃re
> ,
> ≃ru
> )
> with just a pencil and paper.
>
> Are we speaking of artists or of studios?
>
>
>
> I'm talking about studios. As you can see from the website, it's a
> communal studio with multiple artists using different mediums.
>
> As there's no consensus or a clear alternative I'm going to tag it
> amenity=artist_studio. Sub tags could be added to describe specific mediums
> & whether there's a sales outlet included.
>
> Cheers
> Dave F.
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Bug] calculated shortest route wrong

[Eric SIBERT]

Paul,

USENET and Mailing List posting netiquette:

4. Do not cross-post:

http://linux.sgms-centre.com/misc/netiquette.php#xpost

People on [tagging] may not be aware of the beginning of the discussion 
and other people on [osmand] may only receive a fraction of answers.


Thanks

Éric

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

Re: [Tagging] Artist studio?

[André Pirard]

On 2015-04-27 09:59, Martin Koppenhoefer wrote :

> 2015-04-26 10:02 GMT+02:00 André Pirard  >:
>
> Are we speaking of artists or of studios?
> Can't artists perform in various places, e.g. at home?
> After defining artist_studio, will we define artist_house,
> artist_xyz exactly the same?
>
>
>
> -1
> an artist studio might be at home (e.g. in a house, i.e. where the
> artist lives), might be used by a collective of artists or by several
> artists which work together or indepently from each other, it is a
> facility, not a person. This thread is about a studio used by artists.
My proposition can cover exactly that: a studio used by artists in the
same building as a house:
building=house
building:studio=yes
studio:artist=yes
and if you feel important to stress that several artists can use the
studio, something like:
studio:artists=yes

+1

> building=anykind  (e.g. studio)
> (equivalent to building:anykind=yes which is usable for multiple,
> simultaneous building types)
> anykind:artist=hisart
> or, equivalently,
> anykind:artist=hisart=yes (... multiple arts)
>
>
>
> -1
> this would lead to stuff like
> building=power_station
> power_station:artist=*

Then we must reject artist_studio because it can be tagged on a river node.
Or German because there exist meaningless German sentences.
You simply don't use what makes no sense, do you?

+1

> The building tag is about a building. A studio is typically a part of
> a building, not a building itself. The kind of building should not
> make a difference to how we tag the artist inside it.

With my proposition, you may choose to have the studio as part of the
home=house
building=house
house:studio=yes

Or as part of the building next to a house:
building=house
building:studio=yes

Who could ask for more?

+1

> The artist is, let us say, a property or characteristic of the
> building, or rather of its particular type
>
>
> -1, the artist is not a characteristic of the building and should not
> be merged with the building, we should rather have distinct objects
> for the two.

"rather a property of its particular type" means "a property of studio"
means that "artist" is defining what kind of studio we are dealing with,
hence a property of it.
Defining "artist" and "studio" separately to be associated is certainly
not "merging" them.
artist_studio is more like doing it.

In logical structured tagging, there is only one object, which is what
is "on the ground".
It is a "building" and "house" is an attribute telling what kind of
building that is.
Similarly, "studio" is an attribute telling either the kind of building
or what the house is used for.
It has been written many times that we don't make a map of people, and
hence "artists" are not "objects" but attributes of the "studio", or of
the street they are entertaining etc.

+1
>
> and his website
> artist:website=http://...
> or, if he had split his arts:
> artist:drawing:website=http://...
> artist:painting:website=http://...
>
>
>
> why not
> website=* on the artist studio object?

Conclusion.

I have defined two subkeys "artist" and "studio" which can be described
in two wiki pages (at most).
By combining them together and with other keys using the logical
structured tagging syntax, much like a phrase is built, I have solved
not only your issue and mine but also other potential issues.

+1

You want to use keys
like 
///Donaudampfschiffahrtselektrizitätenhauptbetriebswerkbauunterbeamtengesellschaft/
and write a wiki page for each issue they solve.

Are you going to write wiki pages for artist_studio, artist_house,
artist_living_street, film_studio etc.?

-1

Your -1 -1 -1 recalls me that I am on a "not" list, disparaging ideas
without the tiniest effort to find what's good in them and trying to
possibly improve.
I am attempting to solve your issue, mine and others.  You are only
interested in yours.
I personally will use the universal solution.

André.



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

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

[Paul Johnson]

On Wed, Apr 29, 2015 at 2:53 PM, Ilpo Järvinen 
wrote:

> On Wed, 29 Apr 2015, Paul Johnson wrote:
>
> > On Wed, Apr 29, 2015 at 1:58 PM, john whelan 
> wrote:
> >   The difficulty is in many cities traffic lights are synchronised
> >   in such a way that cars may have to stop at the first but there
> >   after if they are travelling at or close to the speed limit they
> >   will not be stopped on subsequent sets of lights when travelling
> >   in a straight line.  ie there is no penalty.
> >
> > I would love to know if there's a tagging schema to hint at which
> direction
> > the green wave rolls on a street.  Tulsa is somewhat notorious for
> > reintroducing two-way traffic on streets timed for one-way, effectively
> > creating a "red wave" in the direction opposite the street's previous
> > one-way direction.  There's quite a few around work and I dogfood the
> map on
> > routine trips to find hangups.  Ideally, the "red wave" direction would
> be
> > penalized severely for cars and bicycles, and incentivized for
> pedestrians
> > (since walking the direction as the motorist's red wave usually produces
> a
> > pedestrian green wave (or very near to it) by coincidence in many
> cities).
>
> One would have to account also time of the day/weekday/holidays etc. which
> might affect the scheduling of the traffic signals. They run with
> different programs at different times of day. Tracking all those by survey
> alone might turn out rather time consuming and error-prone, however, if
> one can get the traffic light management departments to open up their
> timing data it might be very useful for this.
>

For the sake of sanity, let's assume that we're talking traffic lights that
are either always on a timed pattern, which should also be reasonable for
signals that go to two or four way stops at night (and possibly during a
natural disaster).  This should reasonably handle normal operation of the
signals (even in Portland, which often has traffic lights skip a signal to
hold motorists, bicycles and sometimes even pedestrians to prevent a
conflicting movement with trams and streetcars).  The idea for this concept
would be to provide some hint that, under the usual set of circumstances,
going a specific direction on a two way street is going to really hurt.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Ilpo Järvinen]

On Wed, 29 Apr 2015, Paul Johnson wrote:

> On Wed, Apr 29, 2015 at 1:58 PM, john whelan  wrote:
>   The difficulty is in many cities traffic lights are synchronised
>   in such a way that cars may have to stop at the first but there
>   after if they are travelling at or close to the speed limit they
>   will not be stopped on subsequent sets of lights when travelling
>   in a straight line.  ie there is no penalty.
>  
> I would love to know if there's a tagging schema to hint at which direction
> the green wave rolls on a street.  Tulsa is somewhat notorious for
> reintroducing two-way traffic on streets timed for one-way, effectively
> creating a "red wave" in the direction opposite the street's previous
> one-way direction.  There's quite a few around work and I dogfood the map on
> routine trips to find hangups.  Ideally, the "red wave" direction would be
> penalized severely for cars and bicycles, and incentivized for pedestrians
> (since walking the direction as the motorist's red wave usually produces a
> pedestrian green wave (or very near to it) by coincidence in many cities).

One would have to account also time of the day/weekday/holidays etc. which 
might affect the scheduling of the traffic signals. They run with 
different programs at different times of day. Tracking all those by survey 
alone might turn out rather time consuming and error-prone, however, if 
one can get the traffic light management departments to open up their 
timing data it might be very useful for this.


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

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

[Paul Johnson]

On Wed, Apr 29, 2015 at 1:58 PM, john whelan  wrote:

> The difficulty is in many cities traffic lights are synchronised in such a
> way that cars may have to stop at the first but there after if they are
> travelling at or close to the speed limit they will not be stopped on
> subsequent sets of lights when travelling in a straight line.  ie there is
> no penalty.
>

I would love to know if there's a tagging schema to hint at which direction
the green wave  rolls on a
street.  Tulsa is somewhat notorious for reintroducing two-way traffic on
streets timed for one-way, effectively creating a "red wave" in the
direction opposite the street's previous one-way direction.  There's quite
a few around work and I dogfood the map on routine trips to find hangups.
Ideally, the "red wave" direction would be penalized severely for cars and
bicycles, and incentivized for pedestrians (since walking the direction as
the motorist's red wave usually produces a pedestrian green wave (or very
near to it) by coincidence in many cities).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wood+Coastline conflict

[Janko Mihelić]

sri, 29. tra 2015. 18:32 Bryce Nesbitt  je napisao:


 In the case of a mangrove forest, it means


 exactly what it seems like: there is


no other land type between forest and water.



I think you should map a mangrove forest over the water, if tree trunks are
sticking out of water.

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

Re: [Tagging] Wood+Coastline conflict

[Bryce Nesbitt]

On Wed, Apr 29, 2015 at 6:23 AM, Erik Johansson  wrote:

> So are the tree trunks growing
> right at the  coastline, or is there a 1m-5m zone where there are no
> tree trunks and you are really mapping "landcover=tree_canopy? So I've
> never really figured it out  exactly what it means when the coastline
> and the treeline shares the same way.


In the case of a mangrove forest, it means exactly what it seems like:
there is
no other land type between forest and water.

In other cases it's a handy approximation, close enough for mapping
purposes.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wood+Coastline conflict

[Erik Johansson]

On Fri, Apr 24, 2015 at 2:16 PM, Torstein Ingebrigtsen Bø
 wrote:
> Hi,
>
> Some island are covered completely  with wood. For these island I get a tag
> conflict. Since the natural tag is used for both. I have two solutions:
> 1. make a combined tag like natural=coastline;wood
> 2. make a 1-way relation for the wood tag and tag the way with
> natural=coastline
>
> which one is prefered?

To keep my blood pressure low I do not map trees on islands at least
in the current OSM datamodel.

There are two cases the whole islands is filled with trees, and the
islands is partially filled with trees. So are the tree trunks growing
right at the  coastline, or is there a 1m-5m zone where there are no
tree trunks and you are really mapping "landcover=tree_canopy? So I've
never really figured it out  exactly what it means when the coastline
and the treeline shares the same way.

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

Re: [Tagging] [Talk-GB] Wiki deprecation of an in-use feature

[Bryce Nesbitt]

On Tue, Apr 28, 2015 at 11:17 PM, Warin <61sundow...@gmail.com> wrote:

>
> I think the boating people need to change. If not 'they' need to convince
> at least 2 users.. and properly define what 'they' are doing and why... on
> the wiki ... maybe 'they' should take a very close look at all the waterway
> wiki pages before more bogus definitions are found?
>

"they" seem quite happy with waterway=water_point on the UK canal system:
http://overpass-turbo.eu/s/94x
The waterway tag keeps those sites off the main map and GPS units -- on
purpose.



Regardless: the Wiki is what's out of control.  No group of mappers should
have their tags yanked out from under them.
Those who want to change tagging should convince the mappers involved, not
just wikifiddle.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Colour coding of wiki description boxes

[Christoph Hormann]

On Monday 27 April 2015, Frederik Ramm wrote:
>
> I think that is wrong to colour-code the whole box red for
> "deprecated" feature, for the usual reason - it only takes a handful
> of people to "deprecate" something and this could easily lead to
> widely used tags being shown in red, leading people to believe that
> there is something wrong about them.

Yes, the proposal process is simply unsuited in a meritocratic system 
like OSM for tags that are currently in significant use.  It makes a 
lot of sense to discuss and evaluate new tags from scratch or to 
decommission tags that have gone out of use almost completely.  
Unfortunately these applications of the proposal system are rare these 
days and it is too often used to push a certain tagging scheme against 
competing ideas.

Or to phrase it differently - the opinion of mappers using a tag should 
weight at least as much as those of people voting on a tag proposal and 
it is a problem when a tag that is actively used by 100 people is 
deprecate by votes of just a few.  Same goes the other way round of 
course - a proposal rejection despite a lot of people following it does 
not really mean that much.

Instead of a deprecatation proposal on a actively used tag the arguments 
against it should be put up in the tag documentation to convince 
mappers not to use it rather than discouraging them by use of signal 
colors.  There is for example the {{Verifiability}} template that can 
be used to indicate tags that are vague in definition.

-- 
Christoph Hormann
http://www.imagico.de/

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