Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

key: /almost all tagging should occur here/ | _data may be reused in 
parent_ | *data may be reused in parent and any 'adjacent' (with the 
same letter) parent*


/public transport network///[A]

   /route_master=public transport /[B]

   /route variant/ [C]

   _combined stop/way relation suitable for public transport
   v2_ [E]

   _*shared way relation*_ [G]

/road network///[A]

   /road /[C]

   _*shared way relation*_ [G]


/cycle network//**/[A]

   /cycle route /[C]

   *_shared way relation_* [G]

_

potential new use of tags that may be required:

[E/G]: type=route + route=part

_

notes:

 * [G] may be infinitely nested as required to prevent duplicate sets
   of ways (although this should rarely be required)
 * [G] may require names in some cases and should always require
   type=route, but should include no other tags unless it very
   specifically relates to only the members of the relation and can't
   be included in any parent relation (unicorns are probably more common)
 * [G] should almost always not be used for a single way unless it will
   assist in maintainability. if a
 * I don't believe route_master=public transport actually exists, but
   the same concept should work for any public transport
 * the route=* tag should not be required until you move up to [C],
   shared way relations and bus stop relations should be open to any
   route type to increase re-usability
 * as they are just a connected line of ways, shared way relations
   should be usable in either direction, the direction to use could be
   specified via a role. although reusable for routes going in the same
   direction, [E] will rarely be reusable for both directions of a
   route because it contains both platforms and stops, and platforms
   usually differ depending on direction.
 * if this becomes accepted it may become a good idea to specify a
   members limit for relations (at which point it should be split up).
   such ways should probably
 * I may consider adding a rough idea on perceived pros/cons, depending
   on demand
 * I may add a more visual version, depending on demand
 * example will be coming with version 4 (if you wish to add your own
   as well, or an inspired version please base it heavily on reality if
   it is on main OSM. do not make any existing route relations unusable)

_

changelog:

#2

 * fix mistake in key
 * add missing formatting to key
 * remove redundant reference to [F]
 * specify when example should be live
 * update potentially needed tags following discussion
 * remove mention of shared=yes, this does not need to be used in the
   newest version
 * reorder changelog so it's newest first

#1

 * removed [D] and [F]. [D] was meant to be removed prior to sending,
   [F] is not required.
 * added a few more notes so it may be referred to on its own
 * the bus example applies to any public transport really, adjust
   language accordingly
 * warned against damaging existing relations' usability/the creation
   of fictional data
 * added extra details on a request if needed basis
 * added this changelog and relevant versioning to help people keep
   track. this should be traceable to the (unlabelled) version 0

#0

 * initial concept

special thanks:

 * you may request your name here and optionally credits for ideas you
   contributed (being kept in an opt in basis in case people don't want
   their names shown)

On 3/15/19 5:54 PM, seirra blake wrote:


key: almost tagging should occur here | data may be reused in parent | 
data may be reused in parent and any 'adjacent' (with the same letter) 
parent


/public transport network///[A]/
/

/route_master=public transport /[B]

/route variant/ [C]

_combined stop/way relation suitable for public transport
v2_ [E]

_*shared way relation*_ [G]


/road network///[A]/
/

/road /[C]

_*shared way relation*_ [G]*
*


/cycle network//**/[A]/*
*/

/cycle route /[C]

__

__

*_shared way relation_* [G]

_

potential new tags that may be required:

[C]: shared=yes (to tell the software there is use of shared ways, but 
the software probably should be able to work that out)


[E/F/G]: route=shared (this is considered in case type=route 
explicitly requires a route=* key)


_

notes:

  * [G] may be infinitely nested as required to prevent duplicate sets
of ways (although this should rarely be required)
  * [G] may require names in some cases and should always require
type=route, but should include no other

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

hmm maybe. version 4 will include a detailed example, once that is 
available feel free what would be missing for that purpose


On 3/15/19 7:19 PM, Martin Koppenhoefer wrote:

maybe we can have roles to state whether the tags of the referenced object 
should apply to the relation or if only the geometry matters. These superroutes 
could be also useful for admin relations

Cheers, Martin
___
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] Superroutes - good, bad or ugly?

[seirra blake]

hmm... I'm not quite sure on what would be best. I do see your point in 
the case of just splitting very long ways there, they would not be 
'shared' at all. to the best of my knowledge type=* is intended to 
exclusively define the relation. in all circumstances that we have 
discussed, it still joins up to make a route, so perhaps its best not to 
change the relation type. the chain idea is a nice one, but that would 
make the smaller bits that join together... links. that may get 
confusing quite fast; or chain-links, which might sound a bit too much 
like we're talking about a physical chain.  part might be a good 
candidate, it's already there in the sense of building:part=*; so 
following similar convention we could have route:part=yes, that seems 
pretty intuitive; although we can probably go a step further and just do 
a combination of type=route and route=part, I'll probably use that in 
the example I make.


On 3/15/19 7:03 PM, Peter Elderson wrote:
The just-a-chain-of-ways relation doesn't have to be shared. It's 
shareable, but the sharing really is of no consequence.


I think software needs a tag to control the selection for the purpose 
it serves, OR allow any route relation without a type within all route 
types it supports.
I would indeed go for an explicit label, just not "shared". Maybe 
"general" or "chain" or "basic" or "segment", "fragment", 
"elementary", just not something that says how it's going to be used.


Editors can keep their check that there MUST be a supported type tag, 
and add that type=basic (or whatever word is chosen) can only have a 
single consecutive ordered collection of ways. Other routes of any 
type should be allowed to contain ways AND basic routes, apart from 
more complex checking for particular cases such as PT variants.


___
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] Superroutes - good, bad or ugly?

[seirra blake]

I can understand your concern. I did actually consider mentioning 
something about skipping stops.. but I forgot to, I spent a good few 
hours on the original, so I guess my thoughts got easily distracted. 
I'll make an example based on the real data to help illustrate the idea, 
but I'll also include an imaginary express version that only stops at a 
few major stops. provided everything goes as planned I'll link to a 
fairly realistic example in version 4 (I need version 3 to fix a mistake 
I made). I understand that you may not want to follow each version due 
to being busy or whatever, so until the example is ready any future 
version will be 3.x (so for example: 3.0,3.1,3.2...); this way you'll be 
able to Ctrl+f and search for '#4', if there's no #4 it isn't ready yet 
and so you won't waste your time reading through the changelog for it. 
as for seeing all the stops/being able to compare to official feeds, 
that may fall more under what the renderer is expected to do, as it 
should already be reading all the segments as one whole route.


On 3/15/19 6:30 PM, Jo wrote:
When I start mapping a bus line, I have several route relations which 
contain all the stops for each variation in itinerary.


When I add the ways, it would be nice to reuse subroute relations for 
the parts where ways are shared between lines.


When I come back later and I want to compare whether the number of 
variations for a line is still the same, I want to compare against 
sequences of stops in the route relations, hence the reason why I 
would not add the stops to the subroute segments. (Compare against 
data from the operator or GTFS)


We also have 'express' lines that skip stops. if the stops are put in 
the subroute relations, then they can not be reused for those lines.


As far as I'm concerned, the sequence of stops is the 'signature' 
defining each variation in itinerary.


Polyglot

On Fri, Mar 15, 2019 at 6:55 PM seirra blake 
mailto:sophietheopos...@yandex.com>> wrote:


key: almost tagging should occur here | data may be reused in
parent | data may be reused in parent and any 'adjacent' (with the
same letter) parent

/public transport network///[A]/
/

/route_master=public transport /[B]

/route variant/ [C]

_combined stop/way relation suitable for public
transport v2_ [E]

_*shared way relation*_ [G]


/road network///[A]/
/

/road /[C]

_*shared way relation*_ [G]*
*


/cycle network//**/[A]/*
*/

/cycle route /[C]

__

__

*_shared way relation_* [G]


_

potential new tags that may be required:

[C]: shared=yes (to tell the software there is use of shared ways,
but the software probably should be able to work that out)

[E/F/G]: route=shared (this is considered in case type=route
explicitly requires a route=* key)


_

notes:

  * [G] may be infinitely nested as required to prevent duplicate
sets of ways (although this should rarely be required)
  * [G] may require names in some cases and should always require
type=route, but should include no other tags unless it very
specifically relates to only the members of the relation and
can't be included in any parent relation (unicorns are
probably more common)
  * [G] should almost always not be used for a single way unless
it will assist in maintainability. if a
  * I don't believe route_master=public transport actually exists,
but the same concept should work for any public transport
  * the route=* tag should not be required until you move up to
[C], shared way relations and bus stop relations should be
open to any route type to increase re-usability
  * as they are just a connected line of ways, shared way
relations should be usable in either direction, the direction
to use could be specified via a role. although reusable for
routes going in the same direction, [E] will rarely be
reusable for both directions of a route because it contains
both platforms and stops, and platforms usually differ
depending on direction.
  * if this becomes accepted it may become a good idea to specify
a members limit for relations (at which point it should be
split up). such ways should probably
  * I may consider adding a rough idea on perceived pros/cons,
depending on demand
  * I may add a more visual version, depending on demand
  * I may add an actual example, depending on demand (if you wish
to add your own as well, or an inspired version please base it
heavily on reality if it is on main O

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

key: almost tagging should occur here | data may be reused in parent | 
data may be reused in parent and any 'adjacent' (with the same letter) 
parent

//

/public transport network///[A]/
/

   /route_master=public transport /[B]

   /route variant/ [C]

   _combined stop/way relation suitable for public transport
   v2_ [E]

   _*shared way relation*_ [G]


/road network///[A]/
/

   /road /[C]

   _*shared way relation*_ [G]*
   *


/cycle network//**/[A]/*
*/

   /cycle route /[C]

   __

   __

   *_shared way relation_* [G]

_

potential new tags that may be required:

[C]: shared=yes (to tell the software there is use of shared ways, but 
the software probably should be able to work that out)


[E/F/G]: route=shared (this is considered in case type=route explicitly 
requires a route=* key)


_

notes:

 * [G] may be infinitely nested as required to prevent duplicate sets
   of ways (although this should rarely be required)
 * [G] may require names in some cases and should always require
   type=route, but should include no other tags unless it very
   specifically relates to only the members of the relation and can't
   be included in any parent relation (unicorns are probably more common)
 * [G] should almost always not be used for a single way unless it will
   assist in maintainability. if a
 * I don't believe route_master=public transport actually exists, but
   the same concept should work for any public transport
 * the route=* tag should not be required until you move up to [C],
   shared way relations and bus stop relations should be open to any
   route type to increase re-usability
 * as they are just a connected line of ways, shared way relations
   should be usable in either direction, the direction to use could be
   specified via a role. although reusable for routes going in the same
   direction, [E] will rarely be reusable for both directions of a
   route because it contains both platforms and stops, and platforms
   usually differ depending on direction.
 * if this becomes accepted it may become a good idea to specify a
   members limit for relations (at which point it should be split up).
   such ways should probably
 * I may consider adding a rough idea on perceived pros/cons, depending
   on demand
 * I may add a more visual version, depending on demand
 * I may add an actual example, depending on demand (if you wish to add
   your own as well, or an inspired version please base it heavily on
   reality if it is on main OSM. do not make any existing route
   relations unusable)

_

changelog:

#0

 * initial concept

#1

 * removed [D] and [F]. [D] was meant to be removed prior to sending,
   [F] is not required.
 * added a few more notes so it may be referred to on its own
 * the bus example applies to any public transport really, adjust
   language accordingly
 * warned against damaging existing relations' usability/the creation
   of fictional data
 * added extra details on a request if needed basis
 * added this changelog and relevant versioning to help people keep
   track. this should be traceable to the (unlabelled) version 0

special thanks:

 * you may request your name here and optionally credits for ideas you
   contributed (being kept in an opt in basis in case people don't want
   their names shown)

On 3/15/19 2:37 PM, seirra blake wrote:


I can see *a lot* of shared routes in my area because most of the 
buses heavily use a star topography (everything must take you to a 
central station) as opposed to a hybrid mesh/star topography 
(everywhere has access to a service to a central station, but there 
are circular routes to allow quicker travel in some circumstances). 
for example my local service has one incredibly early train station 
detour (presumably for long distance commuters), the two main routes 
(incoming/outgoing) and a route that stops at the bus depot. all 4 of 
these routes share a large part of it and that's just one route 
number! such route segments could help shrink and simplify maintaining 
the relations a lot. for example if there's a detour due to roadworks, 
you don't have to edit the very large number of relations 
individually, (our bus station has around 20 bays, each taking 
multiple services...) just the shared child relations. I don't think 
we need a  specially labelled super route relation, but perhaps we do 
need a way to tell the data user that a segment is shared. these are 
the problems I see:


 1. where do the tags go?
 2. do you need a separate one for each direction?
 3. is type=super_route or similar the best idea?
 4. how far can they nest?
 5. a shared route is being used for public transport, should the stop
positions and bus

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

yeah roughly so. in terms of mapping, no. as relations are on somewhat 
of a 'meta' level though, I considered it mostly due to the fact people 
seem to feel some sort of tag is needed. I (personally) wondered whether 
the use of type=route would require the use of a route tag no matter 
what (or I guess... should we just use a new type=shared? people seemed 
to preferably not want an entire new relation type though). but yeah the 
idea is essentially that the shared segments may be used in place of the 
identical set of ways independent of whatever the route wants to use 
them for. as it defeats the purpose for public transport somewhat if the 
bus stops/stop positions are still defined uniquely for each route the 
idea is that you can also make shared relations for those. the original 
idea was that you have a relation connecting two separate bus stop and 
way relations but after some thought... bus stops are always (unless 
there's a very extreme earthquake maybe? but I think if it's strong 
enough to physically switch bus stops we have more important things to 
worry about) attached to the same ways. I will upload a slightly updated 
version, just bear with me while I make sure I've checked all my emails 
and update it. I will reply to myself with it


On 3/15/19 3:22 PM, Peter Elderson wrote:


This seems to boil down to: You can put any sequence of connected ways 
in a package (shared route segment) and use that package in any route 
to replace these ways themselves.


You would need to allow all types of route relations to contain ways 
and shared segment relations.


I'm not sure if you would need any special tag to indicate it's 
shared. If it's used more than once, it's shared, right?


Fr gr Peter Elderson


Op vr 15 mrt. 2019 om 15:38 schreef seirra blake 
mailto:sophietheopos...@yandex.com>>:


I can see *a lot* of shared routes in my area because most of the
buses heavily use a star topography (everything must take you to a
central station) as opposed to a hybrid mesh/star topography
(everywhere has access to a service to a central station, but
there are circular routes to allow quicker travel in some
circumstances). for example my local service has one incredibly
early train station detour (presumably for long distance
commuters), the two main routes (incoming/outgoing) and a route
that stops at the bus depot. all 4 of these routes share a large
part of it and that's just one route number! such route segments
could help shrink and simplify maintaining the relations a lot.
for example if there's a detour due to roadworks, you don't have
to edit the very large number of relations individually, (our bus
station has around 20 bays, each taking multiple services...) just
the shared child relations. I don't think we need a  specially
labelled super route relation, but perhaps we do need a way to
tell the data user that a segment is shared. these are the
problems I see:

 1. where do the tags go?
 2. do you need a separate one for each direction?
 3. is type=super_route or similar the best idea?
 4. how far can they nest?
 5. a shared route is being used for public transport, should the
stop positions and bus stops be included with all the ways?

so... what do we do? this is what I see as a solution:

 1. if a route is shared, tags should be minimal and only related
to the physical route itself perhaps not even including the
usual route tag (AFAIK wouldn't just about any route relation
in existence define the route tag? so this would just be
another pointer to the software that this isn't your regular
route. but maybe it still is best to tag it, in which case
maybe route=shared?), rather than things such as what bus
routes it is part or anything, this can easily be seen simply
by looking at parent relations
 2. maybe use the roles forward/backward? I don't think these are
used for much any more
 3. what do we gain? I think this can more easily be solved by
simply adding another tag such as shared=yes which can tell
the software that there are route relations that are intended
to be treated as just one big way. see below for a more
detailed explanation.
 4. I don't see a reason to limit the nesting, I imagine in most
use cases, the benefit of sharing duplicate relation data
probably outweighs any impact from processing nesting
 5. if a shared route is used for both a numbered road route and
public transport it's probably unfair on the road user that
doesn't need them if they are included. also this would make
it difficult to work out where to place it in a public
transport V2 relation.. as they have stops at the top, ways at
the bottom but this has both!

so here's an indented, somewhat simplified example 

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

oh the idea is that [G] has type=route, but no route=* because it may be 
used in any form of route (with some 'common sense' of course); route 
does not apply until [C] so route=road would not get reused. there is 
actually a small error, [D/E] is the same and stays exclusively within 
public transport. unless you actively map an island I would hope you are 
joking. in case you weren't the context is that someone made a whole 
fake settlement on an actual island so it would render on the main page 
and someone had to revert a whole load of changesets. I can't imagine 
much friction from the local community if I make an example relation 
alongside the current one and add a note that until further notice 
although based on real data it's a proof of concept though. I'll reply 
to my own email and add a slightly more updated version (just of the 
example) addressing some of this, just to make sure it's clear what I 
meant. if you feel an example would help somewhat I'll make one too; it 
could be useful to see how renderers handle it now. let me know if you'd 
like a 'physical' example.


On 3/15/19 3:00 PM, Jo wrote:

Good analysis Seirra,

I would not "reuse" route=road in other route=* relations though. 
route=bicycle might share segments with route=foot/walking/hiking, but 
I'd keep everything related to bus/trolley_bus and coach together in 
terms of sharing of subroutes not mix it with other route types.


For public transport the biggest benefit will be ease of maintenance.

The way I see it route=bus relation should describe a single variation 
in itinerary, and thus include all the stops for that variation. So in 
my view the subroutes only contain ways.
I would create subroutes for each direction of travel, so no 
forward/backward roles need to become involved. If the subroute would 
only contain a single way, a subroute relation probably wasn't needed.


Paul Allen, I did read your objections to this, but that bus route is 
wildly exceptional, whereas buses travelling along 'corridors', 
reusing the same roads as the rest of the lines is very common (as 
that is where the stops are, obviously).


Maybe I should try to create an example somewhere. Preferably a small 
island


Polyglot

On Fri, Mar 15, 2019 at 3:38 PM seirra blake 
mailto:sophietheopos...@yandex.com>> wrote:


I can see *a lot* of shared routes in my area because most of the
buses heavily use a star topography (everything must take you to a
central station) as opposed to a hybrid mesh/star topography
(everywhere has access to a service to a central station, but
there are circular routes to allow quicker travel in some
circumstances). for example my local service has one incredibly
early train station detour (presumably for long distance
commuters), the two main routes (incoming/outgoing) and a route
that stops at the bus depot. all 4 of these routes share a large
part of it and that's just one route number! such route segments
could help shrink and simplify maintaining the relations a lot.
for example if there's a detour due to roadworks, you don't have
to edit the very large number of relations individually, (our bus
station has around 20 bays, each taking multiple services...) just
the shared child relations. I don't think we need a  specially
labelled super route relation, but perhaps we do need a way to
tell the data user that a segment is shared. these are the
problems I see:

 1. where do the tags go?
 2. do you need a separate one for each direction?
 3. is type=super_route or similar the best idea?
 4. how far can they nest?
 5. a shared route is being used for public transport, should the
stop positions and bus stops be included with all the ways?

so... what do we do? this is what I see as a solution:

 1. if a route is shared, tags should be minimal and only related
to the physical route itself perhaps not even including the
usual route tag (AFAIK wouldn't just about any route relation
in existence define the route tag? so this would just be
another pointer to the software that this isn't your regular
route. but maybe it still is best to tag it, in which case
maybe route=shared?), rather than things such as what bus
routes it is part or anything, this can easily be seen simply
by looking at parent relations
 2. maybe use the roles forward/backward? I don't think these are
used for much any more
 3. what do we gain? I think this can more easily be solved by
simply adding another tag such as shared=yes which can tell
the software that there are route relations that are intended
to be treated as just one big way. see below for a more
detailed explanation.
 4. I don't see a reason to limit the nesting, I imagine in most
use cases, the benefit of sharing duplica

Re: [Tagging] Superroutes - good, bad or ugly?

[seirra blake]

I can see *a lot* of shared routes in my area because most of the buses 
heavily use a star topography (everything must take you to a central 
station) as opposed to a hybrid mesh/star topography (everywhere has 
access to a service to a central station, but there are circular routes 
to allow quicker travel in some circumstances). for example my local 
service has one incredibly early train station detour (presumably for 
long distance commuters), the two main routes (incoming/outgoing) and a 
route that stops at the bus depot. all 4 of these routes share a large 
part of it and that's just one route number! such route segments could 
help shrink and simplify maintaining the relations a lot. for example if 
there's a detour due to roadworks, you don't have to edit the very large 
number of relations individually, (our bus station has around 20 bays, 
each taking multiple services...) just the shared child relations. I 
don't think we need a specially labelled super route relation, but 
perhaps we do need a way to tell the data user that a segment is shared. 
these are the problems I see:


1. where do the tags go?
2. do you need a separate one for each direction?
3. is type=super_route or similar the best idea?
4. how far can they nest?
5. a shared route is being used for public transport, should the stop
   positions and bus stops be included with all the ways?

so... what do we do? this is what I see as a solution:

1. if a route is shared, tags should be minimal and only related to the
   physical route itself perhaps not even including the usual route tag
   (AFAIK wouldn't just about any route relation in existence define
   the route tag? so this would just be another pointer to the software
   that this isn't your regular route. but maybe it still is best to
   tag it, in which case maybe route=shared?), rather than things
   such as what bus routes it is part or anything, this can easily be
   seen simply by looking at parent relations
2. maybe use the roles forward/backward? I don't think these are used
   for much any more
3. what do we gain? I think this can more easily be solved by simply
   adding another tag such as shared=yes which can tell the software
   that there are route relations that are intended to be treated as
   just one big way. see below for a more detailed explanation.
4. I don't see a reason to limit the nesting, I imagine in most use
   cases, the benefit of sharing duplicate relation data probably
   outweighs any impact from processing nesting
5. if a shared route is used for both a numbered road route and public
   transport it's probably unfair on the road user that doesn't need
   them if they are included. also this would make it difficult to work
   out where to place it in a public transport V2 relation.. as they
   have stops at the top, ways at the bottom but this has both!

so here's an indented, somewhat simplified example of how it roughly 
would nest based on the idea of a public transport route, a cycle route 
and a road relation that share the same set of ways (_underlined_=can be 
shared in parent nesting level, *bold*=can be shared in nesting levels 
outside of the parent one, italic=the level at which main tagging should 
occur. for easier referencing each equivalent level of nesting has been 
assigned a letter):


___

/bus network///[A]/
/

   /route_master=bus /[B]
   //

   /route variant/ [C]

   _*route segments*_ [D]
   __

   _combined bus stop/way relation suitable for public
   transport v2_ [E]
   __

   _shared bus stop relation_ [F]_
   _

   _*shared way relation*_ [G]

/road network///[A]/
/

   /road /[C]

   _*shared way relation*_ [G]*
   *


/cycle network//**/[A]/*
*/

   /cycle route /[C]

   __

   __

   *_shared way relation_* [G]

_

potential new tags that may be required:

[C]: shared=yes (defaults to no)

[E/F/G]: route=shared (this is questionable in terms of benefits though)

_

notes:

[G] may be infinitely nested as required to prevent duplicate sets of 
ways (although this should rarely be required)


as you can see, this allows a lot of the data to be shared between the 
various types of relations, whilst also allowing current relation 
structure to remain the same, this is just an extra higher level of 
detail, where required. due to the way public transport relations are 
handled it may be required to even have every segment in [D] contained 
in a relation, however as cycle and road relations are purely made up of 
ways they may not need the same kind of treatment and be able to mix 
items from [G] with directly referenced ways. the separation of bus 

Re: [Tagging] Pets allowed

[seirra blake]

pet=permissive? although if the operator does straight out say 'pets 
allowed' without any further suggestion (be it images, small print or 
whatever) I guess it would be yes until proven otherwise or further 
explained/surveyed. if this does get put in an article it may be worth 
noting that it's preferable by far to avoid using pet=yes because few 
places actually allow any pet without restrictions. on a fun side note 
though, my friend has quite extensively confirmed that London tube is 
ferret=yes. there are some namespaces that may still be useful though, 
I'll give some examples: dog:leash_only to indicate if they need to be 
on a leash or can roam freely; useful for parks which in some areas are 
starting to impose leash only parks and ferret:carry_only to indicate if 
the pet needs to be in a carrier/other suitable vessel (be it a bag 
that's open/ventilated or an article of clothing or whatever) as whilst 
their pet ferret is fine in their hood, I imagine if it was roaming 
freely it may not get such a warm reception.


On 3/9/19 1:14 PM, Paul Allen wrote:
On Fri, 8 Mar 2019 at 18:11, Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:


We should strive for least specific tagging restrictions necessary
to describe what we want.
pet=no (generally no animals allowed)
dog=yes (but dogs are)
bird=yes (birds as well)
parrot=no (but parrots not)
etc.

For allowances it is more difficult (as the alligator example
shows, pet=yes would likely be too permissive).


I think we should start from an implicit pet=no.  Simply because 
pet=yes includes my pet
elephant, your pet boa constrictor and his pet lion and so we're 
usually going to have
pet=no with an exception list.  So we might as well say that pet=no is 
implicitly assumed
if an exception list is present.  Or pet=no is the default unless 
explicitly over-ridden by
either pet=yes or an exception list.  And if it's the default 
assumption if there is no
exception list or pet=yes then there no reason to tag it explicitly 
(you can if you want, but it's

not necessary).

I also think pet=yes ought not be used and we need something like 
pet=check_with_operator,

except that is ugly.  I can't think of a better value, though.

--
Paul


___
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] Pets allowed

[seirra blake]

I'm guessing it depends on how specific the authority is. on the one 
hand you'd think it'd usually just be either birds or no birds however I 
imagine the distinction may still crop up. as I can't actually see any 
article saying about animals used as access tags, I imagine it's just 
tag as you see fit, and if in the future there really is any issues it 
can be handled then. I would just add to the wiki page as appropriate 
but what I gather is that most changes to tag pages outside of perhaps 
good examples of the tags 'in the wild' or support in renderers has to 
be voted on first, and considering the reaction I usually get asking 
about tagging I wouldn't feel comfortable writing a proposal, it would 
probably get shot down very quickly for one reason or another. I 
understand the need for voting and strong criticism mind you, it's just 
very daunting especially as I'm not well versed in wikis.


On 3/8/19 4:51 PM, Martin Koppenhoefer wrote:



sent from a phone

On 7. Mar 2019, at 22:58, Warin <61sundow...@gmail.com 
> wrote:



Presently they are tagged as per access tagging.
motor_vehicle=yes/no
horse=yes/no
dog=yes/no
ferret=yes/no
parrot=yes/no
etc



so birds should get individual tags based on family or species?
*budgerigar=yes*
*ostrich=no*
*etc?*
*
*
*
*
*Cheers, Martin *
*
*

___
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] Pets allowed

[seirra blake]

then I guess it might have to be pets? it isn't necessarily ideal, but 
it is a lot more specific than nothing at all. from what has been said 
though, it looks like pet=yes/pet=no may be more appropriate as species 
are already specified in the singular form (as well as most other access 
tags I can think of). it may be worth adding some potentially relevant 
species tags and the more generic pet tag to 
https://wiki.openstreetmap.org/wiki/Access in case it's relevant to 
someone again in the future. I'm guessing you probably need to make a 
proposal and cast voting for it first though


On 3/7/19 10:27 PM, Cascafico Giovanni wrote:

Unfortunately dataset I'm manually importing has a boolean "pets" field.
I guess if go for "dogs" it will be 9/10 right, while a generic "pets" 
99/100 (considering the alligator anomaly :-) The latter has less 
taginfo popularity, but better fits source data.


Il gio 7 mar 2019, 14:09 seirra blake <mailto:sophietheopos...@yandex.com>> ha scritto:


while I can't see a problem with a tag for each pet, it may still
make more sense to have a pets tag and just namespace
species/related things under it similar to the access tag. use
cases I can think of:

  * pets=no | no matter what, no pets
  * pets=yes | open to all or at least most pets other than
specified examples such as...
  * pets:dogs=no | dogs that are pets are not allowed, a guide dog
does not necessarily count as a pet or at least, I don't think
of one as being a pet.
  * pets:cats=1 | only one cat allowed

this does still make it vague in the sense that if only one cat is
allowed, is it per party or per person, but this probably could be
made more specific with another tag namespaced under pets (my mind
is blank, I haven't eaten yet. however this feels like the best
approach to cover most situations). this may also be useful for
things like water-bowls/treats for pets as mentioned elsewhere
here; for example: my bank offers dog biscuits for dogs, the train
station used to offer a water-bowl as well, but I haven't put much
thought into seeing if it's there after the take over by LNER.

On 3/7/19 12:17 PM, Paul Allen wrote:

On Thu, 7 Mar 2019 at 12:05, mailto:p...@trigpoint.me.uk>> wrote:

Pets is probably a bit vague, many hotels will accept pet
dogs, but are less likely  to accept cats and extremely
unlikely to my pet alligator (no I don't really own one).


Some holiday cottages accept dogs but place a limit on the number
(only one; a maximum of two; etc.)
Yes, some do accept cats, and there are many cat owners who would
love to be able to take their
cat on holiday with them.  So it would be nice if we had
something a little more flexible than
dog=yes/no.

Obviously dogs=no will only apply to pets, registered
assistance dogs are covered by the law of the country, in the
UK a hotel/pub/restaurant is not allowed to refuse assistance
dogs. I assume the same is true throughout the EU.


I believe that, in the UK, NO business can refuse assistance dogs
(but I could be wrong).  It's also
the case in the UK that non-assistance dogs are NOT legally
prohibited from pubs and
restaurants but only from food preparation areas: it's the
owner's decision as to whether or not
dogs are allowed where food is served and sold. See

https://www.thekennelclub.org.uk/our-resources/kennel-club-campaigns/be-dog-friendly/

Many shops and a few restaurants in my town display a sign
somewhere saying that dogs
are allowed.

-- 
Paul



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

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


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

Re: [Tagging] Pets allowed

[seirra blake]

I never saw that in access before, but that actually makes a lot of 
sense. conditionals are somewhat underutilised where I live so I always 
forget about them, but that's a fair point


On 3/7/19 9:58 PM, Warin wrote:

On 08/03/19 00:07, seirra blake wrote:


while I can't see a problem with a tag for each pet, it may still 
make more sense to have a pets tag and just namespace species/related 
things under it similar to the access tag. use cases I can think of:


  * pets=no | no matter what, no pets
  * pets=yes | open to all or at least most pets other than specified
examples such as...
  * pets:dogs=no | dogs that are pets are not allowed, a guide dog
does not necessarily count as a pet or at least, I don't think of
one as being a pet.
  * pets:cats=1 | only one cat allowed



Presently they are tagged as per access tagging.
motor_vehicle=yes/no
horse=yes/no
dog=yes/no
ferret=yes/no
parrot=yes/no
etc

this does still make it vague in the sense that if only one cat is 
allowed, is it per party or per person, but this probably could be 
made more specific with another tag namespaced under pets (my mind is 
blank, I haven't eaten yet. however this feels like the best approach 
to cover most situations). this may also be useful for things like 
water-bowls/treats for pets as mentioned elsewhere here; for example: 
my bank offers dog biscuits for dogs, the train station used to offer 
a water-bowl as well, but I haven't put much thought into seeing if 
it's there after the take over by LNER.




Where a quantity limit applies ? dog:1= yes @ per party ???


___
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] Pets allowed

[seirra blake]

while I can't see a problem with a tag for each pet, it may still make 
more sense to have a pets tag and just namespace species/related things 
under it similar to the access tag. use cases I can think of:


 * pets=no | no matter what, no pets
 * pets=yes | open to all or at least most pets other than specified
   examples such as...
 * pets:dogs=no | dogs that are pets are not allowed, a guide dog does
   not necessarily count as a pet or at least, I don't think of one as
   being a pet.
 * pets:cats=1 | only one cat allowed

this does still make it vague in the sense that if only one cat is 
allowed, is it per party or per person, but this probably could be made 
more specific with another tag namespaced under pets (my mind is blank, 
I haven't eaten yet. however this feels like the best approach to cover 
most situations). this may also be useful for things like 
water-bowls/treats for pets as mentioned elsewhere here; for example: my 
bank offers dog biscuits for dogs, the train station used to offer a 
water-bowl as well, but I haven't put much thought into seeing if it's 
there after the take over by LNER.


On 3/7/19 12:17 PM, Paul Allen wrote:
On Thu, 7 Mar 2019 at 12:05, > wrote:


Pets is probably a bit vague, many hotels will accept pet dogs,
but are less likely  to accept cats and extremely unlikely to my
pet alligator (no I don't really own one).


Some holiday cottages accept dogs but place a limit on the number 
(only one; a maximum of two; etc.)
Yes, some do accept cats, and there are many cat owners who would love 
to be able to take their
cat on holiday with them.  So it would be nice if we had something a 
little more flexible than

dog=yes/no.

Obviously dogs=no will only apply to pets, registered assistance
dogs are covered by the law of the country, in the UK a
hotel/pub/restaurant is not allowed to refuse assistance dogs. I
assume the same is true throughout the EU.


I believe that, in the UK, NO business can refuse assistance dogs (but 
I could be wrong).  It's also
the case in the UK that non-assistance dogs are NOT legally prohibited 
from pubs and
restaurants but only from food preparation areas: it's the owner's 
decision as to whether or not

dogs are allowed where food is served and sold.  See
https://www.thekennelclub.org.uk/our-resources/kennel-club-campaigns/be-dog-friendly/

Many shops and a few restaurants in my town display a sign somewhere 
saying that dogs

are allowed.

--
Paul


___
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] transaction parameters for ATMs

[seirra blake]

some providers already make it publicly available knowledge. for example 
in the UK link ATM has an app, and you can use it to find nearby ATMs. 
most of the things it tells you are pretty standard, but some things 
that may need new tags are pin management services, audio assistance and 
£5 notes (because otherwise you're limited to denominations of 10). I 
was thinking with these tags included, link ATM may feel encouraged to 
import their data and maintain it on OSM allowing them to save costs on 
their end and have a more detailed map. when I tried proposing minimum 
denominations before on here though it got shot down very fast.


On 2/14/19 7:17 AM, Colin Smale wrote:


Tagging min and max withdrawals on the ATM is asking for confusion. 
The normal limits are set by the card issuer, and I can see many 
people mistakenly putting their personal card limits into these tags 
on the ATM.


More relevant here would be the denomination mix. ATMs have a fixed 
number of canisters (maybe 2/3/4), each of which can hold a single 
type of note. Which denominations are loaded depends on historical 
usage patterns. Stocking low denomination notes might be good for user 
convenience, but bad for the possibility of running out of money in a 
busy location. Knowing the normal mix for a particular ATM, in 
particular the smallest denomination, is useful for knowing which 
amounts can be dispensed, and which not.


So instead of min_withdrawal on the ATM, I would suggest min_denomination.

In the case of multi-currency ATMs there will need to be a 
currency-specific variant, like min_denomination:EUR=20


Problem is, it will probably require data from multiple transactions 
from small to large to work out the mix and we need to keep mappers 
merging the data from their experience, and not overwriting the valid 
data from a previous ATM user, while recognising that the denomination 
mix can change, even according to the days of the week (weekends might 
be different to weekdays in city centres).


On 2019-02-14 07:29, OSMDoudou wrote:


The minimum can also differ.

Some banks allow their young customers to withdraw small amounts, 
like 5 EUR, whereas adults and even young customers with cards from 
other banks will not be allowed to withdraw less than 20 EUR.


So, it may create confusion between mappers because what you see as 
options on the ATM may depend on your card and your affiliation with 
the bank.


This impairs verifiability on the ground of the information.
On 2/14/19, 03:45 Warin <61sundow...@gmail.com> wrote:

The maximum may also be limited by the card provider. Need some
careful words on the proposal to say it is the limit of the ATM
provider.


On 14/02/19 13:31, Joseph Eisenberg wrote:
Withdrawals are not the only type of ATM transaction. 


So use
withdraw_min=*
withdraw_max=/*

???

/The currency is set by some other tag that I forget now. That
needs to be mentioned in the proposal.
As a user .. I have no idea what the limits are. I suspect I may
know the lower limit, but not the upper.




Perhaps max_withdrawal would be clearer?
On Thu, Feb 14, 2019 at 10:57 AM Nathan Wyand
mailto:propaga...@nathanwyand.com>>
wrote:

Hello mappers,

I frequently use OSM to find ATM's near me, but many of
these machines place limits on how much can be withdrawn in
1 transaction. This can make it inconvenient and expensive
to withdraw money, requiring several transactions. Another
issue is that many machines only carry $20 notes, which
forces people to withdraw more or less than they actually
desire. I am considering two tags for use alongside
'amenity=atm':

*min_transaction* (the minimum amount of cash that can be
withdrawn in one transaction...typically the smallest
denomination of notes in the machine)
*max _transaction* (the maximum amount of cash that can be
withdrawn in one transaction)

This is my first time proposing a tag, and I would love to
hear your input and and advice. Thank you!

-Nathan
___
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


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


___
Tagging mailing list
Tagging@openstreetmap.org

Re: [Tagging] Tag an information panel

[seirra]

seconded, we have it here in the city centre, it's an electric LED 
display that shows the free spaces in real time (or just says full). in 
our case it is integrated into the road sign



On 01/19/19 14:25, OSMDoudou wrote:

> Tag the capacity of the car park itself. It's more useful.

I think the OP is talking about variable display signs indicating the 
free capacity in real time.



___
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] Public Transport Timetables Proposal RFC

[seirra]

this does feel like a much easier to understand idea now, it may be 
worth thinking of a way to still incorporate the interval in the second 
proposed feature, for example a local bus in my area has one every 10 
minutes for a substantial amount of time.



On 10/31/18 21:04, Leif Rasmussen wrote:
Thanks for the feedback on this proposal! Maintainability and 
corruption of existing features seem to be the two biggest concerns, 
both of which I have reduced in the new version of the proposal.  I 
really like the idea that Polyglot expressed on the talk page of the 
proposal of using a completely separate relation to represent a single 
timetable.  It is a completely different system that is much more 
elegant, versatile, practical, and simple.  By using a relation 
similar in design to turn restrictions, the complexity of this 
proposal has been reduced significantly.


The new version of the proposal will not affect existing public 
transport routes in any way or form.  They will remain unchanged and 
uncorrupted, similarly to how turn restrictions do not affect highways 
in any noticeable way.  Data consumers will not have to worry about 
any changes to public transport details.


https://wiki.osm.org/wiki/Proposed_features/Public_transport_schedules

Please let me know what you all think about the improved proposal.  
Maintainability will still be difficult, but much easier than before.  
It may also be possible for these types of relations to be added by, 
and checked for currency by, StreetComplete without much trouble.


Example of a timetable relation: 
https://www.openstreetmap.org/relation/8873463


Thank you,
Leif Rasmussen


___
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] Tagging suggestions for electricity

[seirra]

here anyway, the networks are more than happy to show an area map and 
generally they don't change. as the resident can choose just about any 
of the energy companies however, that would take a bit of asking around. 
i've never tried asking companies so perhaps they would give the data 
out, otherwise it would have to be surveys. voltage and current is 
usually country wide or in a rather close range? (imagine the difficulty 
supplying electrical products to consumers otherwise). i'm a little less 
sure about earthing systems.



On 08/31/18 10:23, gppes_...@web.de wrote:

I'm asking myself, how is all the (quite specific) data verifiable on the 
ground? Furthermore, don't you need expert knowledge for some things mentioned, 
eg. earthing system,  but also the more straight forward things like voltages 
and especially currents - who is able to identify the correct fuses for that?

Why do you want to tag these properties? To my opinion, no one needs to justify 
tags regarding to usefulness, I'm just curios.


Gesendet: Freitag, 31. August 2018 um 10:17 Uhr
Von: seirra 
An: tagging@openstreetmap.org
Betreff: Re: [Tagging] Tagging suggestions for electricity

yeah that is what i meant. i think they buy it from the network which
serves as a 'middleman' to the generators, because the prices for the
same company and tariff vary depending what network you are in over
here. so presumably they pick and choose their power sources, and then
the network charges them a fee to use them over that network.


On 08/31/18 08:57, Warin wrote:

Here there is the company that I buy my electricity from. They buy it
from the distribution network that I am connected to.
So I can have a choice of who I buy from .. but my network does not
change.
I am not certain if these firms buy it directly from the network .. or
some other body that then sees to the network and the power generators
as separate things.

On 31/08/18 17:43, seirra wrote:

just something to mention about distribution companies here anyway,
we have the network, then we have the company? so for example my
network is UK power network, but my company is utilita? however in
other areas (still in the uk) they would have a different network
altogether


On 08/31/18 05:47, Dolly Andriatsiferana wrote:

 I think this would be hard to maintain, and highly redundant
 since voltage won't change for a given city or even country.
 Think about standards names to fill utilities:electricity.
 Each standard comes with frequency, voltage, rating...


Yes, I agree that in most cases voltage doesn't change much for a
given city. But something that will change frequently is the source
(here in Madagascar mostly from a distribution company, a generator,
or individual solar panels).
And maybe another good idea is to omit those voltage and possibly
redundant details, and put sources directly as values on the main
tag (like how most of the few existing electricity=* tags seem to be
used). So we would have something like:

   * utility:electricity=yes - there is electricity feeding the
 building but the source is not defined
   * utility:electricity=no - there is no electricity source at all
   * utility:electricity=generator/company/solar/windmill... - there
 is electricity and the source is known

Thanks.

2018-08-31 1:47 GMT+03:00 Warin <61sundow...@gmail.com
<mailto:61sundow...@gmail.com>>:

 On 31/08/18 05:20, François Lacombe wrote:

 Le jeu. 30 août 2018 à 19:12, Dolly Andriatsiferana
 mailto:privatemaj...@gmail.com>> a
 écrit :

 I like the idea of keeping a namespace gathering utilities
 such as electricity, gas, internet or other. But the idea
 is also to be able to use a namespace for the utility to
 provide more details (source, voltage, fee...) or
 conditions (if there's schedule in availability) - and with
 *utility:electricity* this would easily generate a complex
 tagging of namespace under namespace, unless you say it is
 no problem to have *utility:electricity:voltage=** for example.


 I think this would be hard to maintain, and highly redundant
 since voltage won't change for a given city or even country.

 Most hoses in Australia have 240 v single phase supplied to
 them. Then they have 'standard' (here) GPOs of 10 Amp capacity.
 Some have one or more higher 15 Amp capacity outlets.
 And then there are some houses that have 3 phase 415v supplied
 to them - and they have 'standard' (here) GPOs of 10 Amp
 capacity, possibly one or more 15 Amp capacity outlets and one
 or more 3 phase outlets.

 So here you have in one neighbourhood 3 different instances of
 electricity presence in houses.



 Agreed with Paul statement about earthing system which is
 specific to each building

 Earthing systems are usually mandated and common to some
 burea

Re: [Tagging] Tagging suggestions for electricity

[seirra]

yeah that is what i meant. i think they buy it from the network which 
serves as a 'middleman' to the generators, because the prices for the 
same company and tariff vary depending what network you are in over 
here. so presumably they pick and choose their power sources, and then 
the network charges them a fee to use them over that network.



On 08/31/18 08:57, Warin wrote:
Here there is the company that I buy my electricity from. They buy it 
from the distribution network that I am connected to.
So I can have a choice of who I buy from .. but my network does not 
change.
I am not certain if these firms buy it directly from the network .. or 
some other body that then sees to the network and the power generators 
as separate things.


On 31/08/18 17:43, seirra wrote:


just something to mention about distribution companies here anyway, 
we have the network, then we have the company? so for example my 
network is UK power network, but my company is utilita? however in 
other areas (still in the uk) they would have a different network 
altogether



On 08/31/18 05:47, Dolly Andriatsiferana wrote:


I think this would be hard to maintain, and highly redundant
since voltage won't change for a given city or even country.
Think about standards names to fill utilities:electricity.
Each standard comes with frequency, voltage, rating...


Yes, I agree that in most cases voltage doesn't change much for a 
given city. But something that will change frequently is the source 
(here in Madagascar mostly from a distribution company, a generator, 
or individual solar panels).
And maybe another good idea is to omit those voltage and possibly 
redundant details, and put sources directly as values on the main 
tag (like how most of the few existing electricity=* tags seem to be 
used). So we would have something like:


  * utility:electricity=yes - there is electricity feeding the
building but the source is not defined
  * utility:electricity=no - there is no electricity source at all
  * utility:electricity=generator/company/solar/windmill... - there
is electricity and the source is known

Thanks.

2018-08-31 1:47 GMT+03:00 Warin <61sundow...@gmail.com 
<mailto:61sundow...@gmail.com>>:


On 31/08/18 05:20, François Lacombe wrote:

Le jeu. 30 août 2018 à 19:12, Dolly Andriatsiferana
mailto:privatemaj...@gmail.com>> a
écrit :

I like the idea of keeping a namespace gathering utilities
such as electricity, gas, internet or other. But the idea
is also to be able to use a namespace for the utility to
provide more details (source, voltage, fee...) or
conditions (if there's schedule in availability) - and with
*utility:electricity* this would easily generate a complex
tagging of namespace under namespace, unless you say it is
no problem to have *utility:electricity:voltage=** for example.


I think this would be hard to maintain, and highly redundant
since voltage won't change for a given city or even country.


Most hoses in Australia have 240 v single phase supplied to
them. Then they have 'standard' (here) GPOs of 10 Amp capacity.
Some have one or more higher 15 Amp capacity outlets.
And then there are some houses that have 3 phase 415v supplied
to them - and they have 'standard' (here) GPOs of 10 Amp
capacity, possibly one or more 15 Amp capacity outlets and one
or more 3 phase outlets.

So here you have in one neighbourhood 3 different instances of
electricity presence in houses.




Agreed with Paul statement about earthing system which is
specific to each building


Earthing systems are usually mandated and common to some
bureaucratic boundaries.

___
Tagging mailing list
Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging
<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





___
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] Tagging suggestions for electricity

[seirra]

just something to mention about distribution companies here anyway, we 
have the network, then we have the company? so for example my network is 
UK power network, but my company is utilita? however in other areas 
(still in the uk) they would have a different network altogether



On 08/31/18 05:47, Dolly Andriatsiferana wrote:


I think this would be hard to maintain, and highly redundant since
voltage won't change for a given city or even country.
Think about standards names to fill utilities:electricity.
Each standard comes with frequency, voltage, rating...


Yes, I agree that in most cases voltage doesn't change much for a 
given city. But something that will change frequently is the source 
(here in Madagascar mostly from a distribution company, a generator, 
or individual solar panels).
And maybe another good idea is to omit those voltage and possibly 
redundant details, and put sources directly as values on the main tag 
(like how most of the few existing electricity=* tags seem to be 
used). So we would have something like:


  * utility:electricity=yes - there is electricity feeding the
building but the source is not defined
  * utility:electricity=no - there is no electricity source at all
  * utility:electricity=generator/company/solar/windmill... - there is
electricity and the source is known

Thanks.

2018-08-31 1:47 GMT+03:00 Warin <61sundow...@gmail.com 
>:


On 31/08/18 05:20, François Lacombe wrote:

Le jeu. 30 août 2018 à 19:12, Dolly Andriatsiferana
mailto:privatemaj...@gmail.com>> a écrit :

I like the idea of keeping a namespace gathering utilities
such as electricity, gas, internet or other. But the idea is
also to be able to use a namespace for the utility to provide
more details (source, voltage, fee...) or conditions (if
there's schedule in availability) - and with
*utility:electricity* this would easily generate a complex
tagging of namespace under namespace, unless you say it is no
problem to have *utility:electricity:voltage=** for example.


I think this would be hard to maintain, and highly redundant
since voltage won't change for a given city or even country.


Most hoses in Australia have 240 v single phase supplied to them.
Then they have 'standard' (here) GPOs of 10 Amp capacity. Some
have one or more higher 15 Amp capacity outlets.
And then there are some houses that have 3 phase 415v supplied to
them - and they have 'standard' (here) GPOs of 10 Amp capacity,
possibly one or more 15 Amp capacity outlets and one or more 3
phase outlets.

So here you have in one neighbourhood 3 different instances of
electricity presence in houses.




Agreed with Paul statement about earthing system which is
specific to each building


Earthing systems are usually mandated and common to some
bureaucratic boundaries.

___
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] Tagging suggestions for electricity

[seirra]

wouldn't the use of access:private be sufficient? that would tell people 
the building is private meaning anything inside must be too. power 
supply already allows voltage and actually does allow intermittent now i 
look back. due to the fact electricity would often lead to the presence 
of a socket (and often all the same type) i imagine there might be a 
difficult overlap is all


On 08/29/18 10:37, Dolly Andriatsiferana wrote:
Thanks seirra for pointing to power_supply. But I don't know if it can 
really be applied to individual private buildings? Because as far as I 
understand it is to be used for services or amenities like camp sites, 
ie whether you can get power there to plug your electrical stuff? The 
difference is that electricity=* (or whatever should be used) is to 
indicate that there's a source of electricity power feeding a 
building/settlement but it doesn't have to be provided as part of a 
service for example.


Le mer. 29 août 2018 11:56 AM, seirra <mailto:gene...@sarifria.x10.bz>> a écrit :


you might find power_supply to be better suited as it is already
documented https://wiki.openstreetmap.org/wiki/Key:power_supply it
already covers all of those topics except for intermittent,
although if it is relevant i don't see why you can't put it


On 08/29/18 05:46, Dolly Andriatsiferana wrote:

Hi,

I was searching for a tag to indicate if a building has
electricity or not, and if possible to specify the electricity
source. I've found no documented tag, but a search on taginfo [1]
led me to the key electricity=*. Currently it's being used mostly
with values solar/none/generator/yes/always.

On OSM Help [2] someone proposed the following tagging which
seems better in my opinion too:

  * electricity=yes/no/intermittent - to indicate the presence of
electricity
  * electricity:source=solar/generator/distribution_company/windmill...
- to specify the electricity source
  * electricity:voltage=* - the electricity voltage
  * other details using namespaces...

What do you think? Has someone here used the electricity=* tag
before?
Afterwards we might be able to start documenting the tag on the wiki.

Cheers,
Dolly

[1] https://taginfo.openstreetmap.org/keys/electricity
[2]

https://help.openstreetmap.org/questions/65477/indicate-if-a-building-has-electricity-or-not


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


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



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


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

Re: [Tagging] Tagging suggestions for electricity

[seirra]

you might find power_supply to be better suited as it is already 
documented https://wiki.openstreetmap.org/wiki/Key:power_supply it 
already covers all of those topics except for intermittent, although if 
it is relevant i don't see why you can't put it



On 08/29/18 05:46, Dolly Andriatsiferana wrote:

Hi,

I was searching for a tag to indicate if a building has electricity or 
not, and if possible to specify the electricity source. I've found no 
documented tag, but a search on taginfo [1] led me to the key 
electricity=*. Currently it's being used mostly with values 
solar/none/generator/yes/always.


On OSM Help [2] someone proposed the following tagging which seems 
better in my opinion too:


  * electricity=yes/no/intermittent - to indicate the presence of
electricity
  * electricity:source=solar/generator/distribution_company/windmill...
- to specify the electricity source
  * electricity:voltage=* - the electricity voltage
  * other details using namespaces...

What do you think? Has someone here used the electricity=* tag before?
Afterwards we might be able to start documenting the tag on the wiki.

Cheers,
Dolly

[1] https://taginfo.openstreetmap.org/keys/electricity
[2] 
https://help.openstreetmap.org/questions/65477/indicate-if-a-building-has-electricity-or-not



___
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] access/maintenance platforms

[seirra]

not quite i just used them as examples because i didn't know that was 
what those particular metal platforms were if it is acceptable i can 
link to a screenshot from google streetview? if not i can take a picture 
next time i am physically there and link to that



On 08/27/18 17:17, Paul Johnson wrote:



On Mon, Aug 27, 2018, 06:36 seirra <mailto:gene...@sarifria.x10.bz>> wrote:


hello, i was wondering what would be the best way to tag a metal
platform? for example the metal staircases that are at times used for
apartments/used for access/maintenance


You mean the fire escape?



___
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] access/maintenance platforms

[seirra]

hello, i was wondering what would be the best way to tag a metal 
platform? for example the metal staircases that are at times used for 
apartments/used for access/maintenance



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

Re: [Tagging] ATMs and cashback

[seirra]

as an example, say a cash machine dispenses £10 and £20 notes... you 
can't guarantee you'll get 20s can you? but what you do know, is you can 
get any multiple of 10. so maybe the standard notation could be that you 
put currency, the currency code, then the smallest amount you can get? 
as the smallest amount is usually meant to be able to make up any larger 
amount theoretically that should be enough. (for example, 5 would 
declare you can get anything that is a multiple of 5, 10 would declare 
anything that is a multiple of 10). so using that idea you could put 
currency:GBP=5, and that would declare it lets you get multiples of 5, 
but if you're unsure you can put currency:GBP=yes. i guess you could 
also put currency:GBP=5;10;20. there are no other cases of numerical 
uses for the currency tag, so it seems like an okay way to do it



On 08/24/18 19:41, Paul Allen wrote:


On Fri, Aug 24, 2018 at 6:38 PM, seirra <mailto:gene...@sarifria.x10.bz>> wrote:


i would imagine it would be better having some data over none though?


Incomplete data is better than no data.  Incorrect data is worse than 
no data.  The problem with this is that

incomplete (or even complete) data can become incorrect over time.

OTOH, we already map other things that are relatively ephemeral.  
Opening hours can change.  Hygiene certificate
ratings can go up or down.  Businesses go bankrupt. Etc.  There's a 
place near me that was a shop, then a
fast food outlet called "Porky Pies", then an Indian restaurant, 
within the last month it became a fast food outlet
called Deegee's.  That's all over the span of about 5 years.  It's 
inconsiderate of them to force me to keep updating

the map.

ATM denominations would be great if there is an effort to keep it up 
to date.  Maybe suggest that mappers only tag
it (with whatever tag we decide upon, if we decide to do it, and if 
ever we can decide on a tagging scheme) if they
use that particular ATM at least monthly.  Everyone will ignore the 
suggestion, of course, and use the tag on ATMs

they've used only once and will never use again.

Maybe I'm just worrying because I can remember the days when ATMs 
dispensed £1/£5, then went to £5/£10 and
are now (mostly) £10/£20.  Inflation is still present and bank 
branches keep closing, so there's more demand for
ATMs.  Which means they'll empty faster, which means we may see 
£20/£50 soon.


In the end, though, if enough people want do to it they'll do it, so 
all we can do here is try to come up with a

sensible way of tagging it then document it.

We already have currency:XXX=yes/no (a proposal but the iD editor has 
supported it for a while).  So maybe something like 
currency:denomination:GBP=10;20.  Then if there's a locality with two 
common currencies where an ATM might dispense
one, or the other, or both, we can use currency:denomination:GBP=10;20 
+ currency:denomination:EUR=5;10 (a
situation we're unlikely to see in the UK, but it's just an example).  
There's probably a better way of doing it, and

people will be along shortly to argue about it. :)

--
Paul



___
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] ATMs and cashback

[seirra]

i would imagine it would be better having some data over none though? 
the main thing that got me thinking about this really, was that if we 
got the ability to tag this out there, could we then for example 
convince link atm to use osm for their data? i figured it was best only 
contacting them after we got a consensus on tagging this. the cashback 
thing would make sense though right? that's relatively constant. For the 
ATMs do you think it would be better if we got a vote on it?



On 08/24/18 17:58, Paul Allen wrote:
On Fri, Aug 24, 2018 at 3:38 PM, seirra <mailto:gene...@sarifria.x10.bz>> wrote:


i can confirm this to be the case. where i work the cashback
procedure is indeed just a signature of the receipt. As far as i
know ATMs that issue £5 notes tend to for a long time, i don't
recall any here suddenly stopping.


ATMs have a finite capacity.  Which means that ATMs which serve two or 
more denominations may run out of one
denomination before the others.  So £5 notes can stop suddenly because 
they run out.  However, a lot of the ATMs in this
part of the world switched from £5/£10 to £10/£20 because inflation 
meant that average amount withdrawn had increased
to the point they needed to be refilled too frequently.  The 
£5/£10/£20 machines are rare and tend to be at banks, where

they can be refilled more quickly.

The problem with mapping denominations is not that a machine may run 
out of one denomination, that's a temporary
thing.  The problem is that a £5/£10 machine may be upgraded or 
replaced to dispense £10/£20.  Or a £10/£20 may
be changed to £20/£50.  How often that happens depends upon the rate 
of inflation in that part of the world. It's
definitely useful to know, but the information may go stale too 
quickly and be verified/remapped too infrequently.  I'm

in two minds about the utility of mapping this.

however people still often request cashback due to the fact it
saves the extra trip (and the closest ATM is difficult to
troubleshoot if it goes down


There is one shop where I specifically request cashback even though it 
has an ATM mounted in the wall outside.  My
bank has a loyalty scheme whereby the online banking system presents 
me with discounts at certain shops (as a way
of encouraging people to use the online banking).  Every time this 
shop appears I use it.  And then get 5% off my
payment for electricity top-up, phone top-up, mains water charges, gas 
bill and cashback.  I wouldn't use that shop for
any other thing as it's a convenience store and more expensive than 
the local supermarket.  But whenever I can get £50
cashback for £47.50 and cheaper gas, electricity and mains water, I 
leap at the chance.  Names intentionally
withheld because if everyone catches on that store brand will withdraw 
from the deal. :)


--
Paul



___
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] ATMs and cashback

[seirra]

i can confirm this to be the case. where i work the cashback procedure 
is indeed just a signature of the receipt. As far as i know ATMs that 
issue £5 notes tend to for a long time, i don't recall any here suddenly 
stopping. source on why it may be valuable information to some (note the 
small number that do): 
https://metro.co.uk/2018/05/21/why-do-so-few-cash-machines-dispense-fivers-and-where-are-they-7565615/ 
an extra way to verify for link ATMs specifically: 
https://www.link.co.uk/consumers/locator/ where i work there are three 
ATMs, however people still often request cashback due to the fact it 
saves the extra trip (and the closest ATM is difficult to troubleshoot 
if it goes down, i don't think the operator is local). so cash machines 
are verifiable by survey, or by checking official sources; cashback 
would be purely survey. ATMs can also offer phone top ups 
(vending=telephone_vouchers?) and pin change services. all of these 
should be surveyable.



On 08/24/18 14:15, Paul Allen wrote:
On Fri, Aug 24, 2018 at 1:44 PM, Philip Barnes > wrote:


On Fri, 2018-08-24 at 14:22 +0200, Martin Koppenhoefer wrote:

How is this verifiable? Do they write it on the machine what kind
of notes are contained?


Certainly not verifiable, sometimes they may give you a choice but
not always.


Some ATMs do say what notes they MAY dispense.  That was fairly common 
back when they switched from dispensing
£5 and £10 to £10 and £20.  Sure, if you go to a £10/£20 machine it 
may have run out of £10 notes.  Sure, if you go to
a £5/£10/£20 machine (they do exist) it might have run out of £5 
notes.  But most of the time you can get the lower value.
Usually the machine decides, so if you ask for £20 you may not get two 
x £10, but some machines will try to give at least
one, and (if your request is high enough) two of the lowest 
denomination.  Of course, if you really want 2 x £10 you can
make two withdrawals to foil machines that try to dispense the fewest 
notes.


Certainly it's verifiable.  Try to make a withdrawal of £5 and it will 
either tell you it doesn't dispense them or that it
has temporarily run out of them.  This information is useful to know 
if you're in a strange place, need (say) £25 cash and
have only £26 in your account.  An ATM that doesn't dispense £5 notes 
is not of use to you.  So it's verifiable and possibly
worth mapping.  The problem is, as with much information, is it's 
somewhat ephemeral.  Next week there may still be

an ATM there but it no longer dispenses £5.

Cashback is not a misleading name, it is not a cash withdrawal.
They add extra to your payment and give you the change. It is
offered to reduce the shops charges for banking cash but is
usually more trouble than it is worth as the cashier has to write
down the transaction number and you then have to sign for it.


I've had cashback from several different shops and NONE of them 
required the cashier to write down the transaction
number.  It's all done electronically these days. Sometimes, some 
shops require you to sign the shop's copy of
the receipt but that's a policy of the shop to try to minimize people 
later claiming they weren't given the cash (it doesn't
really help and the distraction is more likely to cause both parties 
to forget to hand over/receive the money).


--
Paul



___
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] ATMs and cashback

[seirra]

Is there a way to put what currency denomination they output? for 
example: whilst every cash machine here should theoretically output 
£20/£10 notes, there are a growing number that output £5 notes 
(obviously allowing the user to withdraw multiples of 5 rather than just 
multiples of 10). I imagine that's useful data to include, but is there 
a consensus on how that should be tagged? there didn't seem to be 
anything on the ATM page. also some stores offer a service called 
'cashback' (misleadingly named, but essentially with your purchase you 
can withdraw money from your card, it's a similar experience to using an 
ATM except you do it at a shop checkout and it isn't done by a machine 
(excluding self checkouts)) how would that be tagged?



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

Re: [Tagging] delivery areas?

[seirra]

I was thinking more to the tune of specific things like charity shops or 
smaller stores where it may not be standard



On 08/23/18 16:42, Dave F wrote:
If you mean things like fast food deliveries etc, then tag the 
website, which should have such details. How horrendously confusing 
would the database be with every delivery service was mapped?


DaveF

On 23/08/2018 16:34, seirra wrote:
hello, i was wondering if there was any established way to record 
delivery areas? would i be correct to think relations would be the 
best method?



___
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

[Tagging] delivery areas?

[seirra]

hello, i was wondering if there was any established way to record 
delivery areas? would i be correct to think relations would be the best 
method?



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

Re: [Tagging] areas of risk

[seirra blake]

yeah, if it did get mapped it should probably at least be something specific 
otherwise the user has no idea what to watch out for, and it may unreasonably 
deter people from the area, i think it might be the same reason reviews aren't 
recorded?outside of that i don't think osm performs live actions or even can, 
does it? (would probably have some cool use cases though) whereas (as an 
example! there's probably a better neutral tag name to use) something like 
activity=graffiti would tell the user it's there, but also gives them enough 
information to make an unbiased decision (whilst some may think of it as a sign 
of danger, probably an equal number of people aren't even affected by its 
existence in an area) for example near lincoln, new mexico there's a rock that 
is a popular graffiti spot (before anyone looks for it to at least map as art, 
that was years ago that i was there, it might not still exist)
On Aug 20 2018, at 8:45 am, Mateusz Konieczny  wrote:
>
> 18. Sierpień 2018 20:44 od djakk.dj...@gmail.com 
> (https://link.getmailspring.com/link/1534751304.local-117f7c54-95d6-v1.4.2-f587b...@getmailspring.com/0?redirect=mailto%3Adjakk.djakk%40gmail.com=dGFnZ2luZ0BvcGVuc3RyZWV0bWFwLm9yZw%3D%3D):
> > For such a subjective thing, it should be mapped by each openstreetmap 
> > member : djakk maps this area as dangerous, baloo as not dangerous, etc and 
> > the renderer makes an average.
>
>
>
>
> This is a horrible idea and it should not be used. OSM is not a place
> for such inherently subjective opinions.
> ___
> 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] use of points even when it clearly defines a building?

[seirra blake]

oh okay yeah i get it!

On Aug 17 2018, at 4:17 pm, Jmapb  wrote:
>
> On 8/16/2018 6:39 PM, seirra wrote:
> > if a floor of a building is for example: a store at the bottom of the
> > building, and the rest is apartments... shouldn't it then be a
> > building labelled as a chemist, with the tag level=0 and at the same
> > point on the map, a building labelled as apartments with the tag level=1?
>
> Usually this would be mapped as a node (point) for the shop, set inside
> the perimeter of the building. The node gets tagged with all the
> information specific for the shop (name, phone, opening_hours, etc.) The
> building area gets tagged with all of the physical attributes of the
> building (height, building style, sometimes the building has its own
> name that it keeps regardless of what shop is occupying the ground
> floor.) The address tags would also generally go on the building itself
> -- unless the building has multiple addresses.
>
> We definitely don't want two buildings at the same location to indicate
> the two different uses of a single building. It is possible to draw an
> area for the bottom floor shop instead of a node -- just tag the area as
> a shop, not as a building. And add the level=0 tag, as you mentioned.
> (And it probably wouldn't be the *entire* bottom floor of course; you'd
> want to leave room for the stairs for instance.)
>
> The general rule is *not* to map any specifics of private areas of
> buildings -- the apartments on the upper floors, for instance. You can
> use the building:units= tag to indicate the number of apartments, and
> addr:flats= tag to list the apartment numbers, but that's generally as
> far as we go.
>
> J
> ___
> 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] access:disabled... yes or designated?

[seirra]

oh yeah i just wasn't sure whether there was a reason it was barely mentioned 
and had no wiki page. i'll probably stick to preferring that over 
access:disabled judging from what everyone has said and the fact it even has 
renderers using it
On 19/08/18 13:00, Martin Koppenhoefer wrote:
>
>
> sent from a phone
>
> On 19. Aug 2018, at 13:32, seirra  (https://link.getmailspring.com/link/58d81cc2-f042-224a-fbae-fc49e84df...@sarifria.x10.bz/0?redirect=mailto%3Ageneral%40sarifria.x10.bz=dGFnZ2luZ0BvcGVuc3RyZWV0bWFwLm9yZw%3D%3D)>
>  wrote:
> > i don't mean amenity=parking_space... i mean parking_space=disabled
>
> all keys are „valid“, you can use any tag you like in OSM. There are very few 
> exceptions, e.g. “type” is considered a reserved tag to indicate the relation 
> type.
>
> There is a map that renders the tag you asked about:
> https://wiki.openstreetmap.org/wiki/Rollstuhlkarte.ch 
> (https://link.getmailspring.com/link/58d81cc2-f042-224a-fbae-fc49e84df...@sarifria.x10.bz/1?redirect=https%3A%2F%2Fwiki.openstreetmap.org%2Fwiki%2FRollstuhlkarte.ch=dGFnZ2luZ0BvcGVuc3RyZWV0bWFwLm9yZw%3D%3D)
>
>
> cheers,
> Martin
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> (https://link.getmailspring.com/link/58d81cc2-f042-224a-fbae-fc49e84df...@sarifria.x10.bz/2?redirect=mailto%3ATagging%40openstreetmap.org=dGFnZ2luZ0BvcGVuc3RyZWV0bWFwLm9yZw%3D%3D)https://lists.openstreetmap.org/listinfo/tagging
>  
> (https://link.getmailspring.com/link/58d81cc2-f042-224a-fbae-fc49e84df...@sarifria.x10.bz/3?redirect=https%3A%2F%2Flists.openstreetmap.org%2Flistinfo%2Ftagging=dGFnZ2luZ0BvcGVuc3RyZWV0bWFwLm9yZw%3D%3D)___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] access:disabled... yes or designated?

[seirra]

i don't mean amenity=parking_space... i mean parking_space=disabled


On 18/08/18 00:27, Martin Koppenhoefer wrote:



sent from a phone

On 17. Aug 2018, at 09:45, seirra <mailto:gene...@sarifria.x10.bz>> wrote:



is parking_space even a valid tag though?(i can't see any documentation)




it is a tag for a single parking space.
it is documented:
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space

Cheers,
Martin


___
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] areas of risk

[seirra]

well like i said, i meant more for specific things that aren't just 
generalisations where it may actively  prevent you from doing something 
or where it is a regular occurrence. i don't personally see the 
race/class related aspect, but as previously said i respect that others 
feel it is there and thus should be avoided (i hope i'm not offending, 
although i respect the final decision i really don't understand)



On 08/17/18 18:30, Paul Johnson wrote:

Then you're just splitting class and race hairs.

On Fri, Aug 17, 2018, 11:20 seirra <mailto:gene...@sarifria.x10.bz>> wrote:


there can be notable areas though, outside of what may usually be
expected


On 08/17/18 16:03, Paul Johnson wrote:



On Thu, Aug 16, 2018, 16:35 seirra mailto:gene...@sarifria.x10.bz>> wrote:

hmmm i do see the point there about racial/class bias... i
was thinking more about areas that were known crime spots/had
associated illegal activities people may want to avoid(to the
point there are regular police patrols at night)? also places
where getting a phone out could lead to it being stolen? i've
heard that can be an issue in some areas. just wasn't sure if
any of those scenarios really deserved tagging because i
didn't really feel there was a bias there? either way just
wanted to check (sorry if this shows up as a double post, i
saw there was a reply to mailing list option i should be
using, i get the impression the first time didn't send)


At that point, you're just avoiding cities in general, as crime
rates tend to increase proportionally to population density.



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


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



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


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

Re: [Tagging] double doors?

[seirra]

oh okay! i've never heard of the term wings before for doors so i 
wouldn't know. it's something that here is commonly called a 'french 
door' (i don't know why, it is literally just two doors making a wider 
doorway). i'll try that then



On 08/17/18 17:20, Tobias Knerr wrote:

On 17.08.2018 14:10, seirra wrote:

should these be split into two separate door elements, or should it be
tagged as just a really wide door?

Assuming we're talking about a hinged door with multiple wings, there's
a proposed door:wings key with 178 uses at the time of writing. Using
that, you would simply add the door:wings=2 tag to the door node.

___
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] tagging a gamesroom?

[seirra]

this was more somewhere with a dedicated room really


On 08/17/18 14:29, Philip Barnes wrote:

On Fri, 2018-08-17 at 13:04 +0100, seirra wrote:

what should a games room (think things like darts, pool/snooker,
card
games) be tagged as? when i looked around i couldn't seem to find
any
official consensus or unofficial for that matter


I would say they are not normally standalone objects but part of
something else. For example I expect most pubs to have a dartboard,
dominoes and you can play cards anywhere you have a table. Some will
also have a pool table, but they have mostly gone out of fashion.

Standalone pool and snooker clubs certainly exist, would probably add
some sort of sub tag to a social club.

Phil (trigpoint)

___
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] areas of risk

[seirra]

there can be notable areas though, outside of what may usually be expected


On 08/17/18 16:03, Paul Johnson wrote:



On Thu, Aug 16, 2018, 16:35 seirra <mailto:gene...@sarifria.x10.bz>> wrote:


hmmm i do see the point there about racial/class bias... i was
thinking more about areas that were known crime spots/had
associated illegal activities people may want to avoid(to the
point there are regular police patrols at night)? also places
where getting a phone out could lead to it being stolen? i've
heard that can be an issue in some areas. just wasn't sure if any
of those scenarios really deserved tagging because i didn't really
feel there was a bias there? either way just wanted to check
(sorry if this shows up as a double post, i saw there was a reply
to mailing list option i should be using, i get the impression the
first time didn't send)


At that point, you're just avoiding cities in general, as crime rates 
tend to increase proportionally to population density.




___
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] double doors?

[seirra]

should these be split into two separate door elements, or should it be 
tagged as just a really wide door?



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

[Tagging] tagging a gamesroom?

[seirra]

what should a games room (think things like darts, pool/snooker, card 
games) be tagged as? when i looked around i couldn't seem to find any 
official consensus or unofficial for that matter


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

Re: [Tagging] areas of risk

[seirra]

in that particular example, i'm referring to where just having your 
phone visible is enough to lead to theft? (i don't know if it was 
exclusively phones, it was a warning from a local) money and cars are 
probably other examples of what could be mapped though.



On 08/17/18 00:22, Martin Koppenhoefer wrote:


sent from a phone


On 17. Aug 2018, at 00:25, seirra  wrote:

lives they say if someone sees your phone it gets stolen? so safety:phone=no 
could be a good example?


like you have to take special care of your phone, but don’t worry for your 
money or your car, they’re only interested in phones?


Cheers,
Martin
___
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] areas of risk

[seirra]

I was thinking more if a specific crime happens often enough to be 
attributed to a street/building. by overlaid I'm guessing you mean as in 
third party like mentioned earlier?



On 08/17/18 00:36, Shawn K. Quinn wrote:

On 08/16/2018 02:32 PM, seirra wrote:

Hello, i was wondering whether there was a way to tag areas that may be
risky/dangerous to walk in? i can think of a few streets that could use
the tag, was there anything of the sort that has been agreed on?

Past discussions have indicated this is not something which can be
objectively mapped in the OSM database. A posted sign warning of a high
crime area, as well as things like graffiti, the
dilapidated/deteriorated state of buildings, etc. could be mapped or
tagged on existing objects as appropriate. Crime data by police
beat/precinct could be overlaid onto a map generated from OSM data as well.




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

Re: [Tagging] areas of risk

[seirra]

 i understand that, i was giving a less 'political' example, because 
if the OP feels they shouldn't be mapped, then discussion needs to be 
sensitive too. i meant more not mentioning them specifically here... for 
the same reason in the sentence before.



On 08/17/18 00:31, Warin wrote:

On 17/08/18 08:25, seirra wrote:
i did originally mean more for example if an area is known for a 
specific crime... listing it there? for example where a friend of 
mine lives they say if someone sees your phone it gets stolen? so 
safety:phone=no could be a good example? i can think of other 
examples such as specific streets patrolled at night due to known 
criminal activity (which should be tagged with the specific crime, 
because otherwise it's no use to anyone), 
The areas I am thinking of .. your life is at risk. Forget money, 
phones.. your very life.


but given OP's expressed issues on the matter i figure it's best not 
to mention them specifically


If your going to map them .. then they will be public.




On 08/16/18 23:14, Martin Koppenhoefer wrote:


sent from a phone

On 17. Aug 2018, at 00:09, Andy Mabbett  
wrote:


What, like tax avoidance and insider dealing?


I believe he’s more after corruption and abuse of institutional power.

Cheers,
Martin
___
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



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

Re: [Tagging] use of points even when it clearly defines a building?

[seirra]

in that case wouldn't it make more sense to just put start_date:building 
so there was just one object with the same information? obviously if 
there's multiple uses for the building then the use of points makes 
sense until someone maps the actual polygons



On 08/17/18 00:19, Martin Koppenhoefer wrote:


sent from a phone


On 17. Aug 2018, at 00:39, seirra  wrote:

where a point clearly defines a building in these areas should it be corrected? 
also if a floor of a building is for example: a store at the bottom of the 
building, and the rest is apartments... shouldn't it then be a building 
labelled as a chemist,


we try to distinguish the building from the user. A building is a building, a 
chemist is a company. Often simple cases are mapped taking a “short cut” and 
the poi and the building are mixed into one OSM object, what is tolerated but 
generally deemed less precise because you don’t know which of the tags belongs 
to the building and which to the business.(name? start_date? etc)

A common solution is creating a node within the building polygon for the 
business. Another way is using an overlapping way or creating a multipolygon 
(even with just one outer member in some cases) for the business.

cheers,
Martin
___
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] access:disabled... yes or designated?

[seirra]

huh. I thought i read about it needing to be access:disabled... however 
i feel like this should be quoted: "Nodes and areas tagged with amenity 
<https://wiki.openstreetmap.org/wiki/Key:amenity>=parking_space and 
parking_space 
<https://wiki.openstreetmap.org/w/index.php?title=Key:parking_space=edit=1>=disabled 
<https://wiki.openstreetmap.org/w/index.php?title=Tag:parking_space%3Ddisabled=edit=1> 
are rendered on rollstuhlkarte.ch 
<http://rollstuhlkarte.ch/?zoom=15=47.37=8.54=B0FTT> 
(Wheelchair symbol with a small P in the top right corner; also see 
rollstuhlkarte.ch-Wikipage 
<https://wiki.openstreetmap.org/wiki/Rollstuhlkarte.ch>)." and upon 
inspection there are MANY, much more than the use of access:disabled, or 
even disabled! is parking_space even a valid tag though?(i can't see any 
documentation) because this seems to be the only example of actual 
rendering, should we first see if we can get the developers to 
transition to rendering the disabled tag before we change it?



On 08/17/18 00:11, Martin Koppenhoefer wrote:


sent from a phone


On 17. Aug 2018, at 00:19, seirra  wrote:

also i saw some cases of access:disabled=customers? wouldn't access=customers 
paired with access:disabled=designated be a good pairing?


actually the documented tag is
“disabled=*” and it has more than double the usage than “access:disabled=*”
capacity:disabled=* ist by far (30 times) more used than either of these.

Semantically, for a parking access:disabled makes less sense, because access is 
about who can enter the polygon ;-) For a road it could be beneficial to prefix 
“access” because it removes any ambiguity.


cheers,
Martin
___
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] use of points even when it clearly defines a building?

[seirra]

oh! before i go to bed just one last one, when correcting some typos or 
wrong use of tagging i've noticed a few locations that used points 
rather than directly applying the feature to the building (as in no 
buildings having features at all as if it was an agreed style)... most 
notably:


italy north plars
crescent street montreal
Czech Technology Park
Grand Admiral Resort & SPA

where a point clearly defines a building in these areas should it be 
corrected? also if a floor of a building is for example: a store at the 
bottom of the building, and the rest is apartments... shouldn't it then 
be a building labelled as a chemist, with the tag level=0 and at the 
same point on the map, a building labelled as apartments with the tag 
level=1? or should we wait until we (hopefully) have the ability to more 
easily switch between layers and then sort it out once that lands? (to 
avoid difficulties on the ID editor)



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

Re: [Tagging] areas of risk

[seirra]

i did originally mean more for example if an area is known for a 
specific crime... listing it there? for example where a friend of mine 
lives they say if someone sees your phone it gets stolen? so 
safety:phone=no could be a good example? i can think of other examples 
such as specific streets patrolled at night due to known criminal 
activity (which should be tagged with the specific crime, because 
otherwise it's no use to anyone), but given OP's expressed issues on the 
matter i figure it's best not to mention them specifically



On 08/16/18 23:14, Martin Koppenhoefer wrote:


sent from a phone


On 17. Aug 2018, at 00:09, Andy Mabbett  wrote:

What, like tax avoidance and insider dealing?


I believe he’s more after corruption and abuse of institutional power.

Cheers,
Martin
___
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] access:disabled... yes or designated?

[seirra]

"assigned with a specific role" is probably the best interpretation for 
example "this is a designated disabled parking area" would mean the 
specific role is parking for disabled people. the preferred model does 
seem to be tagging access=no then the exceptions from what i can tell. 
there probably should be more templates really to aid in this, but then 
again if you don't define the access tag and the only thing there is 
access:disabled=designated i guess it's the same idea. also i saw 
some cases of access:disabled=customers? wouldn't access=customers 
paired with access:disabled=designated be a good pairing? it's just then 
a question of how we also specify the no tag in the neatest way possible 
or if we omit it in that scenario



On 08/16/18 23:06, Jo wrote:

you mean it must be tagged:

access=no
+exceptions
?

designated is an odd word. I started to understand it as signposted as 
such, or clear from road markings.


but it's not the meaning it has in designated driver, where it means 
"assigned with a specific role/responsability"


Op do 16 aug. 2018 om 23:59 schreef Warin <61sundow...@gmail.com 
<mailto:61sundow...@gmail.com>>:


On 17/08/18 07:46, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 16. Aug 2018, at 23:35, seirra mailto:gene...@sarifria.x10.bz>> wrote:
>>
>> should cases where yes was used be corrected to designated? or
should it be considered a stylistic choice?
>
> generally, it doesn’t work very well, because you want to
express who can park there not who can access the lot. It should
be “only” or “designated” because yes does not exclude others,
while only does and designated tends to do.
>

For OSM .. to exclude others it should it not be tagged

access=no

then

disabled=yes/designated to accept disabled?


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



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


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

Re: [Tagging] access:disabled... yes or designated?

[seirra]

alright, when i get the time i'll correct them and link to this 
discussion, perhaps tomorrow if i remember



On 08/16/18 22:46, Martin Koppenhoefer wrote:


sent from a phone


On 16. Aug 2018, at 23:35, seirra  wrote:

should cases where yes was used be corrected to designated? or should it be 
considered a stylistic choice?


generally, it doesn’t work very well, because you want to express who can park 
there not who can access the lot. It should be “only” or “designated” because 
yes does not exclude others, while only does and designated tends to do.

cheers,
Martin
___
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] access:disabled... yes or designated?

[seirra]

should cases where yes was used be corrected to designated? or should it 
be considered a stylistic choice?



On 08/16/18 22:29, marc marc wrote:

Le 16. 08. 18 à 21:42, seirra a écrit :

another query, for access:disabled should the correct usage for a
standard disabled parking space be designated or yes?

designated seems the better value for this case
___
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] areas of risk

[seirra]

hmmm i do see the point there about racial/class bias... i was thinking 
more about areas that were known crime spots/had associated illegal 
activities people may want to avoid(to the point there are regular 
police patrols at night)? also places where getting a phone out could 
lead to it being stolen? i've heard that can be an issue in some areas. 
just wasn't sure if any of those scenarios really deserved tagging 
because i didn't really feel there was a bias there? either way just 
wanted to check (sorry if this shows up as a double post, i saw there 
was a reply to mailing list option i should be using, i get the 
impression the first time didn't send)



On 08/16/18 21:52, Jmapb wrote:


On the other hand, an overlay with data about various risk factors -- 
crime, weather, accidents, air quality, cancer clusters, whatever -- 
would be a fine feature for a 3rd party map app to offer. But these 
things don't belong in the OSM database.


As far as "bad areas" and "class and racial bias" go, I'll admit that 
I contemplated the idea of tagging the walking paths within some city 
public housing projects as access=destination, because it reflects the 
reality on the ground -- generally, people don't walk *through* the 
projects to get to a destination on the other side. But it's 
immediately obvious that this is bias-based interpretation: when I say 
"people" I mean people I know, and OSM is for everybody, not just 
people I know. So unless the paths are physically impeded, 
unmaintained to the point of decay, or signed "residents only" they 
need to be equal to any other walking path.


J


On 8/16/2018 4:25 PM, Paul Johnson wrote:
Other than dog toilets, this is too subjective to be included in OSM 
at all, and tends to stink of class and racial biases.


On Thu, Aug 16, 2018, 14:35 seirra <mailto:gene...@sarifria.x10.bz>> wrote:


Hello, i was wondering whether there was a way to tag areas that
may be
risky/dangerous to walk in? i can think of a few streets that
could use
the tag, was there anything of the sort that has been agreed on?


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



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




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


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

[Tagging] access:disabled... yes or designated?

[seirra]

another query, for access:disabled should the correct usage for a 
standard disabled parking space be designated or yes? the usage is mixed 
so i'm unsure... i'm sticking with designated for now (it's 'designated' 
to a disabled driver)



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

[Tagging] areas of risk

[seirra]

Hello, i was wondering whether there was a way to tag areas that may be 
risky/dangerous to walk in? i can think of a few streets that could use 
the tag, was there anything of the sort that has been agreed on?



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