Re: [Tagging] AE and BE orthography in tagging

2015-04-27 Thread fly
Am 27.04.2015 um 13:47 schrieb Martin Koppenhoefer:
 Recently I had amened the shop=jewelry page with a short notice that
 shop=jewellery should be preferred, as this is British orthography and the
 generic tagging rules/guidelines state that tags should be in British
 English where possible.

+1

 http://wiki.openstreetmap.org/w/index.php?title=Tag:shop%3Djewelrydiff=nextoldid=1114081
 
 Now this change has been questioned and the mapper who reverted it asked me
 to first have a discussion with the community before going to change the
 page.

The discussion took already place [1][2][3].

There is even a proposal [4].


Cheers fly

[1] https://lists.openstreetmap.org/pipermail/tagging/2010-July/002892.html
[2] https://lists.openstreetmap.org/pipermail/tagging/2010-July/002895.html
[3] https://lists.openstreetmap.org/pipermail/tagging/2014-July/018328.html
[4]
https://wiki.openstreetmap.org/wiki/Proposed_features/BE-Spelling_shop%3Djewelry

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


Re: [Tagging] fire extinguisher class

2015-04-26 Thread fly
Am 23.04.2015 um 19:43 schrieb Craig Wallace:

 fire_extinguisher:class:uk=8A 55B 75F

In general and also valid here:

Please, add the LC to to value and not to the key. This way we only need
one tag and not one for every country.

fire_extinguisher:class=UK:8A;UK:55B;UK:75F

Thanks fly

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


Re: [Tagging] addr:interpolation on highway

2015-04-23 Thread fly
Am 23.04.2015 um 06:34 schrieb Bryce Nesbitt:
 On Wed, Apr 22, 2015 at 8:13 PM, John F. Eldredge j...@jfeldredge.com
 wrote:
 
 Would you need to split the road into two ways, one for the left side and
 one for the right side, even if the roadway is not actually divided? This
 would cause a mismatch between the rendering and what is physically present.

 
 I would not do that.
 Highway tagging is only suitable for marking the range (e.g. 101-152) not
 the side.
 That's often all that's signed, and there may not be an odd/even convention.
 
 
 You are right that
 normally an interpolation way demands the overhead of three parallel ways
 (centerline, left side, right side).

Please, no overlapping (overhead) ways, but the street as centre and
parallel on both sides the interpolations.

Thanks

By the way, I count interpolations only as intermediate state and it is
often not true for the whole street as you need to split them as soon as
one housenumber is missing or as soon as you have additional numbers
like alphabetical ones or 114/2.

fly


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


Re: [Tagging] addr:interpolation on highway

2015-04-21 Thread fly
Are there addresses on both side of the street ?

Think it is wrong tagging as addr:interpolation=* should be on  separate
way(s) on one or both side(s) of the street and the first plus the last
node get the addr:housenumber=*.

cu fly

Am 21.04.2015 um 19:25 schrieb Bryce Nesbitt:
 JOSM's validator presently complains if any addr tags are on a
 highway.  The code
 note says the author wanted to catch highway=residential / addr:postcode
 type tagging.
 
 But it also complains on this tagging:
 
highway=residential
addr:interpolation=all
addr:housenumber=100-500
 
 
 Which seems pretty clean and nice.  I experimented with it here:
 https://www.openstreetmap.org/way/227298796/history
 
 Thoughts on this type of tagging? The Karlsruhe wiki is not clear on this
 point.
 I like the tagging, at least until such time as individual address points
 are later added.
 It's fast, clear, uncluttered, and stable as things are improved with
 better imagery.


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


Re: [Tagging] Outdoor DSLAM

2015-04-20 Thread fly
Am 20.04.2015 um 15:31 schrieb Andreas Labres:
 I'm looking for a good tagging for an outdoor DSLAM:
 
http://de.wikipedia.org/wiki/Digital_Subscriber_Line_Access_Multiplexer
http://en.wikipedia.org/wiki/Digital_subscriber_line_access_multiplexer
 
 (in Austria they are called ARU = Access Remote Unit and bear a label
 ARU###, so they are rather easy to identify; and they spring up like 
 mushrooms
 these days)
 
 http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dstreet_cabinet#Street_cabinet_categories
 suggests:
 
man_made=street_cabinet
street_cabinet=telecom
 
 but this telecom is too little as it doesn't distinguish the DSLAM
 functionality (with an active DSLAM component) from a regular old
 Kabelverteiler (cable distribution box, which is just passive).
 
 Taginfo finds:
 
communication=outdoor_dslam291
man_made=Outdoor DSLAM18
and some notes and comments
 
 So it seems suitable to tag:
 
man_made=street_cabinet
street_cabinet=telecom
communication=outdoor_dslam
 
 Comments?

Think the type of communication transmitted is tagged with name space so far

communication:mobile_phone=*


communication:dslam=outdoor ?
communication:outdoor_dslam=* ?

cu fly


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


Re: [Tagging] Highway barrier

2015-04-14 Thread fly
Am 14.04.2015 um 11:45 schrieb Martin Koppenhoefer:
 2015-04-14 11:35 GMT+02:00 Dave F. dave...@madasafish.com:
 
 IMO oneway on the node is inconclusive as a node has no direction  it
 should already be on the way.

 
 
 +1, but the spikes are oneway spikes, so I think we should have this
 distinction at the top level (i.e. barrier-key). It is fundamental that you
 can cross from one side and are hindered from the other. There are also
 omnidirectional spikes like this type elsewhere:
 http://www.indosoftcorp.com/image.php?pid=50 (that's a portable version)

Not sure if top level is needed as with one sentence about
barrier=spike, I can not really distinguish.

Though, we need to differ by subtag or main value.

* without main value I fear it gets complicated for routing software
* direction=* would be useful to indicate which side is dangerous
* with bollard=* we can tell if a bollard is removable, similar would by
useful for any spikes.

cu fly

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


Re: [Tagging] Way inside riverbank

2015-04-14 Thread fly
Am 14.04.2015 um 12:52 schrieb Christoph Hormann:
 On Monday 13 April 2015, Torstein Ingebrigtsen Bø wrote:
 Hi,

 I'm currently importing topological data of Norway to OSM. From the
 data set we have riverbanks; however, we do not have the deepest
 middle way as required by the wiki [1]. This middle line is therefore
 drawn manually. This is a time consuming (and dull) job. For one
 municipal it takes around 5-10 hours to draw all these lines, in
 Norway we have 428 municipals. Drawing all these middle lines will
 slow down the time to import everything dramatical. I am therefore
 curious of what is the benefits of this line. Is it really necessary
 or is it a nice to have?
 
 It is the other way round - the riverbank polygon is optional and 'nice 
 to have'.  The waterway line is what actually defines a river in OSM, 
 it also gets the name tag and other attributes.  The primary reason for 
 this is to map the water flow structure.  Also it is much easier to 
 verify and fix structural errors in waterway line mapping than for 
 water polygons.
 
 Generating a waterway line when you only have polygons is fairly simple 
 via straight skeletons (http://en.wikipedia.org/wiki/Straight_skeleton)  
 If the source data set does not contain continuous line features for 
 rivers generating those should be part of import preparation.  And i 
 disagree with Janko here - if the source data does not contain certain 
 information that is required according to OSM mapping conventions you 
 should not import the data unless you produce the information in some 
 way (either through manual mapping, computing the missing data or 
 getting it from other sources).  Otherwise the data becomes dead mass 
 in the OSM database.

+1

Thanks for the wording.

Cheers fly


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


Re: [Tagging] Defacto: man_made=storage_tank

2015-04-14 Thread fly
Am 14.04.2015 um 11:34 schrieb Martin Koppenhoefer:
 2015-04-14 7:20 GMT+02:00 Mateusz Konieczny matkoni...@gmail.com:
 
 I think that building=storage_tank would be even better.
 
 
 
 you can use both. Building is about a building typology, while man_made is
 about a function.

+1

and not every storage_tank might be a building.

cu fly


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


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

2015-04-14 Thread fly
Am 14.04.2015 um 09:08 schrieb Volker Schmidt:
 How would you tag:

 
 Here are my reformulated answers.
 Note that the answers do not apply to all countries, and most certainly not
 to the US, where to my knowledge there are no distinctions between bicycle
 and pedestrian use of sidewalks and cycleways. More specifically, I believe
 my replies are correct in Germany and Italy

Do only know the tagging in my region in Germany.

 1) Picture 1 with the blue traffic sign

 
 My answer:
 highway=path; foot=designated; bicycle=designated; segregated=yes.
 In addition you may want to specify which side is the footway and which
 side is the cycleway by lanes=2 and bicycle:lanes=yes|no and
 foot:lanes=no|yes
 You may also add colour:lanes=red|grey

Please, use the proper access tags with :lanes
highway=path
bicycle=designated
foot=designated
segregated=yes
bicycle:lanes=designated|no
foot:lanes=no|designated
vehicle=no

 2) Picture 1 without the blue traffic sign

 
 My answer:
 Anything of the following, depending on context:
 highway=unclassified/track/pedestrian/cycleway/...
 But none of foot/bicycle=designated/official/yes

+1
would use highway=unclassified/service/track/path

 3) Picture 2 with the blue traffic sign

 
 My answer:
 exactly as in case (1) for the cycle-and-foot-way and in addition
 bicycle=use_sidepath on the street

Would not tag the sidewalk as separate object

highway=*
cycleway=track
segregated=yes
sidewalk=both

alternatively as separate objects three ways
main:

highway=*
bicyle=use_sidepath
sidewalk=sidepath

and on both sides

as 1) with additional
oneway=yes
path=sidewalk

 4) Picture 2 without the blue traffic sign

 
 My answers:
 
 Alternative (a)
 highway=residential
 sidewalk=both
 Reason: If there is no sign whatsoever, I would consider both sides as
 sidewalk (Buergersteig in German).

+1

Well, in Germany bicycles are legally allowed to use the sidewalk in
this case but it is not compulsory.

As the German bicycle club (ADFC) advises its member not to use it
anymore (after the blue signs where removed) and my personal observation
are that other people riding on the former cycle track higher the
chances that car driver honk and even riskily overtake when I correctly
ride one meter left of the curb on the street.

Therefor everyone using this former cycle track is lifting the risk of
accidents and there are usually more than one reason why the signs where
removed.

All together I can understand others using

sidewalk:bicycle=yes

but would not tag it. Instead I usually add a note=* to tell others that
the signes where removed.

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

highway=*
sidewalk=sidepath

plus on both sides

highway=path
foot=designated
bicyles=yes
oneway=yes
path=sidewalk

 In all four cases there are in addition all the other tags like surface=;
 smoothness=; lit=

+1

sidewalk:surface=paving_stones
cycleway:surface=paving_stones

sidewalk:smoothness=good/intermittent
cycleway:smoothness=good/intermittent

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


Re: [Tagging] Feature Proposal - RFC - trailhead

2015-04-14 Thread fly
Am 14.04.2015 um 23:35 schrieb Bryce Nesbitt:
 On Tue, Apr 14, 2015 at 12:40 PM, fly lowfligh...@googlemail.com wrote:

 Why not map the amenity/features as own objects ?

 If it is important for the route relations I rather have a new role
 similar to guidepost for the starting/end node.
 
 I agree the toilet/parking/information sign should all be tagged separately.
 
 But there are cases where the trail-head has a given and well known NAME.
 So far I generally tag that on the parking area, but parking is not
 necessarily a requirement for having a trailhead.

Sounds like place=location then.

Cheers fly

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


Re: [Tagging] Feature Proposal - RFC - trailhead

2015-04-14 Thread fly
Am 14.04.2015 um 21:32 schrieb Bryce Nesbitt:
 +1
 I've long wanted a tag for trailheads,
 and they are commonly mapped on paper maps.
 
 However that said I've found the definition of trailhead to be slippery.

+1

 Is every road/trail/parking lot junction automaticaly trailhead?
 Or are we only talking about named trailheads?

Why not map the amenity/features as own objects ?

If it is important for the route relations I rather have a new role
similar to guidepost for the starting/end node.

cu fly

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


Re: [Tagging] Paintball

2015-04-14 Thread fly
Am 12.04.2015 um 18:01 schrieb Andreas Goss:
 Since most people here seem to agree on this and we also have
 sport=archery I created a wiki page:
 
 http://wiki.openstreetmap.org/wiki/Tag:sport%3Dpaintball
 
 Question is if we should to some retagging with shooting=paintball.

Yes, but with care. May be, even by contacting the previous author.
Otherwise we quickly end up with a mechanical edit.

Could you please add some information about leisure=pitch and
leisure=sports_centre on the paintball page. shooting and archery should
me present as link as well.

Cheers fly


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


Re: [Tagging] Feature Proposal - Voting - Reception Desk

2015-04-08 Thread fly
Am 08.04.2015 um 01:07 schrieb Warin:
 -fly
 Time? There are many proposals that are sitting around .. waiting on
 this 'time' thing.. years ... Why? The ones I have looked at are not
 changing .. nothing is happening with them - thus there looks to be no
 'development' while they sit and wait. This proposal is fairly simple -
 the addition of one simple value to an already existing key? Any
 implications ... no I don't think so, any developments over time ..
 again I don't see them.

So do you have problems to wait a half/full year ?
Lets see how your proposed tag is used.

Feel free to reactivate old proposals or even create the missing wiki
pages if usage seems to be established.

We always end up with the problem to proper document, first the proposal
and later the key and value pages. Though it is not always fun and can
be real work especially in a foreign language.

 Consensus .. that is what I'm aiming for. New rules or not.

+1 though there are cases where we have to state that we do not find a
consensus

 If your only voting on the tag (amenity=reception_desk) why are you
 commenting on the documentation? :-) ... That is a joke by the way.

Do not get me wrong. I vote by tagging and not on the proposal and if we
want to find a consensus I am happy with discussion on this list. There
are no veto but I can always post my concerns.

 I have 'improved' the documentation .. there is not much to say about a
 reception desk ... fortunately.

Yeah the final wiki page might even get shorter but the content counts.
We do not want to overwhelm the reader with information but need a clean
and distinguished description. The archived proposal is important to get
more information if in doubt.

cu fly

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


Re: [Tagging] New values for entrance=

2015-04-08 Thread fly
Am 07.04.2015 um 07:28 schrieb Bryce Nesbitt:
 On Mon, Apr 6, 2015 at 8:44 PM, johnw jo...@mac.com wrote:
 
 If it is truly a bad idea to create further entrance=* tags, then how to
 tag other kinds of various entrances (with tag combos) should be added to
 the entrance wiki so someone doesn’t just come and add a bunch of values
 w/o asking the tagging list.

How about some examples with access tags and/or opening_hours ?

 Sometimes you have to just run with what you've got.  Creating a whole new
 separate scheme creates it's own sort of mess, especially if done timidly.
 
 I encourage you to come up with a good, relatively non-overlapping set of
 entrance tags, and then
 define what happens if they need combining ( e.g.  entrance=student;visitor
 ? )

What is wrong with using access tags ?


 entrance=main
 entrance=staircase
 http://taginfo.openstreetmap.com/tags/entrance=staircase

Nice one with completely empty own wiki page in two languages [1].
Wonder which import or editor did promote this tag ?

 entrance=service
 entrance=student
 entrance=alternate

 The real tag pollution occurs when people tag too many types of entrances.
 Then the rendering becomes harmful,
 and the map guides you to an entrance you can't use.  But since that's
 inevitable, you need to provide tags that more focused rendering can ignore.

The map or the router ?
Sure you want to find the main entrance but access can be quite tricky
and entrance=student will lead to all kinds of other values, instead of
using access tags.

How about opening_hours ? Know many side entrances (entrance=yes) with
different opening_hours. Which maps shows this ?

Cheers fly

[1] https://wiki.openstreetmap.org/wiki/Tag%3Aentrance%3Dstaircase

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


Re: [Tagging] New values for entrance=

2015-04-08 Thread fly
Am 06.04.2015 um 23:45 schrieb Ilpo Järvinen:
 On Mon, 6 Apr 2015, fly wrote:
 
 Even entrance=staircase seems to be problematic as it overlaps with
 entrance=main and entrance=service.
 
 No it doesn't. The entrance is either entrance=staircase or 
 entrance=service so I see entrance=staircase as a sort of subclass
 of entrance=main. And BTW, the main condition backdoor that is used in 
 the comment of entrance=service pretty ambiguous to begin with. This is 
 especially true in many case with building=apartments doors leading to 
 staircases from both sides (this comes with an experience of pretty many 
 entrance=staircase nodes mapped) but this might of course somewhat depend 
 on country/area/suburb.

I was thinking about a building=apartments with one main entrance and a
backdoor both leading to the indoor staircase.

The backdoor might be open for everyone, leading to a private parking
with restricted access or even only leading into a private garden of one
single household.

Now when to use main, service, staircase or service.

If I go one step further and create a separate building:part=staircase
within the building=apartment the only true value for the front door
which fits for both is main and staircase is redudant.

cu fly


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


Re: [Tagging] Which entities use area=yes

2015-04-07 Thread fly
Am 07.04.2015 um 17:31 schrieb Dave F.:

 As I was tidying up some data in my locale I noticed area=yes sub tag on
 natural=wood which, AFAIK isn't required.

+1

 From memory the only two I know that can require it are railway=platform
  highway=pedestrian when drawn as closed ways. Are there any others 
 do other renderings have different rules regarding this?

railway=platform should not need it but renderer are sometimes dumb.

highway=service are often drawn as area and I have also seen
highway=path/footway

Another subject are aeroways=* though the last discussion ended in
preferring lines and have the renderer interpret width=*

There are some barriers like wall and retaining_wall (city_wall ? )
where an explicit area=yes makes sense.

In the end we could always use a multipolygon for areas where it might
make problems to distinguish between closed way but line and closed way
and area and could get rid of area=yes.

cu fly


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


Re: [Tagging] Which entities use area=yes

2015-04-07 Thread fly
Am 07.04.2015 um 18:39 schrieb Dave F.:
 Hi
 
 I thought it was required for platform as some were being drawn as a
 single line  as OSM has no specific closed polygon entity, renderers
 can't tell if it's an area to be filled or an extremely squiggly platform.

No problem with platform as way (line) but as closed way, really.
Wonder about platform building a ring but no area. All the the ones I
know at least have different ref=* and therefore need to be splitted.

Could you show us a real world example, please ?

 Ah, I forgot about aeroways. I'm surprised the conclusion was the width
 tag. With locations that have aerial imagery it's much more accurate to
 trace its width. Couldn't the renderers adapt to both? If it has area
 then fill it, if it has width render it as such.

Same problem as highway=*, you never know if a closed way tagged with
aeroway=taxiway is an area or a loop.

As far as I can judge a clean separation would be the best:

for highway and aeroway representing the area as area:highway=*
respectively area:aeroway=* and only tag ways with highway and aeroway.

Cheers fly

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


Re: [Tagging] Feature Proposal - Voting - Reception Desk

2015-04-05 Thread fly
Nice that you follow the new, unwritten rules.

Sorry, but I usually only vote by using the tag and not on the wiki,
still I would say, give it more time and improve the documentation as we
will need it anyway (both the tag and its docu).

Cheers fly


Am 01.04.2015 um 03:02 schrieb Warin:
 Hi,
 
 I have taken this back to the Draft status/stage.
 
 There is not much of a change to the basic proposal amenity=reception_desk.
 
 There is a much more verbose explanation of things .. like what key to use.
 
 Summary of voting ..
 
 Thank you all for voting. 38 votes is I hope a good representation.
 
 21 for
 
 17 against.
 
 Of those against;
 10 state it should not be an amenity key and most of those are for it
 being in the tourism key.
 My failing there for not explaining that it has applications to offices,
 industries and educational areas where tourism is not an appropriate key.
 
 1 says it needs more time.
 
 
 1 says it is not necessarily a desk.
 I have never come across one that was not a desk - telephone, public
 address system and sign in in all housed on a desk.
 
 2 (with another supportive comment from someone else) says it should
 embedded in 'the indoor tagging scheme'.
 The 'indoor tagging scheme'? That is going to have the same kind of
 problems with the tags for toilets, telephones, shops swimming pools,
 etc etc. The problem posed by this tag exists for many others and will
 need to be addressed by the indoor tagging system NOT by this tag
 alone.  The 'indoor tagging system' looks to be in evolution ... and
 will probably take some time before being generally accepted.
 
 How is reception desk shown to be part of another feature? By its
 location in most instances. It has also been suggest that a site
 relation could be used. The site relation looks to be in some state of
 'proposed'... I could not hazard a guess as to when it will progress
 onwards.
 (proposed) relation
 https://wiki.openstreetmap.org/wiki/Relations/Proposed/Provides_feature
 
 Also note the other proposal
 
 https://wiki.openstreetmap.org/wiki/Relations/Proposed/Cluster
 
 I don't see how the problem can be addressed by the simple value of the
 proposed reception_desk .. particularly as it is a problem/solution for
 other things too?
 
 
 
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging


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


Re: [Tagging] [OT] Licensing of information from websites

2015-03-31 Thread fly
Am 31.03.2015 um 13:59 schrieb Dan S:
 2015-03-31 12:51 GMT+01:00 Andrew Guertin andrew.guer...@uvm.edu:
 I wonder that nobody so far did spell out a warning about adding
 information from websites. The simple key website=* is ok, but every
 information like address, prizes and all the amenities is most of the
 time not usable due to license problems.

 cu fly


 I'm pushing this offtopic and this discussion should probably go to
 legal-talk (I've set reply-to there), but that paragraph does not match my
 understanding of copyright law (IANAL, etc.).

 My understanding is that a piece of information like an address or phone
 number is a fact and is ineligible for copyright protection. If the fact has
 been collected into a database, though, the database is in some countries
 eligible for protection under a separate form of IP.

 Thus if you go to a business' website to find their phone number and put it
 in OSM, everything is okay, but if you go to a phone book to find it, that's
 not okay and you could impact use of OSM in jurisdictions that have database
 protections.
 
 Andrew, you are correct. People who are concerned about licensing do
 forget this distinction sometimes. You've described it very well (the
 difference between copying a phone number and a phone book)

Ok, forget about the address and the phone number but how to handle all
other information like the availability of washing machines or the
cuisine of an restaurant ?

cu fly


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


Re: [Tagging] recommend tagging of volcanos as ways rather than nodes

2015-03-30 Thread fly
Am 30.03.2015 um 16:58 schrieb Janko Mihelić:
 In a broader sense, volcano is a mountain that appeared after a volcano
 blew up. The problem is, we don't yet have a way of mapping mountains.
 There was a suggestion to map a mountain by tagging mountain=xyz on all
 entities that define a mountain, that is peaks, ridges, mountain passes and
 such. Maybe we could use features mentioned by Richard Z.
 (geological=volcanic_lava_channel, geological=volcanic_caldera_rim) and
 give them all the same volcano=xyz tag.

+1

volcano and peak are both mountains and we do not have an area tagging
system for fuzzy areas.

Talk a look at e.g Hawaii and please tell me where the volcanoes start.
Somewhere below sea level ?

So far volcano should be mapped as node and everything else like crater
need an own tag.

cu fly


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


Re: [Tagging] Micro- and macromapping with area=*

2015-03-30 Thread fly
Am 30.03.2015 um 17:02 schrieb Daniel Koć:

In general area=yes/no is broken. Usually, there should not be a problem
to get the information from the object (type).

With some tags which are valid for closed (area) and unclosed ways we
have problems and the best we can do, is to define one solution as
default and mark the opposite with an additional tag (area=yes/no).

 Lately I was trying to rethink our general tagging schemes and came up
 with the impression that areas half-designed part of OSM tagging system.
 
 IMO we have 2 problems with it: small one in microscale and a big one in
 macroscale, but most probably we can deal with them separately.

Do not see that much differences to define several cases.

 ***
 
 In microscale we have some common uses of area=yes tag as area hint,
 like with highway=footway, highway=pedestrian or highway=service. But I
 think we also need some other like (a) highway=cycleway + area=yes or
 (b) highway=crossing + area=yes (both are quite easy to extend) and more
 complicated, but highly needed (c) street area scheme like in
 http://wiki.openstreetmap.org/wiki/Proposed_features/Street_area .
 
 We won't see the issue just looking at the taginfo usage statistics:
 
 http://taginfo.openstreetmap.org/tags/area=yes#combinations
 
 but it's easy to understand there's something wrong with having some
 popular area types being tagged and rendered as such, while some other
 are still considered just a point or a line. And it's not the future,
 it's already here at z19 (z18 is still rather fine) - for example some
 streets can be even 4 times wider than on default rendering (see the
 holes between footways and the streets at
 http://www.openstreetmap.org/#map=19/52.23171/21.02082 )!

Right the definition of highway is a complete mess. Would be much more
consistent to use area:highway=* for all areas and to render highway=*
only as lines with width=* or a default width.

 ***
 
 Macroscale is harder, because general hierarchy of tags is treated as
 given and I think we need to fix this hierarchy a bit. The problem is
 best visible when compared to buildings and I already wrote about it on
 Talk list, so let me quote relevant parts:
 
 That's what we have now (forgetting the buildings functions issue for a
 moment):

No, your definition is wrong, please, do not publish this as it does not
help to get the right definition in users' heads and it will not help
our problem as talking about broken examples is a fail.

 amenity=school  building=school
 landuse=religious  building=church
 landuse=industrial/man_made=works  building=industrial (?)
 
 and I see the pattern like this:
 
 area=school  building=school
 area=religious  building=church
 area=industrial/works  building=works
 
 Just area instead of amenity/landuse/man_made/... hell - isn't it
 easier and more elegant?

We do not need the definition of area in a tag, see above. It does not
give any extra information.

Additional, we do not always need landuse=* to define an area, so I
rather stick with amenity/man_made/natural/place_of_worship.

 You can spot a building and you know what the rules are:
 
 1. The key will be always building - not anything else (like house
 or architecture).
 2. If you don't know anything more about it, yes is safe, general
 value you can always choose (and if you know the form, you are welcome
 to choose something specific).
 
 What if we could have the same level of clearness for areas? For example
 natural=wood vs landuse=forest - you see the area covered with trees and:
 
 1. You are not sure what the key should be (is it maintained or not?).
 2. You have no safe general value, because wood implies natural key
 - but again: you may not know if it's really not maintained.

Once again, we do not need to define that it is an area as the object
already includes the information.

wood vs forest is an topic on its own and how about landcover=* ?

We have some problematic tags beyond highway=* like barrier=*wall where
we might still need area=* but this should be only a handful of tags.

Cheers fly

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


Re: [Tagging] Tagging method of amenities at camp_sites

2015-03-30 Thread fly
Am 30.03.2015 um 23:35 schrieb John F. Eldredge:
 It's about time that renderers started supporting semicolon-delimited lists. 
 Splitting apart a delimited string is a trivial programming task. I know, 
 having worked as a programmer for the last 29 years.

+1

cu fly


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


Re: [Tagging] Tagging method of amenities at camp_sites

2015-03-30 Thread fly
Am 29.03.2015 um 11:27 schrieb Bryce Nesbitt:
 On Sun, Mar 29, 2015 at 1:37 AM, Warin 61sundow...@gmail.com wrote:
 
 What if you do know details .. but not the exact location? Still place a
 node somewheres?

 
 How about at that point you go visit the site, and map based on that visit.
 
 OSM has a ten year history: have a look at existing convention.  This
 tagging list has only moderate influence
 on anything that happens in OSM-land.

+1

I wonder that nobody so far did spell out a warning about adding
information from websites. The simple key website=* is ok, but every
information like address, prizes and all the amenities is most of the
time not usable due to license problems.

cu fly


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


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

2015-03-28 Thread fly
Am 28.03.2015 um 13:24 schrieb Simon Poole:
 
 I have to say that this adds yet another value to the bicycle tag that
 doesn't solve any problems (note: if at all it naturally should be
 mandatory however that is not my primary concern).

+1

 We have bicycle=designated and bicycle=official for mandatory use
 cycleways (where the concept of such exists). official already tries
 to capture a nuance in a specific countries law that is lost on most
 (and probably doesn't exist in reality) trying to differentiate further
 doesn't make any sense (and we already have use_sidepath thrown in to
 the mix).

In Germany, community decided to use mostly *=designated for the blue
signs (mandatory). At least my *=official were almost completely changed
back to *=designated which might go along with the still outstanding
support of *=official in Mapnik-Carto.

On the other hand, I only use *=designated with the blue signs otherwise
only *=yes together with (motor_)vehicle=no.

Just had to point two other mappers to the wiki[1] the last week after
changing lots of

highway=path
bicycle=designated
foot=designated

to highway=cycleway

Cheers fly


[1] https://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dcycleway

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


Re: [Tagging] Historic tower

2015-03-24 Thread fly
start_date is more universal like using it for shops and amenities and
not only for buildings is possible.

You can use start_date with construction=*, too, it only vanishes after
the construction is finished.

Have no problem with construction:start_date=* but please use
comprehensive and clear tags.

Why not invent some more tags for constructions like buildings=* if useful.

cu fly

Am 23.03.2015 um 23:15 schrieb Warin:
 start_date ? start of planning?, construction? occupation?
 
 completion of planning? construction? occupation?
 
 built_data ... is fairly simple. I like simple and plain. It would need
 more words for structures that have several 'additions',
 'refurbishments', etc .. but the meaning is more apparent than
 start_date and completion_date.

  On 24/03/2015 8:43 AM, John F. Eldredge wrote:
 Wouldn't it make much more sense to use start_date for the starting
 date, and completion_date for the completion date?


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


Re: [Tagging] Proposal : Move smoking tag to active status

2015-03-23 Thread fly
Am 23.03.2015 um 08:35 schrieb Friedrich Volkmann:
 On 21.03.2015 01:54, Bryce Nesbitt wrote:
 Any objection to moving:
 http://wiki.openstreetmap.org/wiki/Proposed_features/Smoking
 because it is heavily used and obviously well established.

You are right my +1 was to fast.

 I object. The feature page should document actual usage, and actual usage
 differs from proposed usage.

+1

 smoking=outside is the second most common value
 and 15x more abundant than the proposed smoking:outside=yes. By the way, I
 find the proposed tag smoking:outside=separated ridiculous because you
 cannot separate air masses outside.

There might be different areas like front court and back court but as
these keys have only low numbers they should be only on the proposal page.

 The proposed keys smokefree=* (65 objects) and smoking_hours=* (14 objects)
 should also be removed from the feature page.

+1

cu fly

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


Re: [Tagging] Fuel shops

2015-03-23 Thread fly
Am 23.03.2015 um 07:02 schrieb johnw:
 
 On Mar 20, 2015, at 6:19 PM, Warin 61sundow...@gmail.com wrote:

 You can change it .. or make proposals here. Just don't change the existing 
 values and it should be fine.
 I'd think you'd be adding heating oils, propane and kerosene.
 
 
 The wiki entry is uneditable - I’ve edited quite a few wiki pages now, so I’m 
 used to going to the edit tab and seeing the text  markup in the text box to 
 edit, but  there’s only a snippet for the top of the page - the table is not 
 there to be edited (yes, I’m attempting to edit the whole page, so it should 
 be there). 
 
 I’ve never seen an error like this before. 

Please, always include a link.

Guess you are looking for the template page of fuel types [1].


By the way, thought we use operator=* instead of tenant=*. What is the
difference or is it something we need to clean up [2] ?  Does tenant=*
with only little more than 400 appearances according to taginfo [3]
really deserve an own wiki page [4] ?

Cheers fly


[1] https://wiki.openstreetmap.org/wiki/Template:Fuel_types
[2] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel#Names
[3] https://taginfo.openstreetmap.org/keys/?key=tenant
[4] https://wiki.openstreetmap.org/wiki/Key%3Atenant

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


Re: [Tagging] Accepted or rejected?

2015-03-23 Thread fly
Am 23.03.2015 um 09:53 schrieb Paul Johnson:
 On Wed, Mar 18, 2015 at 3:19 PM, Andreas Goss andi...@t-online.de wrote:
 
 It is amazing to see how few people participate in this discussion and
 vote compared to the number of mappers.


 STOP USING MAILINGLISTS!!!

 Those things might be nice for some tech savy people, but for everybody
 else it's just as mess and feels like spam.
 
 
 Are you from the past?  Email is the most basic service out there; don't
 expect it to go anywhere anytime soon.

+1

as long as there is no alternative for offline support we need email.

Please also have in mind the amount of traffic between plain text and html.

We did not talk about security issues and scripts, yet.

Cheers fly


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


Re: [Tagging] Deleting private objects in private spaces

2015-03-23 Thread fly
Am 22.03.2015 um 23:11 schrieb Warin:
 On 23/03/2015 1:20 AM, fly wrote:
 Am 17.03.2015 um 07:26 schrieb John Willis:
 There was a big bruhaha about any mappers mapping Israeli military
 installations. They were deleting everything and leaving notes not to
 map things on that location, if I remember correctly.

 I don't know the details, but I imagine that OSM might get blocked in
 certain countries if certain things are mapped, I dunno.
 So you need an own style for Israeli but no argument to exclude it for
 the rest of the world or in the data base.


 
 Personally I only map 'usefull' stuff.. stuff that the general public
 can use, or stuff that is usefull in an emergency.
 There is a lot to map that falls into this category that I'm not looking
 for stuff to map! Lots of roads in India for instance that are not mapped.
 
 I'll ignore military installations unless they are historic and
 sometimes open to the public.

It should be still up to each mapper to map what she/he likes to but why
should I deny someone to map all military and secrete service areas all
over the world.

Only because some government does not like it should not be a point to
stop mapping in OSM.

Anyway, where is the border ? Which government is good and which is bad.

cu fly


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


Re: [Tagging] Fuel shops

2015-03-23 Thread fly
Am 23.03.2015 um 15:33 schrieb Martin Koppenhoefer:
 2015-03-23 15:27 GMT+01:00 Stephan Knauss o...@stephans-server.de:
 
 The wiki describes operator=independent as he value has been used when
 exact details of the operator are not known, other than that they are a
 small independent firm.
 Sounds like that's exactly what we are looking for.

 http://wiki.openstreetmap.org/wiki/Tag:operator%3Dindependent

 
 
 no, I think he wants a tag that says: this petrol station is not
 associated with one of the big mineral oil companies. The proposed tag
 operator=independent is a hack by putting something different than an
 operator into the operator value, IMHO nothing we should encourage, and
 this information will be lost as soon as someone adds a proper operator to
 the POI.

Yeah, the value of operator is a string and there might exist some
person or brand/company call Independent.

There will be always an operator so operator=independent does not work
for two reasons.

We need an additional tag for independent fuel stations. This tag is
useful for several shops aswell.

chain_independent=yes ?

Sorry, my English is AE influenced and not my mother tong, so I have
some difficulties to find some proper words.

cu fly


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


Re: [Tagging] Feature Propsal - RFC - Generalized Overhead Wire Mapping - utility_wires=overhead/underground

2015-03-22 Thread fly
Am 18.03.2015 um 05:08 schrieb Bryce Nesbitt:
 In celebration of:
  http://wiki.openstreetmap.org/wiki/3D-mapland
 I offer to the tagging discussion:
 http://wiki.openstreetmap.org/wiki/Proposed_features/Quickly_Marking_Utility_Wires
 A proposal for quickly marking large areas with utility pole style.
 
 To be resolved are which streets within an area can be assumed to
 have overhead lines,
 if the area is marked with lines.

I can understand the intend of the proposal but I do not like it in the
current state.

1. If renderers do not nicely present mirco-mapped areas they need to be
fixed and may be also the current tagging system to better present
differences.

2. do not use it for areas but only for streets as areas are more
difficult to evaluate and once on street is differently equipped you
will get conflicts between street and area

3. I would always consider this kind of tagging as an intermediate state
before micro-mapping. Thus once the utility is mapped as own object the
tag on the street should not be used anymore. Please, avoid duplications
in the data.

cu fly

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


Re: [Tagging] Proposal : Move smoking tag to active status

2015-03-22 Thread fly
Am 21.03.2015 um 18:43 schrieb Martin Koppenhoefer:
 Am 21.03.2015 um 08:54 schrieb Michael Reichert naka...@gmx.net:

 I agree. Because it is used on 47541 objects at OSM all over the world,
 it's best to move the page to Key:smoking.
 
 +1

+1 but please copy and archive the proposal

fly


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


Re: [Tagging] Fuel shops

2015-03-22 Thread fly
Am 19.03.2015 um 17:43 schrieb Martin Koppenhoefer:
 2015-03-19 17:12 GMT+01:00 fly lowfligh...@googlemail.com:
 
 brand=none or
 no_brand=yes to proper mark the independence.

 some independent petrol stations are organized in associations and use
 these as their brand, see e.g. here:
 http://de.wikipedia.org/wiki/Bundesverband_freier_Tankstellen
 not being part of a mineral oil corporation doesn't necessarily mean you
 don't use a brand name.

So, we need an additional tag for independent shops/petrol stations as
brand=* and operator=* might be already used.

Do we need company_chain=* or does independent=yes work ?

cu

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


Re: [Tagging] Deleting private objects in private spaces

2015-03-22 Thread fly
Am 17.03.2015 um 07:26 schrieb John Willis:

 On Mar 17, 2015, at 3:17 PM, Mateusz Konieczny matkoni...@gmail.com wrote:

 AKA military installations in certain countries I would happily map 
 military installation in Russia/North Korea/Iran/USA/whatever -
 it is not illegal for me. Maybe they can make laws making it illegal for 
 their citizens to do this, but is it changing anything for me?
 
 There was a big bruhaha about any mappers mapping Israeli military 
 installations. They were deleting everything and leaving notes not to map 
 things on that location, if I remember correctly. 
 
 I don't know the details, but I imagine that OSM might get blocked in certain 
 countries if certain things are mapped, I dunno. 

So you need an own style for Israeli but no argument to exclude it for
the rest of the world or in the data base.

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


Re: [Tagging] Historic tower

2015-03-22 Thread fly
Am 21.03.2015 um 07:43 schrieb Marc Gemis:
 On Fri, Mar 20, 2015 at 11:54 PM, Warin 61sundow...@gmail.com wrote:
 
 But perhaps it would be more universal to have

 built_date=1200 AD

 
 I always thought start_date was used for that.

+1

but how to handle buildings which where finished after two/three centuries ?

cu fly


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


Re: [Tagging] Different definition of role forward/backward

2015-03-19 Thread fly
No one out there interested in this ?
Any comments, please.

cu

Am 14.03.2015 um 18:47 schrieb fly:

 For years the definitions about role forward/backward are completely
 different on the wiki page about route=road [1] versus the page about
 route relations (type=route) [2].
 
 While all other route=* seem to follow the updated role definition that
 the role depends on whether the route follows the directions of the way
 (forward) or not (backward), the route=road still uses forward/backward
 for the route direction only not regarding the direction of the way.
 
 Does the wiki reflect the usage ?
 
 These two different definitions makes the whole concept even more
 complicated for users and software.
 
 Can we change/adjust route=road to follow the same definition as all
 other routes ?
 
 Cheers fly
 
 
 [1] https://wiki.openstreetmap.org/wiki/Tag:route=road
 [2] https://wiki.openstreetmap.org/wiki/Relation:route#Members
 


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


Re: [Tagging] Fuel shops

2015-03-19 Thread fly
I see no problem with amenity or shop as long as the description on the
wiki is well done. It is an amenity no doubt but we need proper subtags
for the vehicles and the amount.

shop=fuel was mentioned on a different thread about companies which fill
up your private diesel or gas tanks for heating, so we always have to
distinguish between small and big suppliers.

operator=independent is similar to highway=living_street an easter egg.
The operator is still some judicial person and we need brand=none or
no_brand=yes to proper mark the independence.

cu fly

Am 19.03.2015 um 15:25 schrieb Jan van Bekkum:
 +1
 
 The last thin I want is to count on a regular filling station and to and up
 at a bottle store with my 4WD. A that will happen if the type of store is
 an attribute, as map makers will show them the same. So please make it a
 different value for the tag, not fuel.
 
 On Thu, Mar 19, 2015 at 3:11 PM Stephan Knauss o...@stephans-server.de
 wrote:
 
 On 19.03.2015 20:31, p...@trigpoint.me.uk wrote:
 However I can see nothing wrong with amenity=fuel, that is what it is in
 that part of the world . What turns amenity=fuel into a regular filling
 station is the building=roof.

 There is a huge difference. You'll notice that if you end up with your
 Diesel pickup in front of a amenity=fuel shelf out of Whiskey bottles
 filled with gasoline. The quantity is even too small to substantially
 fill up a car.

 Those pumps from a barrel are fine for a car. We used them recently on a
 trip near Doi Inthanon. Filling up 500 Baht of Diesel was no issue at all.

 There is operator=independent.
 I suggest this along with amenity=fuel for everything which is suitable
 for filling up a car or small truck/pickup.

 This is to differentiate from big brands like PTT which usually also
 come with a convenience store/coffee shop.

 Vending machines selling petrol for cars also fine.

 The problem are vending machines only serving for motorbikes and those
 bottle-shops.
 I would like to avoid them being amenity=fuel as it is hard to convince
 every western map-maker to query additional tags before deciding how to
 render them. That tag is already too established without extra tags.



___
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 fly
Am 18.03.2015 um 09:26 schrieb Warin:
 On 18/03/2015 5:02 PM, Marc Gemis wrote:

 On Tue, Mar 17, 2015 at 9:42 PM, Bryce Nesbitt bry...@obviously.com
 mailto:bry...@obviously.comwrote:

 A separate debate is how to increase voting participation.  making
 pending votes more visible in the editing tools could help.


 Just some idea:
 Translate the proposal in German, French, Spanish and Russian, ...
 (the largest communities outside the English speaking countries)
 Let people vote and discuss in their own language. Sum up the votes
 from the different pages.

-1

 It is a good idea.
 The main problem is that an issue in one place may have been resoled in
 another. So there may need to be some cross flow between the discussions
 when required/requested?
 
 The secondary issue is the translation. I'm afraid I'd be using one of
 those computer translators to do it .. thus there will be some amusement
 .. not a bad thing .. it can be cleaned up once done.

+1

 Not everyone is willing/capable to discuss in a foreign language.
 
 Yep. And thus OSM misses out on probably some very good ideas.
 And this may well encourage others to make more tags.

So, we need some mediators to help to break the language barrier. People
willing to help with English or even take over ideas and make proposals.

I could understand if a proposal is first written in a language
different than English and later translated into English but the wiki
itself needs lots of work on much more important pages than translating
proposals in multiple languages.


One thing for creators of proposals which are not voted on and everybody
else would be to make the transfer to an official wiki page once the tag
is in major use. Then translation can start.

cu fly


___
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 fly
Am 18.03.2015 um 12:55 schrieb Martin Vonwald:
 2015-03-18 12:47 GMT+01:00 Markus Lindholm markus.lindh...@gmail.com:
 
 A thought, how difficult would it be to include in the wiki-page how
 many different mappers have actually used a specific tag. Perhaps via
 TagInfo.

 
 
 This in fact would be a very helpful information! Although - please
 everyone correct me if I'm wrong - the numbers from taginfo are not what we
 want: as far as I know, taginfo shows the number of mappers, that added or
 changed(!) an object with a given tag. Much more meaningful would be the
 number of mappers, that actually added a specific tag. This is much harder
 to determine and even this number would be biased, because of way-splits.

Exactly, you need to use more of the history, as how do you tread
replaced objects like node - area ?

The first author of an object does not have to be the one who introduced
the tag.

Seems to be really complex.

Cheers fly


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


[Tagging] Different definition of role forward/backward

2015-03-14 Thread fly
Hey

For years the definitions about role forward/backward are completely
different on the wiki page about route=road [1] versus the page about
route relations (type=route) [2].

While all other route=* seem to follow the updated role definition that
the role depends on whether the route follows the directions of the way
(forward) or not (backward), the route=road still uses forward/backward
for the route direction only not regarding the direction of the way.

Does the wiki reflect the usage ?

These two different definitions makes the whole concept even more
complicated for users and software.

Can we change/adjust route=road to follow the same definition as all
other routes ?

Cheers fly


[1] https://wiki.openstreetmap.org/wiki/Tag:route=road
[2] https://wiki.openstreetmap.org/wiki/Relation:route#Members

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


Re: [Tagging] Blatant tagging for the renderer: bridges abandoned railways

2015-03-09 Thread fly
Am 09.03.2015 um 15:27 schrieb Michael Reichert:
 Hi ael,
 
 Am 2015-03-09 um 15:22 schrieb ael:
 I have resorted to changing railway=abandoned to railway=disused
 on several occasions just to get mapnik and friends to render 
 bridges. Bridges over roads and rivers are major features of relevance
 to tall vehicles and boats, so really should show up on standard
 rendering.

 According to the wiki railway=abandoned applies when the rails have been
 removed, and disused should be used when the rails are still present.

 Not suprisingly this has been raised before, as for instance at
 http://wiki.openstreetmap.org/wiki/Talk:Railways.

 I don't like tagging for the renderer and normally avoid it, but in this
 case it seems to be necessary to maintain the reputation of OSM/mapnik.
 
 Would you please change this back?! There also other maps using OSM data
 which rely on good and exact tagging!
 http://openrailwaymap.org
 
 There is no reason to increase the reputation of OSM-Carto. If it
 renders bad images, they bad and the stylesheet has to be fixed, not the
 data!

+1

Still miss support for man_made=bridge which leads to mapping for the
renderer as user add highway=* + area=yes to the area to get it rendered.

cu fly


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


Re: [Tagging] route=foot

2015-03-08 Thread fly
In my area, the symbols and corresponding network are the same despite
leading across completely paved tracks or following small, steep and
muddy paths.

How would you describe the differences and how do you handle mixed cases ?

All the attributes can be obtained from the tags of the ways and the
distance and time completely subjective as you can simply walk some
metres along a iwn.

Ok, despite the value hiking I would prefer to group all
walking/hiking routes and have a different value or at least additional
tags in combination with route=foot for city (tourist) walks.

The outcome needs to be added to the wiki as the is non for route=foot
ATM and we need to evaluate the use-cases in advance.

cu fly

Am 04.03.2015 um 04:48 schrieb Steve Bennett:
 Huh. And here in Australia (well, at least amongst the people I know) the
 difference between a hike and any other form of walking is strictly
 whether it's more than one day. A daywalk is, well, a day or less, and a
 hike is two or more days.
 
 But that doesn't cause me any concerns using route=hiking.
 
 On Mon, Mar 2, 2015 at 11:37 PM, Philip Barnes p...@trigpoint.me.uk wrote:
 
 On Mon, 2015-03-02 at 13:06 +0100, Marc Gemis wrote:
 In Belgium and The Netherlands we have tagged all the regional walking
 networks as foot. With this system of walking networks it is possible
 to plan walks as short as 2-3 km and and long as a few hundred
 kilometers. For me the short walks are no hikes, but that might be the
 wrong interpretation.


 We had some discussion about this (foot vs hiking) a few years ago. We
 decided to stay with foot because that was used in The Netherlands and
 Germany. And because some of those networks cross the border, it did
 look appropriate to change it only in Belgium.

 In UK English, the language of OSM, hike has extreme connotations.
 Hiking implies a route over extreme ground and a forced high pace. If I
 was to describe one of my ramblers walks as 'a hike' I would not get
 many takers.

 US English uses the term hike to describe a walk in the countryside,
 which is the usage I suspect Fly is using.

 Having done a Overpass Turbo query on route=foot locally, it returns the
 Shropshire Way and Severn Way. I would not use the term hike to describe
 either, route=foot is absolutely appropriate.

 Phil (trigpoint)


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


Re: [Tagging] route=foot

2015-03-01 Thread fly
Am 01.03.2015 um 22:04 schrieb SomeoneElse:
 On 01/03/2015 20:17, fly wrote:
 Wait a minute, out of the 25,000 over 21,000 have a network=* which
 leads me to the assumption that most should be tagged route=hiking.
 
 What makes you think that?

Come on, just have a look at the numbers [1],

15,581 + 5,700  21,000

fly

[1] https://taginfo.openstreetmap.org/tags/route=foot#combinations



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


Re: [Tagging] route=foot

2015-03-01 Thread fly
Am 01.03.2015 um 23:11 schrieb SomeoneElse:
 On 01/03/2015 21:48, fly wrote:
 Am 01.03.2015 um 22:04 schrieb SomeoneElse:
 On 01/03/2015 20:17, fly wrote:
 Wait a minute, out of the 25,000 over 21,000 have a network=* which
 leads me to the assumption that most should be tagged route=hiking.
 What makes you think that?
 Come on, just have a look at the numbers [1],

 15,581 + 5,700  21,000

 fly

 [1] https://taginfo.openstreetmap.org/tags/route=foot#combinations
 
 Could you explain what you're trying to say here with more words?  I
 really don't understand what you're getting at here at all.

I just say, that out of the 25,000 objects tagged with route=foot over
21,000 have been tagged either network=lwn or network=rwn and would be
better tagged route=hiking as that is the route type for hiking routes.

In general, I do not like route=foot but I sustain the description on
the German wiki page and the little passage at the beginning of the
second table on the English wiki page of route=hiking.

Better ?




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


Re: [Tagging] Feature Proposal - RFC - parking=storage: additional values for key parking

2015-03-01 Thread fly
Am 01.03.2015 um 16:46 schrieb Jan van Bekkum:
 I have adapted the proposal to reflect the results of this discussion.

As long as there is not category for service-businesses I would use
amenity=vehicle_storage as this is no shop but a service and
shop=storage sounds like a super category for
shop=bags;suite-case;cartoon-box.

cu fly


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


Re: [Tagging] route=foot

2015-03-01 Thread fly
Am 01.03.2015 um 19:47 schrieb SomeoneElse:
 On 01/03/2015 17:43, fly wrote:
 Is route=foot really the tag we want to use for walking routes and city
 tours ?
 
 There are 25,000 of the things out there - it's not exactly some niche
 tagging:
 
 http://taginfo.openstreetmap.org/tags/route=foot
 
 I've used foot in the UK for routes that aren't really hiking (but
 aren't necessarily city walking tours either).  People choose whatever
 seems best to them at the time, and the usage of foot seems to
 suggest that a lot of people think that it is appropriate.

Wait a minute, out of the 25,000 over 21,000 have a network=* which
leads me to the assumption that most should be tagged route=hiking.

It is never to late to fix mistakes from the past.

cu fly

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


Re: [Tagging] tagging very wide steps - highway=steps on an area?

2015-02-27 Thread fly
Am 27.02.2015 um 16:56 schrieb Martin Koppenhoefer:
 2015-02-27 16:36 GMT+01:00 fly lowfligh...@googlemail.com:
 
 I think the easiest way to represent several upper and lower is to model
 several stairs, one for each upper+lower combo. This can happen for
 example
 when there are blocks in the middle of the stairs.

 Do I really need one relation for every step ?
 
 no, not for every step, for every part of stairs delimited by landings
 (German: Podest / Zwischenpodest)

I understand that but I have still the problem with my stairs. Did you
take a look at the pictures ? (Sorry, not the best ones).

Problem is that on one side there is a sloped road and steps get fewer
and fewer until the last two end. Aditionally one the top there were two
steps which had an own shape and only some part in common direction with
the other steps.

cu fly

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


Re: [Tagging] tagging very wide steps - highway=steps on an area?

2015-02-27 Thread fly
Am 27.02.2015 um 12:09 schrieb Martin Koppenhoefer:
 2015-02-27 9:07 GMT+01:00 johnw jo...@mac.com:
 
  I read the wiki entry on steps (
 http://wiki.openstreetmap.org/wiki/Tag:highway%3Dsteps
 http://wiki.openstreetmap.org/wiki/Tag:highway=steps) and the
 discussion page,

 and besides the discussion on which direction means uphill (that really
 needs to be decided),
 
 I had assumed for years that the direction pointing upwards was a commonly
 agreed on standard, being myself an architect I hadn't expected this to be
 questionable, but as I got so much flak from people insisting on the other
 way round, I now am adding the tag incline=up to all steps. This way you
 remove any ambiguity and introduce some further stability also for cases
 where the way direction gets inverted. No need for any (IMHO unachievable)
 decision any more ;-)

I usually take care that the way points uphill and add incline=up.

 can I use steps to define an area, just like highway=pedestrian?
 
 There is the area relation proposal which deals explicitly with this
 (type=area), but it isn't supported by any data consumer AFAIK.
 Please note that you have to create a new relation for every continuous
 part of stairs (i.e. the stair landings are not included).
 http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area#Area-steps.2C_steps_which_are_wide_and.2For_irregular
 
 Might sound complicated but it is actually quite easy to model:
 
 1. create an empty relation and add the tags:
 type=area
 highway=steps
 (and more like step_count, surface, etc.)
 
 2. draw the upper delimiting way of the steps (border where the last riser
 is) and add it with the role upper to the relation
 
 3. draw the lower delimiting way (border where the first riser is) and add
 it with the role lower to the relation
 
 done.
 
 if you want you can
 
 4. draw the lateral boundaries and add them with the role lateral to the
 relation (suggested for non-linear lateral boundaries only).

+1

Though, I am not sure how to model steps with fading steps to one or
both sides and several upper or lower

There is also:

https://wiki.openstreetmap.org/wiki/User:Marek_kleciak/Stairs_modelling

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


Re: [Tagging] tagging very wide steps - highway=steps on an area?

2015-02-27 Thread fly
Am 27.02.2015 um 16:16 schrieb Martin Koppenhoefer:
 2015-02-27 14:24 GMT+01:00 fly lowfligh...@googlemail.com:
 
 Though, I am not sure how to model steps with fading steps to one or
 both sides and several upper or lower
 
 I am not sure if I understand fading steps correctly. Usually I'd say
 that the single step is there as long as there is any kind of riser (in
 German the term is Steigung, see http://www.vbg.de/apl/zh/z113/8.gif for
 reference). I imagine you intend with fading that the riser will get
 smaller along the single step until it reaches zero. That zero point is the
 end of the stairs and if these ends of the single steps of one stair are
 not in a line you'll have to model also a lateral way (typically they are
 in line).

Well have a look:
https://upload.wikimedia.org/wikipedia/commons/9/9b/Augustinerplatz_%28Freiburg_im_Breisgau%29_5340.jpg
http://ais.badische-zeitung.de/piece/02/88/16/82/42473090.jpg

 I think the easiest way to represent several upper and lower is to model
 several stairs, one for each upper+lower combo. This can happen for example
 when there are blocks in the middle of the stairs.

Do I really need one relation for every step ?

 Here is a reference picture of one of the most famous stairs outdoors:
 http://de.wikipedia.org/wiki/Liste_bekannter_Treppen#mediaviewer/File:Spanische-Treppe.jpg
 To model the lower main part (between the lateral walls and until the 2
 dominant street lights) you'll need 9 relations: 3 times (left, middle,
 right) 3 parts of stairs (the former divided by 2 landings). I suggest to
 model the landings as highway=pedestrian, area=yes.

Well, go for it.

Cheers fly

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


Re: [Tagging] Breakdown bays?

2015-02-27 Thread fly
Did sleep one night and now think we should include bays and lanes
within the lanes:-Tagging

lanes=3
lanes:forward=2
lanes:backward=1
access:lanes:forward=yes|yes|emergency
access:lanes:backward=yes|emergency

All together I am not happy with the description of lanes=* and
lanes:*=* anymore. Where is it useful as we already do not count bicycle
lanes but do count exclusive bus or taxi lanes and even ones with access
forbidden but wide enough for motorized vehicles.

Would prefer to change lanes=* and lanes:*=* to be the numbers with
general access allowed and adding all additional lanes with access:lanes:

lanes=2
lanes:forward=1
lanes:backward=1
access:lanes:forward=yes|no|no
access:lanes:backward=yes|no
bicycle:lanes:forward=yes|designated|no
bicycle:lanes:backward=yes|yes
bus:lanes:forward=yes|no|designated
bus:lanes:backward=yes|designated
taxi:lanes:backward=yes|yes
width:lanes:forward=3|1.5|2.5
width:lanes:backward=3|3

Would be a road with forward a normal lane, a bicycle lane and either
bus bay or bus lane (depending on length) and backward a normal lane and
a bus lane with bicycle and taxi allowed.

Am 26.02.2015 um 09:04 schrieb Martin Vonwald:
 2015-02-25 16:52 GMT+01:00 fly lowfligh...@googlemail.com:
 
 Well, emergency=bay might interfere with access tagging and we should
 probably use left/right as you will find them not only on dual carriage
 roads.

 emergency_bay=both/left/right ?

 
 That seems reasonable to me. 
 
 How do we tag emergency lanes ?

 
 I asked that some time ago, but afaik there's no solution (yet).



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


Re: [Tagging] Super-keys are evil

2015-02-25 Thread fly
Though, I have to admit that introducing new categories nor moving tags
from one to another is not easy and often bricks, like osm-carto will
not support it for quite some time, are through between your legs.

Still in favour of introducing some more categories.

cu fly

Am 24.02.2015 um 20:02 schrieb Frederik Ramm:

 On 02/23/2015 02:43 AM, Kurt Blunt wrote:
 Right now, tags serve two distinct purposes. There are attribute tags
 like name=Wall Street, and there are category tags like
 amenity=parking or aeroway=helipad. 
 
 This works for many things but not all; the border can be blurred. You
 will not be able to fit every key into your category or attribute schema.
 
 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.
 
 And if you travel along a dark track in the night then you might be
 robbed by a highwayman.
 
 A contributor is left to feel like
 an idiot for not understanding the logic behind this system.
 
 Woe betide all who mistake highway=unclasssified for a street that lacks
 classification.
 
 For these reasons, I believe there is a case to be made for an
 overhaul of category tags. My personal opinion is that we should get
 rid of super-keys altogether and instead promote all categories to
 keys with empty values: 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.
 
 And power=line becomes line= and barrier=line becomes, uh, wait a minute.
 
 It is not so simple, even leaving aside the fact that many programs
 would simply dismiss your empty values.
 
 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 in theory what you call super keys is a good thing to
 have because it gives you a layered level of understanding. For example,
 if someone tags
 
 natural=water
 water=lake
 lake=turlough
 
 then you have a chance to understand this is a natural feature (and
 not man-made) even if you don't know what a lake is; you can understand
 this is a lake (and not a reservoir) even if you don't know what a
 turlough is; or you're so much into water bodies that you can actually
 understand the full message.
 
 If the tag was instead the space-saving
 
 turlough=
 
 then you'd be stumped without recourse to the giant tag dictionary that
 explains to your renderer that something tagged turlough= should
 perhaps be drawn in a blue-ish colour.
 
 Matter in a nutshell: Certainly the way we use these super tags has a
 lot of historical baggage but I don't think it is a stupid idea per se,
 *especially* if your goal is (like you're claiming yours to be) making
 tags easy for mappers.


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


Re: [Tagging] Breakdown bays?

2015-02-25 Thread fly
Am 25.02.2015 um 16:19 schrieb Martin Vonwald:
 Hm...had a quick look how they are tagged and I'm not really convinced.
 They are tagged as area beside the road (without any connection) or as
 individual roads. In my opinion both does not fit well :-/

So what do you have in mind ? Tagging them as additional tag on the way
with highway=*? Using lanes:-Tagging ?

I use lanes:-Tagging for bus_bays by the way.

cu fly

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


Re: [Tagging] Breakdown bays?

2015-02-25 Thread fly
Am 25.02.2015 um 16:41 schrieb Martin Vonwald:
 2015-02-25 16:34 GMT+01:00 fly lowfligh...@googlemail.com:
 
 So what do you have in mind ? Tagging them as additional tag on the way
 with highway=*? Using lanes:-Tagging ?

 
 I don't think of them as lanes, so I wouldn't use some :lanes-tag. I
 thought that there is already a tag, that I simply put on the road for the
 length of the bay - just like e.g. sidewalk=right. But that's obviously not
 the case and it is not possible with highway=emergency_bay.

Well, emergency=bay might interfere with access tagging and we should
probably use left/right as you will find them not only on dual carriage
roads.

emergency_bay=both/left/right ?

 When tagged as node I lose the length. Tagging as separate way seem
 counter-intuitive - there is no separate road. Tagging as area seems...
 strange ;-)

+1

How do we tag emergency lanes ?

At least in cases of lanes the position of the phone is also important.

Cheers fly

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


Re: [Tagging] tag for portages?

2015-02-23 Thread fly
Am 22.02.2015 um 23:26 schrieb John F. Eldredge:
 I think the wooden portages he refers to are a series of wooden
 rollers one would roll the canoe along, to avoid having to carry the
 full weight.

Exactly, sorry for misunderstanding.

Please, forget my suggestions, as I was talking about additional
features, like some wooden construction to drag the canoe along. Often
it works on the grass, too, but we do not have grass everywhere.

Cheers fly


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


Re: [Tagging] tag for portages?

2015-02-22 Thread fly
How about adding the side ?

portage=left/right/both
portage:left=*

Are there any major differences in construction/use ?
I know wooden portages but there might be other material.

Any thoughts how to deal with mircromapping, e.g. adding the portage as
own object next to a path. What tags should remain on the highway ?

Cheers fly

Am 22.02.2015 um 15:25 schrieb Brad Neuhauser:
 Thanks for the feedback! portage=* was my initial instinct, but I was
 starting to second guess after finding the other tags. Cheers, Brad
 
 On Sat, Feb 21, 2015 at 10:46 PM, Bryce Nesbitt bry...@obviously.com
 wrote:
 
 This seems like a good place for highway=path + portage=yes
 Because these are definitely still paths (and sometimes coincident with a
 land based path).

 whitewater=portage_way seems overly specific, as does canoe=portage.



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


[Tagging] restricted *way=* with additional access

2015-02-20 Thread fly
Am 19.02.2015 um 18:05 schrieb 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.

Well, I was gonna to ask how to tag mixed foot+bicycle pathes which
allow private vehicle access

highway=path
bicycle=designated
foot=designated
vehicle=private

or pedestrian streets which allow taxi and delivery some time a day/week

highway=pedestrian
bicycle:conditional= yes @ (Mo-Sa 00:00-06:00,21:00-24:00, Su,PH)
taxi=yes
vehicle= delivery @ (Mo-Sa 05:00-16:00; PH off)

Which routing software is actually using all these tags ?

cu fly

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


Re: [Tagging] Deprecating aerialway=goods

2015-02-18 Thread fly
Am 18.02.2015 um 14:36 schrieb Richard Z.:

 suggest deprecating this particular value of aerialway as there are
 much better ways to map industrial/freight lines with usage=* and 
 foot=* type restrictions.
 
 The new description is already in:
 
 http://wiki.openstreetmap.org/wiki/Key:aerialway#Usage

+1

 discussion:
 http://wiki.openstreetmap.org/wiki/Talk:Key:aerialway#Obsoleting_aerialway.3Dgoods


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


Re: [Tagging] high mobile masts on man_made=mast

2015-02-17 Thread fly
Am 17.02.2015 um 01:07 schrieb Warin:
 On 16/02/2015 11:33 PM, fly wrote:
 Be careful some mast as support for wind generators might be entered.

 Thought antenna vs mast might be a problem but not mast vs tower.


Should have added some picture. Please have a look at the pictures on
[1] and [2]:

 
 An antenna is not a mast nor a tower, just as a wind generator is not a
 mast nor a tower. They may be mounted on top of a mast of tower .. but
 they are not towers nor masts themselves.

Never said that a antenna nor a wind generator are masts or towers but
if you want to tag the support=* we sill need to distinguish.


 -
 I like the easy distinction between mast and tower by the guy wires. If
 it is technically correct ..

-1

 Some structures (masts?) supported by guy wires, have internal ladders
 .. for maintenance of the supported item.

+1

Is there any difference considering the foundation of the structure ?
Towers usually have one and mast not ?

Cheers fly


[1] https://de.wikipedia.org/wiki/Selbststrahlender_Sendemast
[2] https://en.wikipedia.org/wiki/Mast_radiator

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


Re: [Tagging] RFC aerialway=zip line

2015-02-17 Thread fly
Am 17.02.2015 um 12:59 schrieb Richard Z.:
 Hi,
 
 RFC for aerialway=zip line is opened:

This was a typo. True is aerialway=zip_line.

 https://wiki.openstreetmap.org/wiki/Proposed_feature/aerialway%3Dzip_line

Would not include the zip_line on playgrounds as playground=zipwire
[1][2] is already in use and there seem to be some differences between a
playground feature and aerialways.

Otherwise you need to deprecate playground=zipwire.

cu fly

[1] https://wiki.openstreetmap.org/wiki/Key:playground
[2] https://taginfo.openstreetmap.org/tags/playground=zipwire


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


Re: [Tagging] Change of rendering: place of worship and, terminal without building tag

2015-02-17 Thread fly
Am 17.02.2015 um 22:02 schrieb Andreas Goss:
 Having a landuse for “religion” seems simple to understand
 
 Oh really? Is every Kindergarden run by the chruch in Bavaria now a
 landuse=religious? What about office building run by the church? What if
 they overlap with other landuses?
 
 If people really continute to use this tag I will use it for everything
 run by the chatholic church in Germany, after all they are the largest
 private land owner... Then they can have fun with their church yards.

I still do not understand, why we can not use religion=* without any
landuse.

As far as I understand there can be only one landuse but neither the
proposal nor the wiki page really faces the problem especially regarding
deprecating other landuse like cemetery without offering a replacement.

cu fly


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


Re: [Tagging] Change of rendering: place of worship and, terminal without building tag

2015-02-17 Thread fly
Am 17.02.2015 um 22:40 schrieb Tom Pfeifer:
 Andreas Goss wrote on 2015-02-17 22:02:
 If people really continute to use this tag I will use it for everything
 run by the chatholic church in Germany, after all they are the largest
 private land owner... Then they can have fun with their church yards.
 
 the tag is about land_use_, not land_ownership_
 AFAIK we do not want to tag ownership in OSM.

and religious is no land use, exactly.

 fly wrote on 2015-02-17 22:14:
 I still do not understand, why we can not use religion=* without any
 landuse.
 
 on which area description?

I have no problem to additionally add amenity=place_of_worship or
appropriate tag to the area. The same is true for supermarket with there
own area including parking. No problem to tag the whole area
shop=supermarket. For buildings we have building=*.

Maybe we just lack of a proper tag to describe the area but
landuse=religious is a poor answer.

Anyway, we probably need more of the primary tags anyway as people look
at things from different perspectives and we already have the same
scenario with landuse=forest vs natural=woods vs land_cover=tree.

 As far as I understand there can be only one landuse but neither the
 proposal nor the wiki page really faces the problem especially regarding
 deprecating other landuse like cemetery without offering a replacement.
 
 it is probably for historic reasons that cemetery slipped into the
 landuse category. It would be logical to migrate it to amenities, such
 as graveyard.

I understand landuse=cementry as a land use but not religious. Anyway we
are using amenity=hospital for the whole area without any use of landuse.

Cheers


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


Re: [Tagging] high mobile masts on man_made=mast

2015-02-16 Thread fly
Am 16.02.2015 um 11:32 schrieb Martin Koppenhoefer:
 2015-02-16 4:25 GMT+01:00 Dave Swarthout daveswarth...@gmail.com:
 
 On Mon, Feb 16, 2015 at 4:23 AM, Martin Koppenhoefer 
 dieterdre...@gmail.com wrote:

 I've been taught that a mast is usually not self supporting, ie. has
 guy wires while a tower is self supporting.

 +1

-1
Usually depends on the construction and height.

 Also, the wiki definition needs changing IMO. Maybe they meant to say, a
 few meters in diameter.


+1
We have height=*.

How to we define the difference between mast and pole ?
Do we need support=mast ?

 
 Thing is that in German we have (slightly) different usage of these terms,
 there are the words
 
 - Turm (tower in some cases): typically something accessible by humans
 (with stairs, not just a ladder), if its masonry it will always be a
 Turm, while steel lattice could be either, but for power towers, these
 will never be called Turm in German but Mast
 
 - Mast something not accessible (except maintenance by technicians,
 typically no stairs but just a ladder), can be guy wired, but doesn't have
 to (used e.g. for most technical installations like support for antennas,
 street lamps (i.e. also cases where English uses the words pole, pylon
 or rod), ships, flags, telco wires, power towers, ...
 
 de:Mast is always something tall and thin, while de:Turm is always
 accessible, but can also be not very high (e.g. defensive towers of ancient
 fortifications in some cases).
 
 The current definition in the wiki almost reflects this German usage 100%
 (no wonder, apparently written by a German), but not completely because
 there are very high guy wired structures like antennas, e.g. this one would
 be called Mast in German:
 http://en.wikipedia.org/wiki/KVLY-TV_mast
 
 I think the main difference is that a Mast cannot be entered, while a
 Turm is intended to be entered by humans.

Be careful some mast as support for wind generators might be entered.

Thought antenna vs mast might be a problem but not mast vs tower.

Cheers fly



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


Re: [Tagging] high mobile masts on man_made=mast

2015-02-16 Thread fly
Am 16.02.2015 um 13:33 schrieb fly:
 Am 16.02.2015 um 11:32 schrieb Martin Koppenhoefer:
 2015-02-16 4:25 GMT+01:00 Dave Swarthout daveswarth...@gmail.com:

 On Mon, Feb 16, 2015 at 4:23 AM, Martin Koppenhoefer 
 dieterdre...@gmail.com wrote:

 I've been taught that a mast is usually not self supporting, ie. has
 guy wires while a tower is self supporting.

 +1
 
 -1
 Usually depends on the construction and height.

Sorry, tried to write:

Usually depends on the construction and diametre but not height.


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


Re: [Tagging] building=yes on nodes?

2015-02-16 Thread fly
Am 14.02.2015 um 23:06 schrieb Tobias Knerr:
 On 14.02.2015 22:11, SomeoneElse wrote:
 ... it also says that it shouldn't be used on relations, which would
 exclude perfectly valid multipolygons, such as this one:
 
 Multipolygons are a means to map areas. So they are covered by the area
 icon.
 
 The relation icon stands for relations that are not areas,
 just as the way icon stands for ways that are not areas.

How about type=building ?

 It appears that again people are trying to use the wiki to tell other
 people how to map rather than describe how things tend to be mapped.
 
 Nobody is telling anyone not to use multipolygons.

This is totally misleading as the type of the object is still a
relation. Once we introduce an area object we might cover closed ways
and multipolygones as one category. For now we depend on the object type
or e.g. editor software already need to implement the area type to offer
proper presets.

cu fly

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


Re: [Tagging] Change of rendering: place of worship and, terminal without building tag

2015-02-16 Thread fly
Am 16.02.2015 um 11:56 schrieb Martin Koppenhoefer:
 2015-02-15 13:44 GMT+01:00 John Willis jo...@mac.com:
 
 Landuse=religious is a generic version of churchyard.

 I agree that a churchyard could have a dedicated tag like
 amenity=churchyard (similar to amenity=graveyard) or historic=churchyard.
 IMHO landuse shouldn't define a feature, but be used as an attribute (the
 usage of the land).

+1


 I can think of several large church complexes in California - a massive
 Mormon temple, a Presbyterian church ground a with a small preschool, a
 couple Catholic Churches, a Jehovah's Witness hall, a big mega-church hall,
 a cult-like church that meets in a house (registered as a church so it
 shows up in google maps as one), a mosque, a Greek Orthodox something
 church, a Jewish community center, and now about 100 Buddhist temples and
 Shinto shrines.

 let's take a look at the community center: do we want different landuse for
 a community center operated by a religious community compared to a profane
 one? (This is a question we have to ask ourselves in order to find tagging
 definitions, it is not a rhetorical question).
 
 Shall we have different landuses for schools operated by a religious
 community compared to a government school?
 
 Just as a sidenote: if I were to tag all residential places in Rome which
 belong to the catholic church, 25% of Rome would be landuse=religious.
 
 So far I have simply added religion=christian, denomination=catholic to
 universities, schools and kindergardens operated by the catholic church,
 because they are mainly universities, schools and kindergardens, not
 religious places in my eyes. There are also banks operated by the church,
 is this religious landuse?
 So far I have not experienced a problem with adding religion and
 denomination tags to features operated by a religious community and have
 continued to use the same landuse I'd use otherwise on the same kind of
 feature (if any). What would I gain by adding landuse=religious?

+1

I usually use amenity=place_of_worship for the whole area similar to
amenity=school and amenity=hospital.

Do not think landuse=religious is any landuse.

The problem with the numbers are that a small number of users did
introduce it and iD and JOSM way to early introduced presets for it,
even when the tag was by far established and the discussion about it on
this list was not finished, yet.

cu fly

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


Re: [Tagging] Bus route relations. Forward/backward tag

2015-02-16 Thread fly
There are still cases where forward/backward are useful with P2-routes.
E.g. a route with a loop and some members used twice but different
directions.

Personally, I still use forward/backward on any member of a route which
is only used in one direction and for all P2-routes as it makes it much
easier to get the direction of the route with incomplete data.

cu fly

Am 16.02.2015 um 08:40 schrieb Jo:
 On the one hand I'm not adding roles to the ways in PT routes relations
 anymore, instead I add all the ways in the correct order. Some ways are
 included twice.
 
 But if you prefer to add them, you have to know forward/backward relates to
 the direction of the way itself. If it follows the arrow: forward, if it
 goes against it: backward. If you do it right, JOSM is able to sort your
 ways automatically.
 
 If you're still on the v1 scheme, where there is only one route relations
 doing a futile attempt to describe all variations, I suggest you switch to
 the new scheme where a route_master describes the line and route relations
 describe each variation from beginning to end.
 
 
 This is how we do it in Belgium:
 http://www.openstreetmap.org/user/Polyglot/diary/28401
 
 There are some links to Youtube videos included in that article.
 
 2015-02-16 5:52 GMT+01:00 Hans De Kryger hans.dekryge...@gmail.com:
 
 Me and a fellow mapper are adding bus routes to are city and are confused
 about
 ​ the Forward/backward tag you use on relations. I think I'm using it
 right yet every time i check ​ÖPNVKarte, it shows the route going the
 opposite way in which i intended. Just looking for any help i can get. I'm
 quite confused on the usage of the tag especially the use of it on a two
 way street. Which way is forward and which way is backward. Thanks in
 advance.

 ÖPNVKarte
 ​ - (​
 http://xn--pnvkarte-m4a.de/


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


Re: [Tagging] route=running

2015-02-14 Thread fly
Am 13.02.2015 um 11:19 schrieb Andreas Labres:
 On 05.02.15 06:44, Andreas Labres wrote:
 Would it be O.K. to add route=running to the Wiki?
 
 I'd also need a value for nordic walking routes, could this be 
 route=nordic_walking?

What is the difference between a nordic_walking and a running route ?
Does it really matter or am I only allowed to run/walk along with sticks
in my hand ?

While I understand that we need tags for running - nordic_walking -
fitness_trail we might think about one category and an additional tag.

 Here is an example of the signpost for a running and a walking route:
 
 http://www.bad.tatzmannsdorf.at/typo3temp/yag/11/1130x505827a8921.jpg
 
 www.laufarena.at gives details of the routes in that area.
 
 running:
L11 Panoramalauf
L12 Höhenweg
L13 Wechselblick
L14 Wendepunktstrecke Golfplatz
L15 Tschabachrunde
L16 Neustiftrunde
L17 Aufwärmrunde
L18 Resortrunde
L19 Drumlingrunde
 
 nordic walking:
W11 Friedensweg
W12 Panoramarunde
W13 Hianzenweg
W14 Quellenweg
W15 Moorweg
W16 Bernsteinweg
 

By the way the type=route wiki page [1] first lists foot and later talks
about hiking.

Thought foot is a higher category and we might difference between hiking
and walking.

Cheers fly


[1] https://wiki.openstreetmap.org/wiki/Relation:route


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


Re: [Tagging] Waste_collection - a new Feature Proposal - RFC

2015-02-14 Thread fly
Am 14.02.2015 um 02:41 schrieb Dave Swarthout:
 I think amenity=waste_disposal with sub tags for the type of waste being
 disposed of could be a workable solution. It's more complicated than using
 another top level tag like dump_station, etc., for sewage but allows for
 more specificity when desired. This seems to be a good, general purpose,
 top level tag.

+1

It will work far better than waste=* or rubbish=* on there own if you
also think about the amenity=recycling and the possible overlaps.

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


Re: [Tagging] Feature Proposal - Voting - traffic_signals (Lukas Schaus)

2015-02-10 Thread fly
Still do not see any need for a relation once we have micromapped enough
and this should be the prior quest.

What I totally miss are options for operating_time. I won't be able to
tag the phase as many other did already mention but I can tell you the
times when traffic_signals are usually operating.

Guess people might already use opening_hours but I rather prefer
operating_time.

Am 10.02.2015 um 14:33 schrieb Lukas Schaus:
 fly lowflight66 at googlemail.com,  Mon Feb 9 15:47:00 UTC 2015
 You did not comment on my question about micromapping a junction and
 adding a highway=traffic_signal at the pedestrian crossing or the stop
 line for each direction separately. Have a look at the examples below
 [1],[2].

 For complete direction separated junctions like [3] we probable will not
 even need any relation.

 Please, consider this tagging style and show me how this will work
 together with your proposal.

 Altogether, I am not sure if this relation is needed at all but for sure
 not at the current base.

 Still would prefer simple tags on the nodes if possible.

 cu fly

 [1] https://www.openstreetmap.org/#map=19/48.10739/7.85080
 [2] https://www.openstreetmap.org/#map=18/48.06123/7.81258
 [3] https://www.openstreetmap.org/#map=19/47.98530/7.82814
 I am sorry i did not see your question,
 If the traffic signals are mapped at the stop line or the pedestrian
 crossing this scheme works still perfectly. the From way is the way the
 signal is at and the direction can be specified by forward or backward.
 Simple Tags on the nodes only work with this scheme mentioned by you.
 With intersections where the signal is mapped at the crossing of 2 roads
 it is not working. Why would there no relation needed in 3?
 
 AYTOUN RALPH ralph.aytoun at ntlworld.com, Tue Feb 10 11:09:16 UTC 2015
 My feelingsis this not something for a separate study by someone
 rather
 than a feature on OSM? Keeping this kind of information updated will
 be an
 impossibilitymany cities are becoming computerised and the signals
 adjusted according to the traffic conditions along that road. At best the
 timings could be either static or variable.
 
 That is why we kept the mapping of the phases simple and not accurate.
 These values shall give an idea on how long a total cycle of the
 traffic_signal is and an average of green time or the proportion between
 red and green time. These two information are very helpful for simulations.
 Please note that the phases tag is only one part of the proposal. at
 least as important is the ability to define to-ways for the signal.
 Knowing this other traffic_signals on the way can be ignored since they
 are not of concern for the turning vehicle. Also the defined connection
 of a turn_lane to its destination is a major benefit from this scheme

So we need at least tags for these situations like button operated and
psv-priority and so on.

cu fly


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


Re: [Tagging] Feature Proposal - Voting - traffic_signals (Lukas Schaus)

2015-02-09 Thread fly
Am 09.02.2015 um 15:35 schrieb Lukas Schaus:
 Hi,
 
 My proposal concerning the modelling of traffic signals is now open
 for voting.
 
 http://wiki.openstreetmap.org/wiki/Proposed_features/Traffic_Signals#Voting

You did not comment on my question about micromapping a junction and
adding a highway=traffic_signal at the pedestrian crossing or the stop
line for each direction separately. Have a look at the examples below
[1],[2].

For complete direction separated junctions like [3] we probable will not
even need any relation.

Please, consider this tagging style and show me how this will work
together with your proposal.

Altogether, I am not sure if this relation is needed at all but for sure
not at the current base.

Still would prefer simple tags on the nodes if possible.

cu fly


[1] https://www.openstreetmap.org/#map=19/48.10739/7.85080
[2] https://www.openstreetmap.org/#map=18/48.06123/7.81258
[3] https://www.openstreetmap.org/#map=19/47.98530/7.82814

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


Re: [Tagging] Tram tracks running in a road

2015-02-09 Thread fly
Am 08.02.2015 um 19:45 schrieb Janko Mihelić:
 2015-02-08 17:48 GMT+01:00 fly lowfligh...@googlemail.com:
 Am 07.02.2015 um 11:19 schrieb Martin Vonwald:
 2015-02-07 0:31 GMT+01:00 Janko Mihelić jan...@gmail.com:
 2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich luca.perc...@gmail.com:

 We could also user a lanes modifier:
 lanes=3
 lanes:backward=2
 tram:lanes:backward=yes|no
 tram:forward=yes

To get it clear, I only use these tags as addition on highway=* tagged
with lanes:-Taggingsystem. There is always a separate way with railway=*
+ track=1 for each track.

 Actually, I use an even more general approach:
 railway:forward=tram
 railway:lanes:backward=tram|no

 together with access I also use train
 access:lanes:backward=no|yes
 train:lanes:backward=designated|no

 
 I don't understand why you would use railway:forward=* and
 railway:lanes:forward=*. Aren't those two redundant?

Yes, the first is used for lanes:forward=1 while the second one for
values greater than 1.

Please read carefully, I used forward and backward and followed the
quoted example.

 Also, why train and not tram?

tram would work in my case but I know also rails used by freight train
which are embedded into the road.

I see train as a more general access tag compared to tram, cable_car,
light_train etc.

 I like railway:lanes:forward/backward=* because sometimes you can have
 rails on the street which are not used by anything, so using tram/train
 doesn't make sense. But if you say tram:lanes:forward/backward=* than that
 implies that there are rails there, so no other tags are needed anymore.

I would always use railway:forward/backward= for
lanes:forward/backward=1 but won't insist on that one.

For more than one lane in one directions I use
railway:lanes:forward/backward=* as I already mentioned above this is
not only tram specific.

train or tram are access tags which I only use if I need them usually
only in cases of access=no or access:lanes:forward/backward=no|no|yes or
similar.

Forgot to send some links the other day:

[1] https://www.openstreetmap.org/#map=18/47.99472/7.85038
[2] https://www.openstreetmap.org/#map=19/47.98524/7.83145

cu fly

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


Re: [Tagging] Tram tracks running in a road

2015-02-08 Thread fly
Am 07.02.2015 um 11:19 schrieb Martin Vonwald:
 2015-02-07 0:31 GMT+01:00 Janko Mihelić jan...@gmail.com:
 2015-02-06 17:29 GMT+01:00 Luca Sigfrido Percich luca.perc...@gmail.com:

 We could also user a lanes modifier:
 lanes=3
 lanes:backward=2
 tram:lanes:backward=yes|no
 tram:forward=yes

Actually, I use an even more general approach:
railway:forward=tram
railway:lanes:backward=tram|no

together with access I also use train
access:lanes:backward=no|yes
train:lanes:backward=designated|no

 I think this is the best way to tag this. There's a great map paint style
 for seeing roads in towns in JOSM, and it helps a lot with tagging lanes.
 It's called Lanes and road attributes. Unfortunately, it doesn't show
 trams, but if we start tagging them, it will probably start rendering them.

+1 but we need to find some consistent tagging system.

 Let me know if there's a place with a lot of such tags and I try to update
 the style. (Please contact me directly via martin (the usual) vonwald
 (dot.) info for this)

+1

Cheers fly


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


Re: [Tagging] Access restrictions for shoulder lanes?

2015-02-06 Thread fly
Am 06.02.2015 um 14:00 schrieb Bryce Nesbitt:
 In the USA occasional sections of even Interstate highways are open to
 bicycles,
 where no equivalent route exists. There's some argument to tag these as
 bike paths to avoid the tag soup of lanes,
 and ensure the (unusual) situation is perfectly clear.

Why is bicycle=yes and motorroad=no not enough ?

Please no separate ways, as you loose the information that you are using
a motorway and might looking forward to find a nice bicycle path.

cu fly


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


Re: [Tagging] Feature Proposal - RFC - temperature

2015-02-04 Thread fly
Am 04.02.2015 um 10:56 schrieb Kotya Karapetyan:
 Hi,
 
 +1 for the proposal as such.
 
 I have suggestions for some parts of the proposal though.
 
 1) I would discourage specification of the temperature without the
 scale indication. I have never lived in the US but I see from the Web
 that Americans like specifying temperature in degrees Fahrenheit
 without mentioning it (the same way as we in Europe use centigrade
 without underlying it). Taking into account the international nature
 of the OSM community, I foresee a significant risk that the map will
 get populated with invalid values. Warin is right about SI units, but
 SI is not even strictly followed in the technical and scientific
 community, not to mention the general public. Obviously, Americans in
 general ignore it by using inches, miles and degrees Fahrenheit :) I
 am afraid many people will not have heard about SI guidelines and will
 not have read the wiki page in significant detail.
 
 Therefore, for the sake of clarity, I suggest always specifying F or
 C with the temperature value.

+1
Units for temperature are really wired and obviously Kelvin which I
would suspect to be the default is not really used in real live as
Celsius has the better scale for real life usage.

 2) I suggest clarifying the verbal specification of the temperature.
 - Replace chilled with cool (by analogy with warm) and also
 because chilled actually assumes that I know that the object was
 purportedly cooled down, which adds yet another uncertainty and is
 usually not very relevant;
 - remove the definition of substantially colder etc., because it
 doesn't add any clarity. I agree that it is important to distinguish
 between safe and unsafe situations, so let's just do that:
 
 freezing
 cold — may be unsafe to handle
 cool
 warm
 hot — may be unsafe to handle
 boiling
 adjustable — the object temperature can be changed by consumer/user
 variable — the object temperature can vary on its own
 ambient — the object always remains at ambient temperature (note that
 this may include the object being cold and warm, including being
 unsafe to handle, depending on the ambient temperature; think about
 water in Siberia rivers in January)

Only two values I could live with are cold and hot. Generally these
values are too ambiguous and an estimated value is much better.

 3) For the numeric specification, I suggest adding:
 - above/below options
 - approximate value
 - range of temperatures (using above/below)
 
 E.g.
 temperature:circa = 80 C
 temperature:above[:circa] = 300 C
 temperature:below[:circa] = 1000 C

I would add this in the value like:

temperature =  10 C
temperature =  300 C

We still can use source:temperature=estimated

4) How do we tag a shower with cold and hot water ?

temperature=4 C;80 C ?

Does this depend on the hose, e.g. one separate for each temperature or
a mix-batterie ?

cu fly

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


Re: [Tagging] Access restrictions for shoulder lanes?

2015-02-03 Thread fly
Am 03.02.2015 um 13:23 schrieb Richard Welty:
 On 2/3/15 6:14 AM, Colin Smale wrote:

 Same as for normal vehicles, but ignoring the access tag and any
 restrictions


 but you've declared that access=no applies both to obstructed
 routes (bollards, guardrails, etc) and unobstructed routes.

In my understanding emergency need infos like width, max physical height
and about sharp turns.

All barriers should be tag separately and tags like access and oneway on
the ways are just some more information but not the most important ones.

cu fly


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


[Tagging] roof:shape with several connected buildings

2015-02-03 Thread fly
Hey

Can someone give me a hint how to tag two buildings which have a wall in
common and share one roof, e.g. roof:shape=hipped for both together.

Do we have a tag for only on one side hipped ?

I have this problem with several buildings but usually one the
first/last of the row are a problem.

Thanks fly

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


Re: [Tagging] Electronic or 'e' cigarettes?

2015-02-03 Thread fly
Am 02.02.2015 um 23:28 schrieb Andy Mabbett:
 On 22 January 2015 at 18:00, fly lowfligh...@googlemail.com wrote:
 
 Anyway, I do not know a single shop in my area which only sells them so
 shop=* will never fit.
 
 Never? I'm reminded of the maxim that the singular of data is not 
 anecdote.
 
 (There are several such shops in my home city.)

Was this really that misunderstood-able ?

Sure, this sence was writing in a subjective manner. Did not want to say
that there are no such shops but rather that I need subtags or a
different key in order to tag shops which offer them.

cu fly

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


Re: [Tagging] Access restrictions for shoulder lanes?

2015-02-03 Thread fly
Am 03.02.2015 um 10:34 schrieb Martin Vonwald:
 Fine. But how do you specify where this lane is or if there is a lane at
 all?

In the lanes:-tagging system it would work like:

boulder|lane|lane|boulder|turn-lane|bicycle lane

access:lanes=no|yes|yes|no|yes|no
bicycle:lanes=no|no|no|no|no|designated
turn:lanes=|||slight_right|

only problem are once again lanes*=*

Would could handle boulder lanes like bicycle lanes and not counting
them would lead to

lanes=3

my 2 ct
fly


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


Re: [Tagging] roof:shape with several connected buildings

2015-02-03 Thread fly
Am 03.02.2015 um 17:37 schrieb fly:
 Hey
 
 Can someone give me a hint how to tag two buildings which have a wall in
 common and share one roof, e.g. roof:shape=hipped for both together.
 
 Do we have a tag for only on one side hipped ?
 
 I have this problem with several buildings but usually one the
 first/last of the row are a problem.

Well, I found roof:shape=side_hipped [1] which seems to fit.

Cheers fly

[1] https://wiki.openstreetmap.org/wiki/OSM-4D/Roof_table#Roofs_with_2_faces


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


Re: [Tagging] RFD pipeline sub tag substance

2015-01-29 Thread fly
Am 29.01.2015 um 10:59 schrieb Martin Koppenhoefer:
 2015-01-29 5:41 GMT+01:00 johnw jo...@mac.com mailto:jo...@mac.com:
 
 if this is the proper term used for pipelines, then this would be
 the right one, 

 Otherwise, =multi (like sports) would be the best. 

 but you would not need such a tag, since it would be 

 substance=gas
 substance:detailed=multiphase_gas

 if you keep it at two levels of detail (water, gas, oil,  fuel,
 sewage, heat, coolant, etc), 

 I'd like to repeat once again that substance doesn't seem to be a nice
 key descriptor for values like gas, fuel, heat, as it refers to
 physical matter/material and heat or gas or fuel in its actual
 meaning aren't materials.

+1
but what do you suggest. Do we need a key for the state of matter or
better use water_steam or hot_water or fluid_propane ?

 using the colon separator would keep from making additional tags
 (everything would be kept in the substance tagspace) - especially
 generic tags like fuel= water= gas= which might have uses elsewhere
 (like the water_tap discussion here earlier) or be confused for other
 uses (like not a subkey, but a straight key by itself), someone could
 stick fuel=unleaded_87 onto a gas station. Or does that already
 exist?

Have a look at fuel=* [1]. Nice, we already have the value in key
variant and a key=value variant with possibility to use semi-colon.

At least, we should consider the same tags for the same substances/fuels.

How about substance=wood_pallets.

cu fly


[1] https://wiki.openstreetmap.org/wiki/Key:fuel

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


Re: [Tagging] [OSM-talk] Quay

2015-01-28 Thread fly
Am 28.01.2015 um 02:51 schrieb Warin:
 On 27/01/2015 9:29 PM, Jean-Marc Liotier wrote:
 (This discussion originated on talk - crossposted to tagging on
 Malcolm's suggestion)

 On 26/01/2015 21:16, Malcolm Herring wrote:
 On 26/01/2015 19:23, Jean-Marc Liotier wrote:
 http://wiki.openstreetmap.org/wiki/Proposed_features/Harbour#Quay
 mentions that a quay will normally be tagged as part of the
 coastline natural=coastline. Apart from that I found no clue
 anywhere else about how a quay should be tagged... Am I missing
 something ? Considering how well-used man_made=pier is, I am
 surprised that quays get such scant attention. man_made=quay anyone ? 
 To quote the IHO dictionary: quay. A WHARF approximately parallel to
 the SHORELINE and accommodating ships on one side only, the other
 side being attached to the SHORE. It is usually of solid
 construction, as contrasted with the open pile construction usually
 used for PIERS.

 So yes, your reasoning is correct  that section of the coastline
 that forms the quay could indeed be tagged man_made=quay.

 Yes, this is about what I had in mind:
 - Either take a section of natural=coastline and overload it with
 man_made=quay
 - Or draw a dedicated man_made=quay way on top of a natural=coastline

 I have no idea which one would be best. I lean towards the first one
 for easier editing - ways exactly on top of each other are difficult
 to select.


 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
 
 Off topic.
 http://wiki.openstreetmap.org/wiki/Proposed_features/Harbour#Quay .. is
 dated .. 2008 or before .. 8 years ? proposed? Ridiculous! Abandoned ..
 why? And what is used in its place? Very poor documentation - nothing
 directly on why it failed.

Sadly, all proposal without a change within some time period where set
to abandoned some time ago. Please feel free to take over and reactivate it.

 
 
  One could also use waterway=quay or waterway=wharf. This would
 associate it with a waterway, might be a natural feature (think of a
 solid sandstone bank used as a wharf), or man made so why not waterway? 
 Does not sit with man_made=pier .. but those don't occur as natural
 features? My thinking is to follow highway=* tagging where traffic
 lights are tagged hightway=traffic_lights rather than
 man_made=traffic_lights. This groups things together for a more logical
 system of things that would be associated all in the one main tag.

Actually, I am in favour of creating more keys in stead of too much
grouping. We already get conflicts with highway=traffic_lights vs.
highway=crossing and imagine traffic_calming=* to be under
highway=traffic_calming.

I would propose to use man_made=quay analog to pier and guess that there
are not many natural quays.
Still waterway=quay is used a little more often [1], so documentation
and some con-sense is needed.

 ---
 As the coastline in some places is man made .. I'd much rather see
 coastline as waterway=coastline rather than natural=coastline. This
 comes back to my thoughts on OSM tagging philosophy/thinking/order 

waterways are all linear objects and it contradicts to your
waterway=quay/wharf

I would not take all keys literally and we will always have a discussion
about natural=* I guess.

Cheers fly


[1] https://taginfo.openstreetmap.org/search?q=quay#values

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


Re: [Tagging] length=

2015-01-27 Thread fly
Am 27.01.2015 um 16:34 schrieb Martin Vonwald:
 2015-01-27 16:26 GMT+01:00 François Lacombe fl.infosrese...@gmail.com
 mailto:fl.infosrese...@gmail.com:
 
 In my mind, a road climbing a mountain won't have the same length in
 reality than in the DB : the Z dimension may have influence too.
 
 
 Ok - understood. Although I doubt, that there is real usage for that
 example. But I had a quick look in overpass: besides aeroways it is
 quite often used on bridges and tunnels, where the actual (official)
 length can be observed. Makes sense.

But how to handle it one ways considering splitting and combining ways ?

For bridges and tunnels this info belongs to the area or the relation
but not to an unclosed linear way.

About aeroways we already have an own thread as we have more problems
with them.

cu fly




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


Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

2015-01-27 Thread fly
Am 24.01.2015 um 17:28 schrieb Martin Vonwald:
 
 
 2015-01-24 17:20 GMT+01:00 Никита acr...@gmail.com
 mailto:acr...@gmail.com:
 
 Are you an idiot? I mean really.
 
 
 I hereby request a ban of this individual from this mailing list and I
 definitively support an OSM-wide ban.

+1

this user needs some break/holiday and has to prove that he his willing
to accept a community.

I did not read any apology so far, which would be a first step.

Altogether we can use our time/power for better stuff than this
exhausting discussion which is leading nowhere

cu fly


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


Re: [Tagging] Feature Proposal - RFC - addrN:*

2015-01-22 Thread fly
Am 22.01.2015 um 04:02 schrieb John F. Eldredge:

 If you have a strictly delimited plot of land, with no house currently
 built upon it, but which is intended for later construction, does it
 have a house number?  Or is the address only assigned once a building is
 built?

In Germany the address always belongs to the plot and not to the
building and they are assigned in advance.

cu fly



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


Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

2015-01-22 Thread fly
Am 22.01.2015 um 18:08 schrieb Marc Gemis:
 
 On Thu, Jan 22, 2015 at 4:49 PM, althio althio.fo...@gmail.com
 mailto:althio.fo...@gmail.com wrote:

Well at least iD knows quite well about the semi-colon:
Just merge two ways together and you might get access=no;yes
highway=primary;path without any warning.


 New people can have problems or make mistakes and then experienced
 users can help and point to recommended tagging or explain good
 practices .
 
 Not everybody reaches out to community for help. Probably many just stop
 mapping, requiring them to create a new key, instead of typing something
 in a free text field is not going to help IMHO.

That is why I would be interested to mention the semi-colon on tag-pages
where it is in common use. This helps in general for question about list
or array, order or not.

 Or do you refer to iD (as the main editor for new people) where it is
 not possible to override presets to edit keys on the first part of the
 tag panel?
 
 
 What I tried to explain is that when you go for a tagging scheme where only
 cuisine:xxx=yes is allowed, the editor (iD) should offer a simple UI
 that allows people to create new values. In this case that means keys,
 since the values are actually in the  keys.
 
 At this moment, it is also not possible to create JOSM presets that
 generates keys based on user input AFIAK.

+1

 Using a xxx:yyy schema also requires checkboxes besides every existing
 value in JOSM presets.
 So I don't see how it is any easier for new mappers or preset creators.

Presets are a problem [1],[2] and it is not easy to present tag list
with more than 50 tags per object.


Cheers fly


[1] https://josm.openstreetmap.de/ticket/6268
[2] https://josm.openstreetmap.de/ticket/8993


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


Re: [Tagging] Electronic or 'e' cigarettes?

2015-01-22 Thread fly
Am 22.01.2015 um 19:43 schrieb Matthijs Melissen:
 On 22 January 2015 at 18:00, fly lowfligh...@googlemail.com wrote:
 Well the first page should be under proposal and it should not be listed
 under shop or if only under some proposal paragraph
 
 Only six shop types have been approved by the wiki/voting process:
 bakery, baby_care, second_hand, seafood, bookmaker, and lottery (and
 seafood is questionable due to not having the required number of
 votes).
 
 Do you suggest to list all other shop types, including well-known ones
 such as shop=supermarket, as 'under proposal'?

No, but it is common sence to introduce tags in proposal name space and
once they are in common use accept them because of it use.

 The wiki page is very recent with only two contributors. I wouldn't be
 surprised if e-cigarette in the db was also contributed by no more
 than 1-2 mappers. I suggest contacting them to make sure that they are
 ok with e_cigarette, and then make the change to wiki and db.
 
 There are at least 30 mappers who have used shop=e-cigarette. Almost
 all of them started using this tag *after* user StephaneP imported
 about 80 e-cigarette shops in France.
 
 I also think that e-cigarette would be better than e_cigarette, as the
 - does not represent a space, and e-cigarette is a regular English
 word, used for instance in newspapers.

No doubt about the spelling but still prefer a tag without abbreviation
and advertising background. So call it by proper name. In my case
electronic_cigarette=yes.

Cheers

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


Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

2015-01-22 Thread fly
Am 22.01.2015 um 21:32 schrieb Tod Fitch:
 I've been following this and the addrN thread with a mixture of amusement and 
 irritation.
 
 Lots of the arguments come down to how easy it is to parse using some tool or 
 another. Or whether the problem the original poster was trying to address 
 actually exists.
 
 With respect objects that have multiple values for a key, the arguments seem 
 to come down to either:
 
 1. key=value1;value2;. . . ,valueN
 2. key:value1=yes + key:value2=yes + . . . + key:valueN=yes
 
 As a programmer I can parse either set using any number of different methods.
 
 I am not against using a :' in the key string to create name spaces and for 
 grouping related keys. I think that is a very useful construct.
 
 But from a purely logical point of view, I'd say the second way misses the 
 concept of key=value and is using key:value with a noise suffix of 
 =yes. Typically missing keys should be treated as having a value of either 
 no or unknown. Unless you can show me where key:value1=is something 
 other than yes then I may suspect you of putting values into the key field 
 of the data.
 
 Might I suggest that a convention for keys that may contain multiple values 
 that the : delimiter be used in the key but rather than putting arbitrary 
 (data) values after the colon, use an numeric index:
 
 key:1=value1
 key:2=value2
 key:3=value3

No not at all, this makes it worse. Numbers are way to general and you
gain little.

: is usualy used for subkeys so key1, key2 would even be better.

fly


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


Re: [Tagging] sidewalk=* or footway=*

2015-01-20 Thread fly
Sorry, was talking about the RFC discussion on this list [6] but your
link or better gmane.org [7] as threads are better listed is the
starting point.

The discussion at the same time about sidewalk as separate ways might be
also interesting.

cu fly

[6] http://thread.gmane.org/gmane.comp.gis.openstreetmap.tagging/7106
[7] http://thread.gmane.org/gmane.comp.gis.openstreetmap.tagging/7051

Am 20.01.2015 um 13:55 schrieb Hubert:
 Thanks for the quick response.
 Sadly the discussion page wasn't much help. But I think I found the right 
 thread on the mailing list (though I haven't read it yet):
 https://lists.openstreetmap.org/pipermail/tagging/2011-March/007023.html

 -Original Message-
 From: fly [mailto:lowfligh...@googlemail.com]
 Sent: Dienstag, 20. Januar 2015 01:05
 To: Tag discussion, strategy and related tools
 Subject: Re: [Tagging] sidewalk=* or footway=*

 Please have a look into the archive of this list and the discussion of
 the sidewalk proposal.

 It was designed to replace footway=both/left/right/none but transition
 is slow.

 JOSM just introduced a validator warning offering an automatic change.

 Speaking for myself, I did not care to change a whole city and with
 your mentioned numbers a well-designed software will still look for
 both tags.



 Am 19.01.2015 um 16:44 schrieb Hubert:
 Hallo,

 I am working on some ideas for a proposal[1]to double represent
 cycletracksand footways.It is at the very beginning  at the moment
 and
 I haven’tmade upmy mindabout how to do that.

 While I was researchingdifferentstuff, I noticed that the proposals
 to
 footway=*[2]and sidewalk=*[3] haven’t been voted on.Yet, it sais“Do
 not use***footway*=*on other

 than___highway_http://wiki.openstreetmap.org/wiki/Key:highway=___foo
 tway_http://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway”in
 a warning box ontheKey:footway wiki page [4].It appears that this box
 has been added by a user only3 days after posting a comment on
 thediscussionpage. [5]

 Also aoverpass query[1]as of2015-01-14 has return around 40.000 uses
 offootway=*on highway=*roads*only, excludinghw=footway/cycleway/path.
 Howeverthere are500.000 usesof sidewalk=*.While this shows a majority
 usefor sidewalk=*, I can’t seewhy
 footway=* should bedeprecatedfor *roads*nor did I find arelated
 discussion about this.

 Could someone point meinthe right directionformore information on
 that
 topic?

 Yours

 Hubert


 [1]___http://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepresent

 ation_http://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepr
 esentation

 [2]___http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_

 [3]___http://wiki.openstreetmap.org/wiki/Proposed_features/Footway_

 [4]___http://wiki.openstreetmap.org/wiki/Key:footway_

 [5]___http://wiki.openstreetmap.org/wiki/Talk:Key:footway_


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


Re: [Tagging] sidewalk=* or footway=*

2015-01-19 Thread fly
Please have a look into the archive of this list and the discussion of
the sidewalk proposal.

It was designed to replace footway=both/left/right/none but transition
is slow.

JOSM just introduced a validator warning offering an automatic change.

Speaking for myself, I did not care to change a whole city and with your
mentioned numbers a well-designed software will still look for both tags.



Am 19.01.2015 um 16:44 schrieb Hubert:
 Hallo,
 
 I am working on some ideas for a proposal[1]to double represent
 cycletracksand footways.It is at the very beginning  at the moment and I
 haven’tmade upmy mindabout how to do that.
 
 While I was researchingdifferentstuff, I noticed that the proposals to
 footway=*[2]and sidewalk=*[3] haven’t been voted on.Yet, it sais“Do not
 use***footway*=*on other
 than___highway_http://wiki.openstreetmap.org/wiki/Key:highway=___footway_http://wiki.openstreetmap.org/wiki/Tag:highway%3Dfootway”in
 a warning box ontheKey:footway wiki page [4].It appears that this box
 has been added by a user only3 days after posting a comment on
 thediscussionpage. [5]
 
 Also aoverpass query[1]as of2015-01-14 has return around 40.000 uses
 offootway=*on highway=*roads*only,
 excludinghw=footway/cycleway/path. Howeverthere are500.000 usesof
 sidewalk=*.While this shows a majority usefor sidewalk=*, I can’t seewhy
 footway=* should bedeprecatedfor *roads*nor did I find arelated
 discussion about this.
 
 Could someone point meinthe right directionformore information on that
 topic?
 
 Yours
 
 Hubert
 
 [1]___http://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepresentation_http://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepresentation
 
 [2]___http://wiki.openstreetmap.org/wiki/Proposed_features/Sidewalk_
 
 [3]___http://wiki.openstreetmap.org/wiki/Proposed_features/Footway_
 
 [4]___http://wiki.openstreetmap.org/wiki/Key:footway_
 
 [5]___http://wiki.openstreetmap.org/wiki/Talk:Key:footway_
 
 
 
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
 


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


Re: [Tagging] Overhead signs (Überkopfwegweiser)

2015-01-18 Thread fly
Well, we already have two systems which work well together to get all
tagged.

1. the already mentioned destination*:lanes=* system
2. additionally the relation type=destination_sign

So the only thing I would miss are some tags to better tag the
properties of the sign itself like direction=*, support=* or ele=*.

Do we have traffic_sign=destination_sign or highway=destination_sign or
similar tag as main tag for the node.

Is gauntry that important, that we need an own main tag dor it or would
it better fit as subtag ? Eventually even support=* alone will work.

cu fly

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


Re: [Tagging] Feature Proposal - RFC - (Traffic Signals)

2015-01-18 Thread fly
Additional to below I want to mention that on a micromapping style a
traffic_signal is placed one the pedistrian crossing or the stop_line. I
even came across ones one the stop_line and an addition highway=crossing
on the pedestrian crossing.

I am tagging direction=* for the direcion it faces.

Together with the :lanes tagging you do not need any relation at all but
could simply add the information on the node with :lanes tagging

cu fly

Am 18.01.2015 um 14:14 schrieb Tom Pfeifer:
 Sorry but I'm sceptical about the scheme. It adds very little value
 compared
 to its own complexity. In particular the timing of the lights is highly
 volatile
 in modern cities, and it seems impossible to collect the ground truth as a
 mapper just by observing them.
 
 Take the 2050 traffic lights in Berlin for example [1], which are
 controlled in 3 tiers.
 Each junction works autonomously with predefined programmes for
 different times
 of the day and days of the week, even if disconnected. In the next tier,
 junctions are regionally clustered, so they can sync for better traffic
 flow.
 In the third tier, they are connected with two fibre rings to the traffic
 management centre in the former airport Tempelhof buildings, where their
 cycles can
 be completely changed and adapted: to the current traffic flow or
 accidents,
 in response to mass events, and e.g. to switch a 'green corridor' for a
 state visitor.
 
 Thus as a mapper with a stop watch, you never know which of these
 programmes
 you are currently observing.
 
 Tom

+1

 [1] Ref: VMZ Berlin, 2013
 
 Lukas Schaus wrote on 2015-01-15 12:15:
 Hello Everybody,

 please take some time to read my proposal concerning more detailed
 modelling of traffic signals and tell me your thoughts.

 http://wiki.openstreetmap.org/wiki/Proposed_features/Traffic_Signals

 I will keep track of the discussion page and the Comments section of
 the proposal.

 Greetings

 Lukas Schaus

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


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


Re: [Tagging] Feature Proposal - RFC - addrN:*

2015-01-18 Thread fly
Am 17.01.2015 um 23:11 schrieb Friedrich Volkmann:
 On 16.01.2015 05:48, Ineiev wrote:
 On Thu, Jan 15, 2015 at 12:53:13PM +0100, Martin Koppenhoefer wrote:

 you could use polygons (e.g. 2 distinct multipolygons, one for each
 address), and add a note to inform your fellow mapping colleagues that the
 overlap is intended (note is not needed but nice).

 I think this solution has an essential advantage: distinct
 multipoligons with single addr:housenumbers can go do distinct
 associatedStreet relations. you can't do it with addrN:; and
 the mapper may want to use associatedStreet e.g. because
 it provides a way to specify parallel addresses in different
 languages (I believe, this feature is used in countries like Ukraine).
 
 If we need language versions for the street name, we'll probably need them
 for city names (Kiyev/Kiyiv) etc. too. So you'll not only need an
 associatedStreet relation, but also an associatedCity relation.
 
 You can (mis-)use the addrN schema for that purpose:
 
 addr:city=ukrainian city name
 addr:street=ukrainian street name
 addr:housenumber=123
 addr:2:city=russian city name
 addr:2:street=russian street name
 addr:2:housenumber=123
 
 The number of tags multiplies with the number of street/housenumber
 combinations, but that may still be simpler than congruent housenumber
 polygons all of which are member of several associatedSomething relations.
 
 I think that the best solution may be:
 
 addr:city=ukrainian city name
 addr:city:ru=russian city name
 addr:street=ukrainian street name
 addr:street:ru=russian street name
 addr:housenumber=123

+1 for language sufix.
cu


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


Re: [Tagging] Tag destination vs. relation destination_sign

2015-01-16 Thread fly
Am 16.01.2015 um 09:31 schrieb Martin Vonwald:
 
 2015-01-15 22:12 GMT+01:00 fly lowfligh...@googlemail.com
 mailto:lowfligh...@googlemail.com:
 
 Please, do not forget to mention direction:lanes*.
 
 
 destination:lanes ;-)

Thanks, yes.

Was tagging directions and writing about destination:lanes.

cu


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


Re: [Tagging] Tag destination vs. relation destination_sign

2015-01-15 Thread fly
Actually the signs alone make it difficult, we need good pictures with
the road and signs.

Often it is tagged on highway=*_link but for sure there are other cases.

Please, do not forget to mention direction:lanes*.

cu fly

Am 15.01.2015 um 19:48 schrieb Lukas Sommer:
 To clarify the wiki a little bit more, I would also add to the
 key:destination page a sentence like “Where to use? Use destination=*
 on the highway (OSM way) after the position of the
 signpost/groundwriting.” And I would remove (as explained above) the
 three examples with the yellow/white signposts for being confusing.
 Thoughts?
 Lukas Sommer
 
 
 2015-01-11 15:48 GMT+00:00 Martin Vonwald imagic@gmail.com:
 2015-01-10 19:40 GMT+01:00 Lukas Sommer sommer...@gmail.com:

 +1. Key:destination for the simple cases the the relation for the
 complex cases seems fine for me.


 I'll wait until monday and if up to then nobody complains, I'll update the
 wiki as mentioned before.


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


Re: [Tagging] bicycle:lanes=designated|... vs cycleway:lanes=lane|...

2015-01-14 Thread fly
Am 13.01.2015 um 13:38 schrieb Martin Vonwald:
 When writing the :lanes-proposal I used those tags in an example. But in
 my opinion bicycle:lanes=...|designated|... fits better.

I was irritated by your example, as well. Maybe, you can rework some
examples and add them to the wiki. At least, marking the original ones
as outdated would be really appreciated.


Thanks fly

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


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

2015-01-13 Thread fly
Am 13.01.2015 um 17:17 schrieb François Lacombe:
 
 2015-01-13 16:17 GMT+01:00 Kotya Karapetyan kotya.li...@gmail.com
 mailto:kotya.li...@gmail.com:
 
 
  I vote yes but this will automatically need a refinement.
 
 Have you also voted at
 https://wiki.openstreetmap.org/wiki/Proposed_features/water_tap#Voting
 ?
 
 
 Yes, as Fanfouer

I won't vote.

 
 I fully agree regarding the (in)consistency and would be happy to
 contribute to develop a consistent tagging scheme and the method to
 maintain it.
 
 
 Well, a full list of features regarding water networks (fountains,
 springs, industrial facilities for treatment, ...) which can be added to
 OSM would be a great beginning.
 
 We'll be able then to summarize the existing tags, and maybe refine some
 of them to best describe those features.
 
  
 
 Let's return to it once this tag discussion is over. It took more than 4
 months already!
 
 
 The time shouldn't be a problem here.
 4 month is really quick when some other proposals need years to be
 completed.
 http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Power_transmission_refinement

And there is no need to ever have a vote.

Most of the discussion as far as I remember where beyond man_made=water_tap.

The proposal now is only about one tag and as I read it, it is no
replacement but only a possible addition to amenity=drinking_water,
though this could be better documented.

Hope the rest of the discussion won't get lost and we already had
similar problems with amenity=drinking_water + drinking_water=no. E.g.
we need some rework of the whole issue and at least two tags where one
could describe the method/structure to gain the water (well,tap ..).

Cheers fly

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


Re: [Tagging] barrier=net ?

2015-01-13 Thread fly
I mostly met them on tennis courts.

For my common understanding, I would be able to break through a net with
a sharp knife while I would struggle to do so with a fence. This would
still fit with material=* but isn't there a difference in construction
between fence and net where the first is free standing where the second
one is tied up.

Wonder how a net could fit under fence in foreign languages or if it is
much easier to have an own main value for it.

cu fly

Am 07.01.2015 um 05:50 schrieb Andrew Harvey:
 I've also used it to tag nets in the water used to provide swimming
 areas safe from sharks.
 
 On 07/01/2015 11:42 am, johnw jo...@mac.com mailto:jo...@mac.com
 wrote:
 
 There are 544 uses of barrier=net, and I want to add it into the wiki.
 
 For many golf courses, driving ranges, and baseball fields world
 wide, and many school grounds in Japan, they may have a fence or
 wall, and in addition a separate expansive and very tall netting, in
 some cases 5 to 10 stores tall for a driving range, supported by
 steel or concrete poles (that look like telephone poles).
 
  In many instances, the net alone is the sole barrier between a golf
 course and adjacent property, forgoing a wall or fence, when
 trespassing or privacy concerns is not an issue.
 
 I don’t think these kinds of nets fits very well with =fence, so I’d
 like to add the value to the wiki page (and then for rendering in
 -carto)
 
 
 Javbw.


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


Re: [Tagging] correct access tagging for tourist attraction

2015-01-02 Thread fly
Happy new year

Am 31.12.2014 um 19:05 schrieb Greg Troxel:
 
 johnw jo...@mac.com writes:
 
 perhaps use the =destination tag instead of =private on the road you are 
 supposed to use. 
 http://wiki.openstreetmap.org/wiki/Key:access 
 http://wiki.openstreetmap.org/wiki/Key:access

Please, no.

 I agree.  There's also access=customers that I use for parking lots.
 access=destination is supposed to be some legal notion in the UK.   In
 the private facility case, it's really a question of some places being
 signed for no access and some being welcoming, but it a
 with-permission-of-landowner kind of way.

I still prefer access=permissive as I often take short cuts by foot
across these private roads without being a customer.

 Another approach is to use access=no for the ones you shouldn't use (and
 for which almost no one among the public gets permission)

That is access=private and not access=no

 and
 
   access=permissive
 
 for the one the public should use.  It's a little off; presumably going
 there at night is not ok.  But as a
 represent-the-world-with-what-we-have-now approach, it seems like a
 pretty good fit.

+1

access=permissive is the one we need here, access=destination has some
legal aspect.

The other roads would be access=private.

Still be careful with access=* as it might depend on your traffic mode
and foot/bicycle/horse/ski might have different rules.


cu fly

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


Re: [Tagging] Shared foot- and cycletracks

2015-01-02 Thread fly
Do not see any advantage compared to highway=path with proper access-tags.

Am 28.12.2014 um 19:54 schrieb Mateusz Konieczny:
 Please, stop proposing tags conflicting with widely used ones.
 
 Also, your example with Poland is incorrect (pedestrians have priority
 over cyclists).

+1

Same in Germany

cu fly

 2014-12-28 18:35 GMT+01:00 Ulrich Lamm ulamm.b...@t-online.de
 mailto:ulamm.b...@t-online.de:
 
 Hi mapping and cycling friends,
 
 I have suggested a special highway-class for the slim tagging of
 this very common kind of cycling facilities that up to now affords a
 combination of four tags.
 
 https://wiki.openstreetmap.org/wiki/Proposed_features/foot_cycleway
 
 Yours'
 Ulrich
 ___
 Tagging mailing list
 Tagging@openstreetmap.org mailto:Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
 
 
 
 
 ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
 


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


Re: [Tagging] key:support, man_made=surveillance

2015-01-02 Thread fly
The cleanest solution is always a proposal but for values it is
sometimes not demanded on.

I think it is much better to describe all values on the page of the key
possibly in different paragraphs or on an own page.

You can still list appropriate values on the page of the primary tag and
link to support. Have a look at the page for the key direction [3].

cu fly


[3] https://wiki.openstreetmap.org/wiki/Key:direction


Am 27.12.2014 um 23:56 schrieb François Lacombe:
 I suggest to focus on what is actually approved.
 
 Like location=*, usage=* or substation=*, main proposal features like
 pipeline should be described on a dedicated key page
 Those feature key pages will use some of these tags (like support=*) and
 give the values which correspond to.
 
 If man_made=surveillance want to use support=* key, values should be
 given on man_made=surveillance page.
 
 
 Furthermore, a dedicated support=* key page can be created to explain
 how this tag is used and link to pipeline or surveillance page to have
 an idea of values in details.
 
 Such a structure will help a lot QA and tools maintainers to define more
 precisely their list of accepted values for each main feature (pipeline
 or surveillance for instance).
 
 
 Cheers
 
 *François Lacombe*
 
 fl dot infosreseaux At gmail dot com
 www.infos-reseaux.com http://www.infos-reseaux.com
 @InfosReseaux http://www.twitter.com/InfosReseaux
 
 2014-12-27 20:38 GMT+01:00 Rainer Fügenstein r...@oudeis.org
 mailto:r...@oudeis.org:
 
 hi,
 
 since the pipeline proposal was approved, I'm currently creating
 sub-pages for most tags used in the proposal. I took the liberty to
 create a page for support=* [1], as discussed earlier.
 
 two ideas:
 - support=* could also be useful for man_made=surveillance. the
 example picture in [2] prominently features a pole.
 - since surveillance cameras are often mounted on ceilings,
 I introduced support=ceiling.
 
 let me know if this is acceptable or requires a proposal.
 
 cu
 
 
 [1] http://wiki.openstreetmap.org/wiki/Key:support
 [2] http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsurveillance


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


  1   2   3   4   5   >