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

[Warin]

On 11-Jan-18 12:58 PM, Andrew Davidson wrote:



On 11/01/18 06:30, Tijmen Stam wrote:

On 10-01-18 11:37, Andrew Davidson wrote:
Yeap, that would be an edge case. Guess no-one thought that you 
could have an entire route that is only one way. 


I don't see why this is a problem.


This thread is getting quite long. To recap, the problem is that if 
your PTv2 route consists of only one way there is no way to tell in 
which direction it runs without providing more information.

Break the single way into 2 ways...
Or use the order of  'stops' .. they should be ordered from start to 
finish. If a circular route then start and finish can be the same.






The solution would be either:

1. Put in at least two stops/platforms.
Which you need to do anyway. 


Actually you don't. The stop/platforms are only "recommended if 
available".


In fact a valid PTv2 route can be just a relation with:

type=route
route=train/.../ferry

and a single way. Everything else is recommended or optional.
Then there would be no method of getting on or off .. you need some 
'stops'.


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

Re: [Tagging] Kerbs

[Shu Higashi]

I think we can at least add an image tag as a raw data for someone
such as wheelchair users or mapillary that may estimate the height
automatically in the future :)
lowered:
https://www.openstreetmap.org/node/4294717996
raised:
https://www.openstreetmap.org/node/4293918233

Shu Higashi

2018-01-08 18:00 GMT+09:00, Selfish Seahorse :
>> Maybe there's a good middle ground: a kerb height ranking, in lieu of
>> taking out a ruler and/or guessing a true kerb:height value.
>> kerb:height=low/medium/high, with corresponding ranges in cm (0-3, 3-10,
>> 10+).
>
> That's actually very similar to mountable/semi-mountable/non-mountable
> or wheelchair=yes/limited/no and would lead to the same problems you
> described further above. If we want to prevent putting wheelchair
> users in categories, I think it's better to give the actual heights.
>
>
> On 7 January 2018 at 21:38, Nick Bolten  wrote:
>>> Even if only three out of four wheelchair users were satisfied with
>> `mountable`, `semi-mountable` and `non-mountable` this would be a step
>> forward, in my opinion.
>>
>> I would wager that the fraction of wheelchair users covered would be a
>> minority - there's a lot of diversity that tends to get lumped into just
>> 'wheelchair accessible' and it's really not one-size-fits-all in any way.
>> In
>> order for two wheelchair users to have the same requirements and
>> preferences, they'll need to sync up on all of these things: short-burst
>> athleticism, endurance, average speed, age-related compounding factors,
>> manual vs. electric chair, wheel traction, wheel width, wheel radius,
>> chair
>> width, side-to-side stability, comfort level with using streets and
>> driveways, etc. Now think of any two random users: how likely are they to
>> match on all of those categorizations?
>>
>> I'm going on a bit too long, but you get the idea. Most of those needs can
>> be directly handled with just a few neutral, measurable, on-the-ground
>> tags:
>> kerb shape + height + width, footpath width + incline, surface tags, etc.
>> And all users benefit from those tags - bicyclists will also appreciate
>> surface and kerb tags, as will parents using strollers or people hauling
>> luggage. And most of these tags are useful in an additive way: one is
>> good,
>> two is better, etc, etc, and can be queried to figure out where
>> information
>> is missing and turn it into quests like maproulette.
>>
>> Let's consider just one common situation: manual wheelchairs tend to have
>> larger radius wheels than electric wheelchairs do, which, just due to
>> physics, impacts how they handle displacements like curbs. The
>> higher-radius
>> wheels have an easier time of it due to the angle of approach + extra
>> leverage (though the user can become tired doing curb after curb), and
>> there
>> are a lot of curbs right on the cusp of being doable by electric
>> wheelchair
>> users. Even just for this one common situation, we have to ignore
>> wheelchair=yes, and probably a mountable/semi-mountable/unmountable tag,
>> because what's actually dictating access is variation in the curb shape +
>> height.
>>
>> Maybe there's a good middle ground: a kerb height ranking, in lieu of
>> taking
>> out a ruler and/or guessing a true kerb:height value.
>> kerb:height=low/medium/high, with corresponding ranges in cm (0-3, 3-10,
>> 10+).
>>
>>> Besides, I didn't think of these values to be a replacement for
>>> kerb:shape, but an addition.
>>
>> Ah, well I initially misunderstood. But I still think it's better to
>> completely drop the idea of overarching 'wheelchair access' tags for
>> pedestrian tagging, due to the concerns above. Wheelchair users need
>> unambiguous information and we already have ambiguous info in
>> wheelchair=yes
>> and access=*.
>>
>> Fundamentally, everyone is trying to answer the question, 'can a
>> wheelchair
>> user traverse this line/point/area?', and while it's tempting to say 'yes'
>> or 'no', the true answer representing the majority of users is, 'it
>> depends', which is why we need tags that reflected neutral, measurable
>> on-the-ground conditions.
>>
>>> However, if we want to make the current scheme more usable, it is
>>> necessary to also specify the angle of inclination for sloped kerbs (and
>>> maybe kerb ramps too). Compare the following two kerbs, which have the
>>> same
>>> shape, but a different level of accessibility (...)
>>
>> You're completely right. And while we have the incline=* tag, there's no
>> standard for where or how to apply it to a curb interface. Do we tag the
>> node itself, and what does it mean of kerb=raised has an incline value? If
>> tagging a node with incline=*, how do we figure out the direction of the
>> incline, and how much does it matter? Does a kerb=* node imply that a
>> footway should be split, and the two ways it connects to should (ideally)
>> have separate incline=* tags? I prefer that last option, personally. Plus,
>> it would benefit from adding a separate curb ramp tag for a way: a

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

[Andrew Davidson]

On 11/01/18 06:30, Tijmen Stam wrote:

On 10-01-18 11:37, Andrew Davidson wrote:
Yeap, that would be an edge case. Guess no-one thought that you could 
have an entire route that is only one way. 


I don't see why this is a problem.


This thread is getting quite long. To recap, the problem is that if your 
PTv2 route consists of only one way there is no way to tell in which 
direction it runs without providing more information.






The solution would be either:

1. Put in at least two stops/platforms.
Which you need to do anyway. 


Actually you don't. The stop/platforms are only "recommended if available".

In fact a valid PTv2 route can be just a relation with:

type=route
route=train/.../ferry

and a single way. Everything else is recommended or optional.


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

Re: [Tagging] drinkable vs. drinking_water

[Graeme Fitzpatrick]

> Please keep in mind that OSM is about local knowledge so the important
> question is if people locally drink the water or not.


& there are any number of places in the world where the local population
happily drink water, that visitors from first-world countries would turn
away from in horror!
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] drinkable vs. drinking_water

[Mateusz Konieczny]

On Wed, 10 Jan 2018 18:31:43 +
marc marc  wrote:

> for ex if a previous mapper use amenity=drinking water,
> you can't keep it and add it's a amenity=fountain.

We already have https://wiki.openstreetmap.org/wiki/Key:drinking_water

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

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

[Jo]

I like the hail_and_ride tag for route and route_master relations and the
hail_and_ride role for segments of the route where it applies (so as a role
for the ways).

So this is ready to vote upon, as far as I'm concerned.

Polyglot

2018-01-10 19:20 GMT+01:00 Fernando Trebien :

> Thanks. Following your link, I found some discussion on this already:
> * https://wiki.openstreetmap.org/wiki/Talk:Proposed_
> features/Differentiation_for_routes_of_public_transport#
> stopping_pattern_values
> * https://wiki.openstreetmap.org/wiki/Talk:Proposed_
> features/hail_and_ride#Next_step:_Voting.3F
>
> On Wed, Jan 10, 2018 at 2:53 PM, marc marc 
> wrote:
> > Le 10. 01. 18 à 17:11, Fernando Trebien a écrit :
> >> Since you brought this up, where I live there is a bus network for
> >> which people can hail anywhere.
> >
> > maybe suggest a stopping_pattern=everywhere
> > https://wiki.openstreetmap.org/wiki/Proposed_features/
> Differentiation_for_routes_of_public_transport
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> --
> Fernando Trebien
> +55 (51) 9962-5409
>
> "Nullius in verba."
>
> ___
> 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] drinkable vs. drinking_water

[marc marc]

Le 10. 01. 18 à 18:42, Martin Koppenhoefer a écrit :
> 2018-01-10 18:19 GMT+01:00 marc marc :
> 
> maybe it's time to split tag and render in 2
> this is the tagging ML, for style decisions of osm carto see here: 

I agree but check first message of this threat :)
remove the "render" part of my message, it keep the same meaning.
currently some tag are mutually exclusive
for ex if a previous mapper use amenity=drinking water,
you can't keep it and add it's a amenity=fountain.
That's why my message of fact was not to talk about rendering but about 
the split between what that look like (fountain, well, tap), the quality 
(drinkable or not), the function (fill a bottle or fill a tank) and the 
connector (able to connect a pipe or not).

After removing the word "render" in this clarification,
I hope that  will allow you to discuss the underlying problem :-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Urbex

[OSMDoudou]

I don't read them asking to remove routes from maps.

 

What catches my eye in the article is they ask to "remove our side streets from 
their algorithms and not offer them as recommendations".

 

So, it's a matter of municipalities putting the right signs in the field (e.g. 
destination only -- which they need to do anyway to fine abusive cut-through), 
tagging the map accordingly (local OSM mappers will happily do that) and the 
routing engine will simply gently abide.

 

 

From: Kevin Kenny [mailto:kevin.b.kenny+...@gmail.com] 
Sent: Wednesday, January 10, 2018 03:41
To: Tag discussion, strategy and related tools 
Subject: Re: [Tagging] Urbex

 

https://lists.openstreetmap.org/pipermail/talk-us/2018-January/018279.html

 

On Tue, Jan 9, 2018 at 7:32 PM, Andy Mabbett mailto:a...@pigsonthewing.org.uk> > wrote:

On 8 January 2018 at 23:39, Kevin Kenny mailto:kevin.b.kenny%2b...@gmail.com> > wrote:

> Witness municipalities asking us to remove their
> streets from the map

When & where did that happen?

[off-topic for the tagging list, so please feel free to point me to an
alternative venue]

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


___
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] route/forward/backward members in all types of routes

[marc marc]

Of course that could/should be mapped.

Le 10. 01. 18 à 18:47, Jo a écrit :
> but you would still have a sequence of connected ways and hence the 
> order in which to follow them would be clear. I can understand one can 
> hail anywhere, but the starting point and last stop can still be mapped, 
> or not?
> 
> 2018-01-10 17:53 GMT+01:00 marc marc  >:
> 
> Le 10. 01. 18 à 17:11, Fernando Trebien a écrit :
> > Since you brought this up, where I live there is a bus network for
> > which people can hail anywhere.
> 
> maybe suggest a stopping_pattern=everywhere
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Differentiation_for_routes_of_public_transport
> 
> 
> ___
> 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] route/forward/backward members in all types of routes

[Fernando Trebien]

Thanks. Following your link, I found some discussion on this already:
* 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Differentiation_for_routes_of_public_transport#stopping_pattern_values
* 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/hail_and_ride#Next_step:_Voting.3F

On Wed, Jan 10, 2018 at 2:53 PM, marc marc  wrote:
> Le 10. 01. 18 à 17:11, Fernando Trebien a écrit :
>> Since you brought this up, where I live there is a bus network for
>> which people can hail anywhere.
>
> maybe suggest a stopping_pattern=everywhere
> https://wiki.openstreetmap.org/wiki/Proposed_features/Differentiation_for_routes_of_public_transport
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."

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

Re: [Tagging] difference between seamark:type=light_minor and seamark:type=light_major

[Mateusz Konieczny]

On Wed, 10 Jan 2018 17:13:23 +1000
Graeme Fitzpatrick  wrote:

> So, by that, if it's in a lighthouse it should be a major, long-range,
> light.

I made edit to OSM wiki - see
https://wiki.openstreetmap.org/w/index.php?title=Tag:man_made%3Dlighthouse&diff=1547190&oldid=1547189

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

Re: [Tagging] drinkable vs. drinking_water

[Mateusz Konieczny]

On Wed, 10 Jan 2018 17:19:08 +
marc marc  wrote:

> maybe it's time to split tag and render in 2
> 
> what the objet look like : fountain, tap, trough, pipe, well
> that can tag using existing amenity or man_made key.
> the render already have a icon for some of them.
> 
> the quality of the water
> blue if unknown, green if it's drinkable, red if it's not drinkable.

Graphical decision of renderers is offtopic here (making data usable
for data consumers is ontopic but it is not problem here - tags
exist already for both physical objects and drinkability state).

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

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

[Jo]

but you would still have a sequence of connected ways and hence the order
in which to follow them would be clear. I can understand one can hail
anywhere, but the starting point and last stop can still be mapped, or not?

2018-01-10 17:53 GMT+01:00 marc marc :

> Le 10. 01. 18 à 17:11, Fernando Trebien a écrit :
> > Since you brought this up, where I live there is a bus network for
> > which people can hail anywhere.
>
> maybe suggest a stopping_pattern=everywhere
> https://wiki.openstreetmap.org/wiki/Proposed_features/
> Differentiation_for_routes_of_public_transport
> ___
> 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] drinkable vs. drinking_water

[Martin Koppenhoefer]

2018-01-10 18:19 GMT+01:00 marc marc :

> maybe it's time to split tag and render in 2



this is the tagging ML, for style decisions of osm carto see here:
https://github.com/gravitystorm/openstreetmap-carto
or maybe on talk.

We're discussing how to describe objects and properties so that people can
make sense of it and render what they want.

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

Re: [Tagging] What should be used - [seasonal=spring] or [seasonal=spring + intermittent=yes]

[Christoph Hormann]

On Wednesday 10 January 2018, Mateusz Konieczny wrote:
>
> I think that seasonal for values other than no should be accompanied
> by intermittent=yes (for the same reasons as parking=surface tag
> alone is not sufficient, one should also add amenity=parking).
>
> But some think that this is adding superfluous detail (like adding
> motor_vehicle=yes to motorways).

That is not the same situation - intermittent=* and seasonal=* are both 
supplemental (secondary) tags that do not make any sense alone while 
highway=motorway and amenity=parking are primary tags.  

There are tons of secondary tags that partly imply each other.  Most 
prominent example is probably access restrictions where you can be more 
or less specific (vehicle=no implying motor_vehicle=no implying 
snowmobile=no).

Trying to force mappers either not to have partly redundant tags or to 
have them added in all cases is not an approach that is likely to be 
successful.  Data users just have to deal with that.

As a data user you should in particular be aware of course that 
intermittent=yes + seasonal=no is a meaningful combination (with 68k 
uses).

-- 
Christoph Hormann
http://www.imagico.de/

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

[Tagging] Water source types

[Cez jod]

Hy!

"On the hiking trails in my part of the world, the volunteers have
constructed a number of piped springs.  A typical one looks like
https://www.flickr.com/photos/ke9tv/6936811420 "

Such a place as in the picture can be tagged fast as natural=spring(if it
occurs alone). After deep reflection may also be a different version, if
the inhabitants(or someone) forwarding the water from the stream which then
flows out identically as in the picture then I think amenity =
drinking_water would be a better because such places along the stream can
be dozens.

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

Re: [Tagging] What should be used - [seasonal=spring] or [seasonal=spring + intermittent=yes]

[Mateusz Konieczny]

On Wed, 10 Jan 2018 18:17:17 +0100
Martin Koppenhoefer  wrote:

> what do you mean by "support"? 

Rendering in OpenStreetMap Carto style (default one on the
http://openstreetmap.org/ )

See https://github.com/gravitystorm/openstreetmap-carto/issues/2095 for
more details.

> Seasonal is different from intermittent,

Yes, some things are both intermittent and seasonal and some only
intermittent

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

Re: [Tagging] drinkable vs. drinking_water

[marc marc]

maybe it's time to split tag and render in 2

what the objet look like : fountain, tap, trough, pipe, well
that can tag using existing amenity or man_made key.
the render already have a icon for some of them.

the quality of the water
blue if unknown, green if it's drinkable, red if it's not drinkable.

I do not, however, see how it is easy to include water_point in this 
schema. Some people think it means faster flow, others think it means a 
space to put in a tank, others think (imho wrongly) that it means you 
can connect a hose to feed a caravan or a garden.
this information might be better in separate tags (water_flow, space 
available for recipient, couplings:type)

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

Re: [Tagging] What should be used - [seasonal=spring] or [seasonal=spring + intermittent=yes]

[Martin Koppenhoefer]

2018-01-10 18:01 GMT+01:00 Mateusz Konieczny :

>
> Is it considered desirable to support using seasonal key without
> intermittent=yes?



what do you mean by "support"? Seasonal is different from intermittent, as
it is about something regularly recurring at roughly the same dates (and
probably duration). Intermittent doesn't give such information, but in
reality such things might often be seasonal as well.

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

[Tagging] drinkable vs. drinking_water

[Cez jod]

In my area where I usually maping, there are no public sources of drinking
water where the water is not suitable for drinking or I do not know that.
I Think for sure this tag is extremely important in countries, areas with
more difficult access to clean water. Maybe as I will be more often in such
areas, I will often use additional water quality markings.

Definition is perfectly prepared
https://wiki.openstreetmap.org/wiki/Key:drinking_water

I wanted to solve the doubts about potentially potable water by
unintentionally re-heating the subject:)

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

[Tagging] What should be used - [seasonal=spring] or [seasonal=spring + intermittent=yes]

[Mateusz Konieczny]

Discussion started as result of
https://github.com/gravitystorm/openstreetmap-carto/issues/2095

Is it considered desirable to support using seasonal key without
intermittent=yes?

I think that seasonal for values other than no should be accompanied by
intermittent=yes (for the same reasons as parking=surface tag alone is
not sufficient, one should also add amenity=parking).

But some think that this is adding superfluous detail (like adding
motor_vehicle=yes to motorways).

Current situation:

https://wiki.openstreetmap.org/wiki/Key:seasonal#Relation_to_intermittent
150k of seasonal=*, mostly yes/no values
( https://taginfo.openstreetmap.org/keys/seasonal#values )
1600k of intermittent=* yes/no values
( https://taginfo.openstreetmap.org/keys/intermittent#values )

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

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

[marc marc]

Le 10. 01. 18 à 17:11, Fernando Trebien a écrit :
> Since you brought this up, where I live there is a bus network for
> which people can hail anywhere.

maybe suggest a stopping_pattern=everywhere
https://wiki.openstreetmap.org/wiki/Proposed_features/Differentiation_for_routes_of_public_transport
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] drinkable vs. drinking_water

[Cez jod]

Hi!
I just want to point out that the tag drink water=yes/no is regulated by
top-down rules. I have no doubts here. Certainly in all civilized countries.
 Personally, I does not add information whether the water is drinking or
not it has to be assessed on the spot by the end user of the map. I have no
intention of having someone's health or life on conscience.
Tagged problem is limited to common, generally available water intakes, not
to all possible in nature.

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

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

[Fernando Trebien]

Since you brought this up, where I live there is a bus network for
which people can hail anywhere. Mostly. There are some parts of town,
such as in downtown, in which there are specific stops for this
service. In most areas it is completely at the passengers' will. This
network coexists with another network for which people can only board
from designated stops.

Moovit supports that service by >> assuming << that users may only
hail from regular bus stops - probably the only way they could make it
work with their journey planner. Should something similar be done in
OSM? (I believe it should not, but anyway.)

On Wed, Jan 10, 2018 at 10:16 AM, Andy Townsend  wrote:
> On 10/01/2018 12:00, Georg Feddern wrote:
>>
>> I am quite sure that in _reality_ a stop _or_ a platform is mandatory in a
>> public transport route - otherwise you would just have a route with
>> 'hitchhiking'?
>
>
> In the real world, that happens.  As well as public transport routes with
> _only_ the route defined (no stops) there are also those with _only_ the
> stops defined and the driver decides how to get to the next one base on
> traffic.  Also there are "request" routes where there are defined stops, but
> not in a defined order.  The above examples all exist in the UK, but think
> about public transport worldwide (minibus taxis in South Africa, for
> example) and things aren't always quite so "nailed down" as they might be
> elsewhere.
>
> Best Regards,
> Andy
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."

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

Re: [Tagging] drinkable vs. drinking_water

[Martin Koppenhoefer]

2018-01-10 16:31 GMT+01:00 Cez jod :

>
> every country has its own sanitary regulations.
>



to refrain what Christoph said: we don't require mappers to perform lab
analytics, it is sufficient that people believe it is drinking water in
order to tag it like this.

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

[Tagging] drinkable vs. drinking_water

[Cez jod]

Hi!
"In French for example "potable" means "drinkable (without problems)""
Always in different languages will be different meaning hence the problem
with tagging.

"Which law is that? And in which language? "
How do you know that drinking water flows from your tap? The question is
for e.g WHO http://www.who.int/water_sanitation_health/water-quality/en/
http://ec.europa.eu/environment/water/water-drink/
ect:.
every country has its own sanitary regulations.

sorry to accidentally refresh the question from 2012.

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

Re: [Tagging] drinkable vs. drinking_water

[Christoph Hormann]

On Wednesday 10 January 2018, Cez jod wrote:
>
> Potable=yes/no means that water in any case should be boiled before
> consumption (raw water) because it has not been tested in the
> laboratory. That's the law.

And the law is a function of the location. ;-)

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

covers this matter quite well.

Please keep in mind that OSM is about local knowledge so the important 
question is if people locally drink the water or not.  

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] drinkable vs. drinking_water

[Colin Smale]

Which law is that? And in which language? 

In French for example "potable" means "drinkable (without problems)" 

I think you are a little inaccurate with your suggestion that
drinking_water is an antonym of waste water/sewage. There is plenty of
water out there which is neither - lakes and rainwater for example, and
plenty of water which is even worse than sewage (industrial waste
stuff).

On 2018-01-10 16:00, Cez jod wrote:

> Potable and drinking_water are not equal.
> 
> drinking_water=yes means I can drink water straight from the source (tap, 
> fountain, source) the water has been laboratory tested, so I know I can drink 
> it without boiling.
> 
> Potable=yes/no means that water in any case should be boiled before 
> consumption (raw water) because it has not been tested in the laboratory. 
> That's the law.
> 
> amenity=drinking_water it contains in itself the tag Potable=yes / no (no 
> need to add it)
> 
> amenity=drinking_water is antonyms for waste water/sewage 
> ___
> 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] drinkable vs. drinking_water

[Cez jod]

Potable and drinking_water are not equal.

drinking_water=yes means I can drink water straight from the source (tap,
fountain, source) the water has been laboratory tested, so I know I can
drink it without boiling.

Potable=yes/no means that water in any case should be boiled before
consumption (raw water) because it has not been tested in the laboratory.
That's the law.

amenity=drinking_water it contains in itself the tag Potable=yes / no (no
need to add it)

amenity=drinking_water is antonyms for waste water/sewage
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What is the unit of seamark:light:range?

[Jo]

Those applications should definitely also be able to understand units. So
it would be good to implement that regardless of what the default is.

2018-01-10 15:07 GMT+01:00 Malcolm Herring :

> On 10/01/2018 13:53, Jo wrote:
>
>> Let's hope there is consensus on this.
>>
>
> There is certainly consensus among all the Seamarks consumer applications.
> To change the current tag values would break them all!
>
>
>
> ___
> 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] What is the unit of seamark:light:range?

[Malcolm Herring]

On 10/01/2018 13:53, Jo wrote:

Let's hope there is consensus on this.


There is certainly consensus among all the Seamarks consumer 
applications. To change the current tag values would break them all!



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

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

[Jo]

The  only case where that could lead to confusion is a route starting at 1
stop, then making a loop over exactly 1 way and coming back to that same
stop. The stop would go in twice in that case and it's extremelyunlikely
that that itinerary consists of 1 unsplit way.

Not to mention that it would be utter nonsense to have a route that brings
you back to the exact same spot, with no stops in between. Major waste of
gas and time, I'd say.

Polyglot

2018-01-10 14:54 GMT+01:00 Martin Koppenhoefer :

>
>
> sent from a phone
>
> > On 10. Jan 2018, at 13:00, Georg Feddern  wrote:
> >
> > I am quite sure that in _reality_ a stop _or_ a platform is mandatory in
> a public transport route - otherwise you would just have a route with
> 'hitchhiking'?
>
>
> yes, you could have a fix route with the vehicle stopping by hand waving,
> or telling the driver where to get off.
> Still interesting to map as a route relation, unlike the cases without a
> fix route (taxis).
>
> 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] route/forward/backward members in all types of routes

[Martin Koppenhoefer]

sent from a phone

> On 10. Jan 2018, at 13:00, Georg Feddern  wrote:
> 
> I am quite sure that in _reality_ a stop _or_ a platform is mandatory in a 
> public transport route - otherwise you would just have a route with 
> 'hitchhiking'?


yes, you could have a fix route with the vehicle stopping by hand waving, or 
telling the driver where to get off.
Still interesting to map as a route relation, unlike the cases without a fix 
route (taxis).

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

Re: [Tagging] What is the unit of seamark:light:range?

[Jo]

Let's hope there is consensus on this. I changed the wiki page that
describes the default units.

Polyglot

2018-01-10 14:38 GMT+01:00 Malcolm Herring :

> On 10/01/2018 06:50, Jo wrote:
>
>> Do we add " nmi" to all of them?
>>
>
> No. I have updated the Seamarks wiki pages to specify nautical miles as
> the default unit for ranges.
>
>
>
> ___
> 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] What is the unit of seamark:light:range?

[Jo]

lol, enough choice. Actually, I tend to like nmi, hard to confuse with
anything else, except maybe national meteorological institute...

2018-01-10 13:44 GMT+01:00 Martin Koppenhoefer :

>
>
> 2018-01-10 10:46 GMT+01:00 Andrew Davidson :
>
>> The symbol for nautical mile can be M, NM, Nm, or nmi (
>> https://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf p.127)
>>
>> M is not a good choice because it's too close to m (metre), M (mile
>> Roman, Irish, survey, international...), or M (mega).
>
>
>
> WP says also "sm" (sea mile).
>
> 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] What is the unit of seamark:light:range?

[Malcolm Herring]

On 10/01/2018 06:50, Jo wrote:

Do we add " nmi" to all of them?


No. I have updated the Seamarks wiki pages to specify nautical miles as 
the default unit for ranges.



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

Re: [Tagging] What is the unit of seamark:light:range?

[Martin Koppenhoefer]

2018-01-10 10:46 GMT+01:00 Andrew Davidson :

> The symbol for nautical mile can be M, NM, Nm, or nmi (
> https://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf p.127)
>
> M is not a good choice because it's too close to m (metre), M (mile Roman,
> Irish, survey, international...), or M (mega).



WP says also "sm" (sea mile).

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

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

[Andy Townsend]

On 10/01/2018 12:00, Georg Feddern wrote:
I am quite sure that in _reality_ a stop _or_ a platform is mandatory 
in a public transport route - otherwise you would just have a route 
with 'hitchhiking'?


In the real world, that happens.  As well as public transport routes 
with _only_ the route defined (no stops) there are also those with 
_only_ the stops defined and the driver decides how to get to the next 
one base on traffic.  Also there are "request" routes where there are 
defined stops, but not in a defined order.  The above examples all exist 
in the UK, but think about public transport worldwide (minibus taxis in 
South Africa, for example) and things aren't always quite so "nailed 
down" as they might be elsewhere.


Best Regards,
Andy



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

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

[Georg Feddern]

Am 10.01.2018 um 12:32 schrieb Ilya Zverev:

Selfish Seahorse wrote:

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

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

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


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

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

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

[Ilya Zverev]

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

But stops are not mandatory in public transport routes, unlike 
highways/railways!

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

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

[Andrew Davidson]

Yeap, that would be an edge case. Guess no-one thought that you could 
have an entire route that is only one way. The solution would be either:


1. Put in at least two stops/platforms.
2. Split the way into two.

On 10/01/18 05:57, Fernando Trebien wrote:

I was about to fix a mistake I caused in the map due to these
contradictions in the wiki, then I found a problematic case [1].

According to PTv2, this route needs to be broken into two, one per
direction, and a route_master relation must be created for them.
Without the forward/backward roles, I believe applications will not be
able to easily find out the direction of travel of either since the
route contains a single way, unless they parse the from and to tags,
which are not required to match station names.

Would this be a deficiency of PTv2?

[1] https://www.openstreetmap.org/relation/5465620

On Tue, Jan 9, 2018 at 4:12 PM, Fernando Trebien
 wrote:

It seems like other people have faced this problem before [1]. The link
provided by JOSM developers refers to the text in the proposal, not to the
main article [3] nor the more specific route type articles.

[1] https://josm.openstreetmap.de/ticket/13768
[2] https://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport
[3] https://wiki.openstreetmap.org/wiki/Public_transport

On Tue, Jan 9, 2018 at 3:28 PM, Fernando Trebien
 wrote:


On Tue, Jan 9, 2018 at 11:13 AM, Tijmen Stam 
wrote:

In PTv2 only a few roles are acceptable: stop and platform (and the
equivalents stop_exit_only and stop_entry_only) for stops and platforms,
and _no role_ for the ways in the route.


In that case, the article on route relations [1] should be updated to
state that forward and backward roles are not always acceptable, and
that the user should read the article on the more specific route type
to know whether it is acceptable or not.

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

--
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."





--
Fernando Trebien
+55 (51) 9962-5409

"Nullius in verba."






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

Re: [Tagging] What is the unit of seamark:light:range?

[Jo]

@Martin Annoyingly the wiki states nmi.

@Andrew I  downloaded all those points worldwide using an Overpass query.
Then I used a regular expression search in JOSM and used the todo list to
check some at random.

Jo



2018-01-10 10:19 GMT+01:00 Martin Koppenhoefer :

>
>
> 2018-01-10 7:50 GMT+01:00 Jo :
>
>> There are 17912 objects tagged with "seamark:light:range" in our data.
>> Not a single one has a unit. They all seem to be in international nautical
>> miles. Do we add " nmi" to all of them?
>>
>
>
>
> the symbol for nautical miles is "NM"
>
> Cheers,
> Martin
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What is the unit of seamark:light:range?

[Andrew Davidson]

The symbol for nautical mile can be M, NM, Nm, or nmi 
(https://www.bipm.org/utils/common/pdf/si_brochure_8_en.pdf p.127)


M is not a good choice because it's too close to m (metre), M (mile 
Roman, Irish, survey, international...), or M (mega).


On 10/01/18 20:19, Martin Koppenhoefer wrote:



the symbol for nautical miles is "NM"

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] Water source types

[Marc Gemis]

On Wed, Jan 10, 2018 at 10:21 AM, Marc Gemis  wrote:
> Seems we are repeating ourselves once again:
>
> https://lists.openstreetmap.org/pipermail/tagging/2012-July/010809.html
> https://lists.openstreetmap.org/pipermail/tagging/2014-November/019998.html
>

and that last discussion continued in 2015 when the proposal was
opened for voting:

https://lists.openstreetmap.org/pipermail/tagging/2015-January/020893.html

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

Re: [Tagging] Water source types

[Marc Gemis]

Seems we are repeating ourselves once again:

https://lists.openstreetmap.org/pipermail/tagging/2012-July/010809.html
https://lists.openstreetmap.org/pipermail/tagging/2014-November/019998.html

regards

m

On Wed, Jan 10, 2018 at 9:53 AM, Thibaud B  wrote:
>>Because drinking water is a *property* of sources, water wells,
>>fountains, drinking fountains (bubblers) etc., I think it makes more
>>sense to tag these objects and to add drinking_water=yes tags
>>(discouraging the use of `amenity=drinking_water`).
>
>>As for the rendering, I like how OsmAnd renders drinking_water=yes/no:
>>with a drop overlay that is blue for drinking_water=yes [^1] and grey
>>for drinking_water=no [^2].
>
>
> Yes in order to have a clear pattern for tagging these "water delivering"
> items, we need to separate the physical aspect from the quality of water
> provided.
>
> Physical aspect would be : water_wells, drinking_foutains --> good for the
> user to know if he can easily drink or fill a bottle or connect a hose etc..
>
> Quality of water would be : drinking_water=yes/no; mineral_water=yes/no
>
> 
> De : Selfish Seahorse 
> Envoyé : mercredi 10 janvier 2018 09:38:00
> À : Tag discussion, strategy and related tools
> Objet : Re: [Tagging] Water source types
>
> On 10 January 2018 at 01:49, Daniel Koć  wrote:
>> I would say that amenity=drinking_water is a general source of the high
>> quality water and it would be good to make it more specific if possible -
>> adding tap, well and pump tags would be nice.
>
> Because drinking water is a *property* of sources, water wells,
> fountains, drinking fountains (bubblers) etc., I think it makes more
> sense to tag these objects and to add drinking_water=yes tags
> (discouraging the use of `amenity=drinking_water`).
>
> As for the rendering, I like how OsmAnd renders drinking_water=yes/no:
> with a drop overlay that is blue for drinking_water=yes [^1] and grey
> for drinking_water=no [^2].
>
> [^1]:
> https://github.com/osmandapp/OsmAnd-resources/blob/master/icons/svg/overlays/drinking_water_yes.svg
> [^2]:
> https://github.com/osmandapp/OsmAnd-resources/blob/master/icons/svg/overlays/drinking_water_no.svg
>
> ___
> 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] What is the unit of seamark:light:range?

[Martin Koppenhoefer]

2018-01-10 7:50 GMT+01:00 Jo :

> There are 17912 objects tagged with "seamark:light:range" in our data. Not
> a single one has a unit. They all seem to be in international nautical
> miles. Do we add " nmi" to all of them?
>



the symbol for nautical miles is "NM"

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

Re: [Tagging] Water source types

[Martin Koppenhoefer]

2018-01-10 3:59 GMT+01:00 Tod Fitch :

> Boxed springs like the one you show in your first photo I typically tag as
> a spring (natural=spring).
>


+1

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

Re: [Tagging] Water source types

[Thibaud B]

>Because drinking water is a *property* of sources, water wells,
>fountains, drinking fountains (bubblers) etc., I think it makes more
>sense to tag these objects and to add drinking_water=yes tags
>(discouraging the use of `amenity=drinking_water`).

>As for the rendering, I like how OsmAnd renders drinking_water=yes/no:
>with a drop overlay that is blue for drinking_water=yes [^1] and grey
>for drinking_water=no [^2].


Yes in order to have a clear pattern for tagging these "water delivering" 
items, we need to separate the physical aspect from the quality of water 
provided.

Physical aspect would be : water_wells, drinking_foutains --> good for the user 
to know if he can easily drink or fill a bottle or connect a hose etc..

Quality of water would be : drinking_water=yes/no; mineral_water=yes/no


De : Selfish Seahorse 
Envoyé : mercredi 10 janvier 2018 09:38:00
À : Tag discussion, strategy and related tools
Objet : Re: [Tagging] Water source types

On 10 January 2018 at 01:49, Daniel Koć  wrote:
> I would say that amenity=drinking_water is a general source of the high
> quality water and it would be good to make it more specific if possible -
> adding tap, well and pump tags would be nice.

Because drinking water is a *property* of sources, water wells,
fountains, drinking fountains (bubblers) etc., I think it makes more
sense to tag these objects and to add drinking_water=yes tags
(discouraging the use of `amenity=drinking_water`).

As for the rendering, I like how OsmAnd renders drinking_water=yes/no:
with a drop overlay that is blue for drinking_water=yes [^1] and grey
for drinking_water=no [^2].

[^1]: 
https://github.com/osmandapp/OsmAnd-resources/blob/master/icons/svg/overlays/drinking_water_yes.svg
[^2]: 
https://github.com/osmandapp/OsmAnd-resources/blob/master/icons/svg/overlays/drinking_water_no.svg

___
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] Water source types

[Selfish Seahorse]

On 10 January 2018 at 01:49, Daniel Koć  wrote:
> I would say that amenity=drinking_water is a general source of the high
> quality water and it would be good to make it more specific if possible -
> adding tap, well and pump tags would be nice.

Because drinking water is a *property* of sources, water wells,
fountains, drinking fountains (bubblers) etc., I think it makes more
sense to tag these objects and to add drinking_water=yes tags
(discouraging the use of `amenity=drinking_water`).

As for the rendering, I like how OsmAnd renders drinking_water=yes/no:
with a drop overlay that is blue for drinking_water=yes [^1] and grey
for drinking_water=no [^2].

[^1]: 
https://github.com/osmandapp/OsmAnd-resources/blob/master/icons/svg/overlays/drinking_water_yes.svg
[^2]: 
https://github.com/osmandapp/OsmAnd-resources/blob/master/icons/svg/overlays/drinking_water_no.svg

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

Re: [Tagging] What is the unit of seamark:light:range?

[Andrew Davidson]

On 10/01/18 17:50, Jo wrote:
They all seem to be in international nautical miles. 

How do you know if there are no units?

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