Re: [Tagging] Public transport cards

[Martin Koppenhoefer]

sent from a phone

> On 17 Jan 2017, at 11:51, Marc Zoutendijk  wrote:
> 
> I’m a very heavy user of public transport and I always use the website from 
> the operator to find out when/where/how my bus/train is going. I would not 
> even think of OSM…


unless your public transport operator has a portal that is worse than looking 
at an osm map ;-)

/anecdotal/
I recall the local portal some years ago (admit they have slightly improved in 
the mean time) recommending me to walk for 51 minutes to a distant bus stop to 
save some changes when the next stop was 2 minutes away and although that one 
required several more changes, as it was raining it was absolutely preferable).

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

Re: [Tagging] Representing "altimetric quotas" in OSM

[Martin Koppenhoefer]

2017-01-17 18:35 GMT+01:00 Nelson A. de Oliveira :

> "ele" without any other attribute is valid?



yes, you can do it, but there's the risk that following mappers will move
the node around if there's nothing visibly identifiable attached to it, and
the positional accuracy will remain opaque. (Some editors will prominently
highlight the node if it has any tag on it, others will not make it very
evident and someone might move it without noting).

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

Re: [Tagging] Representing "altimetric quotas" in OSM

[Shawn K. Quinn]

On 01/18/2017 04:23 AM, Martin Koppenhoefer wrote:
> 
> 2017-01-17 18:35 GMT+01:00 Nelson A. de Oliveira  >:
> 
> "ele" without any other attribute is valid?
> 
> 
> 
> yes, you can do it, but there's the risk that following mappers will
> move the node around if there's nothing visibly identifiable attached to
> it, and the positional accuracy will remain opaque. (Some editors will
> prominently highlight the node if it has any tag on it, others will not
> make it very evident and someone might move it without noting).

JOSM will highlight a tagged node it doesn't recognize as something else
in bright cyan. iD, as of what I remember from the last time I used it,
does not differentiate between an untagged node and a tagged node it
doesn't recognize.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=fuel

[joost schouppe]

> There are general stores (shop= ) that sell fuel too ...

Well, that goes for any product and any shop. While your suggestion does
make sense, we already have a long list of shop types. No one made this
particular suggestion during the fuel-shop discussion (unless I'm mistaken).

But it is true that it might have been more logical to only use shop=[shop
type] for shops that sell a range of products that people have an idea of
(e.g. diy, supermarket). Any shop that specializes in just one product (or
an unusual combination of things) could then be tagged with shop=yes +
sells (or vending:*=*?) to specify what you can buy there. That would have
made tagging specialty stores a lot easier i guess. You could then add
stuff like vending:bread=no to supermarkets if their range excludes
something you would expect (in stead of tagging every little thing they
sell with a positive).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=fuel

[Marc Gemis]

I guess that for every categorization, whether you use shop=x or,
sell=x;y;z or sell:x=yes someone will come by and want to divide that
category into two. So x will be split into x' and x'', both
subcategories of x, until we end up with the categories containing
exactly one product :-)

imho we should stay pragmatic and not to try to add too much detail.
In the end the user will still have to consult the pricelist of the
shop to see whether she wants the specific product for the price
offered by the store and whether the product is available at the
moment of the purchase.

m



On Wed, Jan 18, 2017 at 12:19 PM, joost schouppe
 wrote:
>> There are general stores (shop= ) that sell fuel too ...
>
> Well, that goes for any product and any shop. While your suggestion does
> make sense, we already have a long list of shop types. No one made this
> particular suggestion during the fuel-shop discussion (unless I'm mistaken).
>
> But it is true that it might have been more logical to only use shop=[shop
> type] for shops that sell a range of products that people have an idea of
> (e.g. diy, supermarket). Any shop that specializes in just one product (or
> an unusual combination of things) could then be tagged with shop=yes + sells
> (or vending:*=*?) to specify what you can buy there. That would have made
> tagging specialty stores a lot easier i guess. You could then add stuff like
> vending:bread=no to supermarkets if their range excludes something you would
> expect (in stead of tagging every little thing they sell with a positive).
>
>
>
> ___
> 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] shop=fuel

[Dave Swarthout]

This tag started out being for a very specific type of shop that sells only
one item, motor fuel, in small volume containers. There is a need to keep
shops of this type separate from large full-service facilities that sell
motor fuel in quantities large enough to refill cars or trucks. lt has
now been expanded to include other types of fuel like kerosene and even
charcoal. Fine. That's logical and sensible.

But if you want to rework the tagging structure to handle such borderline
cases as fuel shops that also sell bread, then I feel that would be
defeating the original purpose of this tag. Where will these additions and
modifications stop? A logical but not particularly useful extension of that
reasoning might involve redefining the entire structure of the shop tag
hierarchy by using shop=yes, bread=yes, Crest_brand_toothpaste=yes,
fuel:diesel=yes, knitting_supplies=yes, etc. etc.

But feel free to do so if you must.

On Wed, Jan 18, 2017 at 9:03 PM, Marc Gemis  wrote:

> I guess that for every categorization, whether you use shop=x or,
> sell=x;y;z or sell:x=yes someone will come by and want to divide that
> category into two. So x will be split into x' and x'', both
> subcategories of x, until we end up with the categories containing
> exactly one product :-)
>
> imho we should stay pragmatic and not to try to add too much detail.
> In the end the user will still have to consult the pricelist of the
> shop to see whether she wants the specific product for the price
> offered by the store and whether the product is available at the
> moment of the purchase.
>
> m
>
>
>
> On Wed, Jan 18, 2017 at 12:19 PM, joost schouppe
>  wrote:
> >> There are general stores (shop= ) that sell fuel too ...
> >
> > Well, that goes for any product and any shop. While your suggestion does
> > make sense, we already have a long list of shop types. No one made this
> > particular suggestion during the fuel-shop discussion (unless I'm
> mistaken).
> >
> > But it is true that it might have been more logical to only use
> shop=[shop
> > type] for shops that sell a range of products that people have an idea of
> > (e.g. diy, supermarket). Any shop that specializes in just one product
> (or
> > an unusual combination of things) could then be tagged with shop=yes +
> sells
> > (or vending:*=*?) to specify what you can buy there. That would have made
> > tagging specialty stores a lot easier i guess. You could then add stuff
> like
> > vending:bread=no to supermarkets if their range excludes something you
> would
> > expect (in stead of tagging every little thing they sell with a
> positive).
> >
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] cardinal directions

[Martijn van Exel]

I am trying to be consistent with the outcome of the discussion that we had on 
talk-us a couple of years ago. Right now both are used (north/south/east/west 
as relation member role as well as direction on the relation tag) but the 
former is used way more often. That’s why I am suggesting going with the 
practice that has surfaced as the most popular, as well as the outcome of 
earlier discussion. 

Perhaps I am not understanding you correctly, but I am *not* suggesting to use 
tags on ways to indicate cardinal direction, just assign roles to relation 
members. Agreed that adding this type of info to ways makes it impossible to 
validate / maintain.

This also does not have to preclude having separate e/w or n/s relations + a 
super relation — I think that is actually good practice for big relations to 
keep them manageable.

Martijn van Exel

> On Jan 13, 2017, at 11:40 PM, Paul Johnson  wrote:
> 
> 
> 
> On Fri, Jan 13, 2017 at 3:42 PM, Martijn van Exel  > wrote:
> Hi all, 
> 
> Some of you may remember the discussion we had on tagging cardinal directions 
> in the US, which led to the wiki page[1] describing the current practice.
> Basically the convention we arrived on is to tag relation members with 
> role=north/east/south/west to indicate cardinal direction.
> This is backed up by usage in the US. About 75% of way members of Interstate 
> road relations have directional role members[2].
> 
> Can we not do this?  Can this not be a thing?  Can we instead go route master 
> and only have child relations have cardinal roles, with child ways being 
> exclusively forward/backward?  Because cardinal directions on the ways 
> themselves is 1) ambiguous AF and 2) breaks validation on a level that it can 
> take hours to days for experienced editors to manually validate, and can't be 
> automated as a result.
> 
> ___
> Talk-us mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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

Re: [Tagging] shop=fuel

[joost schouppe]

2017-01-18 15:33 GMT+01:00 Dave Swarthout :

> This tag started out being for a very specific type of shop that sells
> only one item, motor fuel, in small volume containers. There is a need to
> keep shops of this type separate from large full-service facilities that
> sell motor fuel in quantities large enough to refill cars or trucks. lt has
> now been expanded to include other types of fuel like kerosene and even
> charcoal. Fine. That's logical and sensible.
>
> But if you want to rework the tagging structure to handle such borderline
> cases as fuel shops that also sell bread, then I feel that would be
> defeating the original purpose of this tag. Where will these additions and
> modifications stop? A logical but not particularly useful extension of that
> reasoning might involve redefining the entire structure of the shop tag
> hierarchy by using shop=yes, bread=yes, Crest_brand_toothpaste=yes,
> fuel:diesel=yes, knitting_supplies=yes, etc. etc.
>

Well, I for one like to take a middle ground between what works now and
what we will probably need in the future.

Vending machines are mapped entirely according to this model, using
vending:*=* . By the logic we used for shop=*, it should have been
amenity=bread_vending_machine or amenity=vending_machine + bread=yes. The
vending:* tagging style makes it easier to process all sorts of data, and
easily allows further extension.

I wouldn't say we should change shop tagging styles to that. I was merely
taking the stated position that fuel shops should follow that structure to
its logical conclusion. And I'm starting to think we might actually have to
consider it to avoid ever further cluttering of the shop types.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Public transport cards

[Lauri Kytömaa]

Warin wrote:
>Marc Gemis wrote:
>> bus/bike/train routes. Something no PT provider can offer as they only
> Never say never?
>
> A PT provider with multi modal planer - bus, train, light rail  and ferry
> for Sydney, Australia
>
> http://www.transportnsw.info/

Fwiw, we've had a country wide bus-train-airplane router for years
http://www.journey.fi/en/ although I'm not absolutely certain it has local bus
timetables for each and every small town that might have some bus lines;
just one such place is listed currently.
It has an updated version in public beta,
like this (doesn't seem to support linking to a specific UI language):

https://beta.matka.fi/reitti/Toukola,%20Helsinki::60.208836,24.972565/Levintie,%20Kittil%C3%A4::67.724127,24.854204

(If you only get one route suggestion, you get more by changing the
departure time to noonish.)

-- 
alv

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

Re: [Tagging] zero waste

[Éric Gillet]

2017-01-17 17:01 GMT+01:00 Martin Koppenhoefer :
>
> > On 17 Jan 2017, at 13:50, Greg Troxel  wrote:
> >
> > certification:zero-waste.org=yes
>
>
> +1


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

Re: [Tagging] shop=fuel

[Marc Gemis]

I thought we went through this discussion on sell or vending a couple
of months ago, where the fear was that we would start "importing" the
sales catalogue of shops and that it would be very hard to maintain.

A vending machine typically sells 1 type of product, so there it is
more or less doable.
Still there will be people who would like to different between the
types of bread or brands of candy or sodas in vending machines and
start mapping that as well. Is this what we want ? Or is the current
level of detail sufficient ?





On Wed, Jan 18, 2017 at 4:35 PM, joost schouppe
 wrote:
>
> 2017-01-18 15:33 GMT+01:00 Dave Swarthout :
>>
>> This tag started out being for a very specific type of shop that sells
>> only one item, motor fuel, in small volume containers. There is a need to
>> keep shops of this type separate from large full-service facilities that
>> sell motor fuel in quantities large enough to refill cars or trucks. lt has
>> now been expanded to include other types of fuel like kerosene and even
>> charcoal. Fine. That's logical and sensible.
>>
>> But if you want to rework the tagging structure to handle such borderline
>> cases as fuel shops that also sell bread, then I feel that would be
>> defeating the original purpose of this tag. Where will these additions and
>> modifications stop? A logical but not particularly useful extension of that
>> reasoning might involve redefining the entire structure of the shop tag
>> hierarchy by using shop=yes, bread=yes, Crest_brand_toothpaste=yes,
>> fuel:diesel=yes, knitting_supplies=yes, etc. etc.
>
>
> Well, I for one like to take a middle ground between what works now and what
> we will probably need in the future.
>
> Vending machines are mapped entirely according to this model, using
> vending:*=* . By the logic we used for shop=*, it should have been
> amenity=bread_vending_machine or amenity=vending_machine + bread=yes. The
> vending:* tagging style makes it easier to process all sorts of data, and
> easily allows further extension.
>
> I wouldn't say we should change shop tagging styles to that. I was merely
> taking the stated position that fuel shops should follow that structure to
> its logical conclusion. And I'm starting to think we might actually have to
> consider it to avoid ever further cluttering of the shop types.
>
> ___
> 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] Representing "altimetric quotas" in OSM

[Warin]

On 18-Jan-17 09:28 PM, Shawn K. Quinn wrote:

On 01/18/2017 04:23 AM, Martin Koppenhoefer wrote:

2017-01-17 18:35 GMT+01:00 Nelson A. de Oliveira mailto:nao...@gmail.com>>:

 "ele" without any other attribute is valid?



yes, you can do it, but there's the risk that following mappers will
move the node around if there's nothing visibly identifiable attached to
it, and the positional accuracy will remain opaque. (Some editors will
prominently highlight the node if it has any tag on it, others will not
make it very evident and someone might move it without noting).

JOSM will highlight a tagged node it doesn't recognize as something else
in bright cyan. iD, as of what I remember from the last time I used it,
does not differentiate between an untagged node and a tagged node it
doesn't recognize.


It would assist if the simple node with tag 'ele' on it also included the 
source so it can easily be checked and possibly a note to explain it.


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

Re: [Tagging] shop=fuel

[Warin]

On 19-Jan-17 06:48 AM, Marc Gemis wrote:

I thought we went through this discussion on sell or vending a couple
of months ago, where the fear was that we would start "importing" the
sales catalogue of shops and that it would be very hard to maintain.


Yes. It was I who raised it.

Those who object to such detail don't have to add it, use it ... many won't use 
certain OSM tags now as they have nothing to do with them.
Some people on that thread requested more and more detail .. so I suggested 
ways that that could be done.
Then others said that was too much detail ... and there people that wanted the 
detail dissipated in to the eather.




A vending machine typically sells 1 type of product, so there it is
more or less doable.
Still there will be people who would like to different between the
types of bread or brands of candy or sodas in vending machines and
start mapping that as well. Is this what we want ? Or is the current
level of detail sufficient ?


Detail will get finer as time goes by.

Look at the highway tag ... now has incline, smoothness, surface ...

Progress is not necessarily good for all but will occur. If undirected it may 
well be uncoordinated.

OSM is now getting 'sells' tags by individual names ... meaning there will be a 
lot of new tags that will need some thought.

Examples of this are the present fuel, motorcycle and bicycle shops .. all 
separate sells tags that are individual schemes... little co-ordination.

Consider having each highway type with separate ways of tagging smoothness

motorways have evenness fine to poor

tracks have roughness; very to little

residential have smoothness 0 to 10

That is where shops selling detail is headed.







On Wed, Jan 18, 2017 at 4:35 PM, joost schouppe
 wrote:

2017-01-18 15:33 GMT+01:00 Dave Swarthout :

This tag started out being for a very specific type of shop that sells
only one item, motor fuel, in small volume containers. There is a need to
keep shops of this type separate from large full-service facilities that
sell motor fuel in quantities large enough to refill cars or trucks. lt has
now been expanded to include other types of fuel like kerosene and even
charcoal. Fine. That's logical and sensible.

But if you want to rework the tagging structure to handle such borderline
cases as fuel shops that also sell bread, then I feel that would be
defeating the original purpose of this tag. Where will these additions and
modifications stop? A logical but not particularly useful extension of that
reasoning might involve redefining the entire structure of the shop tag
hierarchy by using shop=yes, bread=yes, Crest_brand_toothpaste=yes,
fuel:diesel=yes, knitting_supplies=yes, etc. etc.


Well, I for one like to take a middle ground between what works now and what
we will probably need in the future.

Vending machines are mapped entirely according to this model, using
vending:*=* . By the logic we used for shop=*, it should have been
amenity=bread_vending_machine or amenity=vending_machine + bread=yes. The
vending:* tagging style makes it easier to process all sorts of data, and
easily allows further extension.

I wouldn't say we should change shop tagging styles to that. I was merely
taking the stated position that fuel shops should follow that structure to
its logical conclusion. And I'm starting to think we might actually have to
consider it to avoid ever further cluttering of the shop types.

__



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

Re: [Tagging] [Talk-us] cardinal directions

[Paul Johnson]

On Wed, Jan 18, 2017 at 8:59 AM, Martijn van Exel  wrote:

> I am trying to be consistent with the outcome of the discussion that we
> had on talk-us a couple of years ago. Right now both are used
> (north/south/east/west as relation member role as well as direction on the
> relation tag) but the former is used way more often. That’s why I am
> suggesting going with the practice that has surfaced as the most popular,
> as well as the outcome of earlier discussion.
>
> Perhaps I am not understanding you correctly, but I am *not* suggesting to
> use tags on ways to indicate cardinal direction, just assign roles to
> relation members. Agreed that adding this type of info to ways makes it
> impossible to validate / maintain.
>

Right, I think we're on the same page.  I'm also suggesting it's high time
we revisited the issue as the tools to handle managing
north/east/south/west roles (as opposed to forward/backward) just plain
never materialized.  If it was going to happen, it would have already
happened (it's been years!).


> This also does not have to preclude having separate e/w or n/s relations +
> a super relation — I think that is actually good practice for big relations
> to keep them manageable.
>

 Pretty much have to for any relation that has a dual carriageway at one
end and is more than a few ways long.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging