Re: [Tagging] Are rowboats covered by "boat=*" or "canoe=*"?

[Georg Feddern]

Am 23.06.2020 um 06:29 schrieb Joseph Eisenberg:
The wiki page Key:boat  
says that tag is to specify


"Legal access restriction for boats. In the sense of OSM these are 
small boats and pleasure crafts, including yachts."


The picture shows a "no rowboats" sign: File:A.16_Fahrverbot.svg 



But there is also a key canoe=* - the page Key:canoe 
 says:


"Legal access restriction for boats without a motor or a sail like 
canoes, kajaks or rowboats."


I can see how canoes and kayaks are basically the same, since both are 
narrow boats that usually carry 1 or 2 people and are propelled by 
paddles.


But should rowboat access restrictions be under this key 
canoe=yes/no/designated, or are they under boat=yes/no/designated - or 
something else?




I would consider a rowboat a 'boat' - but the problem is that the "No 
rowboat" sign does not mean the vehicle class but the 'drive' of the 
vehicle:

"A boat that is _not_ driven by motor or sail."
So it also forbids canoe/kayak.

So the access can only be determined correctly if a rowboat is 
considered with the access canoe=*.


E.g. the german regulations differ

a) by drive
- motor
- sail
- oars/paddle

b) by class
- sport (motor or sail boat/yacht - but not: canoe, kayak, rowboat, 
surf..., jetski)

- waterski
- wind-/kitesurfing
- waterscooter/jetski

So the access restriction boat=* could only be used for 'sport' boats 
with motor or sail.


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

Re: [Tagging] key, name, long or a partial abbreviation?

[Georg Feddern]

Don't

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

Re: [Tagging] How to tag pedestrian lanes?

[Georg Feddern]

Am 20.10.2019 um 23:23 schrieb Clifford Snow:
I'm not familiar with the laws of the country the picture [1] listed 
in the first post on this thread, but the diagonal yellow lines look 
to me like a don't park here rather than a sidewalk. Even the one 
pedestrian in the picture isn't walking the diagonal yellow lines. Can 
someone confirm that those yellow lines indicate a pedestrian way?


FYI:
https://www.bfu.ch/de/Documents/03_Fuer_Fachpersonen/05_Verkehrstechnik/Empfehlungen/bfu-Grundlagen/Laengsstreifen%20fuer%20Fussgaenger.pdf
https://en.wikipedia.org/wiki/Road_signs_in_Switzerland_and_Liechtenstein 
at 6.19


Regards
Georg

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

Re: [Tagging] How to tag pedestrian lanes?

[Georg Feddern]

Am 20.10.2019 um 11:24 schrieb Markus:

On Sat, 19 Oct 2019 at 23:02, Martin Koppenhoefer
 wrote:

+1, or e.g. sidewalk:right=lane
there are a few instances tagged like this: 
https://taginfo.openstreetmap.org/tags/sidewalk%3Aright=lane

18 out of 30 are additionally tagged sidewalk=right. I think it's
better to keep "sidewalk" out, otherwise it gets too confusing.


Why not in analogy to cycleway=track|lane|...
sidewalk=track|lane|...
sidewalk=yes (as synonym for kerb) was thought too short ... again.

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

Re: [Tagging] Clarification unclassified vs residential

[Georg Feddern]

Am 20.02.2019 um 10:22 schrieb Florian Lohoff:

So for me retagging residential to unclassified is broken under the
assumption that unclassified is something "better" than residential.

It is even more broken when there is residential usage in which case
unclassified is inappropriate.

While discussing i found that there was some modification to the German
version of unclassified not saying that unclassified is something
"better" but suggesting that an unclassified should be dragged into
city limits until the next higher class street. This lets user
assume that unclassified is some higher priority than residential.


I was treating those streets identical for the last 10+ years and only
the city limits gave the indication whether to use unclassified or
residential.

Am i wrong with that usage?


Even the english wiki says:
"The tag highway 
=unclassified is used 
for minor public roads typically at the lowest level of the 
interconnecting grid network."


As part of the interconnecting grid network it should connect to at 
least unclassified or higher roads - unless it is a dead end settlement.
Tagging a through connecting road only because it is inside a city limit 
as residential makes no sense.
And usually a connecting road from outside a city limit has at least a 
bit more traffic as an inner-city-only residential.
So the conclusion an unclassified has a bit higher priority than a 
residential is not far from reality.


Otherwise there is often the problem to tag the main access roads inside 
a bigger residential area.
The practice to tag those as unclassified for a bit higher priority may 
not be optimal - but suitable.


This discussion - and usage - is some years old now - and I thought you 
had at least knowledge of it from the german forum.


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

Re: [Tagging] Creating shop=caravan

[Georg Feddern]

Am 15.01.2019 um 14:43 schrieb Marc Gemis:

On Tue, Jan 15, 2019 at 1:55 PM Georg Feddern  wrote:

tourism=caravan_site is the one where you (at least in Europe) only can
stay with motorhomes (selfpropelled) - but not with caravans (towed).


but the wiki states on
https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcaravan_site
"A caravan site, caravan park or RV park is a place where people with
caravans / motorhomes / recreational vehicles can stay overnight"

only tents are not mentioned.


Yep - that is exactly, what I intended:

It is the agreed meaning in OSM, tagged with a word (language) that is 
the opposite of the real usage in some countries.
Now search as a user a place where you can rest overnight or stay some 
days with your caravan (camping trailer!) while driving through good Ol' 
Germany. ;-)


Georg

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

Re: [Tagging] Link roads between different highways type

[Georg Feddern]

On Tue, Jan 15, 2019, 11:52 Saeed Hubaishan  wrote:


About the subject I used to tag the link with the lowest way class
but in:

https://wiki.openstreetmap.org/wiki/Link_roads_between_different_highways_types

it guides to use the hightest way class. I think this is not right
behavior link from motorway to tertiary way is tertiary way not
motorway, and so.

What do you think about this?



Am 15.01.2019 um 13:19 schrieb Johnparis:
> I agree with you.
>
> For roundabouts and circular junctions, I use the highest type. For 
link roads, the lowest.

>
> I could see an exception for motorway onramps, indicating "starting 
here you can't get off the motorway".

>
>

I could agree with you - with the exception of motorway on- and 
off-ramps, which are always motorway_link up to the end of the motorway 
regulations.


Georg

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

Re: [Tagging] Creating shop=caravan

[Georg Feddern]

Am 15.01.2019 um 00:29 schrieb Dave Swarthout:


Now, if we could only get rid of tourism_caravan_site and replace it 
with tourism=campground. Sigh. That'll never happen but it should.




whoow - please do not stumble over the next misleading OSM-keys. ;-)

I think you mean tourism=camp_site, which is used for placing tents, 
caravans and/or motorhomes - as campground?.


tourism=caravan_site is the one where you (at least in Europe) only can 
stay with motorhomes (selfpropelled) - but not with caravans (towed).
But I am quite sure, that is different for the USA, Australia ore other 
'english' countries - may be even for the Brexiters. ;-)


Language: You can use every word for every meaning - you just have to 
agree about what the meaning is. ;-)


Georg

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

Re: [Tagging] Creating shop=caravan

[Georg Feddern]

Am 07.01.2019 um 08:20 schrieb Graeme Fitzpatrick:

& here we go: https://wiki.openstreetmap.org/wiki/Shop%3Dcaravan :-)

Seeing that apparently it's already been used 130 odd times, can I 
take that we don't actually have to RFC & vote on it?


May be not necessary to RFC & vote - but I think to discuss (may be I 
missed that part already?)


You intend to summarize up caravans, motorhomes and tents.
But I mostly know of 'specialised' shops:
- motorhomes only
- caravans only
- tents only

(OK, I also know some 'supermarkets' with combinations.)

At least I want to find the right dealer for me (e.g. motorhome), so it 
would be necessary to distuingish them.
Because there are mixed shops and all fall under caravaning, I suppose a 
subkey would be necessary - but yet I did not found a useful one or know 
a possible new one.


Any ideas?

Regards
Georg

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

Re: [Tagging] wheelchair designated parking space tagging?

[Georg Feddern]

Am 04.01.2019 um 23:22 schrieb Warin:
Possibly there needs to be a main wiki page for 'disabled' features 
tagging, toilets, tactile paving, parking, access.


On 05/01/19 07:58, Paul Allen wrote:
On Fri, 4 Jan 2019 at 20:44, Richard > wrote:


looking through the wiki can't find how parking space designated
for wheelchair/disabled users should be tagged?




Having a main page - and actualize it - is a really kind service.
BTW: https://wiki.openstreetmap.org/wiki/Key:wheelchair _is_ such a main 
page.


But I do not understand, why people who look-and-not-found something in 
the wiki do not _search_ it.

https://wiki.openstreetmap.org/w/index.php?search=parking+disabled=Special:Search=default=1=43w1ocpu8z9o2545k2x9jn3vd
https://wiki.openstreetmap.org/w/index.php?search=parking+wheelchair=Special:Search=default=1=bquqcdlt1bi3tzdtjohslf972

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

Re: [Tagging] issues with the list of deprecated features

[Georg Feddern]

Am 15.10.2018 um 16:38 schrieb Martin Koppenhoefer:



Am Mo., 15. Okt. 2018 um 14:21 Uhr schrieb Tom Pfeifer 
mailto:t.pfei...@computer.org>>:


On 15.10.2018 10:57, Martin Koppenhoefer wrote:
> 3. amenity=creche and amenity=nursery
> For both tags amenity=kindergarten is suggested as alternative
tagging, which seems clearly wrong
> (kindergarten is usually for ages 3-6 while these tags are for
ages 0-3).

I thought the consensus was here that it depends on the country.
In Germany, I see mostly the "Kita"
(Kindertagesstätte) structure which in the same institution enrols
age 0-6 in different departments
or groups, and a lot offer afterschool supervision (Hort).
This is easily expressed with the min_age + max_age tag, and some
folks use after_school=yes.



For the German situation, KiTa and Hort should/could well be tagged 
with childcare, but "Krippe"? And if we decide to tag a Krippe 
(creche/nursery) the same as a Hort or KiTa, but with age tags, isn't 
that inconsistent with Kindergarten? From my point of view, Hort and 
KiTa are both childcare places which extend beyond the times of 
kindergarten and school (and are after those, typically), while a 
Krippe is for babies up to 3 years and is more like a Kindergarten, 
apart from the age. It would really be much more logical and easier to 
introduce / accept nurseries (there's a reason there is a specific 
term for this in language, no?), then throw most but not all of 
"child-related-stuff" in the same cauldron where you will have to dig 
for age group and other specfic tags in order to make sense of it.


There is always a reason having a specific term for different parts of 
childcare - it is simply easier to talk about a Krippe(nursery), 
Kindergarten, Hort(after school club) instead of a childcare with 
age_group 0-3, 4-6, 7-14.
And it is quite logical to take these terms as tags - in the first 
attempt 
But is it really easier to end up with three different amenities - and 
so with different POIs - for a childcare which enrols all age groups?
Nevertheless the min or max age sometimes differs at the same sort of 
institution - so you may look e. g. after a hort but still have to check 
for the valid age anyway.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

[Georg Feddern]

Am 17.09.2018 um 16:17 schrieb Florian Lohoff:

is it intentional that StreetComplete tags the maxspeed source/type in
maxspeed:type instead of the much more used source:maxspeed?


If you search the german forum you will find that it is indeed intentional:
StreetComplete wird maxspeed:type taggen by westnordost
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] highway=service // public road?

[Georg Feddern]

Am 23.05.2018 um 22:33 schrieb Greg Troxel:

Florian Lohoff  writes:


I now see increasing usage of service roads as a category below
unclassified. People tagging "smaller roads" in the countryside
as a service roads.

I think this is basically wrong tagging.


I find this a little disturbing and now got into an argument whereas
my position is the above - broken down into my more strict language:

- If the public has a right of way
- The road is build/run by public authorities
- Its not something obvious like a parking space
- It cant be service

It might not fit 100% everywhere, but no rule without its exception.

Broadly agreed with your concerns.

A very important characteristic of a place you can drive is

   - it is legally a road, where more or less anyone has a right to
 drive (and this can be public ownership or private).  Typically this
 means that the ground on which it is built is carved out as a
 separate lot for ownership (or government owned).  This can be
 government, or it can be a road in a subdivision which is in the US
 marked "private way" meaning that it is legally a road but privately
 owned.  You can still get a speeding ticket on it, because the road
 use rules apply to private ways, but do not apply to what you do in
 your farm field.

 Whether they apply in a shopping center is an interesting question.
 I'd say: yes, you will be cited, and probably that does not hold
 up.  But in some places (north carolina), the property owner can put
 up signs that the traffic laws apply anyway - I saw these at the
 biltmore estate.   Basically "this is private but the unwashed
 public is here and we want the police to be able to bust them" :-)

   - not legally a road, in that there is no right of access, traffic
 laws do not necessarily apply, and there is no separate parcel for
 it

This is basically
"highway=primary/secondary/tertiary/unclassified/residential" vs
"highway=service/track".

It would be goo to have this be


That's a wonderful theory - and you get a 'stew' mess of unclassified if 
you do that in mapping the reality ...
The mapping differentiation in unclassified (mostly connecting roads), 
service without service=* (mostly destination roads) and track (for - 
due to history - public accessible rural driveways) is simply driven by 
reality.


The first we had at navigating in the late 199x'/early 200x - resulting 
in advising horrible routes through undesirable ways.
With the latter you have a reasonable routing (and rendering too, by the 
way).


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

Re: [Tagging] route/forward/backward members in all types of routes

[Georg Feddern]

Am 10.01.2018 um 12:32 schrieb Ilya Zverev:

Selfish Seahorse wrote:

The course of the route is determined by the order of the stops in the
route relation. Therefore forward/backward roles would be redundant.

But stops are not mandatory in public transport routes, unlike 
highways/railways!
I am quite sure that in _reality_ a stop _or_ a platform is mandatory in 
a public transport route - otherwise you would just have a route with 
'hitchhiking'?

PTv1 - zero or more for both - aha ...
PTv2 - mandatory for both, but if may be only one is present, the other 
is not really mandatory anymore - aha ...


There is a reason for that I only map highway=bus_stop ...

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

Re: [Tagging] Road barrier

[Georg Feddern]

Am 28.11.2017 um 11:54 schrieb Selfish Seahorse:
On 28 November 2017 at 11:26, Georg Feddern <o...@bavarianmallet.de> 
wrote:

Yes, unfortunately the european common-in-use traffic sign "VEHICLES
PROHIBITED EXCEPT MOTORBIKE/SIDECAR" or "Prohibited for any 
double-tracked

motor vehicles" has no equivalent in the OSM access scheme.
I think it is time for a =double_tracked (motor vehicles)!

Are there places where only motorcars are prohibited, but other
double-tracked motor vehicles are allowed?


I do not know of any, but ...


  Otherwise, the
description/meaning of motorcar=* could be adjusted.


-1
motorcar=* is needed, because there are places, that are allowed for 
them _only_ (see parking).
But Dave is right - the implication of motorhomes under motorcar is 
'very unfortunate' too - for the same reasons.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Road barrier

[Georg Feddern]

Am 28.11.2017 um 10:00 schrieb Martin Koppenhoefer:
On 27. Nov 2017, at 13:51, Selfish Seahorse > wrote:



Sorry for asking again, but does anyone know if motorcar=no implies
that there is no access for all multi-track motor vehicles or only for
motorcars?


In case hgv are permitted I’d explicitly tag it with hgv=yes, but 
according to the wiki, motorcar only implies motorhome:

https://wiki.openstreetmap.org/wiki/Key:access


Yes, unfortunately the european common-in-use traffic sign "VEHICLES 
PROHIBITED EXCEPT MOTORBIKE/SIDECAR" or "Prohibited for any 
double-tracked motor vehicles" has no equivalent in the OSM access scheme.

I think it is time for a =double_tracked (motor vehicles)!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Bus relation - circular route - report says not closed

[Georg Feddern]

Am 19.05.2017 um 04:21 schrieb Warin:


P1) JOSM validator reports that the relation is not closed. Yet all 
elements appear and they are connected.


I cannot verify/reproduce the first part/sentence with JOSM (11639 / 12039).
As the relation editor indeed does verify and show the 'circular' aspect 
of the relation it could anyway be only a validator bug.


P2) Roles forward/backward are apparently no longer used, and a role 
to indicate that both directions does not exist. Yet these may assist 
to have these kinds of roles?


Not necessary - see above. 'Used' direction is always defined by order.

P3) stop_position ... left side or right side of the way? On a train 
line this probably works well .. on a road that has traffic in both 
directions with parking on both sides .. stop_position does not have 
all that much information.


Yep, thats the way of OSM - the information is in the order of the 
relation and the platforms.



Thoughts?


Done. ;-)

Georg


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

Re: [Tagging] Anti-slip surfaces

[Georg Feddern]

Hi,

Am 17.04.2017 um 22:58 schrieb Dave F:


What's the best tag to describe an anti-slip surface made from small 
grit pieces coating a layer of bitumen?. Often used on footbridges, 
sometimes pre-made & supplied in rolls to the site. Grit/gravel on 
their own appears inappropriate as they suggest a certain amount of 
looseness. 


it may be not 'the best' tag - but is it not very similar to 'asphalt'?

Georg

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

Re: [Tagging] Traffic sign relevant direction: relation type:enforcement vs. direction=* vs. traffic_signals:direction=*

[Georg Feddern]

Am 27.03.2017 um 17:29 schrieb Martin Koppenhoefer:


2017-03-27 16:34 GMT+02:00 Marc Gemis >:


In the case you have added e.g. a stop sign on the way. A second
mapper comes in, splits the way on the stop sign, reverts the
direction of one of the spit parts. Now the node is at the end of 2
ways with different direction and one cannot know what is
forward/backward in that node. But any good editor can give a
warning/error for such a case.



yes, the editor can issue a warning, but what should be the reaction 
then? Shall we discourage changing way directions because of a stop 
sign node on this way? Usually there's a good reason for people 
changing way directions, adding more complexity to these changes with 
highway signs depending on them is not necessary.


It is just a warning, that this is one of the seldom situations where 
you need a relation - just check, obey and ignore afterwards.

Furthermore the editor can check for the relation too.

Yes there is a possibillity for such a situation, but I doubt they would 
be essentially - and it can be solved by a relation.
But a pure possibility should not effect the majority of simple 
situations - it is OSM-like to consider simple solutions and spare 
relations for the difficult ones only.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Busways

[Georg Feddern]

Am 02.11.2016 um 22:57 schrieb Tijmen Stam:

On 02-11-16 20:27, Martin Koppenhoefer wrote:


careful with access=no, I suggest to use vehicle=no in this case, 
because you risk of excluding pedestrians (and other means of 
transport you didn't think about) as well (happened around here in 
the real life).


That's a good one, although the way most busways are signed (with a 
round "no access" sign red border on white circle) in the Netherlands 
that means no access at all, not even to pedestrians, not even in the 
hard or soft shoulder. 


You mean C1?
If I read it right, it is just closed to "persons in charge of animals 
or livestock" - but not for pedestrians at all.

Or did I misunderstood you?

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

Re: [Tagging] [Talk-us] Freeway exit tagging

[Georg Feddern]

Am 26.08.2016 um 14:18 schrieb Kieron Thwaites:

I can, however, see the rationale behind tagging "none;slight_right",
as well as tagging nothing at all, and as such, I think that this is
an issue that we need to find consensus on.  That said, I believe Paul
is quite correct with his statement that machines "need to be told
about these restrictions in order for them to be able to provide
useful feedback from it" -- something that isn't explicitly present
(or maybe not even implicitly so) but appears obvious to a human on
the ground isn't necessary obvious to a machine.


Please do not take it personally - I just toke your answer to hook on, 
because you agreed on "machines need to be told about these restrictions".


May be I am a bit on the devils advocates side here ... ;)

1. Where are there any restrictions? There is no solid line between the 
3 lanes. ;)
2. If you want to give the machine any advice, you should take 
"through|through|through;slight_right"

because
3. "none|none|none;slight_right" does not give any advice for the both 
left lines - they still could be considered to take the exit.
Well in reality that is the legal situation here - you just have to take 
care for the traffic on the lines. ;)


But in this common case (standard single lane exit) I still do not see 
any necessarity for any advice to the maschine (or the driver), that if 
the route takes the right road one should use the rightmost lane ...
Same situation with solid lines definitely need case 2 - because even 
you should 'implicitly know' to take the rightmost lane there is another 
point where you already _have_ _to_ be on the rightmost lane - the 
maschine needs this advice to announce it appropriate.


But may be I am a bit too old and have driven too long with my own eyes 
and head - and without a navigation assistant. ;)


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

Re: [Tagging] Freeway exit tagging

[Georg Feddern]

I consider the visual lane assistance as it is named - as an assistance 
useful where there are several options.
If there is no assistance anybody who get the advice "take the exit" 
(*)  should obviously use the rightmost lane.
So even _no_ turn lane tagging would be an option for me in this (quite 
normal) case.


(*) Please do not cry "What about left-hand driving" - it is a 
right-hand example!

And any unusual left exit _should_ be tagged with lane assistance.

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

Re: [Tagging] Tagging of larger surfaces for rendering and routing

[Georg Feddern]

Am 14.08.2016 um 23:24 schrieb Stefan de Konink:

On zondag 14 augustus 2016 22:43:04 CEST, Marc Gemis wrote:

IMHO, the value of the highway tag should define its use, not the
surface from which it is made.
So highway=pedestrian (or service or ...), surface=grass; area=yes
makes more sense to me

(or would you start defining highway=paving_stones, cobblestones, etc.
as well ?).


It seems that many people in this discussion take the value "grass" so 
something extreme. The fact grass is used, is because it is currently 
hides the surface in the rendering, and no other common value of 
unpaved areas exists that fits the bill. Personally I find 
highway=service, surface=grass, area=yes appropriate for the camping site


For the whole camping site? Won't there be always some - at least 
virtually - defined parts for the tents/caravans (pitch) and some 
defined parts for the driving (ways)?



but not when it rendered as paved road.


It is not rendered as _paved_ road, it is rendered as _road_ ("part of 
the world where mainly rolling traffic will occure").


It is part of the renderer to decide, which part of the mapping he will 
show - based on the intention of the renderer.
A highway renderer will show the highways - always in contrast to the 
surrounding, even if they have the same surface.
A surface renderer will show the surface - and will ignore the 
difference of the use/service.
Even a mixture is possible with casing and filling - may be that's what 
your intention is.


Just by the seperation of the meaning 'using' and 'surface' - and just 
and only by the seperation in different tags.

It is simply not neccessary to mix them up in one (main) tag.

If you have
tourism=camp_site
highway=service
camp_site=camp_pitch
- and all with surface grass
you have all opportunities for all different rendering - it just depends 
on the chosen renderer.





A renderer could look at the surface tag to colour the area. No reason
to start inventing new values for the highway tag.

+1


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

Re: [Tagging] nursing homes and group homes

[Georg Feddern]

Am 27.06.2016 um 12:17 schrieb Martin Koppenhoefer:


+1 to
social_facility=nursing_home



Just some days ago I had to change with my father from a retirement home 
(with ambulant care) to a nursing home with 24/7 care.


I looked at the social_facility scheme - stumbled about the disclaimer - 
was really confused at first - and changed the tagging then.


First off all I understood the meaning of 
social_facility=group_home;social_facilty:for=senior for a retirement 
home / group home - as written in the description.
But looking at social_facility=assisted_living _that_ describes a 
retirement home / group_home - at least in my opinion and understanding 
of the description.


So I understand:
retirement home /group home as social_facility=assisted_living
nursing home as social_facility=group_home

Does not really make sense of the tag names itself - but of there 
description.


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

Re: [Tagging] Tagging natural or historic regions

[Georg Feddern]

Am 28.03.2016 um 08:28 schrieb Martin Koppenhoefer:

Am 27.03.2016 um 21:59 schrieb Colin Smale :

If we can't mark polygons as fuzzy, then we can only allow 'accurate' polygons

well, as was proposed above, we could introduce a way to store fuzzy areas 
without using polygons, or by using more than one polygon as one object


May be: Using a minimum (core area) and maximum (extension area) 
estimation as one relation.



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

Re: [Tagging] service = parking_access for main ways on a parking lot

[Georg Feddern]

At all - what's the matter with the already said "highway=service" only 
if you can not distinguish the service or if it is a "bigger" service road?


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

Re: [Tagging] boundary relations and the subarea property

[Georg Feddern]

Am 27.11.2015 um 15:46 schrieb André Pirard:
Have you noticed that some borderlines are *hexaplicated* (that they 
appear in 6 different relations) and that *that* is unhealthy 
redundancy that is made unnecessary by subareas?


And that, unlike wanting to destroy an enemy, the programs I spoke of 
would be a great help building and checking the boundary ways mess 
using the non duplicated, simple, clean UK=England+Wales+Scotland 
subarea definitions?


Well, next usecase then:
I want the border/outline of any of those entities ... and not the area.
Mostly there are two sides of a view - or two views on one problem ...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] improve tagging of traffic_calming

[Georg Feddern]

Am 20.11.2015 um 18:24 schrieb Gerd Petermann:

I found 940 nodes which were tagged with highway=traffic_calming.
Most of them were also tagged with e.g. traffic_calming=bump
or traffic_calming=table or one of the other well documented values.
A few were not tagged traffic_calming=*.

I changed those few to traffic_calming=yes and removed the obsolete
highway=traffic_calming tag from the other.
I also verified that the changed nodes are on a highway=* way.



If the highway=traffic_calming is obsolete in those cases -
why isn't


A few nodes were tagged with crossing=*, in those cases I added the tag
highway=crossing (and kept the traffic_calming=* tag)


highway=crossing obsolete in this cases?

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

Re: [Tagging] improve tagging of traffic_calming

[Georg Feddern]

Am 20.11.2015 um 17:29 schrieb Marc Gemis:

On Fri, Nov 20, 2015 at 5:23 PM, Florian Lohoff  wrote:

http://www.mapillary.com/map/im/LeaK3riwsMuv7f0i3Jt3XA/photo

I would tag the crossing as a node and the "table" as part of the way,
not as a node.


If it is really enforced to identify a traffic calming only by presence 
of highway=traffic_calming - this is the only way because



but a combination of highway=crossing; traffic_calming=table on a node
could work as well.


won't be identified as a traffic calming then.

Otherwise:
If a node with highway=crossing and with traffic_calming=* should be 
identified as a traffic_calming

we won't need highway=traffic_calming anymore ...

Regards,
Georg

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

Re: [Tagging] How to tag a fence made with metal bars?

[Georg Feddern]

Am 05.11.2015 um 15:59 schrieb Gonzalo Gabriel Pérez:

Hi everyone,
I'm reading in the wiki ( 
http://wiki.openstreetmap.org/wiki/Key:fence_type ) about the 
fence_type key and I think that it ambiguous the way that is described 
how could be tagged a fence made with metal bars like these, see pictures:


http://www.puertasblindalock.com.ar/images/reja-de-seguridad-2.jpg

http://4.bp.blogspot.com/_3mO9j6PCOQc/S3lYvlCmEaI/AAM/uBmMExArTnI/S660/35150559_1.jpg

http://www.elforjador.cl/img/galeria/el_forjador_reja_3.jpg

Which values between 'bars', 'wire' and 'metal' should be used?



All your examples are just ' metal' - because - in my opinion - the 
pictures for 'bars' and 'wire' are just wrong.
Under 'wire' I would understand some simple wire (one or more 
horizontal) between the poles - wire like in 'electric'.
Under 'bars' I would understand some simple 'bars from metal between the 
poles - like the horizontal poles in the wooden 'pole' example.


Regards, Georg

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

Re: [Tagging] traffic_sign:forward=*

[Georg Feddern]

Am 03.11.2015 um 17:43 schrieb GerdP:
I read the wiki a few times and still did not fully understand how 
this traffic_sign:forward idea should work.


If you read (and use) _only_ traffic_sign:forward - I suppose you read 
only the german wiki page and then I understand your problem, because 
that can not work in all cases.
If you read the english wiki page, you may understand the intention 
better - as there is also a traffic_sign:backward variant mentioned.


It shall work as in reality and as "computered" in the human mind:
Transform the information from the sign (node) to the way in the 
relevant direction - with all possibilities, but even all obstacles also ...


I do not support this "node on way" strategy - I use only the node 
beside way as tagging for the sign itself - and "always on the right 
side" ;-) - at least here in Germany.


Georg

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

Re: [Tagging] tunnel=culvert

[Georg Feddern]

Hello,

Am 25.10.2015 um 11:44 schrieb Gerd Petermann:


I do not fully agree here. In Germany, I often see a traffic sign 
"Vorsicht Düker"


(~ "Attention! Culvert") next to these culverts.

I am not sure why I should pay attention, but it seems that some

people think that the traffic on the road should notify it.

Maybe because it also often means that there is a

barrier=fence along the road.


In fact I thought that these signs are the explanation for the

use of tunnel=culvert on a node.




please be careful:
A "Düker" is not a normal "culvert"!
At a culvert the water is flowing on the same level in the culvert, 
normally with airy room above water level in the culvert.
At a "Düker" the water is "pressured" on a level below the normal water 
level through the "Düker", so there is no room above water level.
The normal road traffic has not to obey these sign - but any street work 
or use (crawling ;) ) at the waterside.


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

Re: [Tagging] manège - area for horse training

[Georg Feddern]

Am 15.10.2015 um 22:57 schrieb Warin:

On 16/10/2015 7:08 AM, Volker Schmidt wrote:


What the picture shows is a Carrière, which is to be tagged as
leisure=pitch
sport=equestrian




+1

And someone will now say that it is not a sport... just like for 
cricket_nets ...


Anyone for another key sport_practice?

Would have similar values to the key sport but used for 'pitches' that 
are only used for practice/training as they cannot be used for the 
full 'sport'.


-1

Ever worked/trained with horses?

What is the key definition for sport?
Concentration? Reactions? Best moves? Power?

Is a carrière
- sport_practice when there is just training
but
- sport when there is a competion?

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

Re: [Tagging] Pubs with accommodation

[Georg Feddern]

Am 28.09.2015 um 14:46 schrieb Andy Townsend:


Depends on the pub, I'd say.  Some places are both a hotel and a pub, 
some have essentially separate "hotel" and "pub" bits (for which 2 
nodes within a building might work)  and some (e.g. 
http://www.openstreetmap.org/node/75844692 ) are pubs that do 
accommodation, but not really hotels, so I'd use accommodation=yes for 
those.




Why not the already established tourism=guest_house for this B offer?

Regards,
Georg

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

Re: [Tagging] waterway=derelict_canal

[Georg Feddern]

Am 27.08.2015 um 18:49 schrieb Philip Barnes:

A disused pub, providing it still looks like a pub, is still a useful
navigational feature. Pubs have always been the normal way of giving
directions.
http://www.mapillary.com/map/im/PrKK4Y3JBpdF3jg6fnLM1g/photo

Turn right by The White Horse, carry on passed The Old Post Office and
Castle, turn left by the White Lion then left again by The Hawkstone.

What could be simpler?


Well - it is simple.
But what you refer to is the simple _name_  - and that name may be still 
there in OSM if it's still sitting on the wall or sign.

In opposite to the amenity ...

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

Re: [Tagging] To tag opening_hours=by appointment

[Georg Feddern]

Am 30.06.2015 um 19:15 schrieb Robin Schneider:

On 30.06.2015 14:04, Marc Gemis wrote:

in the local language (e.g  123 nach␣Vereinbarung
http://taginfo.openstreetmap.org/tags/opening_hours=%22nach%20Vereinbarung%22
--
German for by appointment)
IMHO this means that there is nothing to formalize. This also means that
...Sa 09:00-18:00 + appointment is a comment and nothing has to be parsed.
This should be  ...; Sa 09:00-18:00; Sa also by appointment

Better express it as: Sa 09:00-18:00 || Sa only by appointment


I understand Warin as:

Sa 09:00-18:00  Sa only by appointment


  On 30/06/2015 8:09 PM, Warin wrote:

The above example could become Mo-Tu,Th-Fr 09:00-13:00,14:00-18:00;We

To mean that an appointment is required for Saturday between 9 am and 6 pm.






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

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

[Georg Feddern]

Am 14.04.2015 um 07:28 schrieb Mateusz Konieczny:

On Tue, 14 Apr 2015 00:08:31 +0200
Volker Schmidt vosc...@gmail.com wrote:


https://upload.wikimedia.org/wikipedia/commons/6/69/Separated_cycle_and_foot_path.jpg


I would add also surface (and maybe smoothness) as this one seems
to be quite bad.


3) How would you tag the segregated cycle-and-foot-way shown in


Also, I would add also surface (and maybe smoothness) as this one
for footway/cycleway seems to be quite bad.


No wonder that smoothness ist supposed to be totally subjective - I 
would tend to the opposite quite good ...


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

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

[Georg Feddern]

Am 25.09.2014 11:48, schrieb Pieren:

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


Definitely now we all know that there are different opinions for e.g. 
gravel as paved or unpaved at mappers and consumers.


And where is the benefit to manifest the paved/unpaved meaning in the 
database?

Beside edit wars I see absolutely nothing ...
I vote for inconsistencies between applications - and not between mappers!

A second tag would not change the mind of a consumer about the meaning ...

Georg

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

Re: [Tagging] Proposed change to Tag:access=designated page

[Georg Feddern]

Am 24.08.2014 12:43, schrieb Friedrich Volkmann:

For me, designated means that there's a respective sign, e.g. a cycleway
sign = bicycle=designated.


yes that is the typically (non native-language?) (mis)understanding of 
designated - and guided by the phrase A way _marked_ for a particular use.


Nevertheless e. g. all highway=residential are _designated_ by law - 
without any signs at all... - which leads to _my_ understanding of 
designated ...


Georg

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

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

[Georg Feddern]

Am 01.07.2014 12:34, schrieb Matthijs Melissen:
On 1 July 2014 11:25, Janko Mihelic' jan...@gmail.com 
mailto:jan...@gmail.com wrote:


If I'm right, this will mostly affect pedestrian areas
(highway=pedestrian + area=yes) that have buildings mapped over them.


Yes, that's correct.


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


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

Re: [Tagging] editing polygons in JOSM

[Georg Feddern]

Am 27.05.2014 21:12, schrieb Peter Wendorff:

Am 27.05.2014 20:23, schrieb Tom Gertin:


1. Clip a polygon using another polygon
2. Cut a polygon using a line

Cutting by a line is easy:
[...]
Clipping by a new polygon is basically the same - but draw that new
polygon first instead of the line, then proceed as described above.

As far as I know there is no automatic way to do one of these.


I would recommend the plug-in utilsplugin2.
This will give you new tools, e.g.:
- Add nodes at intersections
- Split object

This will automate some, but not all of the neccesary steps.

Georg

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

Re: [Tagging] simple_brunnel : one node bridge like xing highway over waterway

[Georg Feddern]

Am 03.04.2014 21:43, schrieb Richard Z:

On Thu, Apr 03, 2014 at 06:08:46PM +0100, Dave F. wrote:

On 02/04/2014 17:14, Richard Z. wrote:

as explained in the rationale the dimensions of the bridge/culvert
are frequently only a fraction of the achievable precision. Think
of a track crossing a small creek in a forest valley int the
mountains. The GPS precision will be 10 meters if you are lucky,
the brunnel 2-3m. Mapping this the old fashioned way will produce
junk data, not precision.

Rubbish. Please don't rely on a GPSr. It is only one, of many, ways
to survey. If I see a small bridge over a stream, say 3m I'll map is
as that, because that's how it accurately is in the real world. Some
users have access to detailed aerial imagery to help map accurately.

so again: *** a small creek in a forest valley int the mountains  ***

Where is your aerial imagery? I want that!!

In the mountains you are very lucky if your imagery has less than 10 meter
offset and forests render most aerial imagery useless.


The offset (either GPS or imagery) has influence on _where_ you can map 
the bridge - but not much on _how_ you are able to map it.
I'm neither a friend of a crossing node when there is no connection in 
reality.

Missing or loosing the bridge tag I would always assume a ford there ...

Georg

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

Re: [Tagging] surface=ground/dirt/earth

[Georg Feddern]

Am 13.03.2014 15:56, schrieb fly:

On 13.03.2014 15:37, Fernando Trebien wrote:

But do you think that earth and ground are different kinds of surface?

Well, I would consider earth as earth where ground could be earth but
does not have to be.

All together, I think we could get rid of at least one out of the three
tags after updating the descriptions but this will not that easy with
existing tags in common use.


aehm, well - and which one would you get rid of?

Some times ago I remember a likewise identical discussion at the german 
forum.

AFAIK:

ground
Used for ways where the underground consists of different and often 
changing parts like rock, earth, vegetation (generic value) - as you say 
above.


earth
Used for ways where the underground consists of - well, earth (natural 
sand) constantly.


dirt
See above - the term seems to be outside of OSM used for a man made / 
constructed work - which inside OSM seems to be the (defined) value 
compacted.


So I would get rid of dirt, but keep 'earth' beside 'ground' as a useful 
value (smooth walking on hiking trails) .


Georg

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

Re: [Tagging] origin of some fire_hydrant tagging

[Georg Feddern]

Am 26.02.2014 13:23, schrieb Richard Welty:

i'm currently tinkering with what will be come a proposal to modify
current hydrant tagging.

my thinking is to add
   fire_hydrant:water_source={main,pond,stream,standpipe}
and deprecate fire_hydrant:type=pond


no objections except 'standpipe' - see below.


then the issue is whether we want to modify fire_hydrant:type or
replace it with a different tag altogether, say fire_hydrant:delivery
if we keep type, should we replace pillar with plug or fire_plug or just
let that go.


I would keep hydrant:type - because it is a physical type/design in my 
opinion.

With hydrant:delivery I would not assume the physical type, sorry.

And I would keep type=pillar.
With fire_plug I - and I suppose many others - would assume something 
you can connect with or to.

And that are all hydrants in any design, it is too generic in my opinion.

Regarding standpipe:
I would understand 'standpipe' as the device you need to connect to 
underground hydrants.
So I would not use standpipe for hydrant:source but 'riser' instead, may 
be distuingish between dry_riser or wet_riser.


Georg

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

Re: [Tagging] origin of some fire_hydrant tagging

[Georg Feddern]

Am 25.02.2014 17:08, schrieb Richard Welty:

i'm wondering if anyone can speak to where the tagging
for fire_hydrant:type came from?


AFAIK the Germans are guilty again - and I plea myself for not-guilty. ;-)
(see http://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant 
and their history)


And yes - pond does not really match a hydrant 'type' - the hydrant type 
there may be still a 'pillar' or an 'underground', less a 'wall'.


Is it possible, that in UK/US the 'pillar' type is the norm and the 
'underground' type is not wide spreaded?
At least the http://en.wikipedia.org/wiki/Fire_hydrant uses the term 
'post- or pillar-type fire hydrant'

- but I do not know who wrote that.

At least there is a desire to distinguish between 'pillar' (or synonym) 
vice 'underground' vice 'wall'.


Georg

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

Re: [Tagging] wiki definition for man_made=works

[Georg Feddern]

Am 25.02.2014 22:06, schrieb John Packer:

Then I think I am confused too.
As the description is right now, what is the difference between 
building=factory and man_made=works ?


yes, that is the point of the thread opener:
man_made=works does not make sense for one building only.
I always tag man_made=works for the whole area of a work/factory complex 
of one operator (as one object).


landuse=industrial otherwise may be the whole industrial area with 
several works (it is a use, not an object).

It does not collide with man_made=works and can exist parallel.

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

Re: [Tagging] Feature Proposal - RFC - opening hours open until

[Georg Feddern]

Am 26.02.2014 09:19, schrieb Philip Barnes:


Surely you then need to define when curfew is, does it require a tag 
law=marshal? :)




I don't think so - that's an info you should know or get as soon as you 
need it - wherever you are.

Like the maximum speed without explicit signage - wherever you are.
Or the tax free amount of travel goods. :)



A more real world example, where hours vary, would be open sunrise to 
sunset, which is often used for rural car parks.





Yes - that's why opening_hours already support this. ;-)

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

Re: [Tagging] Feature Proposal - RFC - opening hours open until

[Georg Feddern]

Am 26.02.2014 10:21, schrieb Philip Barnes:


This is going off the tagging issue, but it is a bit scarry that you 
are casually talking about curfews, where outside places like North 
Korea do they exist?



A curfew to me, as a brit equals being arrested/shot for being on the 
street after a certain time.




oh, sorry, this may be a translation problem - my fault.
I used curfew (resp. take it from Martins post and looked it up in an 
online dictionary) in the meaning of legal closing time - the time, 
where all pubs (in an area) have to be closing by law - if they do not 
pay for a late concession/licence.
In German(y) this is called Sperrstunde - this term can be used in the 
same civil/opening meaning for pubs - or in military as you stated above .
Actually I do not know, if or where this is still in usage for pubs here 
- no need for that actually :) -, but I can remember, it was still in 
usage for pubs in my lifetime.


I thought England (or maybe Great Britain) is still using this for pubs.
At least, as this seems to be a problem, that causes the Prime Minister 
to intervene! ;-)

http://news.sky.com/story/1205719/world-cup-pub-opening-ban-overruled-by-pm

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

Re: [Tagging] Feature Proposal - RFC - opening hours open until

[Georg Feddern]

Am 25.02.2014 16:35, schrieb Robin `ypid` Schneider:

On 25.02.2014 16:27, Martin Koppenhoefer wrote:

I don't know in this specific (british) context, but my guess is that
12:00+ indicates (typically) until curfew, while late maybe has the
meaning beyond curfew.

All right. Interesting. If that is the case it might be better to write this
explicitly (using fixed times and comments) because it is probably not desirable
to add this to the syntax.


well, for those who want to know it's open late it _is_ quite desirable.
And if there are no fixed times, it is still open end but with 
different meaning.


The current syntax + does not diffentiate between until curfew and 
beyond curfew.

But this seems to be a desirable differentiation.
Why not extend the syntax with such quite clear definition?

E.g.
+ means open end until curfew
-late means open end beyond curfew

Georg

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

Re: [Tagging] Tagging lifeguard watch towers

[Georg Feddern]

Am 18.02.2014 14:40, schrieb Fernando Trebien:

There's a discussion going on in the Brazilian community on which is
the best tag for this. Among the suggestions are:
- emergency_service=lifeguard
- health_facility:type=first_aid

Thinking from the point of view of applications (rendering and
geocoding), I kind of feel that this may be a health amenity similar
to amenity=doctors/clinic/hospital.


I won't see them as a health_facility and would put them under 
emergency=lifeguard.

http://wiki.openstreetmap.org/wiki/Key:emergency_%28facilities%29

Georg

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

Re: [Tagging] one-directinal bicycle dismount on oneway road ?

[Georg Feddern]

Am 19.01.2014 12:06, schrieb Colin Smale:
In the UK there is a difference between no cycles and no cycling. 
Although in general you may be correct that a dismounted cyclist is 
effectively a pedestrian, there are also footways (or whatever you 
want to call them) signed as no cycles, which means that in these 
cases a dismounted cyclist is not equivalent to a pedestrian. 


Yes, I had that in mind, but that was not the question here. ;-)
(You get what you ask. ;-) )

If foot=yes (explicit or implied) implies bicycle=dismount which 
corresponds to no cycling, I would suggest that bicycle=no would 
then mean no cycles i.e. not even if dismounted.




Ouch - I won't mix this here.
bicycle=no is long time used and defined as traffic, as use, not as 
object.

So bicycle=no means no cycling a long time already.

For no cycles there should be a new tag.
There was a discussion some time ago.

But watch out for talking about what is legally allowed as it varies 
widely by country!




Georg

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

Re: [Tagging] noexit

[Georg Feddern]

Am 03.12.2013 14:48, schrieb André Pirard:




I agree to:
This tag is
- not necessary for routing
- senseless on ways
- only useful on nodes (the last one, where no other way is connected)

The wiki should be changed, especially the use on ways should be removed.


But I do not agree to


I doubt very much that this tags helps anybody or any quality-check 
program to understand anything. A note should suffice, and I think the 
best option would be to remove that confusing tag.


It is useful for quality-check programs to determine This is not a 
missing connection to nearby ways. (false positives)

A note would have to be clear and machine-readable for this case.

It might be useful for renderers as on a map it might look as a 
connection (because of oversize of rendered ways).

But this could be determined by preprocessing also.

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

Re: [Tagging] preproposal : internet webcam

[Georg Feddern]

Am 02.12.2013 11:31, schrieb Pieren:

Adding a sub-tag will simply move the current 21700
man_made=surveillance elements without subtags in uncertainty.


OK, that is a point, I agree here.


I still think that a (public) webcam could be tagged differently from
a CCTV because it's not the same purpose and not the same legislation
even if it is a camera and may transit throught the net. One is
public, the other not.
May I suggest:
man_made=public_webcam
website=*('url' is deprecated in the wiki)



May I suggest another direction to move in the situation?

I see a camera - but absolutely do not know which purpose it has.
Both opportunities (surveillance/webcam) are possible with this 
installation.

Which tag should I use then?
Shall I have to dig it out before tagging?
Or shall I simply ignore the camera and do not tag it?

If we want to extend the tagging, we should use a new but generic tag 
(camera?) in my opinion.
Yes, this may result in parallel tagging - but we should not run in the 
next cul-de-sac with one's eyes open.


Georg


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

Re: [Tagging] preproposal : internet webcam

[Georg Feddern]

Am 29.11.2013 13:03, schrieb Egil Hjelmeland:

On 29. nov. 2013 10:32, Jonathan wrote:

I would agree, I think that covers it.

A webcam is surveillance, it's a camera that is watching you making 
it available to anyone.  Some would say that is a greater 
infringement than an official camera that is regulated.


Maybe the wiki page needs re-wording to reflect that it doesn't 
matter who is watching just that if they're watching with a camera 
then it's surveillance.




I think we live in different universes. This is the kind of stuff I am 
interested in:

http://webcam.svorka.net/bollen/

http://webcam.sollia.net/image.jpg


not living, just thinking:
You can surveil the wheather condition, snow condition, forest fire 
there. ;-)


Well, I think I understand what you mean - I would have prefered a 
generic man_made=camera instead of =surveillance.

I normally can not decide which view angle, zoom or purpose it has.
Only: There is someone watching - but what and why?

Best regards
Georg


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

Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway

[Georg Feddern]

Am 14.11.2013 10:13, schrieb Martin Koppenhoefer:



Am 14/nov/2013 um 00:53 schrieb Robert Whittaker (OSM lists) 
robert.whittaker+...@gmail.com:

I don't see why you can't tag the roads you're talking about
with bicycle=no (or maybe something like bicycle=restricted for the
cases where more significant use is allowed) and then add a second tag
along the lines of bicycle:restriction=DE:use_cycleway to capture the
fact that the legal exclusion of bikes is because of X country's
parallel cycleway rules.


You shouldn't do it, because it would be wrong. There is no legal exclusion of 
bikes on the road, there is an obligation - under certain circumstances - to 
use the cycleway, this is a difference and should not be tagged like an 
exclusion of bikes on the road (e.g. like on a motorway)



@Martin:
Your reply is only valid for the first line of the citation.

@Robert:
The rest of the citation sounds better than the proposed use_cycleway 
- at least for me. But its just the name, not the intention, which is 
the same for both.
If there is a need for the additional tag of country-specific or if it 
may be as country-specific-implicit as other implications for highways 
already - I don't know.


Georg

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

Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway

[Georg Feddern]

Am 14.11.2013 10:47, schrieb Martin Koppenhoefer:



Am 14/nov/2013 um 10:40 schrieb Georg Feddern o...@bavarianmallet.de:

@Martin:
Your reply is only valid for the first line of the citation.


An approach which combines 2 tags in a way that the meaning is only true for 
the combination of both, but not for the single tag, does not work well IMHO. 
We shouldn't have tags like bicycle=no and with a second tag we say, hey, 
actually that is not a real no in this other tag over there.


yes, you are right!
The bicycle=no is missed in the first line of the citation (my 
fault)  - but was meant by me.


But my OK has gone for the bicycle=restricted instead of 
bicycle=use_cycleway.


Georg

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

Re: [Tagging] Feature Proposal - RFC - bicycle=use_cycleway

[Georg Feddern]

Even I am not Pee Wee nor any author of the proposal, but

Am 12.11.2013 19:29, schrieb Dave F.:


How does this improve mapping/routing over using bicycle=no?

How does your proposal distinguish the exceptions to the rule that you 
gave as an example below?


consider a muscular trike, which is clearly classified as a bike and not 
allowed to ride where there is a sign No bicycle.


The user/router knows, that this trike is not allowed or has to avoid 
simple cycleways - so the router has to use roads instead.

But the 'normal' road has a strict bicycle=no now without the sign.

Where shall he ride then?

Georg

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

Re: [Tagging] Usefulness of bicycle=dismount on ways

[Georg Feddern]

Am 16.10.2013 09:23, schrieb Volker Schmidt:
(this thread is so long now, that I  don't remember if I have inserted 
my problem  with bicycle=no/dismount)


Here in Italy we have heaps of pedestrian-only crossings, which are  
part of dedicated combined foot-cycle paths or even pure cycle paths. 
The legal requirements is that cyclists dismount to use them (which no 
cyclist does, but that's a different story).


Where did you get this legal requirement from?
As a tourist I wouldn't interprete the sign as forced to dismount, 
just as there is no combined footway/cycleway anymore.
In this case I would  just be carefully pay attention to the traffic 
situation - and go on as on every other combined road with motorvehicles.



This feature of JOSM indicates to me that there is most likely 
widespread use of bicycle=no on crossings with the meaning of 
bicycle=dismount.
(according to taginfo the combination crossing and bicycle is used on 
42000 nodes, bicycle=dismount is used on 1900 nodes, bicycle=no is 
used on 56000 nodes


A similar problem exists with cycle barriers (chicanes), where often 
bicycle=no is used to indicate that you have to dismount to pass the 
obstacle.


I don't know how routers handle these cases.

I fear that in the end we will be landed with the impossibility for 
routers to distinguish between bicycle=no and bicycle=dismount at 
least on nodes of type crossing and barrier.




You already got the point:
bicycle= no at OSM is always interpreted (and defined) as no cycling.
bicyle=* is an access role, a part of vehicle(!) traffic, not an object.
It does not say anything about dismounted yet - this is an 
interpretation of foot=* which is the implicit role in most cases then.


And in the majority of situations in the world this is the normal 
combination.
There are only some singular situations where pushing bicycles as an 
object is not allowed.
In this situations I am always puzzled, what I have to fear, if I would 
carry the bicycle like a suitcase or parcel/packet ... none I suppose, 
but I never was in such situation yet.


Georg


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

Re: [Tagging] Usefulness of bicycle=dismount on ways

[Georg Feddern]

Am 07.10.2013 19:13, schrieb Richard Welty:

On 10/7/13 1:08 PM, John F. Eldredge wrote:

I remember seeing such a cyclists must dismount on the narrow
footway of a bridge over the James River, in Richmond, Virginia, USA.
Not only was the footway narrow, [...]

there's a cyclists must dismount sign for the footway along the Dunn
Bridge between Albany and Rensselaer NY.


well, if it is tagged as highway=footway you already have to dismount - 
otherwise it would be tagged as highway=cycleway.

So where is the need for a bicycle=dismount here?

I only see the practical need for a bicycle:dismount=no where bicycles 
are even not allowed dismounted.


Georg

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

Re: [Tagging] Usefulness of bicycle=dismount on ways

[Georg Feddern]

Am 08.10.2013 20:16, schrieb Volker Schmidt:






Just for your reference - while for many cases, I agree that
bicycle=no
is appropriate, there are quite interesting cycleways in the Czech
Republic, where using bicycle=dismount for nodes on a path would
make things easier for people editing OSM. Consider this:
http://img.ct24.cz/cache/900x700/article/20/1936/193540.jpg
http://img.ct24.cz/multimedia/videos/image/646/medium/193542.jpg
(and don't ask me what idiot proposed a cycleway like this).


This is the standard way of doing things here in Italy as well. At 
every end of cycleway sign you are legally supposed to dismount and 
cross the lateral road as pedestrian


well, as it is also signed as the end of the legal footway/sidewalk - in 
my opinion it is no need for a _dismount_ there.
In my opinion it is just a legal backdoor, that on these driveways (or 
serviceways?) you leave the legal cycleway/footway (with the regarding 
legal rights above the otherwise crossing traffic) and have to obey the 
crossing traffic for your own risk - even as walker, but also as cyclist.


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

Re: [Tagging] Tagging of local produce

[Georg Feddern]

Am 03.07.2013 05:43, schrieb Bryce Nesbitt:
Some farm stands actually sell in-season produce direct off the 
adjacent farm.  Others, which look the same from the road, sell 
imported goods only.

A third type offers the goods from various local farms.
How could I tag the difference?



May be something like offer=* with
- on-site
- local
- retail
?

Georg

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

Re: [Tagging] New Proposal

[Georg Feddern]

Am 01.05.2013 12:53, schrieb Philip Barnes:


The slip roads are straight ahead, whilst the through route curves to 
the right. The tag is need to tell the router that straight ahead is 
not stay on the same road.


Hope that explains it.



uhm, had you ever considered to tag both following ways as *_link?

In my opinion
- the A56 is a trunk_link, because you have to leave the previous lanes.
- the A682 is a primary_link, because you leave the A56.

In _both_ cases you need a hint from the router to be warned (like keep 
left or keep right).

And AFAIK this would be already supported by routers.

Just my 2 cents.
Georg

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

Re: [Tagging] fire_hydrant extensions proposal

[Georg Feddern]

Am 11.03.2013 13:29, schrieb Richard Welty:

On 3/11/13 7:25 AM, Andreas Labres wrote:

Please keep in mind, there already a rather big list of possible tags:
http://wiki.openstreetmap.org/wiki/DE:Tag:emergency%3Dfire_hydrant
(only in German) and what the OpenFireMap displays (the diameter):
http://openfiremap.org/?zoom=17lat=48.11435lon=16.31743





3) water main diameter (not hydrant diameter)

internal hydrant diameter isn't going to play in the US, nor is pressure
in bar, hence the proposal for extending the tagging system.


fire_hydrant:main_diameter is the same as fire_hydrant:diameter - at 
least in the current tagging usage and 'mappers meaning'.


fire_hydrant:diameter is used for the _main_ _pipeline_ diameter, where 
the hydrant is fed from - as this is indicating the possible value of 
the water supply. (In theory the pressure is normalized ... in practice, 
well ...)


Sure, this is a bit misleading ... it was developed from a german point 
of view regarding the signs and a short-as-possible key ...


The hydrant pipe inner diameter is not tagged yet - afaik.
In Germany the interfaces are standardized anyway - and the 
(underground) standpipe diameter may possibly vary (50, 80, 100), as it 
is a movable part from the fire brigade.


Regards
Georg

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

Re: [Tagging] business closed for renovation - tagging best practice

[Georg Feddern]

Am 17.01.2013 16:42, schrieb Janko Mihelić:


Well then you decide what its status is. Is it an abandoned building 
(building=yes), or is it a temporarily closed McDonalds (building=yes, 
amenity=restaurant, temporary:opening_hours=off).


If someone says Meet me at the abandoned McDonalds, you could find 
that with the temporary tag :) That's more information than just 
building=yes.


so you will find a restaurant with closed doors ... while searching for 
an opened one.


If it is an _abandoned_ restaurant it is no restaurant anymore.
In this case I would remove the amenity tag and leave the name only - in 
fact it _is_ just a building with a big name sign then (case here with a 
Burger King since around 2 years).


Georg


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

Re: [Tagging] Names on relations and not component ways

[Georg Feddern]

Hello,

Am 04.01.2013 14:43, schrieb dies38...@mypacks.net:

I recently created a waterway where I put the name of the waterway on the 
relation but not on the component ways which are grouped by the relation.



To me, not duplicating data would seem to be the better overall practice, and 
duplication of


well, it's one acceptable perception to enter the data into a 
'relational' database - opposite to the 'keep it simple on every way' 
perception.

But why do you duplicate the tag waterway=river on every way then ...?

Regards
Georg

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

Re: [Tagging] Source tag - deprecated for use on objects?

[Georg Feddern]

Am 02.01.2013 18:16, schrieb Martin Koppenhoefer:

+1, the smaller (and more sorted by kind of change action) changesets
get, the better the chance that the following mapping will understand
easily what it is about. There is really no point in grouping
different kinds of edits in the same set of changes, just because you
happen to do them at the same time.


Sometimes I see e.g. a restaurant just by driving by.

Mapping at home
- I draw a building outline from Bing
- add amenity and name from survey
- add address info from internet research (depending on my own memory)

And you really think I will add that in 3 (three!) different changesets?

Regards
Georg

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

Re: [Tagging] SF Muni tram lines are layer=1? and general tagging levels considerations

[Georg Feddern]

Am 18.12.2012 07:31, schrieb A.Pirard.Papou:

On 2012-12-17 22:16, Martin Koppenhoefer wrote :
2012/12/17 A.Pirard.Papou a.pirard.pa...@gmail.com 
mailto:a.pirard.pa...@gmail.com

We badly need precision.


. In fact, the only effect of assigning a layer is that upper
layer objects hide lower layer ones (it's not a mind your step
warning ;-))

it is a way to describe in the database which object is above which 
or whether they are at the same level.

Agreed. And this is why I said that the tag should be called level.
Transforming that into layers is a renderer's matter that is strictly 
forbidden to speak about. Yet...


possible - but its a historical evolution you have to 'correct' then.
And I (and possibly others too) see the key 'layer' differently, see below.


I have traced lengths of streams

  * stream as a constant layer=-2 way, uninterrupted end to end
(even if they don't look so deep),
  * roads are at level 0
  * and bridges and culverts at level -1, in the manner mentioned
above.

very strange way of mapping IMHO, how did you come to this idea?
Exactly as you say above.  They are the actual relative levels of 
these objects.
I have never seen a bridge sitting on a road (and hiding it, even just 
as a hint).


Well, so you just understood the layer key as 'a level of the physical 
object'
whereas in my opinion the layer key is defined as 'a level of a map 
feature (OSM object)'.


Physical 'level' is described best by ele (elevation, absolute) or may 
be by the key 'level' (as in buildings, relative).
The key 'layer' is just a relative hint for renderer - at least in my 
opinion.


Bridge and the 'road element' may be seen as different physical objects.
But in OSM bridge and 'road element' are seen as one object (one OSM 
way) as long as no bridge relation is used.
So you are just not able to divide them in different OSM layers therefor 
- at least not until you map different 'layer' for bridge and road 
element then.


Regards
Georg
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clean-up the seamark landmark tags on the wiki (and perhaps later in the db)

[Georg Feddern]

Hi,

Disclaimer: I have nothing to do with the SeaMap, I'm just a coast dweller.

Am 23.11.2012 11:48, schrieb Frederik Ramm:
True - a cemetery is a cemetery and whether or not cemeteries are used 
as landmarks by seamen doesn't change that.


I do not see, that the seamark:xxx=cemetery will replace the 
landuse=cemetery, so I do not see a fearable change there.
I see that there is a notable difference for navigating purposes 
possible - not every cemetery on the sea is automagically a seamark:xxx 
- but I may be corrected here.


It is inconceivable to have something tagged landuse=cemetery and 
seamark:landmark:category=ferris_wheel.


Please keep on the spur - no one talks about such main differences - but 
you cannot tag two different impacts with just one simple tag.


Furthermore, is landmark really something that can be sensibly 
limited to the scope of naval tagging? Can there be something that is 
a landmark for navigation on water but not a landmark for other 
purposes, and vice versa?


Living in Karlsruhe this is said easily - no pun intended - but living 
at the coast I know of the differences even I am no 'seaman'.
Yes, I consider some landmarks only visible on land and some 
seamark:landmark only visible by sea.

The problem is, to distinguish those at the 'border strip'.

Will OpenSeaMap soon start adding seamark:type=shop, 
seamark:shop=convenience to existing shop=convenience objects if 
these shops can be used by sailors?


Now I think you draw a 'Black man' (bogeyman) on a black wall ...

We have bothered much about that as long as OpenSeaMap tagged offshore 
stuff but I think we cannot tolerate this on the 30% of the world 
surface that have 99.9% of the data ;)


Well, 'routable maps' and 'navigation charts' are for quite the same 
purpose - but each need there own special tags sometimes, may be even on 
the same object.


I do not see that some(!) additional data on a border strip is really a 
problem here.


Georg

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

Re: [Tagging] Map for surface/smoothness?

[Georg Feddern]

Am 11.09.2012 18:14, schrieb Martin Vonwald (Imagic):

Am 11.09.2012 um 16:10 schrieb Georg Feddern o...@bavarianmallet.de:


http://roads.osm4people.org/?zoom=7lat=49.60305lon=10.72137layers=B0TFF

Thanks! This covers surface, but smoothness isn't supported as far as I can see.


not yet - but you may ask at
http://forum.openstreetmap.org/viewtopic.php?id=17496p=1
perhaps he will implement it.

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

Re: [Tagging] Data redundancy with ref tag on ways vs relations

[Georg Feddern]

Am 31.07.2012 10:33, schrieb Petr Morávek [Xificurk]:

Kytömaa Lauri wrote:

  Petr Morávek [Xificurk] wrote:

2) A relation exists with member ways without ref tag. This means that
the route is essentially mapped and any further editor is correcting
errors, that he found. Then someone comes and adds a ref tag to one of
the ways - why?

He drove by, and saw a different ref sign next
to that road from one intersection and the next
one. He has no knowledge of where the ref on
the relation comes from, and if it is still valid on
all the ways currently part of the relation. He
only knows that this way has a ref=new value,
and it's all he can enter. Locals will eventually
notice, and resurvey the whole area - they'd
have to resurvey anyway.

If he knows for sure, that on that road from point A to point B is
ref=42 and not ref=56 as the OSM data says, then the user should fix it
as I wrote in previous email. Remove the ways from the current relation
and add the correct ref tag to the ways themselves, or create a new
relation for them. Problem fixed! Note, that if the edit was mistake
after all, then QA tool analyzing road network should catch that.

If he's not really sure about his data, but wants to alert locals hey,
here may be something wrong, then he should use FIXME tag as for any
other dispute.


Well, I am quite happy with relations and I would like to use them 
only as you want, too.


On the other hand I have the practical expirience, that OSM lives from 
new contributors

- and new contributors have a quite simple approach:
   - E. g. they add nodes, where already buildings exist, because there 
is no icon in their editor, they expect there.

   - They simply do not see relations in their first periods of mapping.

I am quite sure, they would add those ref tags as described above, 
simply because it is their first view.
(I have no practical expirience of that right now - but simply because 
the refs are still on the ways yet here in Germany.)


As a QA contributor you just have two opportunities:
- Remove all ref tags from the ways and organize in relations - again 
and again.
- Tag all ways with the ref tags appropriate. (Double the data with 
redundancy).


You will not get a consistant and straight solution anyway, I am quite sure.


If I understood your scenario correctly, it can be summarized as: Let's
use conflicting ref tags for road disputes instead of fixme tag.
Personally, I don't support this view.


I would understand as:
Live with the (mapping) reality and use the (QA) possibilities it opens up.

Georg


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

Re: [Tagging] Ferry routes, what's the correct approach?

[Georg Feddern]

Am 31.07.2012 22:50, schrieb LM_1:

Not knowing how different routers use access I believe that ways
marked as access=customers should be routed with some sort of warning.
The same goes for access=private. Quite commonly the real final
destination would be in some limited access area and so routers do not
have to absolutely avoid more restrictive access values than public.


Quite commonly the ferry would not be the real final destination - but 
in the middle of the route.
Routers commonly do not use more restrictive access values in the middle 
of a route ...


access=customer may be also parking places with bothside access.
access=private may be also big company areas with bothside access.
Commonly routers shall not use those - so why should they use them at 
ferry terminals?


You may have to pay a fee to access, but I would call this a public 
traffic route.

In particular if there is no other possible route.
As long as there is no other easy way I would tag for routers in this 
case.


Georg


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

Re: [Tagging] Mapping larger Mini-roundabouts

[Georg Feddern]

For highway=pedestrian, at platforms and many other things we allow to 
add area=yes to a feature to turn a circular way (ring) to a circular 
area (filled area, polygon).
If - and that's in fact more or less the result of the discussions we 
had in the last days - the difference between mini roundabouts and 
roundabouts is the traversability of the center part, I would say, 
mapping a mini roundabout as a way would in theory be sufficient 
without area=yes, because area=yes would be implied.
On the other hand I would propose to add area=yes to avoid confusion 
both at data consumer side as well as on mapper side (yes, they MEANT 
it to be a mini roundabout, I guess, because they knew it's an area 
without obstacle in the middle).


+1

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

Re: [Tagging] Mapping larger Mini-roundabouts

[Georg Feddern]

How about diameter=15 on the mini-roundabout node? This is factually 
correct, verifiable on the ground and (IMHO) non-controversial; 
routing would not be affected (no need to route over areas) and 
renderers can draw a bigger blob. Problem solved, simples.


+1 (as to Peter)
I would prefer this method - but would allow the mini-roundabout-tag on 
areas for compatibility reasons - may the latter rest upon 'already 
mapped' or 'stubborn resistance'. ;-)


Georg


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

Re: [Tagging] Mapping larger Mini-roundabouts

[Georg Feddern]

Am 06.06.2012 14:09, schrieb Pieren:

On Wed, Jun 6, 2012 at 1:10 PM, Simone Saviolo simone.savi...@gmail.com wrote:

On the other hand I would propose to add area=yes to avoid confusion both
at data consumer side as well as on mapper side (yes, they MEANT it to be a
mini roundabout, I guess, because they knew it's an area without obstacle in
the middle).

+1

+1 for me too.

I'm confused now. You mean an area=yes on a node tagged as mini_roundabout ?


It is obvious, that you did not cite Peters first sentence - but it is 
mandatory to read it in context, to avoid your confusion. ;-)



-1 for area=yes for something that is traversable only for wide vehicles


Uhmm, it is still traversable physically - it is just only allowed for 
wide vehicles.

Like painted lines/areas on dual carriageways ...


-1 for area=yes on nodes.


+1


-1 for circles with area=yes and implied oneway restriction.


I think I understand your point here - but the simple node still has a 
oneway restriction too.


Georg


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

Re: [Tagging] Dispute prevention: meaning of lanes tag

[Georg Feddern OSM]

Martin Koppenhoefer dieterdre...@gmail.com hat am 29. April 2012 um 17:39
geschrieben:

 2012/4/29 Kytömaa Lauri lauri.kyto...@aalto.fi:
  http://i46.tinypic.com/2cfqivn.png
 
  Which value would people use for the lanes=*?

 
 I think I wouldn't tag any lanes explicitly here. Looks like a
 residential road. I wouldn't expect many trucks in this zone, but if I
 were to map more detail I'd add a width-tag.


+1
Any 'default' assumption of any user of the data would give a value between
1 and 2 anyway.
As you can see, an assumption of 2 may be the better one here - if you take
passenger cars into account.
As you can see, an assumption of 1 would be the better one here - if you
take lorries into account.

Independently of 1, 1.5 or 2 any router would consider this road with
nearly the same value for the traffic considerations.
Any renderer has a better info with width.

What info do you think has lanes=1.5 then?
What do you think a user can derive from this info?





Looks as if 2 cars can pass each other without big problems.


+1
At least no problems regarding traffic time or the mere usage to reach the
point you want.

But look at the pole right behind - I think they won't try to pass
everywhere without advanced caution.

Georg___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] contact:phone or phone to combine with amenity=telephone

[Georg Feddern]

Am 26.04.2012 18:07, schrieb Mike N:

On 4/26/2012 8:51 AM, Martin Koppenhoefer wrote:

Can we use the taginfo stats to revert the change made the 2nd may
  2010 where phone has been replaced by contact:phone and add a 
big

  deprecate notice on the contact: namespace wiki ? (overall, we
  still have 10 times more phone than contact:phone, 20 times more
  website than contact:website, etc)


+1 from me, but I know there are other mappers opposing this and
trying to push the contact: prefix.


   I agree with those wanting the 'contact:' format that it is 
unambiguous and might be easier to use and analyze, but since no data 
consumers use it (that I know of), 'phone' is preferred.I know of 
several data consumers on mobile apps that use 'phone'.


well, I too appreciate the namespaces if they avoid ambiguity - but is 
there really any ambiguity with phone, fax, email, website, webcam?
contact: is a mere categorisation than distinction - and so it is just 
stuffing for me.


Georg


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

Re: [Tagging] Dispute prevention: meaning of lanes tag

[Georg Feddern]

Am 27.04.2012 09:23, schrieb Ilpo Järvinen:

On Thu, 26 Apr 2012, Martin Koppenhoefer wrote:


What do you think of lanes=3.5? I have an example here:

Not sure, how many lanes these are, could be 5 or even 5.5? Depends on
the car widths and the experience of the drivers:

Heheh... :-) ...there's one major difference between 1.5 and=2.5, ie.,
whether the traffic in one direction almost always interferes with the
opposite direction of the traffic, in the latter case it shouldn't happen


So you mean 1.5 is the same as 1 regarding the almost always 
interfere? ;-)


Georg
in the mood too - but in jolly springtime mood ;-)

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

Re: [Tagging] Dispute prevention: meaning of lanes tag

[Georg Feddern]

Am 26.04.2012 13:07, schrieb Colin Smale:
1) the hard shoulder is sometimes opened to traffic, creating an extra 
lane on the right


this case is used in Germany in several regions

e.g.
http://www.staufreieshessen2015.hessen.de/irj/servlet/prt/portal/prtroot/slimp.CMReader/HMWVL_15/Staufrei_Internet/med/c6f/c6f50ce6-66e7-3e21-79cd-aae2389e4818,----

and this leads very fast to the question:

Shall this lane
- be counted - because it is a managed lane, but that it is only sometimes
- or not - because it is most of the time an emergency lane

The article is ambiguous here.

Georg


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

Re: [Tagging] Block names (vs street names) in Brasilia

[Georg Feddern]

Am 25.04.2012 08:58, schrieb Elena ``of Valhalla'':

On 2012-04-24 at 21:46:35 -0400, Nathan Edgars II wrote:

On 4/24/2012 2:13 PM, Alex Barth wrote:

Pieren - thanks for pointing out that area=yes is highway only. How could the 
documentation for it be clearer [1]?

It's not highway only. For example, it can be used on
railway=platform: http://www.openstreetmap.org/browse/way/94063273
or man_made=pier: http://www.openstreetmap.org/browse/way/71124853

but in both cases the meaning is contrary to the default for
the main tag, this feature has not been described by tracing
its center line, but its perimeter


as far as I know and always have considered, that is the meaning in 
_all_ cases - because area was invented to differentiate between the 
linear and area meaning of a tag, if it is ambiguous.
And it is documented - at least actually - for the use in both 
directions, so even to distinguish a linear feature from a default area 
feature (area=no).


But back to the block name question, I do not think area=yes is in 
anyway necessary there:


If you consider block as an address feature, addr:block should be used 
at the address itself, not at the block area in total.
If you consider to describe just the block area - just the perimeter - 
to name it, I think place=locality on a closed polygon would be sufficient.
Only if you need to describe the block as an entity - as an 
'administrative object' or something like that - you need a special 
place= block value.


Georg


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

Re: [Tagging] Block names (vs street names) in Brasilia

[Georg Feddern]

Am 25.04.2012 12:29, schrieb Martin Koppenhoefer:
-1, place=locality shouldn't be used here, because according to the 
wiki it is not to be used for settlements or parts of them


Objection granted!
I abandon this question, Your Honour! ;-)


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

Re: [Tagging] highway=services/rest_area

[Georg Feddern]

Am 20.04.2012 10:46, schrieb Nathan Edgars II:
http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices says that it 
(usually) has fuel and food, but it links to Wikipedia:rest area.


Should the Wikipedia link be removed (and added to 
http://wiki.openstreetmap.org/wiki/Tag:highway%3Drest_area)?


Uhmm, difficult, because the linked wikipedia article refers to rest 
area _and_ service area.


I would differ between
highway=rest_area as rest area (min. parking and rest rooms, may be a 
picnic area or a very small kiosk, but no further service)

and
highway=services as service area. (min. any 'full' service like refuel, 
restaurant, accomodation)



Should the word 'usually' be removed?


Possibly, at least I am expecting a fuel service at highway=services - 
but that may be a result of my german / european practice.
I do not know of service areas with accomodation only, just of fuel and 
optional restaurant, optional accomodation.



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

Re: [Tagging] sidewalks and tagging for the renderer

[Georg Feddern]

Am 11.04.2012 11:35, schrieb Martin Koppenhoefer:

in the case of parallel ways it is impossible to tell whether you can
filter them out or not (there could be a separation or they could be
on different height levels), especially if people are mapping
sidewalks the same as separated footways.


Thats a point - and the differentiation should be really considered in 
the tagging.



  My main concern is routing,
not rendering. I wouldn't take them into account in routing, because I
feel you would get worse results.
E.g. 100 m South of the spot you posted above:
http://www.openstreetmap.org/?mlat=53.865988mlon=27.651201zoom=18layers=M
Imagine you stand there and want to go to the parking on the other
side of the road:


You take very 'short way' examples - to show the point of concern, thats ok.
But these are examples where - I think - no one would even consider to 
use routing.

On the other hand:
1.
Use 'practicable' examples (far longer ways) and you will see, that many 
(not all) of these 'problems' fade away, because the routing will use 
those crossings anyway and lead to the right side before .
If there is no sidewalk on the destination side or another adequate 
footway - it will use your approach anyway ...

2.
A person who can see the situation can see the routing too - and may 
shorten the route on his own risk.
A person who does not .. well, I would not recommend them a shorting 
anyway ...



Another similar issue is that with these sidewalks people often don't
connect crossing footways to the street, they only connect them to the
sidewalk. There are examples for this also in your area, so
unfortunately simply omitting them won't do the job either, because
you would get gaps near crossings.


A crossing footway over a street with bothside sidewalk must not always 
be connected to the street - carriageway and sidewalk are considered as 
different transport route with different usage then.

For routing there is no need to connect them.
For renderer there is no need to consider which is top or bottom - he 
may choose  itself by usage preference. (Distinction of bridge and 
tunnel presumed.)
The signal points or the 'consider a hazard' points may be outside of 
the crossing point itself.
Connections are only needed at points where you can really use a parting 
transport way (which may be a street without sidewalk).





Third, try to cross these not on the crossing staying alive:
http://upload.wikimedia.org/wikipedia/commons/thumb/1/14/Partyzanski_praspekt_8.jpg/300px-Partyzanski_praspekt_8.jpg
http://kp.ru/f/4/image/26/67/396726.jpg


I'll do next time I visit your town. What should be the problem? You
wait until there is no car coming or all cars stop and then you cross.


Yes - I see, you have _seen_ the point already. ;-)

cheers,
Georg

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

Re: [Tagging] sidewalks and tagging for the renderer

[Georg Feddern]

Am 11.04.2012 12:47, schrieb p...@trigpoint.me.uk:

I am wondering what happens where there are no crossings, or outside of built 
up areas where there are no sidewalks.



That's quite easy:
Where there are no crossings - no crossings can be used, any routing 
will use the nearest point approach - with 'wild crossing' (your 
destination is on the other side of the road) or use the road - the 
rest is your personal responsibility to adhere the laws and to preserve 
your health.
Where there are no sidewalks - well, there are no sidewalks, you and the 
router will have to use the 'road'.


A router that does consider sidewalks, will _prefer_ sidewalks and use 
roads otherwise.

A router that does not consider sidewalks will use the roads anyway.

Georg

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

Re: [Tagging] Turn Restriction usage

[Georg Feddern]

Am 11.04.2012 15:42, schrieb Simone Saviolo:

2012/4/11 Ross Scanloni...@4x4falcon.com:

No.  The router should know not to do this. Likewise as below the router
should not make u turns at traffic lights.


Based on what? How does the router know that the two ways are two
carriageways of a single road? Couldn't they be a straight road, that
becomes a oneway street at a certain point, and at that point a
junction brings to a oneway secondary road?


The name of the way, the fact that you are turning  180 degrees on the same
way.

I don't agree.

First, if you're on the same way, you're not turning, but going
straight and following the road. In the case of the OP, I expect to
see three ways, two of which tagged oneway=yes.

Second, if you turn more than 180 degrees, you're hopefully going on a
bridge ;-)

Third, think of a situation like this: http://osm.org/go/0CKuMhs89-



in your example the angle at the considered point is far from dangerous 
or considerable.
Your angle is in the range up to 45° and doesn't even reach 90° (a 
typical crossing / turn situation).


Points of no u-turn - that have to be considered - have angles
- beyond 90° (may be a sharp turn or a crossing at a combine situation)
- mostly beyond 120° and often beyond 150°
This is the range to consider - and that is possible for a router.
The angles depend a bit on the mapper's 'style' and should be considered 
by the mapper - but in most cases the angle will reach those range 
anyway - a split and combine would not be 'rectangle'.
(U-turns at dual-carriage ways with two 90° turns because of a via-way 
have to be considered separately.
If not allowed - even only by law - a turn restriction may be helpful 
there.)


Greetings
Georg

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

Re: [Tagging] sidewalks and tagging for the renderer

[Georg Feddern]

Am 12.04.2012 15:15, schrieb Martin Koppenhoefer:

Am 12. April 2012 08:44 schrieb Georg Fedderno...@bavarianmallet.de:


A router that does not consider sidewalks will use the roads anyway.


No, a router that doesn't consider sidewalks would with the currently
suggested tagging use the sidewalk and think it was a usual footway.



Sorry, I kept my own
 Am 11.04.2012 11:35, schrieb Martin Koppenhoefer:

in the case of parallel ways it is impossible to tell whether you can
filter them out or not (there could be a separation or they could be
on different height levels), especially if people are mapping
sidewalks the same as separated footways.


 Thats a point - and the differentiation should be really considered 
in the tagging.


with the suggested tagging
footway=sidewalk and sidewalk=yes as differentiation

in mind (writing quite the same time).

Georg

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

Re: [Tagging] second_hand shops

[Georg Feddern]

Am 05.11.2011 15:49, schrieb Tobias Johansson:


I think it would be good with two values. only and both, to make a
distinction between purly second hand shops and second hand shops that
also sells new items.


+1


  (maybee second_hand=yes could subbstitute only



-1

If you want to differentiate between 'also' and 'only' you will have to 
be precise.

'Yes' is ambigious for both cases.
E. g. I would see 'secondhand=yes' as as shop which sells normally new 
items but also secondhand - in opposite to 'secondhand=only'.


But while I would look for a furniture or clothes shop which sells 
second hand - I would look for a 'second hand shop' if I am looking for 
IT, electronics, games or other small stuff.

At least here in Germany.

BTW:
A 'shop=car' mostly sells second hand also ... or only.

Georg

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

Re: [Tagging] Best way of tagging split between electronic toll and cash lanes?

[Georg Feddern]

Nathan Edgars II schrieb:
Many toll plazas now have high-speed electronic toll lanes. Tagging 
seems haphazard. As I see it, the choices are:

*What gets tagged as motorway vs. motorway_link?
*What gets the name, ref, and relation membership?
[...] 
So the question is whether to use motorway_link for what's signed as 
an exit, or to consistently use motorway for either cash or for 
high-speed.


I would use _link only, if it really links between two different ways, 
maybe even of the same type.
But here I think it is just one highway going through, so I would not 
tag it as link.
The toll point itself has to be considered as a slow down - essentially 
and visually by the user and supportively by a router.
Using _link for the non-electronic lane may irritate 'normal' routers to 
prefer the electronic toll lane - and that may lead a non-electronic 
user in a dead-end. (downward compatibility as a security fall back)
In this case the router should discriminate the lanes only by access 
tags (see below) - but not by the highway tag itself.


Name, ref and relation - as you may choose every lane to go on your 
(high)way, all of them belong to all lanes in my opinion.




There's also a question of what access restrictions go on the 
high-speed lanes.




OK, to choose the 'right' lane by routers, it is essentially to know  - 
but to use them, you need special equipment, and I don't know, if that 
is different for different toll passages. (Or is EPASS an 'everywhere 
equipment/operator'?)
If you need different equipment, this (or the operator) must be tagged - 
and must be configured for the router too!


I do not know, if an access=electronic_toll (with a subkey 
electronic_toll=*) would be satisfactory. (How do/shall routers handle 
unknown access values? I hope/think as 'no').


Nevertheless - as long as a router cannot discriminate _all_ of the 
necessary informations, he can only warn about the toll point itself - 
and the user have to discriminate visually.


Georg

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

Re: [Tagging] Prevoting: New_barrier_types

[Georg Feddern]

Tobias Knerr schrieb:

Erik Johansson wrote:
  

I think turnstiles and full height turnstiles should be the
barrier=turnstile, add some extra tag to differentiate them.




I'm convinced that this point wouldn't come up if the English language
didn't happen to use the term turnstile for both types of barriers.

  


But considering the fact, that the English language uses one term only, 
one may think about the term 'both types' ...


Considering that you may jump over the lower one is - in my opinion - 
the same, as to say 'you may break through a wooden door opposite to a 
steal one' to claim separate main tags.

A height limitation isn't tagged elsewhere as a separate main tag.
So I am not convinced 'sufficiently'.

Georg


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

Re: [Tagging] types of surveillance cameras

[Georg Feddern]

Hi,

Martijn van Exel schrieb:

I am noticing a two major types. There's what I
call the dome cameras [1] that live in a dome-shaped enclosure and can
probably tilt and swivel to cover a larger area, and there's the static ones
that have a more traditional camera shape [2] and are usually fixed,
pointing in one particular direction.


but do not forget the so-called vandal dome cameras which look like a 
dome, but are only static/fixed types.

Or the 360° cameras which look like a big raindrop only ...


* Does the distinction between dome and static cameras make sense or are
there more major categories?
  


Ask yourself the question What info do I get with this distinction?
I think, the only info is a Maybe ...

A 'normal' mapper can not see the difference between a real PTZ-Dome or 
a vandal-dome camera - you may even do not see, in which direction the 
latter is mounted.
Also not the difference between a fixed mounted static camera and a 
fixed mounted zoom camera.



* Would this be a relevant attribute to tag? I think it is.
  


My conclusion:
You can not easily map the correct type of camera - and you can not 
estimate the surveyed area or details without the technical data of the 
camera.

So I think it is not - at least I won't trust these attributes. ;-)
Tag the manufacturer and the model instead. ;-)



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

Re: [Tagging] Pls explain?

[Georg Feddern]

Steve Doerr schrieb:

On 11/02/2011 12:40, Steve Bennett wrote:


And, slightly more seriously, man_made=MDF - what's that about?


MDF is medium-density fibreboard, so maybe they're tagging what the 
object is made of rather than what the object is?





Even if it is a single-user created and used key - at least it has a 
Wiki page which could be found via search MDF, unfortunately not 
translated yet.

I do not know if it is used outside Germany in OSM - I did not look up.
It is used for Main Distribution Frame (for DSL - Digital Subscriber 
Line).

Sven Geggus imported a list published by the german Telekom.
Well, ok, the value is not a really wise choice with an ambiguous 
abbreviation ...


Georg



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

Re: [Tagging] Equivalence relation

[Georg Feddern]

Peter Wendorff schrieb:

Am 11.01.2011 04:26, schrieb Steve Bennett:

 On 11/01/2011 12:20 AM, Richard Mann wrote:

I put adjacent=yes on the highway=cycleway, so the user of the
cycleway=track tag on the main road can ignore ways with adjacent=yes
on them. The user who'd prefer to use highway=cycleway ways doesn't
know that the cycleway=track is a duplicate, but routers only have to
give a slight preference for highway=cycleway over cycleway=track to
use the right one (and even if they use the wrong one, it doesn't
much matter anyway).
IMHO, this is being extremely optimistic about the powers of a 
router. So you're saying that a router could see the adjacent=yes, 
then locate a nearby cycleway which is adjacent in some way, and 
conclude that the two refer to the same thing?

I think you think too complicated here.
In much cases Steve could be right.
The routing engine has not to consider explicitely the adjacent-tag.
The slightly preference of the separate tagged way over the tag, 
compared with the usually equal lenght of both alternatives will push 
the routing engine to prefer the cycleway explicitly tagged.




+1


But: While routing engines will work well this way, renderers could fail.
A renderer has to check if there in fact is the separated cycleway to 
be allowed to drop the tag for rendering. (If it's the target to 
render cycleways).




If the corresponding highway=*, cycleway=track is also tagged with the 
adjacent-Tag, router and renderer can choose in general, which sort of 
way they use - without any need for locating them.


Regards
Georg




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

Re: [Tagging] boundary=town, place=town

[Georg Feddern]

Steve Bennett schrieb:

Although...that just raises a different question: what's the
difference between a town mapped out as an area (place=town) and a
town mapped with a boundary=administrative, admin_level=8 (plus
relation).

I guess there is no difference, just two different ways of expressing
the same thing. Along with the subtle distinction between a town
*area* and a boundary *way*.
  


at least in Germany place=town (area) is often used for the complete 
settled area with buildings.

(In German there is an administrative term geschlossene Ortschaft.)
Whereas the boundary is the administrative border, often a quite bigger 
area including surrounding rural parts.


Regrads
Georg


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

Re: [Tagging] Differences in cycleways

[Georg Feddern]

Robert Elsenaar schrieb:

Peter wrote:
If you tag it as cycleway:both=track, it's more clear.


Yes you are right. But implicite we have accepted several default in 
our tags.


That's right.
But the problem is, that already hundreds or thousands of cycleway=track 
tagged yet - but in reality they are single-side.
That's the eternal problem, if a tagging is refined lately ... or 
previous used too early.

So you might know, that you implicite mean both, if you tag it now.
But any user doesn't know, if you really meant that - or if you didn't 
care about the late refine of left, right, both - because the tagging 
was already done much earlier.


Regards
Georg


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

Re: [Tagging] Groups of islands, how to tag?

[Georg Feddern]

Erik Johansson schrieb:

On Fri, Nov 19, 2010 at 10:08 AM, Willi wil...@gmx.de wrote:
  

2) If the answer is 'use a relation', have I done it properly, and if so,
why isn't Mapnik rendering the name properly?
  


  

2) If and how a feature is rendered is up to the renderer. The mapper can't
and imho shouldn't try to control this.




Since it's obviously not rendered in any renderer., the question is
how to make this renderable, not how to write the relation in a nice
way..

This problem exist all over and a fix is badly needed, e.g.
1. buildings/entrances
2. islands
3. metro stations/entrances
4. water areas
  


Well at least 1 and 3 (site relation with apropriate roles) as well as 2 
(multipolygon archipelago) _are_ yet renderable - it just has to be done 
- by the renderer. As said above.

So the answer could only be: ticket / patch for mapnik, osmarender, 

Georg


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