Re: [Tagging] Positioning motorway exits

[Tom Pfeifer]

On 08.03.2017 00:01, Johan C wrote:

make sure the requirements for navigational devices like OSMAND should also be 
met


I don't think OsmAnd would have a problem with the node being at the 
physical separation, in particular if the turn:lanes are tagged 
correctly.  OsmAnd will give advance advice to turn and display the 
lanes to use.


tom

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

Re: [Tagging] Fwd: Feature Proposal - Voting - tag "motorcycle friendly" for accomodations

[Warin]

On 07-Mar-17 10:56 PM, Thilo Haug wrote:


Hi all,

thanks to Martin for the clarification.

In the discussion of the (former voted) wiki entry :
http://wiki.openstreetmap.org/wiki/Talk:Key:motorcycle_friendly

I referred to the definition of the German automobile club :

8X---
The German automobile club has the following criteria :

  * (Theft) safe and secure motorcycle parking areas.
  * Facilities for wet clothes.
  * Tools for minor repairs
  * Extensive information material (including tour suggestions,
excursion tips, road maps, useful addresses for motorcyclists)

https://www.adac.de/reise_freizeit/motorrad/motorradfreundliche-gastgeber/qualitaetssiegel/default.aspx
8X---

Those four points should be given if an item is categorized as "yes".


You will get few that meet all of these criteria on a worldwide basis.
The proposal looks like it is a requirement to meet all 4 of these 
criteria.


In some climates wet weather is a lesser concern, so wet clothing 
facilities are less frequently used and as such stored out of the way - 
thus less obvious.

'Extensive' is a subjective term.
The word 'including' means that all these things are required to meet 
the criteria.
The words 'for example' could replace 'including' to allow a few of 
these things or other things to be used to meet the criteria.




"No" means they don't accept motorcyclists (seldom, but exists).


I would take a broader view. I would take 'no' to mean 'discourages' as 
well as the meaning 'rejects'.


As there are certainly accommodations
which just don't care about your means of transport,
there is also a third option, which I called "customary",
as this categorization is already in use (for nudism)
http://wiki.openstreetmap.org/wiki/Key:nudism#Tagging


The meaning of 'customary' is 'usual practice' ... what your proposal 
takes as 'customary' is a lesser friendliness that the 'yes' case. This 
is not the meaning of the word 'customary'! And it is confusing to a 
native English speaker.

Do not use this word this way.

A better word might be 'partial', meaning 'not total, but a bit'.



So I think the criteria is quite clear and not "opinionated".
In case the description could be improved, please let me know in the 
"discussion" :

http://wiki.openstreetmap.org/wiki/Proposed_features/motorcycle_friendly#Proposal


Discussion can also take place here, and you should observe these too.



Cheers,
Thilo

Am 07.03.2017 um 11:20 schrieb Martin Koppenhoefer:


2017-03-07 10:58 GMT+01:00 Thilo Haug >:


"own data, as an overlay" doesn't make sense to me in this case,
as it's data the community should collect, not the transformation
of existing data collections
("motorcycle friendly" web pages, as they are often randomly
listing hotels).
This is the motivation of this tag.


one of the basic fundamental rules in OSM is that data should be 
objective and not opinionated. We do not want restaurant reviews (or 
any other personal review) or a generalized way of saying "suitable 
for cyclists" (you can of course map the factors that say why it is 
suitable or not), and a "friendly:*" tag could be misleading in this 
regard. I agree that there are facts that can indicate a friendlyness 
or hostility towards a certain group of people (e.g. motorcyclists, 
hikers, hunters, cyclists, ...), like the signs, so I am not 
absolutely against a tag like this, but the definition should make it 
clear that it is about objective, observable criteria.


Didn't understand what you mean with "digest approach" ?



You can subscribe to the mailing list getting all the messages as 
soon as they are sent, or in a digest way (many messages together in 
one email) after n messages (I think it's 10 or 15) have been sent to 
the list.


Cheers,
Martin


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


--

Thilo Haug
Bismarckstr.37
72764 Reutlingen

Mobil: +49 177 3185856


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



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

Re: [Tagging] Positioning motorway exits

[Johan C]

Well, the WIKI more or less has a sort of consensus. Yes, we do have the
divided highways ('baulicher trennung'). But there is also the consensus
that it's important to make sure the requirements for navigational devices
like OSMAND should also be met. So, if the physical point is used by a
mapper some extra tagging is needed to show the legal point for the exit.
And the routers should then be altered to handle the extra tagging. OSM is
no toyland anymore, people (like myself) are more and more relying
on reliable OSM data for navigational purposes.

An example for Belgium shows the motorway_junction node way too early:
https://www.openstreetmap.org/?mlat=50.86948=4.48244#map=18/50.86948/4.48244=N
But that's safer for driving than having it too late.

Cheers, Johan


2017-03-07 15:45 GMT+01:00 Jo :

> Extra credit if we can come up with a 'universal' solution :-)
>
> Polyglot
>
> 2017-03-07 10:44 GMT+01:00 Volker Schmidt :
>
>> This touches on a "conflict of interest" between two requirements:
>> (1) OSM tagging practice is to map only physically separated ways as
>> separate ways in OSM.
>> (2) A routing algorithm needs to have information about legally separated
>> ways, e.g. by a continuous white line.
>>
>> In the specific case the exit for the routing algorithm is at the
>> beginning of the continuous white line, i.e node
>> https://www.openstreetmap.org/node/4337339247
>> whereas the split of the ways according to the rule of the separate ways
>> puts it at node https://www.openstreetmap.org/node/370544/, where the
>> motorway junction is placed at the moment.
>>
>> To my knowledge there is no agreed upon common practice.
>>
>> I do not map motorways in Germany, but have mapped motorways and trunk
>> roads in Italy where we have no established common approach, and you can
>> find a nice mix of different approaches. I think we should come to a
>> general best-practice or best-practices agreement. This may imply
>> country-dependent recommendations.
>>
>>
>>
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fwd: Feature Proposal - Voting - tag "motorcycle friendly" for accomodations

[David Bannon]

On 07/03/17 20:58, Thilo Haug wrote:

...

I'm not really sure about which issue you talk in the 2nd part of your 
message "not actual rules",
do you refer to my entry in the proposal about a "code of conduct" ? 
...


Thilo, what I was suggesting is that you need to receive the list 
messages, read them, understand the ideas behind them. That cannot 
happen if you try to block all messages other than your own topic (or 
unsubscribe). Or think of them as spam.




"own data, as an overlay" doesn't make sense to me in this case,


OK, then thats not a suitable solution for you.


Didn't understand what you mean with "digest approach" ?

I thought you mentioned getting the list communications via digest 
instead of directly receiving what you call spam. If not, sorry for the 
distraction.


David





Cheers,
Thilo


Am 07.03.2017 um 04:15 schrieb David Bannon:

On 07/03/17 04:55, Thilo Haug wrote:

..

I (accidentally) unsubscribed because of the "spam" coming in,
means I didn't get just messages regarding the topic.

Thilo, perhaps thats the underlying problem here ?  You read the 
rules on the wiki, complied with what you understood and now, I guess 
feel as if you are being treated a bit unfairly ? However, I doubt 
that any proposal has succeeded where the proposer has not been a 
member of this list, been actively reading the messages at least and 
probably been contributing as well.


The truth is that not all the "rules" are on the wiki, there is a 
huge quantity of community knowledge, not actual rules, and much of 
it is accessible via this list. We have a large number of very 
experienced  database, rendering, mapping, cultural experts who live 
here (no, I'm not one!). They comment on a proposal and help a 
proposal comply with the OSM culture. Their "rules" are not written 
down as the document would run to 100's pages and we'd never agree on 
the content. Written rules have to cover every possible situation. 
Too hard.


This list is very welcoming, always open to new ideas and not, in any 
way, locked into particular policies. Within the list you will find 
widely differing views but always respect for others.


To solve your problem Thilo, you could do a number of things. 
Firstly, tags in OSM do not need be approved. I, personally don't 
recommend unapproved tags but lots will disagree with me. 
Alternatively, its relatively easy to put your own data, as an 
overlay, onto an OSM map. Keep you data privately or put it into one 
of the public POI databases. But really, I strongly recommend you 
keep trying as you are, refine and improve your proposal with the 
help of the mailing list, understand why OSM "rules" are what they 
are. You can then make a good tag, one that can be used around the 
world and rendered on lots of maps.


By the way, I would not recommend the digest approach, I found it 
harder to assign time to. Digest users, when replying, often seem to 
forget to change the message title and are not always taken seriously :-)


David




Am 06.03.2017 um 18:09 schrieb Martin Koppenhoefer:


2017-03-06 17:46 GMT+01:00 Michael Reichert >:


Hi Martin and others,

Am 2017-03-06 um 17:37 schrieb Martin Koppenhoefer:
> yes, that wording is unfortunate, because in most/many OSM
mailing lists
> messages never get approved. I am myself admin of a very
small regional ML
> and from time to time there are periods where a lot of spam
arrives, I can
> imagine checking held back messages in the big lists would be
a lot of work
> (and mostly consist in rejecting spam). You would also have
to do it daily,
> because after some time many messages will seem out of context.

I have changed the wording of the wiki page Proposal_Process
today to
stress the necessity to subscribe the Tagging mailing list.
Feel free to
modify/revert it if you don't like it.



As you name me in person: I was not referring to the wording in the 
wiki but the wording of the mailing list autoresponder message in 
case someone not subscribed sends a message (and from the reply 
might get to the impression that it will pass, which it in fact 
almost never does for any of the OSM lists).


Cheers,
Martin


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


--

Thilo Haug
Bismarckstr.37
72764 Reutlingen

Mobil: +49 177 3185856


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




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


--

Thilo Haug
Bismarckstr.37
72764 Reutlingen

Mobil: +49 177 3185856


___
Tagging mailing list
Tagging@openstreetmap.org

Re: [Tagging] Mapping time zones as geometries (relations)

[Kevin Kenny]

On Tue, Mar 7, 2017 at 1:43 AM, Frederik Ramm  wrote:

> On 03/07/2017 02:06 AM, Kevin Kenny wrote:
> > There are reasonable use cases for wanting to take a timezone name and
> > get back a multipolygon
>
> Question is, does (the core database of) OSM have to fulfil these use
> cases!
>

It at least has to hold the geodata needed for a client to satisfy them. If
it turns out that relations are The Wrong Thing, do we at least have
consensus that time zones are made up of administrative regions, whose
boundaries are a proper subject for OSM? (Time zone boundaries at the level
of detail demanded by tzdata are hard to obtain for many places; this is a
need that OSM could fill.)


> > or to get a list of name and multipolygon for
> > all the timezones (or all the timezones on a given map). That's hard to
> > do unless there are relations for the timezones. Not impossible, we
> > could query administrative boundaries for the tag, but that's likely to
> > be SLOW since the tag will at best be in hstore and not indexed.
> > Grouping disjoint items, such as "all the administrative regions in a
> > time zone" seems tailor-made for relations.
>
> In my opinion, no. We've been there - people (ab)using relations like
> some kind of bookmark, to make data retrieval easier (e.g. a relation
> "all cycleways in XY city" just because it was slow/difficult to
> retrieve them otherwise).
>

"All cycleways in XY city" is a very bad example, because PostGIS can do
that easily without relations. I do that sort of thing all the time, using
ST_Intersects queries. That doesn't work too well at the continental level,
though!


> You would typically use a relation to group things when they can be in
> more group than one, and therefore tagging the membership on the
> individual object becomes cumbersome - cycle, bus, or hiking routes are
> a prime example, since the same street/way can be part of several of them.
>
> Not so with time zones, I should hope; a region can only be associated
> with exactly one (not 0, not more than one) time zone. Hence adding a
> time zone tag to the object is the easiest way to maintain the data and
> to ensure that you don't accidentally have two!
>
> I agree it might make things a little more difficult for the consumer
> but an overpass query can quickly find every boundary relation tagged
> with a certain time zone, and I'm sure sooner or later specialist sites
> will take the data and prepare daily updated json files or whatever that
> one can overlay on a map.
>
>
Hmm... thinking here. The relation types I use most often are multipolygon
(not so much to group things, as to deal with shapes of complex topology),
route (no doubt the many-to-many example that you were thinking of) and
group - where there is a named object that is made up of components: chains
of lakes and archipelagoes come to mind. It struck me as if a time zone was
a similar thing to an archipelago: a named object made up of countries,
states, counties, whatever... non-overlapping component regions. But maybe
simply tagging administrative regions with their time zone names, and
having validators in places like JOSM to test for overlaps, will be good
enough.

As long as we have consensus that the administrative boundaries of time
zones, however structured, are proper subject material for OSM, I'm
reasonably content. I can add rules to my import of OSM data if I must, to
produce correctly-structured auxiliary tables.

Nevertheless, I think we need to consider the common use cases of:

(1) a map that wants to render time zone boundaries. I once did the
operator interface for the central control room of a very large television
broadcast network, and a map showing the locations of affiliate stations
and their timezones was a key component.

(2) a navigation system that wants to warn a driver or passenger that it's
time to change the clock.

(3) a system that can take a map click and answer the question of "what
time is it in this place?"

just as a sanity check that the data model is adequate in principle to
answer those questions.

We can presume that the rules for calculating "what time is it" are out of
scope. The question OSM has to answer is "what rule set applies in place
XXX?" and "where does the rule set named YYY apply?"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] NEW APPROACH : Feature Proposal tag "motorcycle friendly" for accomodations

[Thilo Haug]

Hi Martin,

do I need to search for "quintessence of osm" or "tagging of individual
aspects" to RTFM ? ;-)

Also in this case (such as with the email stuff)
I think it would be good to link to those "basics" in the relevant
documentation (RFC template ?)
to enable the new users to find it.

RTFM doesn't mean to me that I have to search for (possibly
"proprietary") terms
in the "top right OSM search box above".
(see the comment of Warin61 regarding the "feature" term in the
discussion "Values")
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/motorcycle_friendly#No

Thanks for all your input.

Is there any "basic info" I should read ?

Cheers,
Thilo

Am 07.03.2017 um 15:51 schrieb Martin Koppenhoefer:
>
> 2017-03-07 13:30 GMT+01:00 Thilo Haug  >:
>
> there's a totally different, interesting approach from Dieterdreist :
>
>
>
>
> Thank you for the laurel, but I have to reject them, prefering the
> tagging of individual aspects (many tags with clearly defined scope)
> rather than aggregated conclusions (few tags that combine different
> aspects of the same thing) is long proclaimed common practise in OSM.
> It makes the data more universally usable. It's the quintessence of osm.
>
> Cheers,
> Martin
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

-- 

Thilo Haug
Bismarckstr.37
72764 Reutlingen

Mobil: +49 177 3185856

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

Re: [Tagging] NEW APPROACH : Feature Proposal tag "motorcycle friendly" for accomodations

[Martin Koppenhoefer]

2017-03-07 13:30 GMT+01:00 Thilo Haug :

> there's a totally different, interesting approach from Dieterdreist :




Thank you for the laurel, but I have to reject them, prefering the tagging
of individual aspects (many tags with clearly defined scope) rather than
aggregated conclusions (few tags that combine different aspects of the same
thing) is long proclaimed common practise in OSM. It makes the data more
universally usable. It's the quintessence of osm.

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

Re: [Tagging] Positioning motorway exits

[Jo]

Extra credit if we can come up with a 'universal' solution :-)

Polyglot

2017-03-07 10:44 GMT+01:00 Volker Schmidt :

> This touches on a "conflict of interest" between two requirements:
> (1) OSM tagging practice is to map only physically separated ways as
> separate ways in OSM.
> (2) A routing algorithm needs to have information about legally separated
> ways, e.g. by a continuous white line.
>
> In the specific case the exit for the routing algorithm is at the
> beginning of the continuous white line, i.e node
> https://www.openstreetmap.org/node/4337339247
> whereas the split of the ways according to the rule of the separate ways
> puts it at node https://www.openstreetmap.org/node/370544/, where the
> motorway junction is placed at the moment.
>
> To my knowledge there is no agreed upon common practice.
>
> I do not map motorways in Germany, but have mapped motorways and trunk
> roads in Italy where we have no established common approach, and you can
> find a nice mix of different approaches. I think we should come to a
> general best-practice or best-practices agreement. This may imply
> country-dependent recommendations.
>
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Martin Koppenhoefer]

2017-03-07 12:42 GMT+01:00 Jaroslav Kameník :

> Personally I would compromise - leave timezone relations
> where really needed (river/meridian/territorial waters/...) and change them 
> to tagged A.B. otherwise.
>
>

+1

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

Re: [Tagging] Mapping time zones as geometries (relations)

[Andrew Hain]

I think this idea is a winner. We have geometry  for the tricky cases but this 
can just fall through to the administrative geometry in places such as Arizona 
outside the reservations.

--
Andrew

From: Wolfgang Zenker 
Sent: 07 March 2017 10:38:01
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] Mapping time zones as geometries (relations)

Hi,

* Colin Smale  [170307 09:04]:
> [..]
> It is possible to have enclaves/exclaves for a territory which differs
> from the surrounding territory. Taking the US as an example, if we put a
> timezone tag on a State, there may need to be an overriding tag on a
> County or even possibly at a City level. There are also native homelands
> that cross state boundaries which have their own ideas about time. See
> [1] for more info on this.

> We need to address reality; I suggest there are the following options:

> 1) a multipolygon for the time zone, allowing for outer and inner rings,
> sharing ways with admin boundaries where appropriate, otherwise
> dedicated ways with "boundary=timezone"

> 2) tagging admin boundary relations with their timezone, allowing
> lower-level entities to override their parent

> 3) only tagging (all!) low-level entities with their timezone to avoid
> the enclave problems of option 2

> This is actually conceptually similar to the problem of territorial
> defaults for maxspeed and loads of other things.

> What about maritime TZ boundaries that don't correspond to an admin
> boundary?

As we have seen in this discussion so far, timezones in international
waters are kind of meaningless or undefined.

> I cannot believe it is beyond the abilities of OSM to represent time
> zone areas. Of course it can be done.

the question is not if OSM can represent timezones, rather if it should
and if so, in which way to do it.

Following the discussion so far it looks to me like we have a rough
consensus that the geographical extend of timezones should be in OSM
data.

I suggest following the principle of using the simplest solution that
can probably work. To me that would mean to follow your suggested
option number 2 whereever possible and in the (rare) cases where it
is not, to create multipolygons with boundary=timezone subdividing the
administrative units that sit in multiple timezones. These multipolygons
would be treated as lower-level entities overriding their parents.

There was the argument that monstrous multipolygons spanning the length
of half a continent are probably a recipe for unusable data that is
constantly broken. This would to me exclude your option 1.

Your option 3 appears to require loads and loads of redundant data
that will be permanently incomplete; I would try to avoid this.

Wolfgang

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

Re: [Tagging] EuroVelo tagging

[Richard Fairhurst]

Volker Schmidt wrote:

As EV routes are not managed as single entities, every route is split in
pieces managed on a country basis. I know the situation in Italy, as I am
involved in regional and national cycle routes here. EV routes are handled
by BicItalia which is part of FIAB, the "Italian Federation of Friends of
the Bicycle". All EV routes all have also BicItalia numbering (BicItalia
routes are ncn), but it is not necessarily the case that the Italian part
of a given EV corresponds one-to-one to a BicItalia route. So it makes
sense to tag the individual EV routes in one country as one icn and to tie
these icn routes in the different countries together by a super relation.
This means that any BI route that is also part of an EV is part of at least
to bicycle route relations (it typically is also part of lower level routes.


and Warin wrote:

My thoughts on the EV ... following my thinking on the above are;

Have 2 relations ... on on the EV, the other on the other entity (e.g.
BicItalia).


Agreed - I think this is the most sensible approach and it accords with 
most current practice. I'll add some text to the EuroVelo wiki page 
accordingly.


Jo wrote:

It ought to be possible to use hierarchy in those relations. That way you
would map them at the national level and group them for the international
level.


It's a seductive idea, but the problem with this is that the routes 
aren't always strictly hierarchical. For example, EuroVelo 1 in Britain 
uses parts of NCN 7 and NCN 73, but not all of them. So to do a 
hierarchical approach you would need "NCN 7 part one" in "EV 1 
super-relation" and "NCN 7 super-relation", "NCN 7 part two" in "NCN 7 
super-relation" only, and so on. This could get very complex very 
quickly - some parts of NCN 27 are in EV 1, some are in the Tour de 
Manche Anglo-French route, some are in the Dartmoor Way: the 90-mile 
route would need to be split at least four ways. I suspect it'd become 
exceptionally fragile and liable to be broken, and my main concern with 
getting the EuroVelo tagging confirmed is to make sure that there's an 
unambiguous reference so well-meaning newbies are less likely to break it.


cheers
Richard

(apologies for broken threading, tagging@ has disappeared from Nabble)

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

[Tagging] NEW APPROACH : Feature Proposal tag "motorcycle friendly" for accomodations

[Thilo Haug]

Hello all,

there's a totally different, interesting approach from Dieterdreist :

Assessment of tag
Here's an example: drying_room=yes, motorcycle_parking=yes,
motorcycle_repair_tools=yes, motorcycle_tour_tips=yes. I.E. these are 4
tags rather than one, and the drying room for instance isn't something
particularly related to motorcycle tourists, it can by used by everyone
with the need to dry his clothes. --10:55, 7 March 2017
(UTC)http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/motorcycle_friendly#Assessment_of_tag_-_is_it_too_subjective.3F

As I mentioned above this discussion entry, I'd tend to the "KISS" solution,
unless I see that especially the tag "drying_room" would make sense for
several
(mountainbike, hiking, ski/snowboard etc.)

motorcycle_parking already exists :
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dmotorcycle_parking

So what's left is
repair_tools
and
tour_tips

Regarding the latter, I just don't see how this may be bound to either
"motorcycle" or "skiing",
as several Hotels have Skiing in Winter and Motorbike guests in Summer.

Any Ideas how this may be solved ?

I could imagine
motorcycle:tools=yes
motorcycle:parking=yes (then the existing key would need to be changed)
drying_room=yes (new key necessary)

Just don't got a good idea about the "information material" (how to be
used with other items ?)

I think shop=motorcycle should stay a "shop"?

There's currently a problem to differ between a motorcycle dealer
and a motorcycle clothes shop, for example Louis, Polo, Hein Gericke.
According to the current definition you may use
shop=motorcycle
together with
clothes=motorcycle (this is still in "draft" status)
I could imagine to use
motorcycle:clothes=yes
instead ?

Cheers,
Thilo

 Weitergeleitete Nachricht 
Betreff:Re: [Tagging] Fwd: Feature Proposal - Voting - tag "motorcycle
friendly" for accomodations
Datum:  Tue, 7 Mar 2017 12:56:15 +0100
Von:Thilo Haug 
An: Tag discussion, strategy and related tools 



Hi all,

thanks to Martin for the clarification.

In the discussion of the (former voted) wiki entry :
http://wiki.openstreetmap.org/wiki/Talk:Key:motorcycle_friendly

I referred to the definition of the German automobile club :

8X---
The German automobile club has the following criteria :

  * (Theft) safe and secure motorcycle parking areas.
  * Facilities for wet clothes.
  * Tools for minor repairs
  * Extensive information material (including tour suggestions,
excursion tips, road maps, useful addresses for motorcyclists)

https://www.adac.de/reise_freizeit/motorrad/motorradfreundliche-gastgeber/qualitaetssiegel/default.aspx
8X---

Those four points should be given if an item is categorized as "yes".

"No" means they don't accept motorcyclists (seldom, but exists).

As there are certainly accommodations
which just don't care about your means of transport,
there is also a third option, which I called "customary",
as this categorization is already in use (for nudism)
http://wiki.openstreetmap.org/wiki/Key:nudism#Tagging

So I think the criteria is quite clear and not "opinionated".
In case the description could be improved, please let me know in the
"discussion" :
http://wiki.openstreetmap.org/wiki/Proposed_features/motorcycle_friendly#Proposal

Cheers,
Thilo

Am 07.03.2017 um 11:20 schrieb Martin Koppenhoefer:
>
> 2017-03-07 10:58 GMT+01:00 Thilo Haug  >:
>
> "own data, as an overlay" doesn't make sense to me in this case,
> as it's data the community should collect, not the transformation
> of existing data collections
> ("motorcycle friendly" web pages, as they are often randomly
> listing hotels).
> This is the motivation of this tag.
>
>
> one of the basic fundamental rules in OSM is that data should be
> objective and not opinionated. We do not want restaurant reviews (or
> any other personal review) or a generalized way of saying "suitable
> for cyclists" (you can of course map the factors that say why it is
> suitable or not), and a "friendly:*" tag could be misleading in this
> regard. I agree that there are facts that can indicate a friendlyness
> or hostility towards a certain group of people (e.g. motorcyclists,
> hikers, hunters, cyclists, ...), like the signs, so I am not
> absolutely against a tag like this, but the definition should make it
> clear that it is about objective, observable criteria.
>
>  
>
> Didn't understand what you mean with "digest approach" ?
>
>
>
> You can subscribe to the mailing list getting all the messages as soon
> as they are sent, or in a digest way (many messages together in one
> email) after n messages (I think it's 10 or 15) have been sent to the
> list.
>
> Cheers,
> Martin
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

-- 

Thilo Haug

Re: [Tagging] Fwd: Feature Proposal - Voting - tag "motorcycle friendly" for accomodations

[Thilo Haug]

Hi all,

thanks to Martin for the clarification.

In the discussion of the (former voted) wiki entry :
http://wiki.openstreetmap.org/wiki/Talk:Key:motorcycle_friendly

I referred to the definition of the German automobile club :

8X---
The German automobile club has the following criteria :

  * (Theft) safe and secure motorcycle parking areas.
  * Facilities for wet clothes.
  * Tools for minor repairs
  * Extensive information material (including tour suggestions,
excursion tips, road maps, useful addresses for motorcyclists)

https://www.adac.de/reise_freizeit/motorrad/motorradfreundliche-gastgeber/qualitaetssiegel/default.aspx
8X---

Those four points should be given if an item is categorized as "yes".

"No" means they don't accept motorcyclists (seldom, but exists).

As there are certainly accommodations
which just don't care about your means of transport,
there is also a third option, which I called "customary",
as this categorization is already in use (for nudism)
http://wiki.openstreetmap.org/wiki/Key:nudism#Tagging

So I think the criteria is quite clear and not "opinionated".
In case the description could be improved, please let me know in the
"discussion" :
http://wiki.openstreetmap.org/wiki/Proposed_features/motorcycle_friendly#Proposal

Cheers,
Thilo

Am 07.03.2017 um 11:20 schrieb Martin Koppenhoefer:
>
> 2017-03-07 10:58 GMT+01:00 Thilo Haug  >:
>
> "own data, as an overlay" doesn't make sense to me in this case,
> as it's data the community should collect, not the transformation
> of existing data collections
> ("motorcycle friendly" web pages, as they are often randomly
> listing hotels).
> This is the motivation of this tag.
>
>
> one of the basic fundamental rules in OSM is that data should be
> objective and not opinionated. We do not want restaurant reviews (or
> any other personal review) or a generalized way of saying "suitable
> for cyclists" (you can of course map the factors that say why it is
> suitable or not), and a "friendly:*" tag could be misleading in this
> regard. I agree that there are facts that can indicate a friendlyness
> or hostility towards a certain group of people (e.g. motorcyclists,
> hikers, hunters, cyclists, ...), like the signs, so I am not
> absolutely against a tag like this, but the definition should make it
> clear that it is about objective, observable criteria.
>
>  
>
> Didn't understand what you mean with "digest approach" ?
>
>
>
> You can subscribe to the mailing list getting all the messages as soon
> as they are sent, or in a digest way (many messages together in one
> email) after n messages (I think it's 10 or 15) have been sent to the
> list.
>
> Cheers,
> Martin
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

-- 

Thilo Haug
Bismarckstr.37
72764 Reutlingen

Mobil: +49 177 3185856

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

Re: [Tagging] Mapping time zones as geometries (relations)

[Jaroslav Kameník]

Hi all,

this discussion has started because of me, so I would like to add few
comments:).

Should OSM contains timezone data? I think so. Some said, we should use other
sources and overlay them over OSM, but there is no direct mapping except
description in human languages, not too usable for computer. Other thing is that
available map sources use different shapefiles, so they are not aligned to OSM.
You know, I would like to see Prague timezone in my navigation walking along
Czech borders.:)

Should we use extra geometries for timezones? As Frederik wrote, there
are 80 timezone relations now.
There is about 850 other relations tagged with timezone attribute, so
timezone relations are just fraction
of the whole amount and I am not afraid that their amount will grow
(too much). Why? Timezone relations are used
in places where timezone border goes by river/meridian/territorial
waters or to split big countries instead
of tagging hundreds of counties/ We can eliminate some (most?) of
them, but not all of them. Btw. timezone tags
can be misused too - for example - I removed useless timezone tags
from hundreds of small relations in Germany during
timezones editation, there was tag at whole country, and at lots of
admin boundaries too.

Some wrote that timezones are changing. Yes, all OSM are still
changing, shops, bus stops, new buildings, forrests
cutted, we all do such editations often I think...

Some wrote that timezones are not visible. Yes, exactly as lots of
other data in OSM.

Some wrote - delete timezone relations! Thanx, guys, it took lots of
time and work to create them...


So, for me, as you can guess, timezone relations are good and usefull
solution, but I understand that there could be
problems with their sizes and dependence to other geometry. Personally
I would compromise - leave timezone relations
where really needed (river/meridian/territorial waters/...) and change
them to tagged A.B. otherwise.



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

Re: [Tagging] Mapping time zones as geometries (relations)

[Andy Mabbett]

On 6 March 2017 at 00:30, Frederik Ramm  wrote:

> you could easily build time zone
> geometries by either (a) keeping an external database that says "Time
> Zone X consists of the following administrative units" and then
> collecting the units from OSM

That database is Wikidata. make sure that the admin boundaries are
tagged with the relevant Wikidata ID.

> I still think that the mapping of time zones as geometries
> should be discouraged in OSM.

I agree.

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Tagging] Mapping time zones as geometries (relations)

[Wolfgang Zenker]

Hi,

* Colin Smale  [170307 09:04]:
> [..]
> It is possible to have enclaves/exclaves for a territory which differs
> from the surrounding territory. Taking the US as an example, if we put a
> timezone tag on a State, there may need to be an overriding tag on a
> County or even possibly at a City level. There are also native homelands
> that cross state boundaries which have their own ideas about time. See
> [1] for more info on this. 

> We need to address reality; I suggest there are the following options: 

> 1) a multipolygon for the time zone, allowing for outer and inner rings,
> sharing ways with admin boundaries where appropriate, otherwise
> dedicated ways with "boundary=timezone" 

> 2) tagging admin boundary relations with their timezone, allowing
> lower-level entities to override their parent 

> 3) only tagging (all!) low-level entities with their timezone to avoid
> the enclave problems of option 2 

> This is actually conceptually similar to the problem of territorial
> defaults for maxspeed and loads of other things. 

> What about maritime TZ boundaries that don't correspond to an admin
> boundary? 

As we have seen in this discussion so far, timezones in international
waters are kind of meaningless or undefined.

> I cannot believe it is beyond the abilities of OSM to represent time
> zone areas. Of course it can be done. 

the question is not if OSM can represent timezones, rather if it should
and if so, in which way to do it.

Following the discussion so far it looks to me like we have a rough
consensus that the geographical extend of timezones should be in OSM
data.

I suggest following the principle of using the simplest solution that
can probably work. To me that would mean to follow your suggested
option number 2 whereever possible and in the (rare) cases where it
is not, to create multipolygons with boundary=timezone subdividing the
administrative units that sit in multiple timezones. These multipolygons
would be treated as lower-level entities overriding their parents.

There was the argument that monstrous multipolygons spanning the length
of half a continent are probably a recipe for unusable data that is
constantly broken. This would to me exclude your option 1.

Your option 3 appears to require loads and loads of redundant data
that will be permanently incomplete; I would try to avoid this.

Wolfgang

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

Re: [Tagging] Fwd: Feature Proposal - Voting - tag "motorcycle friendly" for accomodations

[Martin Koppenhoefer]

2017-03-07 10:58 GMT+01:00 Thilo Haug :

> "own data, as an overlay" doesn't make sense to me in this case,
> as it's data the community should collect, not the transformation of
> existing data collections
> ("motorcycle friendly" web pages, as they are often randomly listing
> hotels).
> This is the motivation of this tag.
>

one of the basic fundamental rules in OSM is that data should be objective
and not opinionated. We do not want restaurant reviews (or any other
personal review) or a generalized way of saying "suitable for cyclists"
(you can of course map the factors that say why it is suitable or not), and
a "friendly:*" tag could be misleading in this regard. I agree that there
are facts that can indicate a friendlyness or hostility towards a certain
group of people (e.g. motorcyclists, hikers, hunters, cyclists, ...), like
the signs, so I am not absolutely against a tag like this, but the
definition should make it clear that it is about objective, observable
criteria.



> Didn't understand what you mean with "digest approach" ?
>


You can subscribe to the mailing list getting all the messages as soon as
they are sent, or in a digest way (many messages together in one email)
after n messages (I think it's 10 or 15) have been sent to the list.

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

Re: [Tagging] Positioning motorway exits

[Volker Schmidt]

This touches on a "conflict of interest" between two requirements:
(1) OSM tagging practice is to map only physically separated ways as
separate ways in OSM.
(2) A routing algorithm needs to have information about legally separated
ways, e.g. by a continuous white line.

In the specific case the exit for the routing algorithm is at the beginning
of the continuous white line, i.e node
https://www.openstreetmap.org/node/4337339247
whereas the split of the ways according to the rule of the separate ways
puts it at node https://www.openstreetmap.org/node/370544/, where the
motorway junction is placed at the moment.

To my knowledge there is no agreed upon common practice.

I do not map motorways in Germany, but have mapped motorways and trunk
roads in Italy where we have no established common approach, and you can
find a nice mix of different approaches. I think we should come to a
general best-practice or best-practices agreement. This may imply
country-dependent recommendations.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping time zones as geometries (relations)

[Colin Smale]

On 2017-03-07 07:43, Frederik Ramm wrote:

> Kevin,
> 
> On 03/07/2017 02:06 AM, Kevin Kenny wrote: 
> 
>> There are reasonable use cases for wanting to take a timezone name and
>> get back a multipolygon
> 
> Question is, does (the core database of) OSM have to fulfil these use cases!
> 
>> or to get a list of name and multipolygon for
>> all the timezones (or all the timezones on a given map). That's hard to
>> do unless there are relations for the timezones. Not impossible, we
>> could query administrative boundaries for the tag, but that's likely to
>> be SLOW since the tag will at best be in hstore and not indexed.
>> Grouping disjoint items, such as "all the administrative regions in a
>> time zone" seems tailor-made for relations.
> 
> In my opinion, no. We've been there - people (ab)using relations like
> some kind of bookmark, to make data retrieval easier (e.g. a relation
> "all cycleways in XY city" just because it was slow/difficult to
> retrieve them otherwise).
> 
> You would typically use a relation to group things when they can be in
> more group than one, and therefore tagging the membership on the
> individual object becomes cumbersome - cycle, bus, or hiking routes are
> a prime example, since the same street/way can be part of several of them.
> 
> Not so with time zones, I should hope; a region can only be associated
> with exactly one (not 0, not more than one) time zone. Hence adding a
> time zone tag to the object is the easiest way to maintain the data and
> to ensure that you don't accidentally have two!
> 
> I agree it might make things a little more difficult for the consumer
> but an overpass query can quickly find every boundary relation tagged
> with a certain time zone, and I'm sure sooner or later specialist sites
> will take the data and prepare daily updated json files or whatever that
> one can overlay on a map.

It is possible to have enclaves/exclaves for a territory which differs
from the surrounding territory. Taking the US as an example, if we put a
timezone tag on a State, there may need to be an overriding tag on a
County or even possibly at a City level. There are also native homelands
that cross state boundaries which have their own ideas about time. See
[1] for more info on this. 

We need to address reality; I suggest there are the following options: 

1) a multipolygon for the time zone, allowing for outer and inner rings,
sharing ways with admin boundaries where appropriate, otherwise
dedicated ways with "boundary=timezone" 

2) tagging admin boundary relations with their timezone, allowing
lower-level entities to override their parent 

3) only tagging (all!) low-level entities with their timezone to avoid
the enclave problems of option 2 

This is actually conceptually similar to the problem of territorial
defaults for maxspeed and loads of other things. 

What about maritime TZ boundaries that don't correspond to an admin
boundary? 

I cannot believe it is beyond the abilities of OSM to represent time
zone areas. Of course it can be done. 

//colin 

[1] https://en.wikipedia.org/wiki/Time_in_the_United_States 

> Bye
> Frederik___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging