[Tagging] landcover vs landuse

2015-08-19 Thread Pieren
On Sun, Aug 16, 2015 at 1:27 AM, Friedrich Volkmann b...@volki.at wrote:
 On 03.08.2015 00:55, Daniel Koć wrote:
 I have just discovered that while landcover=trees has no Wiki page, it's
 quite established tag (I wouldn't say popular here, because it's just
 about 1% of forest/wood uses) and we could officially define as a generic
 tag for trees areas, when it's not clear for the mapper if it's natural or
 not (forest vs wood).

 No, because the landcover=* key is just nonsense. There is no definition for
 that key. What does landcover mean? Vegetation? Soil? Atmosphere? Buildings?
 Ocean? Everything we map is landcover in some respect. You could use
 landcover=motorway instead of highway=motorway, and landcover=playground
 instead of leisure=playground. The landcover key matches all and nothing.

It's true that this key is mainly supported by a very small group. I
wouldn't say it is established. The taginfo stats are relatively
stable and 760 users is peanuts 5 years after the proposal in OSM
(11/2010). One reason is probably because it's not rendered in main
map site.
But another reason is that most of the constributors draw such
polygons from the aerial imagery and they don't care about the
difference between land use and land cover. When they see a piece
of grass or forest, they just want to draw a single polygon and use a
single tag for grass and forest. Live must be easy for the
contributors. And promoting a new key which may replace or be combined
or partially overlap the old landuse will be extremely confusing for
the non-experts. And this will be endless, like the footway vs path
story.

Pieren

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


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

2015-03-31 Thread Pieren
On Tue, Mar 31, 2015 at 6:55 AM, Jan van Bekkum jan.vanbek...@gmail.com wrote:


Not sure about the typo : is it non-designated or non_designated ?

Pieren

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


Re: [Tagging] Tagging established, unofficial and wild campings

2015-03-27 Thread Pieren
On Fri, Mar 27, 2015 at 12:30 PM, Jan van Bekkum
jan.vanbek...@gmail.com wrote:
 Hi Pieren,
 I have mapped those myself only in cases other reasons
 existed to map than.

But this is not what the first section suggests:
Beautiful place in the mountains, desert or at the beach - no
facilities, usually no explicit owner's permission (wild camp). We
can add attribute camp_site=trekking for trekking camps;

Pieren

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


Re: [Tagging] Increasing voting participation (Was Accepted or rejected?)

2015-03-18 Thread Pieren
On Wed, Mar 18, 2015 at 8:21 AM, Frederik Ramm frede...@remote.org wrote:

I said few years ago that vote should be replaced by opinion poll.
This hasn't change in my view,

 It is however not true that tagging votes are an important core element
 of how we work; we can do perfectly fine without.

Yes and no. It is not a core element but getting feedbacks before
formalising a new tag is better than nothing even locally (like
imports, no ?). But it is true that a tag approved in the wiki
doesn't avoid bad tags. See the endless discussions around
smoothness or  highway=ford on ways or the use of abstruse
abbreviations for the non-natives like ngo, aed or asl.

 Even if certain things
 were tagged differently in different parts of the word, that would not
 break OpenStreetMap.

Only a fraction of us is thinking like this. Using 2, 3 or 10
different tags for the exact same thing is surely providing a job for
OSM consultants but is creating unnecessarily complexity for
contributors and data consumers. Wikipedia wouldn't accept two
articles on the exact same topic. It is our responsibility to keep the
project usable, even for new data consumers.

 The following 35 people think that this proposal is a good idea and
 would recommend using it
 rather than
 This proposal has been accepted

True.

 So please, don't go over board here by trying to force-involve every
 mapper in tag votes; they're simply not important enough, and they
 *should not be*. Don't try to make them important, lasting, or binding.

But the wiki is currently giving the impression that the vote
process is formal and important. So something has to be changed.

Btw, I don't think that translations will help. Some proposals don't
have many feedbacks simply because the interest is not shared by a
large group.

Pieren

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


Re: [Tagging] Accepted or rejected?

2015-03-18 Thread Pieren
On Tue, Mar 17, 2015 at 3:04 PM, Kotya Karapetyan kotya.li...@gmail.com wrote:

 I propose to clarify it by changing the recommended number of votes in
 https://wiki.openstreetmap.org/wiki/Proposed_features#Approved_or_rejected
 from ...8 unanimous approval votes or 15 total votes with a majority
 approval...
 to ...8 or more unanimous approval votes or 10 or more total votes with
 more than 74 % approval
 This will not change anything in terms of the ongoing discussion of how the
 approval influences other things. So the discussion can continue. But we'd
 introduce some mathematical logic in the process.

-1
The main criticism about votes is the approved status and the
small amount of participants, not percentage of approvals. So change
the status name and increase the quorum, not the opposite. It's also
not a problem to keep the vote open for a long time.

Pieren

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


Re: [Tagging] Tagging established, unofficial and wild campings

2015-03-13 Thread Pieren
Informal campgrounds exist in areas where you are allowed to camp
anywhere except... (like in Sweden) or where no rules exist
informal campgrounds shall only be mapped if there is an important reason ...
Nearby presence of public facilities, Their security, Their sheer
beauty, Remote sites 

which means potentially everywhere... imagine a similar proposal for
pissing on trees tagged as informal toilets ?

Pieren

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


Re: [Tagging] Current status of the key smoothness=*

2015-03-11 Thread Pieren
I search an adjective about this tag and I hesitate between very_bad
and horrible ;-)
Btw, what's different today about its verifiability ? I think most of
the people rejecting this tag simply ignore the discussions around it.
This gives a different perspective about your consensus. Removing
the controversy section will just give the false impression that
there is no controversy at all.

Pieren

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


Re: [Tagging] Super-keys are evil

2015-02-24 Thread Pieren
On Mon, Feb 23, 2015 at 2:43 AM, Kurt Blunt k.bl...@inbox.com wrote:

 When you want to tag the same point with multiple categories, those 
 categories must share the same tag and be separated by a semicolon e.g. 
 shop=convenience;alcohol. That is, unless the two categories are under two 
 different super-keys, in which case the object will have a separate tag for 
 each category. This is inconsistent.

We have other options than the semicolon e.g. shop=convenience +
alcohol=yes. We have noticed that excepted some rare exceptions
(like multi-refs or opening hours), semicolons should be avoided in
OSM because data consumers don't like them.

 But nevermind the inconsistency. More importantly, this key-value tag 
 hierarchy makes it unnecessarily difficult for contributors to remember tags. 
 More specifically, it's difficult to remember under which super-key the 
 category is located. Is it building=shrine or amenity=shrine? Is it 
 barrier=city_wall or historic=city_wall? What about city_gate?

Editors are supposed to provide some help tools like the presets where
you type city wall and the editor finds the correct tag for you.
Otherwise you can open the infamous wiki Map features page and use
your browser search function.

 Many tags don't even make sense. What does highway=track mean? Is it a 
 highway that acts as a track? A track is clearly not a type of highway. A 
 track is just a track. A contributor is left to feel like an idiot for not 
 understanding the logic behind this system.

English is not my native language but I learned with OSM that
highway has a modern meaning for main (inter-cities) roads but also
an older meaning for any public road
(http://dictionary.reference.com/browse/highway?s=t). I hope you feel
less like an idiot now...

 amenity=reception_desk becomes reception_desk=,
 highway=track becomes track=,
 aerialway=gondola becomes gondola=,
 barrier=city_wall becomes city_wall=,
 historic=city_gate becomes city_gate=,
 sport=volleyball becomes volleyball=,
 etc.

A key with an empty value doesn't save much. And it can be worse and
lead to misunderstandings. When you write track=, is it for cars
or for trains ? Then you need a subkey again... I know one example
following your idea: the bus=yes which can be used with
public_transport or access keys but with different meanings (and
no possibility to combine on the same element).
In addition, you create much more work for the data consumers. The
first example is the renderer who can render all buildings or all
barriers in the same style, using a single rendering rule for all
types of buildings or barriers which wouldn't be possible with your
solution.
I'm not saying the current system is perfect, we made mistakes (like
the tourism category imho) but it's a compromise. And things can be
changed (see highway=ford or aed) although it's not easy and
really needs good and valid reasons.

 Now, I don't actually think such an overhaul is currently feasible given the 
 massive burden it would put on the database system. However, it might be 
 something to think about for the future.

I think that after 10+ years of discussions, you are not the first who
came with this idea.

Pieren

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


Re: [Tagging] Deprecating aerialway=goods

2015-02-19 Thread Pieren
On Thu, Feb 19, 2015 at 12:38 PM, Richard Z. ricoz@gmail.com wrote:

 How is routing software supposed to know that some aerialway=goods are
 actually taking passengers?

like roads tagged with access=no or private. Or
highway=pedestrian not allowed for cars. We create simple tags for
the average contributors, not to simplify routing software dev's life.

Pieren

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


Re: [Tagging] Deprecating aerialway=goods

2015-02-18 Thread Pieren
On Wed, Feb 18, 2015 at 2:49 PM, fly lowfligh...@googlemail.com wrote:

 http://wiki.openstreetmap.org/wiki/Key:aerialway#Usage

-1

I don't like such general keys like usage (or type) in general.
Basically, it could be used in all tags (e.g. highway=yes +
usage=residential). It's not because it is now spread in railways that
we have to repeat the same mistake (how about mixed usage ? again with
the semicolon joke ?).
An aerialway for goods is not the same as an aerialway for skiers.
Until now, we use different values based on the different
cabins/cars/lifts type. Perhaps instead of goods it could be
replaced by fork or container or container_for_goods, just
enhancing the existing list following the same principle.

Pieren

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


Re: [Tagging] Basic philosophy of OSM tagging

2015-01-16 Thread Pieren
On Thu, Jan 15, 2015 at 9:13 PM, Kotya Karapetyan kotya.li...@gmail.com wrote:

 There will be a tagging
 committee: It will maintain the official OSM tagging scheme.

Historical contributors and leaders will tell you that there is no
official committee in OSM. But, to be a litle provocative, I would
say we already have two committees for tagging scheme:
- the JOSM presets maintainers
- the DWG

Pieren

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


Re: [Tagging] Feature proposal - Voting - Water tap

2015-01-16 Thread Pieren
On Thu, Jan 15, 2015 at 4:13 PM, Kotya Karapetyan kotya.li...@gmail.com wrote:

 As of today, a total of 16 votes have been submitted, 11 of them are
 approvals. Since 2 weeks have passed and the required number of votes
 (15) has been reached, I have closed the voting and will proceed with
 clean up.

Sorry but you could extend the period of feedbacks. 7 of the 11
positive votes came before the 13th january when I posted my
comments about the possible issues (and the discussion forwarded here
which probably drew more attention to more people). After this date
the trend was much more balanced. You say you are aware of the clash
with amenity=drinking_water but you don't explain how you will avoid
this in your cleanup. You also agree that we need a rework but your
proposal is just increasing the difficulties than solving them in the
future. Now, for a water tap in the public space, it will be tagged
with amenity=drinking_water. And for the same water tap inside or
near a cemetery, it will be tagged with man_made=water_tap. How can
we explain that to newcomers ? why amenity in one case and
man_made on the other ? what is implied about potability ? etc

Pieren

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


Re: [Tagging] Feature proposal - Voting - Water tap

2015-01-16 Thread Pieren
On Fri, Jan 16, 2015 at 1:06 PM, Marc Gemis marc.ge...@gmail.com wrote:

 amenity=non_drinking_water ?

Or amenity=non_drinkable_water + a subtag describing the object

 It seems that amenity=drinking_water is cut into stone and we will never be
 able to change this tag, although it obviously blocks more general tagging
 scheme for water sources.

I never said that. Although very hard, it is not impossible to
deprecate a tag in OSM. We just need real good arguments for it.

Pieren

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


Re: [Tagging] Feature proposal - Voting - Water tap

2015-01-16 Thread Pieren
On Fri, Jan 16, 2015 at 4:03 PM, François Lacombe
fl.infosrese...@gmail.com wrote:

 A fountain will striclty have the same external and internal design either
 the water is drinkable or not.

Here you join the other thread about philosophy of tagging. Some
people describe an object, others describe a service. You see a
fountain or a tap and you don't care much if water is drinkable or not
(you prioritize the object description above its functionality). But
many other contributors, bikers for instance, want to find drinkable
water points along the route and don't care if it's a tap or a
fountain (functionality more important than the shape).

Pieren

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


Re: [Tagging] Feature proposal - Voting - Water tap

2015-01-13 Thread Pieren
On Sun, Jan 11, 2015 at 11:58 AM, Kotya Karapetyan
kotya.li...@gmail.com wrote:

 https://wiki.openstreetmap.org/wiki/Proposed_features/water_tap#Voting

I voted earlier today 'no' to this proposal in its current state and
provided my arguments. But now  I'm asked to forward them on this
mailing list (perhaps to see if I'm the only who disagrees).

My main concern with the proposal is its collision with the existing
amenity=drinking_water tag. And we get enough complains from
newcomers about our tagging complexity to not create more confusion.
The amenity=drinking_water tag is old and widely used (82.000 in
taginfo). But recently some people asked how to tag water resource
which is not intended for drinking like tap in cemeteries, see the
question referenced from the help site ([1]). I fully agree that we
need a solution here but it should not interfer with the existing tag
amenity=drinking_water. I did not follow the whole discussion but
when I was called to provide my opinion on the proposal, the first
sentence in the wiki says This is a proposal for tagging of (publicly
usable) water taps, such as those in the cities and graveyards. Water
taps may provide potable and technical water, which can then be
further specified with drinking_water=yes|no.  A bit later, there is
a warning about fire_hydrant but nothing explains here clearly where
is the difference between man_made=water_tap+drinking_water=yes
and amenity=drinking_water. And nowhere it says if drinking_water
subtag is mandatory or not or what is the default value about
potability. And we have seen in the past that with such ambiguities, a
tag is very quickly improperly used by the community. Between the
lines and comments, we see that some people would deprecate the older
tag. Why not but then tell it clearly. What I don't like is what we
have seen in the past with some proposals deliberately ambiguous about
deprecating older tags because they know it is not very popular in the
votes, and enforced the deprecation later, when the tag is moved to
the adopted sections. I'm not personnally a big supporter of the
amenity=drinking_water but I think the current proposal is not clear
enough compared to the existing tags.

Pieren

[1] 
https://help.openstreetmap.org/questions/27869/how-to-tag-water-taps-not-intended-for-drinking-water

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


Re: [Tagging] Boundary Relations. What's a subarea used for?

2015-01-08 Thread Pieren
On Thu, Jan 8, 2015 at 7:54 AM, Frederik Ramm frede...@remote.org wrote:

 So yes, remove them if you are familiar with the mapping style in the
 area you're editing and they are indeed unusual there, but leave them in
 place if it looks like the standard operating procedure in the area.

In France, we know only one person (maybe two) how is unfortunately
very active to promote this role in boundary relations (and not only
in our country). On our ML, we had much more people asking him
repeatedly to stop it or at least use another relation but he never
accepted this. So the concept of standard operating procedure in some
areas has to be interpreted carefully.

Pieren

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


Re: [Tagging] Defining genre for public bookcases

2015-01-07 Thread Pieren
On Sat, Dec 27, 2014 at 6:34 PM, Guillaume Pratte
guilla...@guillaumepratte.net wrote:
 What do you think?

The wiki about public_bookcase has been validated by a public review
but hasn't been converted to the correct template:
http://wiki.openstreetmap.org/wiki/Proposed_features/public_bookcase

Currently in OSM, we have 10 amenity=public_bookcase:
http://taginfo.openstreetmap.org/tags/amenity=public_bookcase

Seeing the numbers and the rarety of such feature, I think you can add
your suggestion directly in your local editions and perhaps also in a
new section in the wiki (noticing it's coming after the vote)

Pieren

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


Re: [Tagging] New openstreetmap-carto version: please check country and state boundaries

2014-12-11 Thread Pieren
On Thu, Dec 11, 2014 at 12:37 AM, Janko Mihelić jan...@gmail.com wrote:
 We used to use admin_level=4 for counties, but were advised that
 admin_level=6 is the standard.

 Anyway, we don't have states. Maybe you were talking about a different
 country?


I didn't find a level=3 boundary relation for Croatia either. But
anyway, here is what is documented on the wiki:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative

and we see several countries with a level 3.
Anyway, you speak about a name and a ref for the relation. Since
when do we need a ref for an admin boundary ?

Pieren

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


Re: [Tagging] Main Distribution Frame added to man_made template

2014-11-19 Thread Pieren
On Wed, Nov 19, 2014 at 1:35 PM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:

 formally a tag to represent the whole building, it is defacto the only tag
 for the whole site (mostly, I guess), and as such defacto representing also
 the telco installation. If you want to map the locations of other service
 equipment like DSLAM, OLT or PSTN, please use different tags (no
 abbreviations or at least a generally understandable prefix like
 telecomunication/telco).

I don't remember any discussion about such tag on a global list. And
we always recommand to not use abbreviations in tags since OSM tags
can be read by any one, not only telecom experts (or any experts
groups who love to exclude others by using a cryptic language). If
it's coming from an import, the use stats do not reflect any
significant adoption by contributions. It is then a defacto bad idea
to validate an import mistake in the wiki ;-)

Pieren

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


Re: [Tagging] governmental / public_administrative landuse are not commercial

2014-11-14 Thread Pieren
On Fri, Nov 14, 2014 at 5:03 AM, johnw jo...@mac.com wrote:
 A couple more landuse cases were added. I’m going to ask now if it is a good
 idea to specifically exclude Police/fire/safety and give them their own
 landuse(s).

I don't think we need a civic subkey in landuse. When I see the
growing list, it will finally generate very small landuse polygons in
OSM. This is not the intend of the OSM landuse. We put tax,
immigration or legislative into the buildings where these services
are. Otherwise, it is endless. We could create a subkey for
landuse=residential with residential=home or residential=garage
or residential=toilets_in_the_garden

Pieren

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


Re: [Tagging] governmental / public_administrative landuse are not commercial

2014-11-14 Thread Pieren
On Fri, Nov 14, 2014 at 12:29 PM, johnw jo...@mac.com wrote:

 it is a subkey for the buildings, to go with building=civic.

My concern is about splitting a landuse polygon just to refine
information that could be stored on buildings themselves for instance.

Pieren

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


Re: [Tagging] Tagging Digest, Vol 62, Issue 31

2014-11-12 Thread Pieren
On Wed, Nov 12, 2014 at 8:50 AM, Mateusz Konieczny matkoni...@gmail.com wrote:
 No, unknown should be tagged as unknown. Even better - not tagged.

+1
We don't tag what is unknown.

Pierre

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


Re: [Tagging] Rooftop parking - new parking=rooftop value?

2014-11-12 Thread Pieren
On Tue, Nov 11, 2014 at 11:22 PM, johnw jo...@mac.com wrote:
 2014-11-11 12:53 GMT+01:00 Tobias Knerr o...@tobias-knerr.de:

 Therefore, would prefer a generic tag that can be added to any feature,
 e.g. location=rooftop.

-1
'location' is already a bad keyword in OSM. Like type, it is too
generic and could be used for every thing.

 On Nov 11, 2014, at 9:36 PM, Martin Koppenhoefer dieterdre...@gmail.com
 Those are excellent ideas. Then you could use location=rooftop (or similar)
 to place basically anything on the roof, including multistory or surface
 parking structures. Garden roofs come to mind.

I think the roof is part of the building 3d or levels mapping. We
should not create a new use of location just for that. I could also
imagine that in some buildings, the parking is somewhere in the middle
and not necessarily on the top or on the bottom of the building, in
which case you will have to invent a new tag for that.
I would prefer something like level=roof or level=3. Just where
the parking(s) is in the building.

Pieren

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


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

2014-10-30 Thread Pieren
On Wed, Oct 29, 2014 at 6:24 PM, moltonel 3x Combo molto...@gmail.com wrote:

 And both tags are
 definitive, whereas maxheight:signed=no (or whatever) is just
 waiting for a better tooled or experienced mapper to do the survey.

No. The survey is done : there is no legal height restriction under
this bridge. Of course, anyone is free to come back and add more tags
like the physical height or the material and 3d shape of the bridge,
etc. But the most interesting information for apps checking clearance
(e.g. for routing) is there = no legal restriction here.

Pieren

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


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

2014-10-29 Thread Pieren
On Mon, Oct 27, 2014 at 8:21 PM, Friedrich Volkmann b...@volki.at wrote:

 (...) But when we see nothing, it's plain wrong to add something to the 
 database.

But it's a common practice today in OSM. It seems you missed the long
discussions about noname=yes or oneway=no. Such tags don't say
here is nothing. It says that someone went on place and checked that
the restriction does not apply. Otherwise, we cannot differenciate
surveyed locations and missing information in OSM.

Btw, I'm also in favour of maxheight=unsigned which is for me less
controversial than maxheight=none (even as a non native English
speaker). Although maxheight is the legal value (like all tags in
the category access), none is suggesting that there is no height
limit at all.

Pieren

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


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

2014-10-29 Thread Pieren
On Wed, Oct 29, 2014 at 1:51 PM, Marc Gemis marc.ge...@gmail.com wrote:

 So why can't we fill in the default value for unsigned bridges explicitly ,
 so e.g. maxheight=4 and add source:maxheight=Country:default ?

I don't know the max height in my country. And probably most of the
contributors don't. So the simple maxheight=unsigned or unmarked
or whatever is easier for the average contributor.
What you suggest is possible and could be automated. But it could be
done by the data consumers as well.

Pieren

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


[Tagging] Default maxspeed unit on waterways

2014-10-29 Thread Pieren
Hi,

Currently, le wiki ([1]) suggests that maxspeed has to specify the
unit knots when it's not km/h. But knot is the unit used worldwide
on waterways. Why should we add something obvious on all waterway
elements ? Could we suggest that the default unit for maxspeed on
waterways is knot and the default km/h remains for highways and
railways ?

Pieren

[1] http://wiki.openstreetmap.org/wiki/Key:maxspeed

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


Re: [Tagging] Default maxspeed unit on waterways

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

What is leading to confusion is to suggest that km/h is the default
unit for waterway speed when  knot is in use everywhere. Please think
as a contributor, not as QA programmer or data consumer (it's easy to
check if the speed limit belongs to a waterway or not).
And The knot is a non-SI unit that is accepted for use with the SI
(https://en.wikipedia.org/wiki/Knot_%28unit%29)

Pieren

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


Re: [Tagging] Default maxspeed unit on waterways

2014-10-29 Thread Pieren
On Wed, Oct 29, 2014 at 3:47 PM, Malcolm Herring
malcolm.herr...@btinternet.com wrote:
 On 29/10/2014 14:12, Ilpo Järvinen wrote:

 I don't know about other countries, but here in Finland the water maxspeed
 signage is in km/h although knot is used for almost everything else.
 In UK waterways, both MPH and knots are used. Usually MPH on canals and
 knots on rivers, though even this can depend on who the navigation authority
 is and how far back in history their statutes were written.

Okay, if the unit is not generalized, then my idea doesn't make sens.
Sorry for the noise.

Pieren

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


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

2014-10-14 Thread Pieren
On Tue, Oct 14, 2014 at 2:58 PM, Ilya Zverev i...@zverev.info wrote:
 Hi! I've noticed today there is an epic voting battle on the fields of
 wiki. Hundreds of mappers came to state their disapproval of person
 relation type. I wonder how many of them actually mapped one, or even
 seen such relations. I found some of them in 2011, and posted an entry
 in SHTOSM about such relations. After at least three years, this
 proposal is not about new relation type, and you should understand
 this.

Well, they are plenty of tags in OSM that nobody has ever heard
excepted his creator ... It's not because we don't use a tag that we
cannot give an opinion. And I cannot remember any public discussion
about such 'person' relation type, at least on the international lists
which could explain why it is coming under the spotlight only today.

 There are 1648 relations of type=person already in the database.

But if I believe some feedbacks, most of them have been created by
only three contributors which is tempering the stats.

 The proposal is basically about documenting a relation type.
 It either can be found in the wiki, or not. Nobody here has the power
 of removing all such relations from the database.

The database is the result of our consensus. Of course anyone has the
power to add any thing but others have the same equal power to remove
them. (The question is more about making a mass insert or a mass
delete). If I find personal data on my own family in OSM, I will
delete them immediatly without any permission.

 Some say, you cannot make something appear in the database just by
 passing proposals in the wiki. You should do some mapping first.

You can add new tags directly in the database. And you can write
anything in the wiki. But it does not mean that the whole community
will accept your idea. Some might, some might not, most will ignore
you. This proposal is questionning the limits of OSM, it is not really
related to some physical element on the ground and is about privacy.

 Well,
 poles have been mapping for 4 years. Is it enough? Or should they have
 waited another 4 years, so there are 10k relations of this type? It is
 a part of OpenStreetMap, whether you like it or not. It won't go away
 if you vote no on the proposal, and there won't be less such
 relations added. So this is not about a new type. This is about
 documenting something that has been mapped for years.

But if the vote (I prefer feedback) is showing that a significant
part of the community does not like the idea, then you cannot refuse
that they will delete one of such relations when they meet one of
them. (mass deletion has to be treated differently)

 And now, this far into mapping persons in OSM, you should not
 prevent documenting established relation types, but help document them
 better.


In one way, you say it is already widely used and in the other way,
you admit it could be better documented. I will show you where we have
problems in the proposal and why a vote process is sometimes better
than simply enforcing an idea.

I copy the description here:
The main purpose of this type=person relation is to link (bind)
different objects describing a person in the data base (such as grave,
memorial place). 

Here clearly, the graves and memorials are mentionned as examples. The
relation could be used for everything related to a person and we find
now such relations linking e.g. a grave with all streets using that
person name. First mistake : it has not been strictly limited to
graves and memorials.

That kind of relation is meant to describe dead persons. For a living
people that kind of relations should be created only if it is
reasonable. 

Second mistake : it has not been strictly limited to dead people. It's
really encouraging contributors to use this relation for everything
related to a person.

Let's assume that good reason for creating that relations is
encyclopedity, that means existing of article about a person on
Wikipedia. 

Third mistake : It is not strictly reserved for notable people and
can be used to name all graves in a cemetery (which might be forbiden
in some countries). Privacy is never mentionned. To solve this, you
could enforce a link to wikipedia because they are already an
encyclopedia and check people notability
(http://en.wikipedia.org/wiki/Wikipedia:Notability_%28people%29). And
once you create a link to wikipedia (or wikidata), you don't need the
relation anymore-

Pieren

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


Re: [Tagging] Feature Proposal - RFC - Water tap

2014-10-13 Thread Pieren
On Fri, Oct 10, 2014 at 7:13 PM, sabas88 saba...@gmail.com wrote:
 Perhaps it's nonsensical but...
 http://taginfo.openstreetmap.org/search?q=entrance%3Dexit

It's like Microsoft story where you have to click on 'start' to stop windows...
But it is not because someone didn't make the best choice that we have
to follow him...

Pieren

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


Re: [Tagging] man_made=bridge

2014-10-13 Thread Pieren
On Fri, Oct 10, 2014 at 8:51 PM, Clifford Snow cliff...@snowandsnow.us wrote:
 On Fri, Oct 10, 2014 at 11:47 AM, Martin Vonwald imagic@gmail.com
 To tag or not to tag, that is the vote! ;-)
 Help me understand how we get to a document tagging standard on the wiki
 without voting. Is there a threshold for when a tag become acceptable? I
 think I understand that voting is problematic with the low number of votes.
 However, I'm not sure waiting until enough people use a tag is practical
 either.

The process called vote is probably not appropriate. But it is the
best method we have to get a feedback from the community and an
attempt to reach a consensus. If you don't do this, the risk is that
several people suggest different solutions/tags that will later
coexists in the database (which is always a mess to fix). Another one
is that your documentation is not found by the others and never
reused. Or that your tag is used for something else. Or that your
description is too vague and open for wrong interpretation.

Pieren

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


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

2014-10-13 Thread Pieren
On Mon, Oct 13, 2014 at 6:55 PM, Paweł Marynowski y...@openstreetmap.pl wrote:

 The idea was to reflect, the best we can, situation with graves.

This is not clear in the proposal. It's much more than graves.
Birthday, family, description, etc. If you check examples, it is
reused to add every details of a person live (memorial, named streets)

 A lot of people mentioned Wikidata. Do you know the rules of Wikidata? There
 are notability rules[1], so it's simply not possible to store information
 about every person there.

This is another question but not about this relation. We have to be
careful about creating a database of named people (and their
relationship) when they are not celebrities. Even for dead people, it
can be conditioned to local legislation.

 I will be more than happy to find better solution to map graves like this
 not using relations.

Pieren

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


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

2014-10-01 Thread Pieren
On Tue, Sep 30, 2014 at 8:56 PM, fly lowfligh...@googlemail.com wrote:
 Once more cite a mail on the previous thread [1]

 Seems to be a real world example, which is mappable with nodes for the
 traffic_signals and an area for the junction.

You even don't need an area if the junction is a node and the traffic
signals are also using their own nodes (thus different osm elements).

Pieren

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


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

2014-09-30 Thread Pieren
On Tue, Sep 30, 2014 at 2:21 PM, Janko Mihelić jan...@gmail.com wrote:

 If there is a need to tag traffic signal names and junction names on the
 same node,

As far as I understood, this is just a theoritical case. Also, in real
world, it doesn't make real sens to name the intersection AND a
traffic signal (with different names). So I would suspend this point
until a real case appears...

Pieren

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


Re: [Tagging] tagging for graves?

2014-09-30 Thread Pieren
On Tue, Sep 30, 2014 at 6:04 PM, Brad Neuhauser
brad.neuhau...@gmail.com wrote:

 In addition, there is a type=person relationship [4] which appears to be
 recommended for this kind of use.

This is typically stuff that are not related to any geographic
feature. It's really using OSM just as a free  access database,
bypassing the restrictions of wikipedia. Something that could be
deleted without regret on both database and wiki.

Pieren

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


Re: [Tagging] New key proposal - paved=yes/no

2014-09-25 Thread Pieren
On Wed, Sep 24, 2014 at 8:16 PM, Pee Wee piewi...@gmail.com wrote:
 No it not a language problem  or a dictionary issue. It's about an OSM data
 consumer (openfietmap)  that thinks it is important to for cyclist to know
 what type of paving can be expected.  Paved, unpaved and semi-paved to keep
 it simple. I think this is OK and it works for me.

I think the main issue raised in this thread is to decide if each data
consumer can decide alone what surface is paved or not (using this
surface key and its hundreds values) or if we are able to find a
common definition stored in the osm db (using this paved key).
With the first option, the paved attribut can be inconsistent
between applications. With the second option, the paved attribut is
subject of personal interpretations from the contributors but this
could be moderated when the surface key is also present.

Pieren

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


Re: [Tagging] name and brand tags

2014-09-24 Thread Pieren
On Wed, Sep 24, 2014 at 5:07 PM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:

 -1, if the name tag has values that aren't actually the name of the tagged
 instance it should be removed. This is not about compatibility, but cleaning
 up tagging for the *-data-consumer.

It's not tagging the data-consumer/renderer. Most of the contributors
don't care about the real oil station (or hotel or bank)
name/brand/operator refinements. We should consider the tag name as
the main key and tolerate that name duplicates brand/operator until
someone updates it with the real station name.

Pieren

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


Re: [Tagging] (Soapy) Massage Parlour

2014-09-23 Thread Pieren
On Tue, Sep 23, 2014 at 4:56 PM, Mishari Muqbil mish...@mishari.net wrote:

 I've also been advised that Thailand is not the only country with this
 legal concept and that as we should be mindful and cautious of this.

But in OSM we map what's on the ground. Create a new tag like
amenity=brothel_even_if_it_is_not_legal_to_say_it_is_one or
brothel=dont_tell_anyone

Pieren

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


Re: [Tagging] Personal Keys for WikiProject, Survey Data for Import

2014-09-18 Thread Pieren
On Thu, Sep 18, 2014 at 8:35 AM, Alex Rollin alex.rol...@gmail.com wrote:

 How do I know/get-notified it was changed?
 Specifically, how would you setup a system to receive notification that the
 object was changed?
 Have you done it?  Do you have some scripts to share?  (Can I please NOT
 have to add a relation?)
 We are talking about many thousands of nodes, btw.

If the ID is a personal ID, not something used by externals, then
why simply not using the OSM element id itself (node id or way id or
relation id) ?

- OSM is not an storages for external IDs, the external DB should link to OSM 
objects
- use wikipedia / wikidata links

Who can decide that wikidata is not an external ID which shouldn't be
stored in OSM ? Why wikidata couldn't link to OSM objects ?

Pieren

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


Re: [Tagging] landuse=grass = natural=grass

2014-09-18 Thread Pieren
On Thu, Sep 18, 2014 at 7:57 AM, Friedrich Volkmann b...@volki.at wrote:
 1. I thought the general consensus was to start using landcover for this
 type of object.

 No consensus. I strongly oppose landcover=* in view of its weak definition,
 and because it invents nothing new. Say, how does landcover=grass differ
 from surface=grass?

I think the consensus is to stay as simple as possible and use only
one tag to say that there is grass on this piece of land. Most of the
contributors don't care if the magic keyword is landuse or natural
or surface or landcover for that and most of them wouldn't agree
to draw different polygons or use several key to make such small
subtleties.

Pieren

___
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

2014-09-17 Thread Pieren
On Tue, Sep 16, 2014 at 8:53 PM, Lukas Sommer sommer...@gmail.com wrote:
 For the junction!

 For a named junction with a (not named) traffic signal: junction=yes +
 highway=traffic_signals. (Quite common on Korea – on the ground, not in the
 database.)


Ok, I improved the wiki about this
:http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Named_traffic_signals.2Ftraffic_signal_systems_.28Japan.E2.80.A6.29

___
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

2014-09-16 Thread Pieren
On Tue, Sep 16, 2014 at 6:38 PM, Lukas Sommer sommer...@gmail.com wrote:
 Currently in OSM we use yet
 highway=traffic_signals for traffic signal names in Japan. And we use yet
 junction=yes for junction names in Korea.

Sounds easy but...
how do you tag a named junction with a traffic signal ?
highway=traffic_signal + junction=yes + name=* means that name is
for the junction or for the traffic signals ? And can we imagine a
case where the junction and the traffic signals are both named (and
possibly differently) ?

Pieren

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


Re: [Tagging] default value for oneway

2014-09-01 Thread Pieren
On Fri, Aug 29, 2014 at 12:48 PM, ael law_ence@ntlworld.com wrote:
 To suggest that we now have to include every possible tag with an
 explicit value on every element is just ridiculous: the logical
 consequence of an explicit oneway on all ways.

+1
The rule is and has always been in OSM the following : if oneway tag
is missing, we assume it is not a oneway (excepted for roundabouts:
and we had epic discussions about the default for motorways but
finally it was said that we should add it explicitely also there). I
can understand it is disturbing newcomers and people coming from GIS.
But once you understand the concept, it's easy. Of course, adding
explicitely that a street is not a oneway, especially in a dense area
with many oneways make sens. It's just telling the other contributors
that this particular attribut has been verified by someone. But don't
ask others to make it mandatory.

Pieren

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


Re: [Tagging] Archway

2014-09-01 Thread Pieren
On Sun, Aug 31, 2014 at 10:25 PM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:
 The key landmark might be a possibility, for example, landmark=archway?
 Prefer to have it in some other name space as not all might be
 significant landmarks. Additional landmark=yes or landmark=archway might
 be ok
 +1, I have in the past used for (much smaller and older) arches man_made=arch

+1 for man_made. landmark is too vague.

Pieren

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


Re: [Tagging] include smoothness=* in JOSM presets?

2014-09-01 Thread Pieren
First, most of the people using presets (JOSM or ID) don't read the
wiki. Tags have to be self-explanatory as much as possible.
And even if you explain that smoothness=excellent is for roller
blade, I know skaters that could use smoothness=good ways easily.
And I'm still waiting some clarifications between very_bad and
horrible... We also had long discussions about reducing/simplifying
the list of values...
I would also like to see at least one application using it, if any.

 I am not really happy about it, but I was unable to invent something better 
 and it
 not as bad as say maxspeed:practical.
Do we have to choose between bad and worse ?
As already mentionned, the skater, biker or car driver will have a
totally different idea/view of what a good or bad smoothness is
for his means of transport.

Pieren

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


[Tagging] leisure=common

2014-08-28 Thread Pieren
I find a bit harsh that leisure=common has been completely withdrawn
from the wiki map features in the middle of the summer. If it's a UK
specific tag, then move it to a special UK map features page/table, no
?

http://wiki.openstreetmap.org/wiki/Template:Map_Features:leisure
http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dcommon

Pieren

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


Re: [Tagging] leisure=common

2014-08-28 Thread Pieren
On Thu, Aug 28, 2014 at 5:17 PM, Dave F. dave...@madasafish.com wrote:
 I believe it was withdrawn as it vague. You logic is stated on one of the
 pages you posted.

It was in the map features page for years : An area where the
public can walk anywhere (UK) 

I guess it is also used in US. I found some examples :
https://www.google.fr/search?safe=offhl=frsite=imghptbm=ischsa=1q=village+commonoq=village+commongs_l=img.3...11667.13247.0.13578.8.7.0.0.0.0.476.476.4-1.1.00...1c.1.52.img..8.0.0.cFS7KjyXTyo

If you don't know what village common is then don't use it. If we
start to delete all vague definitions in the wiki, we should better
start with smoothness :-)

Pieren

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


Re: [Tagging] Map Features template

2014-08-27 Thread Pieren
On Tue, Aug 26, 2014 at 7:36 PM, John Packer john.pack...@gmail.com wrote:

 Some people like these templates because it seems they can make new tag
 values appear in non-english pages by adding them in the english page.
 But this new value appears in english, so in my opinion it kinda defeats the
 purpose of the non-english page...

The purpose of such templates was to have the same list in all
languages. If someone introduces a new entry, it's spread in all local
pages. It's probably not translated immediately but it is by far much
better to see it in English than to have to maintain manually
separated pages/tables. We don't have enough active wiki contributors
for such solution. The tag pages came later and probably many of them
are even not listed in the Map Features where we only show the most
popular and commonly agreed tags. We can also sort and group them
differently from a simple alphabetic order or key string. Not
something we can program easily.

Pieren

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


Re: [Tagging] Religious landuse

2014-08-27 Thread Pieren
On Tue, Aug 26, 2014 at 6:35 PM, Tom Pfeifer t.pfei...@computer.org wrote:

 If you want to expand the meaning of this tag you would need a migration
 strategy,
 but I don't see it necessary. landuse=religious is consistent with
 commercial
 or retail, where you can have different retail amenities or businesses on
 the area. OSM tagging is not perfect, but we do not introduce a new
 inconsistency
 with this tag.

Religious areas can fit into a general landuse like residential
(or even why not commercial, retail, etc). It's not exclusive
(where another landuse polygon is normally). Also I remember the time
we always said that landuse is intended for small scale mapping, not a
parcel scale.

Pieren

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


Re: [Tagging] RENDER

2014-08-26 Thread Pieren
On Mon, Aug 25, 2014 at 8:36 PM, André Pirard a.pirard.pa...@gmail.com
wrote:

 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.


Basically, all renderers already decide what they print or not. Adding a
flag saying hey don't forget my feature will not change this principle.
Also with your tag, the same feature may or may not be displayed on the
map, depending if you added your RENDER tag or not. Your proposal have no
chance to be adopted for these reasons.

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


Re: [Tagging] Religious landuse

2014-08-26 Thread Pieren
On Tue, Aug 26, 2014 at 5:25 PM, Tom Pfeifer t.pfei...@computer.org wrote:

 Thus the comparison with [amenity=school], that can be easily expanded to
 the
 whole campus, fails for [amenity=place_of_worship].

 Thus, an active church building should be tagged
   [amenity=place_of_worship]
   [building=church]
   [religion=*]
 and surrounded by
   [landuse=religious]
   [religion=*]

I'm not following you here. Active or not doesn't change the fact that
now we have two different ways for tagging an amenity and its
surrounding area when we compare with school, hospital,
university or wahteveramenityyoulike. We don't need a
landuse=school because the amenity=school is already covering the
area, not the individual buildings. We have to follow the same logic
for all features. The problem is that amenity=place_of_worship
rendering is for a building on the main map style. This could be fixed
by using a differente style/colour/transparency if the tag
amenity=place_of_worship is combined or not with a tag building=*.
It's extremely sad and dangerous to create a precedent now just
because we have a rendering issue for one of the amenity keys.

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

2014-08-25 Thread 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


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

2014-08-25 Thread Pieren
On Sat, Aug 23, 2014 at 12:25 PM, Martin Koppenhoefer
dieterdre...@gmail.com 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


[Tagging] Fwd: Information board details in bus stops

2014-08-22 Thread Pieren
I forward my question here because I think my first attempt was done
on the wrong list (tran...@openstreetmap.org) :

 Hi,

 How would you tag an information board in a bus stop and mainly, if
 there is a timetable, map, etc.

 This picture on twitter suggests new tags:
 https://pbs.twimg.com/media/BvUsqMEIMAA3VRf.jpg

 information:name, information:map, information:timetable

 I didn't find an existing wiki proposal for such details.

My question is about the information board/boards at bus stops which
someone tries to tag in details in his French city (think about
disabilities). Accidentally, on the transit list, the tag strip=yes
was also questionned (check the picture). I guess it's about the road
markings on the road itself where the bus actually stops (but not
sure, it's maybe also something for blinds). Someone on the other list
suggested to replace it by road_markings=yes. Any other suggestions
about this and the information boards ?

Pieren

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


Re: [Tagging] Forest vs Wood

2014-08-22 Thread Pieren
On Thu, Aug 21, 2014 at 10:29 PM, Andrew Guertin andrew.guer...@uvm.edu wrote:
 landcover=forest
 anywhere there's trees on the ground
 landuse=managed_forest
 where logging activity occurs or the forest is otherwise closely
 tended by humans
 natural=wild_forest
 forests without much human activity, either because they're
 protected or because they're far away from humans

So, after 7 or 8 years of confusion about 2 main tags for forest,
the best idea now is to introduce a third one...

Pieren

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


Re: [Tagging] Mapping cave tunnels passable by human

2014-08-18 Thread Pieren
I'm afraid that the main problem here is not the use location or
layer or cave but highway=path. This tag was created for
multiple vehicles ways, not exclusive to a transportation like
footways or cycleways. Currently the wiki tries to reflect this in the
path definition:

A route open to the public which is not intended for motor vehicles,
unless so tagged separately. This includes snowmobile trails, ski
trails, hiking trails, horse trails, bike trails and paths, mountain
bike trails as well as combinations of the above and other modes of
transportation. 

Unfortunatelly, this tag was abusively (impov) reused later for
climbing routes. And now for caving. But none of these activities are
open to the main public, requires special skills and equipments (incl.
for survey) and, as already mentionned, needs a better handling of
elevation data which is not easy in our model. I'm afraid that the
main reason to not create new highway tags was/is to see them
immediately on the rendered maps...

That's why I would prefer something new like highway=cave (or
whatever you like) without any additional mandatory tags like
location=underground (correct me if I'm wrong but a cave is always
underground). That would not be immediately visible on the map but
data consumers requesting all highway path in Poland could also
safely ignore this creation.

Pieren

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


Re: [Tagging] convert imported natural=rock areas to bare_rock

2014-08-02 Thread Pieren
On Sun, Jul 13, 2014 at 5:54 PM, Friedrich Volkmann b...@volki.at wrote:
 Unfortunately, I am no politician who can spend all of his time for campaigns.

If you plan a mechanical edit exclusively in France, you should at
least send a message to the local list (e.g. talk-fr@; even in
English) to inform the local community about your intentions. It is
not politics but basic courtesy.

Pieren

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


Re: [Tagging] Kindergarten, Childcare and Preschool

2014-07-28 Thread Pieren
On Mon, Jul 28, 2014 at 10:57 AM, Andreas Labres l...@lab.at wrote:
 Additionally, preschool (FWICT) could be expressed as

 amenity=school, age=5-6

No, the age might greatly differ depending in which
continent/country/educational system you are. This can only be an
indicator and country specific (but could be summarized in a per
country wiki page like we do for admin_levels)

Pieren

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


Re: [Tagging] Relations are not categories excepted for type=network ?

2014-07-17 Thread Pieren
If you don't understand that a collection of all bus routes from
operator XYZ in my city is not different than a collection of all
McDonald's restaurants in my town, then I cannot argue any more. And
if we tolerate the first, we cannot refuse the second.

Pieren

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


Re: [Tagging] Religious landuse?

2014-07-17 Thread Pieren
On Thu, Jul 17, 2014 at 10:32 AM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:

I'm surprised about this discussion. Think that
amenity=place_of_worship has to be treated like amenity=school. Nobody
is asking to create a landuse=school because it is rendered properly
on the main osm style. The problem is that amenity=place_of_worship is
always rendered as a building even when it could be a bigger area
(like for schools).

Pieren

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


Re: [Tagging] Relations are not categories excepted for type=network ?

2014-07-16 Thread Pieren
On Wed, Jul 16, 2014 at 8:17 AM, Jo winfi...@gmail.com wrote:
 The same is true for cycling and equestrian networks with numbered nodes.
 There are a few of those networks in Germany as well.
 These are not collections/categories. They are networks of route relations.

Well, you could do the same for all McDonald's restaurants in
Netherlands or all pharmacies in a network or bank branches in Belgium
and say we move one tag to the upper relation to avoid its
repetition. What is done by such relations can be done by a query in
the database with one or two arguments (like the operator or
network tag) and a bbox (see XAPI, overpass, etc for more info).
Repeating the network or operator or brand name is not a problem for
many features in OSM. I don't see why we should create an exception
for footway routes.
As it was writen by Frederik Ramm in 2008 ([1]):
Our database is a spatial database; this means that it has intrinsic
knowledge about the location of objects. If you want to know about all
footways in East Anglia, simply pass in a bounding box of East Anglia
and request all footways, and the collection is made for you
on-the-fly.

Pieren

[1] 
http://wiki.openstreetmap.org/w/index.php?title=Relations/Relations_are_not_Categoriesoldid=179750

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


Re: [Tagging] Relations are not categories excepted for type=network ?

2014-07-16 Thread Pieren
On Wed, Jul 16, 2014 at 11:07 AM, Marc Gemis marc.ge...@gmail.com wrote:

 So we get network:name,  network:operator on each node and route, right ?

Since network is already in use for rwn/rcn/etc, its name could be
set in something like network:name or network_name.
I don't see the point with network:operator where operator is
already used. But tell me if you know an example where the network
operator is differente from the hiking route operator belonging to
this network...

Pieren

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


Re: [Tagging] Relations are not categories excepted for type=network ?

2014-07-16 Thread Pieren
On Wed, Jul 16, 2014 at 11:27 AM, Marc Gemis marc.ge...@gmail.com wrote:

 Just thought of this: since a node can belong to multiple networks (cycling,
 walking, equestrian), we need a tagging scheme for the network name that
 takes this into account.
 So something like : network:rcn:name, network:rwn:name and network:ren:name

No, the tags on the node should be moved to the appropriate route
relation where you also set the network_:name.

 both rcn and rwn are already used in the numbering of the nodes (rwn_ref,
 rcn_ref). I'm not familiar with the equestrian networks

Is this question related to the network relation ?

 Another problem is for routes that form the connection between 2 networks.
 Right now, they are placed in the 2 network relations. How would you tag the
 network names for them ?

Create two route relations, one per network.

Pieren

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


Re: [Tagging] Relations are not categories excepted for type=network ?

2014-07-16 Thread Pieren
On Wed, Jul 16, 2014 at 11:54 AM, Marc Gemis marc.ge...@gmail.com wrote:
 right now the nodes are not placed in the route relation. Although some
 older relations might contain them.

Then you admit it is possible to keep the nodes in the route relation.
Where now you have two relations instead of one just to avoid a tag
network:name. Don't tell me again it's to avoid a repetition of
tags, we do this for many features in OSM. It's not for simplicity :
the whole structure is more complicate to understand (more relations
and different levels). Again, the real reason is to avoid a query in
the database.

 I think you will not find a lot of people in favor of changing the tagging
 scheme for those networks, just because you don't like the network relation.
 Anyway, if you want to change it, I propose you write a proposal with all
 the required changes, and post them to the Belgian, Dutch and German mailing
 lists and forums.

I think this single list and the wiki, instead of ten local lists and
forums, is more appropriate, no ?
I don't have preconception about such relation, if someone find a
valid argument/example which explains it's not using relations as
categories.

Pieren

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


Re: [Tagging] Religious landuse?

2014-07-16 Thread Pieren
On Wed, Jul 16, 2014 at 1:52 PM, John Packer john.pack...@gmail.com wrote:
 Does this seems correct?

It's something else and is related to a rendering issue. The
place_of_worship area is rendered as a black area on the map and is
usually placed on the building polygon. If you want to draw to whole
place which can be more than the building itself, then you have this
rendering issue because you see no difference on the map.
Instead of creating a new tag, this could be fixed in the rendering
style sheet where the color and transparency could be different if the
polygon place_of_worship is combined or not with a building=* tag.

Pieren

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


Re: [Tagging] Relations are not categories excepted for type=network ?

2014-07-16 Thread Pieren
On Wed, Jul 16, 2014 at 3:02 PM, Jo winfi...@gmail.com wrote:
 We have been tagging these networks this way since the beginning of
 Openstreetmap.org. The network relations combine the nodes and the route
 relations for a given network of numbered walking/cycling/horsback riding
 network.

Please, give me an example where the nodes cannot belong to the route
relation and need specificaly a network relation.

 Just like Marc I've also been doing it this way since that is how it was
 described on the wiki.

The wiki is just a proposal. I don't remember it was discussed on
any global list (checked in my archives). It was surely not discussed
in France and the examples I find are personal initiatives.

 And I admit this was to make it possible to download the whole bunch in one
 go with JOSM.

I appreciate this honesty and I could even accept such thing in
earlier OSM time where we missed the tools we have today (like
overpass).

 The combination of route and network relations works and it is an elegant
 solution for this type of numbered node networks. The network relations are
 not categories as such.

This is where we differ. The netwok is just an attribut like many
others (operator, branch). We don't accept this kind of collections
for restaurants, banks, etc. and we have to be consistent and refuse
it for routes for the same reasons.

 Just like you aren't able to change how PT is mapped, because of too
 'complex' when rendering the beast, you won't be able to change this. So let
 it be or remap them all yourself. While you're at it, also make sure all the
 route relations become continuous once again. This is something I'm doing
 every once in a while, as route relations break easily. I created scripts in
 JOSM to help perform this task. I don't feel like rewriting these scripts,
 just because you want to change how these networks have been mapped since
 the very beginning.

It's not the question to remap everything but move the network name
down from the relation to its members. My intent is not to remove all
of such relations but see if we can reject this proposal and provide a
better solution in the wiki. Then advise my local community to not use
them (and remove them in long term).

 You can't expect everybody to read this mailing list, which is kind of moot
 anyway, just like the imports list.

It's always the same. Once we have a conflict between mappers, you
need a meeting point where everyone can express his opinion and put
all arguments on the table. What is writen in the wiki can be the
result of such discussions. Note that the wiki provides a discussion
page and this proposal was already objected since 2009... ([1])

Now, I wanted to see some real examples and followed the ones linked
in the wiki:

http://www.openstreetmap.org/relation/20614 :
type=network
network=road
description=Deutsche Bundesautobahnen
operator=Bundesrepublik Deutschland
all members are route relations; route=road; tagged with
operator=Bundesrepublik Deutschland

This could be fixed by adding the tag network_name=Deutsche
Bundesautobahnen in the route relations.

http://www.openstreetmap.org/relation/153968
type=network
network=iwn
name=Camino de Santiago
The first member is a route relation:
http://www.openstreetmap.org/relation/1247178
type=route
route=hiking
name=Voie de Soulac

And, oh surprise, it belongs to 2 network relations. The second one
is: http://www.openstreetmap.org/relation/3071561
type = network
network=iwn
name=Way of St. James
name:es=Camino_de_Santiago

http://www.openstreetmap.org/relation/157868
type=network
network=rcn
name=Gooi en Vechtstreek
More interesting, it's containing a mix of nodes and relations. Check
the first relation:
http://www.openstreetmap.org/relation/150267
type=route
route=bicycle
network=rcn
Check the first node: http://www.openstreetmap.org/node/45909336
Well, it belongs to the same route relation...

My conclusions so far:
The relation is not used consistently : sometimes you have a name,
sometimes just an operator or description; the values of the
network key are inconstant.
The relation for all motorways in Germany is only a collection/category.
The Camino de Santiago is basically a route master linking smaller
route segments together. It's even worse here since the same long
route is modelized twice in the database...
The bicycle network example shows that the nodes are finally on both
types of relations. This could be simplified with a tag like
network:name.
Shall I continue ?

Pieren

[1] http://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Network

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


Re: [Tagging] Relations are not categories excepted for type=network ?

2014-07-16 Thread Pieren
On Wed, Jul 16, 2014 at 5:23 PM, Paul Johnson ba...@ursamundi.org wrote:
 On Wed, Jul 16, 2014 at 9:57 AM, Jo winfi...@gmail.com wrote:
 We are talking about numbered node NETWORKS, where a network relation is
 entirely appropriate to describe the network of nodes and the routes
 connecting them.

Numbered node cycle networks are not very different from a bus network
in a town. Instead of numbered and signed junction nodes, you have
numbered (or named) and signed stop positions. The only difference is
that a bus line is not choosing its destination at each junction. In
your case, you don't have a predefined list of (master) routes but
only a list of path segments.
But again, like all bus routes in a town or all motorways in a
country, you should be able to retrieve the whole list of smaller
routes and junctions with an appropriate set of tags on the nodes and
route relations.

Pieren

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


Re: [Tagging] Relations are not categories excepted for type=network ?

2014-07-16 Thread Pieren
On Wed, Jul 16, 2014 at 6:33 PM, Jo winfi...@gmail.com wrote:
 I'm having a look at it. It could of course be converted automatically.
 Since I have the scripts to walk through the hierarchy already.

Again, I'm not asking to delete them *right now*. I'm checking if the
proposal is fair and is not breaking the relations are not
categories principle. If no, I could modify the wiki and recommend
some solutions (like using query the appropriate tags on the
collection itself instead of creating a relation for that). Existing
relations could be modified along the way when people are contribution
around them.
@Frank I agree that the wiki should formalize the practice but not all
practices in OSM have to be followed.

Pieren

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


[Tagging] Relations are not categories excepted for type=network ?

2014-07-15 Thread Pieren
I discover that OSM contains 1575 relations of type=network
(taginfo). I guess its definition is coming from this wiki proposal:
http://wiki.openstreetmap.org/wiki/Relations/Proposed/Network

Quotes:
A network groups together routes that share common characteristics,
e.g. a common operator, a common classification scheme (e.g. E-road
network: E 1, ..., E 999), ... 

Use cases

Person A sees a bus route with number 217 and wonders how many other
bus routes exist in that city.

Renderer M wants to render all German motorways using white font on
blue sign (official layout), and all E-roads with white font on green
sign. This can be implemented by adding rules for  20614 (view, XML,
Potlatch2, iD, JOSM, history, analyze, manage, gpx) and  20645 (view,
XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx).

Renderer M wants to render all cycle routes that belong to the
D-Netz. However, there are a lot of other national cycle routes as
well. 

Plus some attached relations examples very explicite.

As raised in the discussion page, is that not exactly breaking the
relations are not categories ([1]) principle ? Can we delete such
relations when we meet them ?

Pieren

[1] http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

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


Re: [Tagging] RFC: Proposed Node Relation

2014-07-10 Thread Pieren
I think here you just try to compensate the missing 'z' component in
OSM. I don't see any problem to have over two elements on the same
position if they have different ele or layer values.

Pieren

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


Re: [Tagging] Track grades

2014-07-09 Thread Pieren
On Tue, Jul 8, 2014 at 9:39 PM, Volker Schmidt vosc...@gmail.com wrote:
 The combination of tracktype, surface and smoothness could fit the bill.

You cannot expect that any renderer will be able to display all
possible combinations of these three keys and dozen values. Or you map
is unreadable.

 However smoothness values are ill-defined and would need more objective
 classification, but they also refer to things like high-clearance vehicles
 http://wiki.openstreetmap.org/wiki/Key:smoothness

Excepted if you can provide a special device measuring the road
smoothness, it will never be objective. Forget the smoothness tag
please. We might replace it by the 4wd tag (but it's only a partial
solution) or another passable tag (for city car, 4wd, mtb, etc)

Pieren

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


Re: [Tagging] Rendering change: buildings within highway areas

2014-07-09 Thread Pieren
We get increasing feedbacks on my local list that the new rendering
rule is counter-intuitive (to not say that it is considered as a bug).
Now roads are rendered on top of buildings even when roads are really
under buildings or underground (tunnels). Why not when your primary
interest is for roads, but it's not so nice when your interest is
buildings ;-)

Examples:
http://www.openstreetmap.org/#map=18/47.61190/-122.33067
http://www.openstreetmap.org/#map=19/43.28450/5.38016

This is now clearly a map style oriented for transport and the result
is more abstractive than previously where the z order reflected more
the real world. We can blame Google for many things but, at least,
they render tunnels below the buildings... If you don't like
buildings, than make it frankly and remove them completely from the
style.

Pieren

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


Re: [Tagging] Rendering change: buildings within highway areas

2014-07-03 Thread Pieren
On Wed, Jul 2, 2014 at 8:46 PM, Georg Feddern o...@bavarianmallet.de wrote:

 Did you consider buildings that are - at least partly - raised on
 pillars/columns with a pedestrian area underneath?


I think such buildings should have a tag layer, no ?

Pieren

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


Re: [Tagging] Subsequent wikipedia links

2014-07-01 Thread Pieren
On Tue, Jul 1, 2014 at 4:42 PM, Andy Mabbett a...@pigsonthewing.org.uk wrote:

 A Wikidata ID is part of a URL and can be rendered as such; for
 example, Q173882 equates to https://www.wikidata.org/wiki/Q173882

It was said at the beginning that wikidata or wikipedia tags will
never replace OSM tags but now I see counter examples or duplicates of
what is already there (like on this scary proposal for the operator,
architect, brand, artist, subject, name etymology [1]) . This is what
I call seeing the OSM project through wikipedia eyes. Since I'm not
a wikipedian, I don't care about such tags if it remains below the
noise level but I hope we will be able to avoid their proliferation in
OSM (e.g. this growing list of wikidata: prefixed tags). I guess the
next step could be to rely on wikipedia for the translations but OSM
has to stay independant, even if it makes wikipedians unhappy.

 It's not unusable; see URL, above.
Consider the contributors that never heart the word 'wikidata' and how
they can understand the tag wikidata=Q173882. It's not a tag I could
describe as self-explanatory.

 An example I've given previsouly is that the Wikidata entry for
 Q173882 (which is St Paul's Cathedral in London) links to the
 MusicBrainz entry for the cathedral, and that tells us which musical
 works have been premiered there. We wouldn't want to use OSM to store
 lists of works premiered in the buildings we map.

OSM is open for all new tags. Once we admit wikidata references, what
would prevent someone to add the MusicBrainz or freebase.com reference
directly in OSM ? Why should we accept one and not the others. Where
is the breaking point ?

Pieren

[1] http://wiki.openstreetmap.org/wiki/Proposed_features/Wikidata

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


Re: [Tagging] tagging of a throughabout

2014-06-30 Thread Pieren
On Sun, Jun 29, 2014 at 7:11 PM, Lukas Sommer sommer...@gmail.com wrote:
 Am I right?

FYI, we had a recent discussion about roundabouts controlled by
traffic lights on this list:
http://gis.19327.n5.nabble.com/Signal-controlled-roundabouts-td5808587.html

Pieren

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


Re: [Tagging] Subsequent wikipedia links

2014-06-30 Thread Pieren
On Mon, Jun 30, 2014 at 1:36 PM, John Packer john.pack...@gmail.com wrote:

 The main reason is that the wikipedia key is well established and supported
 in some sites, which either point a link to it or use some image from the
 page.

No, the main reason is that the wikipedia key is still human readable
where the wikidata is just an encrypted interdatabase foreign key.
I would consider elements exclusively tagged with wikidata as a
pollution (or -at least - incomplete constribution) in OSM, like any
other unusable 'ref's to external resources. And one of the mentionned
example is providing the building operator only through the
wikipedia:operator where most of the data consumers are simply
looking for the operator tag. I discover a semantic shift where
traditional OSM tags are slowly replaced by wikipedia contributors
eyes and habits.

Pieren

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


Re: [Tagging] Former tram lines: disused, abandoned or razed?

2014-06-26 Thread Pieren
On Wed, Jun 25, 2014 at 9:37 PM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:
 +1 to your analysis
 razed doesn't literally exactly represent rails being buried under an 
 asphalt layer, maybe abandoned for all of it?

-1
Asphalt covered parts are not visible, not used and speculated. The
result for such mapping will be an excessive segmentation of the
highways only for historical purpose (would be the same if someone
changes the surface tag every 10 meters). I would suggest to map
such things on historical map projects.

Pieren

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


Re: [Tagging] man_made=pipeline - is onewayness implied?

2014-06-22 Thread Pieren
On Fri, Jun 20, 2014 at 5:22 PM, fly lowfligh...@googlemail.com wrote:

 Better use an own tag like flow_direction=forward/backward/both/none or
 similar. This way we will cover all three cases mentioned below.

Where is the difference between flow_direction=forward/backward and
oneway=yes ? or flow_direction=both and oneway=no ? About
flow_direction=none, then you water stream/canal/pipe is not a water
stream/pipe/canal (change the primary tag).

Pieren

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


Re: [Tagging] Reviewing the use of addr:housename

2014-06-19 Thread Pieren
On Thu, Jun 19, 2014 at 10:14 AM, Serge Wroclawski emac...@gmail.com wrote:

 Paul, if you'd read the actual instances of addr:housename that I
 provided earlier on this thread, then you'd have seen that the name
 field is already being used for the POI itself (as it should be).

But this is a mistake. addr:housename has not been created to
replace name, operator, brand or addr:housenumber. As the wiki
says, it has been created for houses without numbers and designated by
a name. If you build an address for a POI, you need all tags addr:*
plus the POI name. We don't have to duplicate the POI name into
addr:housename.

Pieren

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


Re: [Tagging] Signal-controlled roundabouts

2014-06-18 Thread Pieren
On Wed, Jun 18, 2014 at 8:38 AM, Volker Schmidt vosc...@gmail.com wrote:

 Only relatively recently (1984) the French introduced the roundabout with
 priority in the ring.

Today, most of the roundabouts in France are ... roundabouts where
traffic in the ring has right of way and they are tagged with
junction=roundabout (perhaps 99% of the rings). Since years our
community (and drivers ;) is aware about the difference with traffic
circles (no signage, with or without traffic signals) with priority
to the right (traffic entering into the ring). The famous arc de
triomphe in Paris is one of these junctions which are today the
exceptions ([1]).

Pieren

[1] http://www.openstreetmap.org/way/184551793

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


Re: [Tagging] Signal-controlled roundabouts

2014-06-18 Thread Pieren
On Wed, Jun 18, 2014 at 10:43 AM, Pieren pier...@gmail.com wrote:


Btw, we also have some special cases like this one:
http://www.openstreetmap.org/#map=19/47.20880/-1.58741layers=N

where a tramway is crossing the roundabout. It's a normal roundabout
(not a traffic circle) excepted that traffic lights stop the road
traffic when the tram is crossing the junction.

Pieren

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


Re: [Tagging] No abbreviations in names edge case

2014-06-18 Thread Pieren
After a quick search:
http://web.archive.org/web/20011218005945/http://www.kwtv.com/news/strange/ixl.htm

it seems that the name **is** an abbreviation (and for what is
lost), in which case you don't have to expand it. (perhaps add a tag
note to explain the case...)

Pieren

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


Re: [Tagging] Pipeline bridges

2014-06-18 Thread Pieren
On Wed, Jun 18, 2014 at 11:28 AM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:
 I expect that it would be [man_made=pipeline, location=overground,
 bridge=yes, layer=*].
 +1

-1
I would expect bridge=yes to be combined with highways only. Here
nobody can walk/drive on the pipe. We don't call it a bridge.
location=overground is enough.

Pieren

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


Re: [Tagging] Signal-controlled roundabouts

2014-06-18 Thread Pieren
On Wed, Jun 18, 2014 at 1:42 PM, Janko Mihelić jan...@gmail.com wrote:

 I've never heard of this turning circle term. Maybe we should call this a
 turning circle, and then beg routing application developers to treat it the
 same as roundabout.

Currently, the wiki suggests to tag equally both types of junctions
([1]). To avoid confusion, we could use a specific tag like
junction=traffic_circle (already 33 in taginfo) (then we could
discuss about the oneway=yes implied or not). But I don't think that
routing applications are checking right-of-way's.

Pieren

[1] 
http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout#Signal-controlled_Roundabouts

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


Re: [Tagging] Basic question about functional classification of highways

2014-06-17 Thread Pieren
On Sun, Jun 15, 2014 at 4:00 AM, Fernando Trebien
fernando.treb...@gmail.com wrote:

 For several applications, such as navigation software, a distinction
 would be very interesting, allowing the display of rural primaries and
 secondaries when zooming out, a more accurate speed guess when the
 maxspeed tag is missing (based on these tables, which seem to assume
 that the urban/rural boundary is mapped using a place=* tag, perhaps
 an old idea: 
 http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed).
 The only benefit I can see of mixing the two classification systems
 into a single system is not being required to duplicate a rendering
 rule.

If you tag differently urban roads and rural roads, where is the
difference between using two highway values or simply two maxspeed
values on the same highway ?
Btw, I never understood why the maxspeed=countrycode:zone type
was not simply a maxspeed=zone type since OSM is a spatial db and
knows in which country the way is.

Pieren

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


Re: [Tagging] RFC: Door Values

2014-06-17 Thread Pieren
On Wed, Jun 11, 2014 at 1:44 PM, Martin Koppenhoefer dieterdre...@gmail.com
 wrote:


 My suggestion therefor is to be more explicit with the key identifiers,
 e.g.
 * door_type (or door:type) for hinged / sliding / revolving / ...  (still
 this is somehow ambiguous, because type might also be interpreted as
 glass door, wooden door, ...)


-1
where is the difference between door=* and door_type=* ? very confusing for
newcomers.
I would prefer a door=yes/hinged/sliding/... + automatic=yes or
manual=yes (saying default is manual)
'not sure about door=opening means...

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


Re: [Tagging] Signal-controlled roundabouts

2014-06-17 Thread Pieren
On Sat, Jun 14, 2014 at 9:41 AM, Philip Barnes p...@trigpoint.me.uk wrote:

 This roundabout originally had no lights, but they were added with the
 ring road.

Interesting. Now you get the disadvantages of both systems : you have
the unnecessary waitings on red lights and you use a maximum of land
space for a junction...

Pieren

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


Re: [Tagging] Wiki edits, building tags on nodes versus areas

2014-06-04 Thread Pieren
If the whole building is a shop, I see no reason to not reuse the same
OSM polygon for both features (the building and the shop). However, if
the shop is not the unique entity, like apartments/flats on upper
floors, I also recommended in the past to use a node.

Pieren

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


Re: [Tagging] noexit=yes wiki page update

2014-06-01 Thread Pieren
All arguments are on the table. Nothing new here but a recent change in the
wiki removed what was accepted as a compromise in april.
There is not conceptual mistake to say it's a cul-de-sac on the node or on
the way. Providing the information to QA tools or other contributors on the
last way or on the last node is equal. And please read again the comment
from Frederik Ramm:

https://lists.openstreetmap.org/pipermail/tagging/2014-April/017405.html

I don't understand why some people are not accepting simple things and
facts : we have currently 198.000 noexit on nodes and 119.000 on ways. So
I'm not the only one who think differently than you and enforcing that on
the wiki is really offending the intelligence of these contributors.
And even if you fiddle the wiki, you will not enforce contributors to use
the tag on ways. What will be you next step ? delete the tag in all ways ?
And what will be next ? delete all oneway=no because it's useless most of
the time ?

Pieren

To André, I did not reply to your last message in our private conversation
because I was simply not able to understand your arguments, even with my
best efforts.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Urban perimeter

2014-05-28 Thread Pieren
On Tue, May 27, 2014 at 5:55 PM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:

 I see, for this you'd most probably need a new boundary type (if it isn't
 the same as your administrative boundaries).

+1
type=boundary + boundary=?

Pieren

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


Re: [Tagging] Urban perimeter

2014-05-27 Thread Pieren
On Tue, May 27, 2014 at 3:37 PM, Fernando Trebien
fernando.treb...@gmail.com wrote:
 I like Nelson's idea of using a new value for boundary to represent
 this, mainly because the perimeter is not ground truth but an
 invisible legal definition that roughly matches the urbanized area.
 I was wondering if this concept exists elsewhere so that we can even
 propose such value in a way that's reusable worldwide.

That's the point. Is it legal or just the sum of all urbanized
landuse 's (residential, industrial, retail). Does it include
backyards, garden, orchard, etc ? The limit is often clear on the road
(first/last building + road sign) but fuzzy on aerial imagery if you
want to draw the area. And if all landuses are already mapped, do you
add a new polygon reusing existing nodes or do you create a
multipolygon relation (splitting the existing landuse) or you just
collect the sum of existing landuses ?

Pieren

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


Re: [Tagging] capital and state_capital: how are they being used in your country?

2014-05-15 Thread Pieren
On Thu, May 15, 2014 at 11:31 AM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:

 btw.: The current definition for administrative relations says that
 admin_centre should be used one or no time in the relation, but what if
 there is more than one admin_centre, e.g. entities where the administration
 is split over 2 (or maybe more) places? My suggestion would be to change
 this part of the relation definition in order to allow special cases:
 http://wiki.openstreetmap.org/wiki/Relation:boundary

Why not. But the definition shall be clear : it's only the
administrative(s) centre(s) place(s) to be linked. The risk if we
don't specify a limit is that contributors will use it to link all
places within the boundary (making a substitute of the infamous
is_in tag).

Pieren

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


Re: [Tagging] [OSM-talk] boules=petanque vs. type=petanque

2014-05-15 Thread Pieren
On Thu, May 15, 2014 at 11:07 AM, Dan S danstowell+...@gmail.com wrote:

 type is far too vague - it doesn't namespace at all, so it doesn't
 make it definite if it's a type of boules, a type of pitch, etc. The
 english wiki says, and I concur, Key:type should be avoided:
 http://wiki.openstreetmap.org/wiki/Key:type
 Much better to standardise on the chaining approach i.e. boules=*
 (or boules:type=* would have been another possibility in a parallel
 universe). Luckily, the number of petanque objects is small enough
 that it's possible to harmonise, so long as the nations can agree :)

+1
I don't like the key location=* for the same reasons.

Pieren

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


Re: [Tagging] capital and state_capital: how are they being used in your country?

2014-05-15 Thread Pieren
On Thu, May 15, 2014 at 2:23 PM, Matthijs Melissen
i...@matthijsmelissen.nl wrote:

 Some more strange cases:

We could create an additional role (e.g. capital) when the
admin_centre is not the capital (and only in this case to avoid
unnecessary duplicates).

Pieren

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


Re: [Tagging] admin_level on nodes: wiki vs practice

2014-05-12 Thread Pieren
On Sun, May 11, 2014 at 10:37 AM, sabas88 saba...@gmail.com wrote:

 In Italy we use capital=* with the corresponding (minimum) admin level, so
 Rome has capital=2 and so on..

That's for what 'admin_level' role has been created : to connect the
administrative place to its boundary. The modeling is better than
'capital' (works for all levels and is formally linking both entities)
but I know that renderers prefer tags directly on the node for
convenience.

Pieren

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


Re: [Tagging] deforestation tag

2014-05-05 Thread Pieren
On Sun, May 4, 2014 at 12:32 PM, John Packer john.pack...@gmail.com wrote:
 I didn't understand.
 When is landuse=grass and landcover=grass different things?

If it's just to rename the tag, then we have no advantage to change
1.400.000 polygons and all data consumers...

On Sun, May 4, 2014 at 2:26 PM, Yves yve...@gmail.com wrote:
 Landcover describes what covers the land, landuse what is it used for by
 man.
 Hence landcover=grass and landuse=meadow, you can perfectly use these two
 tags on the same polygon, or on two overlapping ones.
 Yves

Either both landuse and landcover are always matching 100% and
then using two tags instead of one is not really an improvment. Or the
polygons are not 100% identical and you create a mess of two land
layers which are sometimes overlapping, sometimes not. Editing the map
with plenty of landuse polygons is already complex and I'm not
speaking for newcomers. Doubling the amount of land tags/polygons is
shooting ourselves in the foot.

Pieren

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


Re: [Tagging] deforestation tag

2014-05-04 Thread Pieren
On Fri, May 2, 2014 at 7:21 PM, John Packer john.pack...@gmail.com wrote:
 +1, landuse=grass does not make sense, as grass is not a use, use
 landcover=grass for grass covered areas, and landuse=meadow, if it is a
 meadow
 I would love to replace all landuse=grass to landcover=grass on my city, but
 Mapnik doesn't render landcover=grass. (e.g.
 http://www.openstreetmap.org/way/167367132 )

-1
Since landuse and landcover are not always matching, you create
two separate layers of land polygons partially overlapping each
other. This would increase the complexity of mapping which is
something the crowd will never accept.

Pieren

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


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

2014-05-02 Thread Pieren
On Fri, May 2, 2014 at 4:41 PM, John F. Eldredge j...@jfeldredge.com wrote:
 Layer = -1 is not valid data for a waterway that is on the surface, which by 
 definition is layer 0. It is only valid data on an underground waterway.

Pfff, Martin, why did you restart this thread ?
Water is always below the ground, otherwise it's a flood ;-)

Pieren

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


Re: [Tagging] small change to turn restriction relation tagging

2014-04-23 Thread Pieren
On Wed, Apr 23, 2014 at 4:37 PM, Richard Welty rwe...@averillpark.net wrote:

 the signage in some other states in the US for restricted U-turns has
 an explicit authorization posted at each U-turn. i honestly don't
 have a feeling for how general the notion that emergency vehicles
 can ignore all access restrictions really is.

I think the tag makes sens only where a specific road sign exists.
This is the case in my country (not U-turns but service roads or even
pedestrian streets with e.g. special removable bollards)

Pieren

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


  1   2   3   4   5   6   >