Re: [Tagging] Stormwater outlet into stream

[Warin]

On 20/09/18 11:26, EthnicFood IsGreat wrote:



Message: 3
Date: Wed, 19 Sep 2018 17:32:54 +1000
From: Jonathon Rossi 
To: "Tag discussion, strategy and related tools"

Subject: Re: [Tagging] Stormwater outlet into stream
Message-ID:

Content-Type: text/plain; charset="utf-8"

Thanks Graeme.



I did this:
https://www.openstreetmap.org/node/5213660838#map=19/-28.07783/153.42664 


for one stormwater drain nearby.


I don't quite understand the way extending to the north in your example
tagged just man_made=yes and surface=grass, is that the underground pipe
joining to the rest of the network?

Would that work for your purposes?
Regarding the node on the end, yes I think it should work. I always 
viewed
man_made=pipeline for legit big pressurised pipelines but I can't see 
any

harm using it for stormwater drains especially that some get really big.

man_made=pipeline
location=underground
substance=rainwater

The wiki page says man_made=pipeline shouldn't be applied to nodes but
there are already nearly 4000 so that can change, or if I have a decent
idea which way the underground pipes go (easy for the big ones) just 
map a

short way.

Thinking about how this would apply to other waterways I've mapped, I
currently map the streams or drains that pass under roads which 
rainwater

passes through like below, these are quite similar but with a completely
different tagging scheme.

waterway=drain or stream
tunnel=culvert
layer=-1

Do we use waterway=* where it is a naturally occurring stream but humans
earthfilled the location with a concrete culvert and put a road over the
top but that is still part of the earth's waterways of the creek system.
Can't be true because waterway=drain is for man made waterways.

This tagging also appears valid for a big stormwater drain where you can
walk into it:

waterway=drain
tunnel=flooded
location=underground
(https://wiki.openstreetmap.org/wiki/Tag:tunnel%3Dflooded)

Unfortunately it doesn't render in any way, so there's nothing 
showing on

the map to indicate that there's anything there, until you go into edit
mode :-(


I'm not too worried about rendering. In the past I've left a note on the
first node because these drain outlets usually can't be seen from aerial
imagery and many times the creek directly where it pours doesn't even 
look

like a creek from aerial imagery, so the intention was to capture the
information to ensure armchair mappers don't "fix" the creek.

As usual each time I post on the mailing list it opens a can of worms 
and I

learn too much about all the different possible tags :).
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openstreetmap.org/pipermail/tagging/attachments/20180919/43b9cc74/attachment-0001.html>


--



I think what you are mapping would more properly be called a storm 
sewer, not a pipeline.  I think of a pipeline as carrying contents 
under pressure, whereas a storm sewer is gravity-fed.  Therefore I 
think a better tag would be man_made=sewer.


There are differences between drinking water, storm water and sewer water!
You do not want sewer water discharging directly into a local river, 
where as storm water is much more acceptable.
Please don't mix the terms as has been done above, 'storm sewer' is not 
a term that should be used.


If a pipeline is pressured or not makes little difference to the pipe. 
If you want you can specify the pressure in the pipeline using the tag 
pressure=* .. the wiki says to use bar .. so pressure=1 would be about 
atmospheric pressure i.e. not pressurised.




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

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Warin]

On 20/09/18 09:26, Tom Pfeifer wrote:

On 19.09.2018 19:31, Jonathon McClung wrote:
The issue is mostly with how the current standard (as stated here 
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dtoll_booth 
) impacts 
routing. This is said on the proposal page here "Many current routing 
softwares add a delay to trip time when encountering the tag barrier 
=toll_booth 
. 
However, the delay on these more modern toll collection systems is 
significantly less; not requiring the driver to stop in most cases. 
In effect, this means that many drivers will be routed onto a slower 
route.” This is the major difference. Of course the way itself should 
be tagged toll=yes. This is a clean way to a) show where the toll 
begins and b) give the routing software something to account for on 
the way.


First, how much of a delay is added by the routing engines, have you 
investigated this? If so, this would be a few seconds once-per trip, 
not every 500m like a traffic light. Thus the difference on the 
calculated overall travel time would be insignificant.
An old toll both was where I'd have to stop, dig out some money, hand it 
over, wait for any change, then I could go on. 30 seconds to 1 minute 
unless I drop the money.
I think these are all gone now on highways and bridges. They still exist 
and are in use for some National Park entries, possibly some parking 
places.




Second, the problems described would be more easily and more elegantly 
solved with subtagging the existing barrier=toll_booth, instead of 
inventing a new first level tag. Subtagging preserves backward 
compatibility, while a new tag has to be implemented everywhere,


But a toll gantry has no stopping, nor slowing down. A very different 
beast, with the ones around here the vehicle is meant to have an 
electronic device that the toll thing responds with and the payment is 
deducted automatically. If you don't have one of these electronic do 
dads then you get a letter .. with a higher fee. Don't know that "toll 
both" is how they should be tagged from a human conceptual view point 
rather than the practical computing one.


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

Re: [Tagging] landuse for government offices ?

[John Willis]

> On Sep 20, 2018, at 1:04 PM, Joseph Eisenberg  
> wrote:
> 
> Would you be willing to revive the proposal and get it voted? 

SelfishSeahorse asked me if he could take over the proposal, and I agreed. 

There is not much else I can offer other than what I typed in the proposal, 
though a few years of writing practice would probably let me rewrite it better. 

I left OSM mapping because of a change in schedule and internet access, but 
another change brought me back a few months ago. 

But I decided just to work on repairing the mapping of cycling roads, river 
channels/levees, and other’s horrible farmland mapping here in Japan. 

There is not many missing or incomplete tagging systems for those features, so 
I have few complaints.

I use civic_admin already in tagging, and will continue to do so. 

I thought I’d throw in my 2 cents in the mailing list for old time’s sake, and 
please sign my name as a yes vote when the proposal comes due (i might miss 
it). 

Good luck to you all. 

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

Re: [Tagging] Stormwater outlet into stream

[Paul Johnson]

On Wed, Sep 19, 2018 at 5:08 PM Graeme Fitzpatrick 
wrote:

> Thinking about how this would apply to other waterways I've mapped, I
>> currently map the streams or drains that pass under roads which rainwater
>> passes through like below, these are quite similar but with a completely
>> different tagging scheme.
>>
>> waterway=drain or stream
>> tunnel=culvert
>> layer=-1
>>
>> Do we use waterway=* where it is a naturally occurring stream but humans
>> earthfilled the location with a concrete culvert and put a road over the
>> top but that is still part of the earth's waterways of the creek system.
>> Can't be true because waterway=drain is for man made waterways.
>>
>
> That's the way I've always done it as well! To my mind, a stream running
> through a culvert is still a natural waterway that we've put a lid over -
> if it was a man-made dug out channel, that would make it a drain.
>

I generally consider a drain to be basically a man-made drainage ditch,
otherwise a lot of creeks in the Tulsa Area and...really the entire length
of the Los Angeles River, would be a drain, even though they're basically
natural streams with concrete-fortified banks.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landuse for government offices ?

[Joseph Eisenberg]

Would you be willing to revive the proposal and get it voted?

Once it is approved we can make a real wiki page for landuse=civic_admin
and ask JOSM / ID folks about including it in presets.

I agree that it is needed


On Thu, Sep 20, 2018 at 11:59 AM John Willis  wrote:

>
>
> On Sep 20, 2018, at 9:40 AM, Joseph Eisenberg 
> wrote:
>
> It’s not necessary to have a separate landuse area if the government
> office is in a single building or shop. In that case  the overarching
> “landuse” is still retail or commercial.
>
>
> Do they sell "legislation" at a town hall? Does the DMV "conduct
> commerce"? Nope. Retail is always wrong. Commercial is a crutch.
>
> As for not needing an area polygon, I disagree. People mapping in a
> detailed way will want a point, a building, and an area. There are areas
> are available for many landuses, but not civic.
>
> https://www.openstreetmap.org/#map=17/36.31039/139.35191
>
> Here is a convenience store I mapped. It is surrounded by fields, a
> restaurant, Civic buildings and surge resivoir.
>
> It is a single building on a single landuse, similar to the restaurant,
> the police station, fire station, and rice fields.
>
> Because it is a single use area - it doesn't need an area tag to encompass
> it's parking lots? Fences? Driveways? I think it does.
>
> The same is true with any Civic building.
>
> Even a single shop or a single single city hall building can and
> (eventually) should be mapped with such details, just as we would map
> commercial, industrial, and retail buildings. Point - building - area.
> Maybe the point is merged with the building or the area, but building *and*
> area are necessary in all but the most urban of environments.
>
> This is why I proposed land use=Civic, later revised to
> landuse=civic_admin.
>
> If a town hall or government office is a single building, you could just
> map the building and drop a pin on it.
>
> But if you wanted to map the extent of the land, using commercial or
> retail (imo) is *never* acceptable. It is not for commerce nor selling
> goods. We don't use landuse=retail for a hospital or a park for similar
> reasons.
>
> I wholeheartedly believe the decision to use commercial for Civic
> buildings was wrong, and came from an adversity to making enough new
> landuse values at the start. I want to correct that.
>
> I would like all landuse=Foo and building=foo to be similar, and be
> obvious what to use with new mappers. Industrial buildings are mapped on an
> industrial landuse. Building=Civic is mapped on... Commercial? Ugh.
>
> Landuse=civic_admin not only allows the proper mapping of stand-alone
> offices, but is the *only* way to proper way to map Civic complexes of
> multiple buildings with unique names.
>
> It is useful for both stand-alone buildings or multi-building complexes:
> there are always parking lots, walkways, and other amenities that "belong"
> to the point/building, yet are outside the building's footprint. An area
> polygon is the only way to map them, and landuse=* is the most versitille
> and consistent tag key to do it with.
>
> Javbw.
> ___
> 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] Stormwater outlet into stream

[Jonathon Rossi]

Thanks everyone. Apologies in advance for the long reply.

@Graeme I see you tagged the node with
man_made=drain_outlet+substance=rainwater. In your example it makes sense
to map the underground pipe because you know exactly where it is, but I'd
hate for these to start rendering in the future and bits of incomplete
pipes (a few metres long) start showing up drawing over streets.

The wiki for man_made=pipeline
 says it is
meant for "major" pipelines, which these aren't really apply:

By using pipeline are we abusing that tag? Dictionary.com's definition of
pipeline also indicates that a network of pipes isn't a pipeline. I too
don't view the reticulated water network of pipes a pipeline, however there
would generally be a pipeline going from a water treatment plant to a water
reservoir/storage tank; and in the same way the network of sewerage drains
aren't a pipeline, but you could have a pressurised or gravity pipeline to
move sewage to a treatment plant.

Mark's suggestion to use man_made=sewer didn't sound right to me because I
always view sewers as for wastewater which must go to a treatment plant
before entering waterways. Dictionary.com seems to agree, the values for
manhole=*  also agree, this
OSM tagging proposal also agrees
,
however Wikipedia seems to indicate some people refer to stormwater drains
as sewers too, this might be a location thing because I found some
indication that some cities have a combined waste and rain water drain
(these obviously won't directly connect to a waterway).
substance=rainwater;sewage works though.

There is 158 uses of man_made=storm_drain (99% of them on nodes), and most
in North Lakes (just north of Brisbane, Australia), however they've used
that tag rather than manhole=drain. It isn't exactly wrong that they used
that tag on the surface grate because the drain is technically there too,
just as it is at the outlet. (Off topic: but that residential estate is so
well mapped; every tree, lightpole, drain, kerb, driveway, bit of grass all
mapped, looks so great rendered!
https://www.openstreetmap.org/#map=18/-27.21343/153.02634).

I think there is no need to use man_made=drain_outlet because the outlet is
just part of the drain (the smaller ones generally have no extra concrete
to hold earth back), so just use man_made=drain on the node or map a way
(which can join to the waterway=*), however I'd use manhole=drain for
grates on the road surface because they also act as manholes providing
access into the drain. I know some of the large stormwater drains also have
barriers  inside to prevent humans entering, they could be mapped as nodes
on the way too.

I've mapped pump stations for the reticulated water network before (because
they are usually small buildings or fenced off equipment on the surface)
but not the underground pipes, I do see value in mapping the pipelines
especially when they are visible (e.g. passing next to a bridge over a
creek) but wouldn't map the underground network around streets as you'd
have no idea where it went.

If I went with man_made=drain, at what point would one of those drains be
big enough to be a man_made=pipeline? Is a big drain flowing into a big
river (e.g. Brisbane River) that you could stand up inside a pipeline?
Maybe yes, maybe no.

Is a pipeline for delivering a substance, while a drain for taking a
substance away? Is that a distinction that even needs to be made?

On Thu, Sep 20, 2018 at 8:04 AM Graeme Fitzpatrick 
wrote:

>
> Thanks Tijmin & Andrew - name deleted! :-) Thought it should have
> something to explain the open space between 2 houses:
> https://www.google.com/maps/@-28.0775238,153.4261968,3a,75y,192.84h,72.02t/data=!3m6!1e1!3m4!1spFpy3s9A1cXKkiPow16w2Q!2e0!7i13312!8i6656,
> but having now read the "No name" policy can see that's wrong. Have also
> changed the node & pipeline details.
>
> On Wed, 19 Sep 2018 at 17:34, Jonathon Rossi  wrote:
>
>> I don't quite understand the way extending to the north in your example
>> tagged just man_made=yes and surface=grass, is that the underground pipe
>> joining to the rest of the network?
>>
>
> That's it - there's a surface drain & manholes on the street, with the
> visible pipe going into the lake, so I marked the pipeline in back to the
> street. As above, I've ow changed the tagging so that the pipeline is
> marked through the easement, with an outlet at the lake edge.
>
>
>> Thinking about how this would apply to other waterways I've mapped, I
>> currently map the streams or drains that pass under roads which rainwater
>> passes through like below, these are quite similar but with a completely
>> different tagging scheme.
>>
>> waterway=drain or stream
>> tunnel=culvert
>> layer=-1
>>
>> Do we use waterway=* where it is a naturally occurring stream but humans
>> earthfilled the location with a 

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

[Paul Johnson]

On Wed, Sep 19, 2018 at 9:31 PM Tod Fitch  wrote:

>
> > On Sep 19, 2018, at 6:59 PM, Paul Johnson  wrote:
> >
> >
> > An example of an interstate I would call trunk would be I 70 between I
> 68 and I 76, given that those two are the two closest junctions.  Motorways
> should terminate at an interchange with another motorway, not an at-grade
> intersection…
>
> A number of freeways in California would fail that test. Off the top of my
> head, I-280 terminating onto King Street in San Francisco [1]. US-101
> terminating on to Market [2] (actually 101 peels off a bit earlier to go up
> Van Ness). California 55 in Costa Mesa [3]. The western terminus of I-10 in
> Santa Monica [4]. I am sure there are a lot more those are just the few
> that I am familiar with that come to mind.


I 19 in Arizona south of Grand Avenue (AZ 82? going from memory here) as
well...terminates in a traffic light followed immediately by the Mexican
border.  Along the same lines, I 5 south of I 805 (border crossing,
abruptly dumps on to...either a huge boulevard or a trunk if memory serves)
and I 5 north of WA 543 (closed to trucks, left-side bike lanes added (and
thus bicycle traffic merging across the entire carriageway), goes into a
park, then hits a border crossing; mirrored on the other side with BC 99
south of 8 Ave in White Rock BC).  Let's face it, in practice, there's no
such thing as something we recognize as a freeway that crosses an
international border with the continental US since early last decade when
the borders closed to Canada, and it's unlikely anything like that will
exist until the borders reopen.  Tagging a motorway through these crossings
is aspirational at best.  (Also makes for some interesting flubs, like
Alberta Trunk 75 now connecting to I 29 instead of US 75, the old Trunk 75
is now an abandoned spur off Alberta 200 that meets *temporary barricade* that
seperates it from US 75 (which now functionally dead ends instead of
continuing into the abandoned Canadian Customs station; I don't recall the
US side even having a customs checkpoint).

I'm very strongly in favor of trunking these non-freeway Interstates, doing
so would enable data consumers to more precisely warn of a substantial
break from what people (rightfully) expect in a freeway.  Also reflects
real world scenario that, despite how overall as a network, how consistent
the Interstate system is, there are the occasional abrupt exceptions to
this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Paul Johnson]

On Wed, Sep 19, 2018 at 5:15 PM Tobias Zwick  wrote:

>   a) source:maxspeed is still quite simple to use because a 1:1
>  mapping is possible, e.g. source:maxspeed=DE:urban -> maxspeed=50
>  In other words, it's a good start for getting away from explicitly
>  tagged speed limits and is a product of the circumstances


A good first step, but I don't think explicitly tagging maxspeed is really
going to go away just from a feasibility standpoint.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landuse for government offices ?

[John Willis]

> On Sep 20, 2018, at 9:40 AM, Joseph Eisenberg  
> wrote:
> 
> It’s not necessary to have a separate landuse area if the government office 
> is in a single building or shop. In that case  the overarching “landuse” is 
> still retail or commercial.

Do they sell "legislation" at a town hall? Does the DMV "conduct commerce"? 
Nope. Retail is always wrong. Commercial is a crutch. 

As for not needing an area polygon, I disagree. People mapping in a detailed 
way will want a point, a building, and an area. There are areas are available 
for many landuses, but not civic. 

https://www.openstreetmap.org/#map=17/36.31039/139.35191

Here is a convenience store I mapped. It is surrounded by fields, a restaurant, 
Civic buildings and surge resivoir. 

It is a single building on a single landuse, similar to the restaurant, the 
police station, fire station, and rice fields.  

Because it is a single use area - it doesn't need an area tag to encompass it's 
parking lots? Fences? Driveways? I think it does. 

The same is true with any Civic building. 

Even a single shop or a single single city hall building can and (eventually) 
should be mapped with such details, just as we would map commercial, 
industrial, and retail buildings. Point - building - area. Maybe the point is 
merged with the building or the area, but building *and* area are necessary in 
all but the most urban of environments. 

This is why I proposed land use=Civic, later revised to landuse=civic_admin. 

If a town hall or government office is a single building, you could just map 
the building and drop a pin on it. 

But if you wanted to map the extent of the land, using commercial or retail 
(imo) is *never* acceptable. It is not for commerce nor selling goods. We don't 
use landuse=retail for a hospital or a park for similar reasons. 

I wholeheartedly believe the decision to use commercial for Civic buildings was 
wrong, and came from an adversity to making enough new landuse values at the 
start. I want to correct that. 

I would like all landuse=Foo and building=foo to be similar, and be obvious 
what to use with new mappers. Industrial buildings are mapped on an industrial 
landuse. Building=Civic is mapped on... Commercial? Ugh. 

Landuse=civic_admin not only allows the proper mapping of stand-alone offices, 
but is the *only* way to proper way to map Civic complexes of multiple 
buildings with unique names. 

It is useful for both stand-alone buildings or multi-building complexes: there 
are always parking lots, walkways, and other amenities that "belong" to the 
point/building, yet are outside the building's footprint. An area polygon is 
the only way to map them, and landuse=* is the most versitille and consistent 
tag key to do it with.

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

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

[Tod Fitch]

> On Sep 19, 2018, at 6:59 PM, Paul Johnson  wrote:
> 
> 
> An example of an interstate I would call trunk would be I 70 between I 68 and 
> I 76, given that those two are the two closest junctions.  Motorways should 
> terminate at an interchange with another motorway, not an at-grade 
> intersection…

A number of freeways in California would fail that test. Off the top of my 
head, I-280 terminating onto King Street in San Francisco [1]. US-101 
terminating on to Market [2] (actually 101 peels off a bit earlier to go up Van 
Ness). California 55 in Costa Mesa [3]. The western terminus of I-10 in Santa 
Monica [4]. I am sure there are a lot more those are just the few that I am 
familiar with that come to mind.

Cheers!


[1] https://www.openstreetmap.org/#map=18/37.77413/-122.39631
[2] https://www.openstreetmap.org/#map=17/37.77180/-122.42270
[3] https://www.openstreetmap.org/#map=16/33.6439/-117.9146
[4] https://www.openstreetmap.org/#map=16/34.0121/-118.4946


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Paul Johnson]

On Wed, Sep 19, 2018 at 4:51 PM Joseph Eisenberg 
wrote:

>
>
>  Kevin Kenny:
>
>>
>> Not all Interstates *ought* to be tagged as motorways. A case in point
>> is Interstate 93 in Franconia Notch, New Hampshire, which *ought*
>> to be a trunk (it's a two-lane road with a centre guard rail that was
>> added
>> long after the initial construction.)
>>
>
> Amazing! I thought all of the Interstates had been fully converted to
> controlled-access divided motorways. All of the Interstates west of the
> Mississippi seem to be motorways.
>
> But 20 years ago I-5 still had a few uncontrolled intersections in the
> rural mountains of N California.
>

Still has traffic lights and a draw bridge at Washington mile 0, and the
first interchange is sharp enough it probably should have a stop sign or
traffic light itself.  Seen quite a few trucks almost tip trying to make it
off the north approach onto exit 1A for WA 14 East (and the speed limit's
only 50 MPH).  And going south, my very last commute out of Fort Vancouver
was delayed by hours because I stopped for the traffic light, the crash
barriers came down for the draw bridge, and some guy not paying attention
flew past me at the stop line and ran out almost to the crash barrier
before slamming on the brakes, and hit it hard enough to keep the crash
barriers stuck in the fully down position...I've leaned to calling that
motorway anyway.

However, a more obvious "should be a trunk" would be WA 500 between I 5 and
4th Plain Boulevard.
https://www.openstreetmap.org/#map=14/45.6532/-122.6175  I don't
realistically think any part of this deserves the motorway tag at all given
that it ends on a traffic light and it's got two more traffic lights in
between...like almost half of the junctions on it are at-grade and
controlled by traffic signals.  Every time someone fixes it, someone else
goes through and breaks it back to motorway again.

An example of an interstate I would call trunk would be I 70 between I 68
and I 76, given that those two are the two closest junctions.  Motorways
should terminate at an interchange with another motorway, not an at-grade
intersection...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Free drinking water by private entities

[Joseph Eisenberg]

I see that the suggestions about "free refills" are included here because
there was some confusion about the use of "free_refill=yes" in central
Europe. The English word "refill" implies that it is the second time
something has been filled. Thus a customer may request that their glass be
filled again with the same beverage.

I'd suggest a separate proposal page to discuss the free_refill=yes tag.

In North America, free beverage refills are limited to "soft drinks" (aka
fizzy drinks / pop / soda / cola depending on dialect), tea and brewed
coffee. Alcoholic beverages, espresso and specialty coffee drinks, and
other specialty beverage are usually excluded. I don't recall every seeing
free refills of lemonade or fruit juice.

So it would be sufficient to have free_refill=coffee/tea/soft_drink/yes/no
free_refill=yes would imply that all customers can get free refills on
coffee, tea and soft drinks, if all are offered. Or at a cafe that only
serves coffee and tea, free_refill=yes would mean free refills on coffee
and tea (since soft drinks are not available)

Some places only offer refills for free on one category. For example, a
cafe or "diner" may only offer free refills of brewed coffee, while a fast
food restaurant often offers free refills of "soft drinks" but not coffee.
In this case the specific free_refill=coffee or free_refill=soft_drink
would be used.

I don't think it is necessary to use a more complicated namespaced tag,
such as free_refill:coffee=yes, though that could be an alternative.

On Thu, Sep 20, 2018 at 10:00 AM Joseph Eisenberg <
joseph.eisenb...@gmail.com> wrote:

> I’d suggest keeping it simple by using existing tags when possible.
>
> If a cafe or shop gives out free water for customers, tag the shop or cafe
> with “drinking_water=customers”. If it’s for anyone, “drinking_water=yes”
> is currently used. I don’t see a need for a new tag “drinking_water=ask”
>
> If there is a drinking fountain, water tap or bottle refill station in a
> shopping mall or building that has opening_hours, just use
> amenity=drinking_water plus opening_hours=* on the node. Man_made=water_tap
> or =drinking_fountain or =water_well can also be added to the same node for
> more detail.
>
> I believe amenity=drinking_water implies no fee, and public access, so
> these characteristics do not require explicit tagging
>
>
>
> On Wed, Sep 19, 2018 at 8:57 PM bkil  wrote:
>
>> I'd like to discuss three related proposals and two separate ones that
>> can be confused with the others. In all the below cases, the
>> availability is tied to the opening_hours of the containing POI.
>>
>> Five separate proposals could have been created, but I feel that the
>> concepts and words describe these are so close, it is best to have a
>> good overview.
>>
>> I'm open to suggestions both related to the tags themselves and how we
>> should structure and document this proposal in the wiki.
>>
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Free_drinking_water_by_private_entities
>>
>> ___
>> 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] Stormwater outlet into stream

[EthnicFood IsGreat]

Message: 1
Date: Wed, 19 Sep 2018 16:15:37 +1000
From: Graeme Fitzpatrick 
To: OSM Tag 
Subject: Re: [Tagging] Stormwater outlet into stream
Message-ID:

Content-Type: text/plain; charset="utf-8"

On Wed, 19 Sep 2018 at 13:04, Jonathon Rossi  wrote:


I've come across the desire to map a stormwater outlet at the beginning of
a stream a few times now and have failed to find an appropriate tag to
place on the node.


Hi Jono

I did this:
https://www.openstreetmap.org/node/5213660838#map=19/-28.07783/153.42664
for one stormwater drain nearby.

Would that work for your purposes?

Unfortunately it doesn't render in any way, so there's nothing showing on
the map to indicate that there's anything there, until you go into edit
mode :-(

Thanks

Graeme
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openstreetmap.org/pipermail/tagging/attachments/20180919/77e0bdeb/attachment-0001.html>

--

Message: 2
Date: Wed, 19 Sep 2018 17:04:12 +1000
From: Andrew Harvey 
To: "Tag discussion, strategy and related tools"

Subject: Re: [Tagging] Stormwater outlet into stream
Message-ID:

Content-Type: text/plain; charset="UTF-8"

I agree with https://www.openstreetmap.org/node/5213660838

location=underground
man_made=pipeline
substance=rainwater

I think it's okay to place this on a node if you don't know the
location the pipeline goes underground, even if the tags were meant
for ways.

Personally I would just add a way a few meters long to the end of the
stream and tag that, instead of a node.

But I'd omit the name unless it has one, "Stormwater easement" is more
a description than a name.
On Wed, 19 Sep 2018 at 16:16, Graeme Fitzpatrick  wrote:



On Wed, 19 Sep 2018 at 13:04, Jonathon Rossi  wrote:

I've come across the desire to map a stormwater outlet at the beginning of a 
stream a few times now and have failed to find an appropriate tag to place on 
the node.


Hi Jono

I did this: 
https://www.openstreetmap.org/node/5213660838#map=19/-28.07783/153.42664 for 
one stormwater drain nearby.

Would that work for your purposes?

Unfortunately it doesn't render in any way, so there's nothing showing on the 
map to indicate that there's anything there, until you go into edit mode :-(

Thanks

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



--

Message: 3
Date: Wed, 19 Sep 2018 17:32:54 +1000
From: Jonathon Rossi 
To: "Tag discussion, strategy and related tools"

Subject: Re: [Tagging] Stormwater outlet into stream
Message-ID:

Content-Type: text/plain; charset="utf-8"

Thanks Graeme.



I did this:
https://www.openstreetmap.org/node/5213660838#map=19/-28.07783/153.42664
for one stormwater drain nearby.


I don't quite understand the way extending to the north in your example
tagged just man_made=yes and surface=grass, is that the underground pipe
joining to the rest of the network?

Would that work for your purposes?
Regarding the node on the end, yes I think it should work. I always viewed
man_made=pipeline for legit big pressurised pipelines but I can't see any
harm using it for stormwater drains especially that some get really big.

man_made=pipeline
location=underground
substance=rainwater

The wiki page says man_made=pipeline shouldn't be applied to nodes but
there are already nearly 4000 so that can change, or if I have a decent
idea which way the underground pipes go (easy for the big ones) just map a
short way.

Thinking about how this would apply to other waterways I've mapped, I
currently map the streams or drains that pass under roads which rainwater
passes through like below, these are quite similar but with a completely
different tagging scheme.

waterway=drain or stream
tunnel=culvert
layer=-1

Do we use waterway=* where it is a naturally occurring stream but humans
earthfilled the location with a concrete culvert and put a road over the
top but that is still part of the earth's waterways of the creek system.
Can't be true because waterway=drain is for man made waterways.

This tagging also appears valid for a big stormwater drain where you can
walk into it:

waterway=drain
tunnel=flooded
location=underground
(https://wiki.openstreetmap.org/wiki/Tag:tunnel%3Dflooded)

Unfortunately it doesn't render in any way, so there's nothing showing on

the map to indicate that there's anything there, until you go into edit
mode :-(


I'm not too worried about rendering. In the past I've left a note on the
first node because these drain outlets usually can't be seen from aerial
imagery and many times the creek directly where it pours doesn't even look
like a creek from aerial imagery, so the intention was to capture the
information to ensure armchair mappers don't "fix" the creek.

As usual each time I

Re: [Tagging] Feature Proposal - RFC - Free drinking water by private entities

[Joseph Eisenberg]

I’d suggest keeping it simple by using existing tags when possible.

If a cafe or shop gives out free water for customers, tag the shop or cafe
with “drinking_water=customers”. If it’s for anyone, “drinking_water=yes”
is currently used. I don’t see a need for a new tag “drinking_water=ask”

If there is a drinking fountain, water tap or bottle refill station in a
shopping mall or building that has opening_hours, just use
amenity=drinking_water plus opening_hours=* on the node. Man_made=water_tap
or =drinking_fountain or =water_well can also be added to the same node for
more detail.

I believe amenity=drinking_water implies no fee, and public access, so
these characteristics do not require explicit tagging



On Wed, Sep 19, 2018 at 8:57 PM bkil  wrote:

> I'd like to discuss three related proposals and two separate ones that
> can be confused with the others. In all the below cases, the
> availability is tied to the opening_hours of the containing POI.
>
> Five separate proposals could have been created, but I feel that the
> concepts and words describe these are so close, it is best to have a
> good overview.
>
> I'm open to suggestions both related to the tags themselves and how we
> should structure and document this proposal in the wiki.
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Free_drinking_water_by_private_entities
>
> ___
> 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] landuse for government offices ?

[Joseph Eisenberg]

It’s not necessary to have a separate landuse area if the government office
is in a single building or shop. In that case  the overarching “landuse” is
still retail or commercial.

The new landuse=civic_admin is useful when there are multiple buildings and
government offices in a larger area, such as a city block or multiple
blocks. This situation is quite common in American, Latin American and
Asian towns.

Landuse=commercial plus a subtag if commercial=civic or =government is also
possible, but civic doesn’t seem to be a subcategory of “commercial” in the
sense of economic function, even if the buildings are similar

Joseph

On Thu, Sep 20, 2018 at 7:22 AM Graeme Fitzpatrick 
wrote:

> How about when your Govt office is a single "shop" in a retail area? eg
> https://www.openstreetmap.org/node/4221669587, which is a at the end of a
> shopping mall https://www.openstreetmap.org/way/235773662
>
> Should we leave it as a shop, or re-tag that end of the retail building as
> civic_admin?
>
> Thanks
>
> Graeme
> ___
> 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] Feature Proposal - Voting - Toll Gantry

[Tom Pfeifer]

On 19.09.2018 19:31, Jonathon McClung wrote:
The issue is mostly with how the current standard (as stated here 
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dtoll_booth 
) impacts routing. This is said on the 
proposal page here "Many current routing softwares add a delay to trip time when encountering the 
tag barrier =toll_booth 
. However, the delay on these more 
modern toll collection systems is significantly less; not requiring the driver to stop in most 
cases. In effect, this means that many drivers will be routed onto a slower route.” This is the 
major difference. Of course the way itself should be tagged toll=yes. This is a clean way to a) show 
where the toll begins and b) give the routing software something to account for on the way.


First, how much of a delay is added by the routing engines, have you investigated this? If so, this 
would be a few seconds once-per trip, not every 500m like a traffic light. Thus the difference on 
the calculated overall travel time would be insignificant.


Second, the problems described would be more easily and more elegantly solved with subtagging the 
existing barrier=toll_booth, instead of inventing a new first level tag. Subtagging preserves 
backward compatibility, while a new tag has to be implemented everywhere,


tom

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

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Graeme Fitzpatrick]

On Thu, 20 Sep 2018 at 09:04, Daniel McCormick 
wrote:

>
> That is an interesting case of a toll gantry being on the bridge. I fear
> though that adding that to the bridge that goes over the tolled highway
> might cause there to be some confusion concerning which road is actually
> tolled. This is easily worked around though by just adding a node to the
> tolled road very close to the bridge. This solution would be much cleaner
> then previous version of polygon toll gantries and is minimally invasive to
> the data.
>

Makes sense, thanks Daniel!

Thanks

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

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Daniel McCormick]

That is an interesting case of a toll gantry being on the bridge. I fear though 
that adding that to the bridge that goes over the tolled highway might cause 
there to be some confusion concerning which road is actually tolled. This is 
easily worked around though by just adding a node to the tolled road very close 
to the bridge. This solution would be much cleaner then previous version of 
polygon toll gantries and is minimally invasive to the data.


> On Sep 19, 2018, at 4:40 PM, tagging-requ...@openstreetmap.org wrote:
> 
> Re: [Tagging] Feature Proposal - Voting - Toll Gantry

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

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Graeme Fitzpatrick]

On Thu, 20 Sep 2018 at 07:24, Jonathon McClung 
wrote:

Jonathon

Good idea!

One question though

>  We are talking about the increasingly common worldwide appearance of the
> toll gantries on their own. Example pictures can be found here
> 
> .
>

We have a couple of spots where, in one case toll "readers" & in the other
speed cameras are mounted on a bridge crossing the highway eg
https://www.google.com/maps/@-27.95082,153.3420894,3a,75y,164.49h,101.6t/data=!3m5!1e1!3m3!1setsoRfXvi_MJ52Ao30hKMA!2e0!6s%2F%2Fgeo3.ggpht.com%2Fcbk%3Fpanoid%3DetsoRfXvi_MJ52Ao30hKMA%26output%3Dthumbnail%26cb_client%3Dmaps_sv.tactile.gps%26thumb%3D2%26w%3D203%26h%3D100%26yaw%3D100.4385%26pitch%3D0%26thumbfov%3D100

Could you gantry concept also be included on the existing bridge tags?

Thanks

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

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

[Tobias Zwick]

See https://github.com/westnordost/countryboundaries

It's per node. Size and supported admin levels depend on the data you
stick in there. (Also, the faster the access should be, the bigger the
file.)

The default data is a geoJson file from the JOSM project which has all
the countries, and states only for the United States, Canada, Australia,
China and India and is about 1MB.

> I imagine the same calculation could be used for other default
> calculations, like the default language format,

Here is a list of official languages by country iso code:
https://github.com/westnordost/StreetComplete/blob/master/res/country_metadata/officialLanguages.yml

Cheers
Tobias

On 20/09/2018 00:07, Joseph Eisenberg wrote:
> I’m encouraged by this:
> 
> 
> >”3. removes superfluous country ISO-code. Country boundaries
> information
>    is already available in the OSM > database, data users can just use a
>    (reverse) geocoder to find where a street is.
>    (I wrote Java library recently that does this offline in ~0.1ms)”
> 
> 
> Does this offline reverse geo coding calculation require downloading the
> global admin_level=2 boundary data? Is it a reasonable amount of data?
> 
> Does it take 0.1ms per node, or can several highway segments be checked
> in the same calculation?
> 
> I imagine the same calculation could be used for other default
> calculations, like the default language format, 
> 
> Or it could be used to display certain features differently in different
> countries: e.g. don’t use a cross symbol for hospitals in Saudi Arabia.
> 
> For the USA, how quickly can you reverse geocode admin_levels 2, 4, 6
> and 8 for a road? (National, State, County and Municipal) 
> 
> 
> 
> 
> ___
> 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] landuse for government offices ?

[Graeme Fitzpatrick]

How about when your Govt office is a single "shop" in a retail area? eg
https://www.openstreetmap.org/node/4221669587, which is a at the end of a
shopping mall https://www.openstreetmap.org/way/235773662

Should we leave it as a shop, or re-tag that end of the retail building as
civic_admin?

Thanks

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

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

[Tobias Zwick]

> [...] there are already 2 different schemas to fill the same thing,
> why create a 3rd ? wouldn't it be more reasonable to use
> maxspeed:type=default or =unsigned or =nosign for example ?

Also a possibility. I used maxspeed:signed only in the example to make
my point about separating the information. Other possibilities include
maxspeed=implicit, maxspeed=default, maxspeed:default=yes/no.

I have come to accept that there are good reasons why it is difficult to
make progress on this topic:

1. default max speeds are a complicated topic

2. (thus) it is very difficult and requires thorough research to find a
   scheme that is applicable for the whole world and future-proof

3. due to the complexity of inferring maxspeeds, it is very
   inconvenient for data consumers (including QA tools) if no explicit
   maxspeed-value is set

  a) source:maxspeed is still quite simple to use because a 1:1
 mapping is possible, e.g. source:maxspeed=DE:urban -> maxspeed=50
 In other words, it's a good start for getting away from explicitly
 tagged speed limits and is a product of the circumstances

  b) as long as the meta-information for each country necessary to
 infer default speed limits is not freely and easily available
 somewhere in a structured form, data users will likely be very slow
 to adopt a more complex scheme that is applicable worldwide.

I think as maxspeed:type was not able to replace source:maxspeed, so
will any other new scheme as long as it is not applicable to any country.

I started https://wiki.openstreetmap.org/wiki/Default_speed_limits
because of Point 2. Point 3.b) is the reason why I want that table to be
machine-readable and why I also plan to implement a parser for that page
as well as (maybe) a library that implements the rules as given in the
"how to read this table" section.

On 19/09/2018 23:35, marc marc wrote:
> Le 19. 09. 18 à 22:33, Tobias Zwick a écrit :
>> separate the information stored in "source:maxspeed":
>> 
>>
>> 1. Information about whether there is a sign or not (=whether a
>> default speed applies or not)
>>
>>   highway=motorway + maxspeed:signed=no
> 
> I agree with this but there are already 2 different schemas to fill the 
> same thing, why create a 3rd ? wouldn't it be more reasonable to use 
> maxspeed:type=default or =unsigned or =nosign for example ?
> 
>> 3. removes superfluous country ISO-code
> 
> I agree with this point, any preprocessor is able to known that every 
> maxspeed limite in a country is related to the default value of this 
> country.
> 
> that being said, the whole discussion has nothing left with the initial 
> topic: is it not so much to migrate source:maxspeed into maxspeed:type 
> since source:maxspeed is not the source as in the osm sense but the type 
> of panel (or its absence) having effect on the way concerned.
> if it is already so difficult to make progress on this point, I find it 
> difficult to imagine that an even more important change could lead to 
> something other than an additional new scheme and therefore an even 
> greater fragmentation is even more duplicated information
> 
> Regards,
> Marc
> ___
> 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] maxspeed:type vs source:maxspeed // StreetComplete

[Joseph Eisenberg]

>
> I’m encouraged by this:


> >”3. removes superfluous country ISO-code. Country boundaries information
>is already available in the OSM > database, data users can just use a
>(reverse) geocoder to find where a street is.
>(I wrote Java library recently that does this offline in ~0.1ms)”


Does this offline reverse geo coding calculation require downloading the
global admin_level=2 boundary data? Is it a reasonable amount of data?

Does it take 0.1ms per node, or can several highway segments be checked in
the same calculation?

I imagine the same calculation could be used for other default
calculations, like the default language format,

Or it could be used to display certain features differently in different
countries: e.g. don’t use a cross symbol for hospitals in Saudi Arabia.

For the USA, how quickly can you reverse geocode admin_levels 2, 4, 6 and 8
for a road? (National, State, County and Municipal)


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

Re: [Tagging] Stormwater outlet into stream

[Graeme Fitzpatrick]

Thanks Tijmin & Andrew - name deleted! :-) Thought it should have something
to explain the open space between 2 houses:
https://www.google.com/maps/@-28.0775238,153.4261968,3a,75y,192.84h,72.02t/data=!3m6!1e1!3m4!1spFpy3s9A1cXKkiPow16w2Q!2e0!7i13312!8i6656,
but having now read the "No name" policy can see that's wrong. Have also
changed the node & pipeline details.

On Wed, 19 Sep 2018 at 17:34, Jonathon Rossi  wrote:

> I don't quite understand the way extending to the north in your example
> tagged just man_made=yes and surface=grass, is that the underground pipe
> joining to the rest of the network?
>

That's it - there's a surface drain & manholes on the street, with the
visible pipe going into the lake, so I marked the pipeline in back to the
street. As above, I've ow changed the tagging so that the pipeline is
marked through the easement, with an outlet at the lake edge.


> Thinking about how this would apply to other waterways I've mapped, I
> currently map the streams or drains that pass under roads which rainwater
> passes through like below, these are quite similar but with a completely
> different tagging scheme.
>
> waterway=drain or stream
> tunnel=culvert
> layer=-1
>
> Do we use waterway=* where it is a naturally occurring stream but humans
> earthfilled the location with a concrete culvert and put a road over the
> top but that is still part of the earth's waterways of the creek system.
> Can't be true because waterway=drain is for man made waterways.
>

That's the way I've always done it as well! To my mind, a stream running
through a culvert is still a natural waterway that we've put a lid over -
if it was a man-made dug out channel, that would make it a drain.

This tagging also appears valid for a big stormwater drain where you can
> walk into it:
>
> waterway=drain
> tunnel=flooded
>

I'd *strongly* recommend that you don't try walking into tunnels that are
flooded! - you're going to get very wet & the consequences could be bad :-)

As usual each time I post on the mailing list it opens a can of worms and I
> learn too much about all the different possible tags :).
>

Welcome to the Club - at least it's not just me! :-)

Thanks

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

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

[Joseph Eisenberg]

 Kevin Kenny:

>
> Not all Interstates *ought* to be tagged as motorways. A case in point
> is Interstate 93 in Franconia Notch, New Hampshire, which *ought*
> to be a trunk (it's a two-lane road with a centre guard rail that was added
> long after the initial construction.)
>

Amazing! I thought all of the Interstates had been fully converted to
controlled-access divided motorways. All of the Interstates west of the
Mississippi seem to be motorways.

But 20 years ago I-5 still had a few uncontrolled intersections in the
rural mountains of N California.

Does I-93 still have stoplights or intersections without ramps, in NH?

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

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

[marc marc]

Le 19. 09. 18 à 22:33, Tobias Zwick a écrit :
> separate the information stored in "source:maxspeed":
> 
> 
> 1. Information about whether there is a sign or not (=whether a
> default speed applies or not)
> 
>   highway=motorway + maxspeed:signed=no

I agree with this but there are already 2 different schemas to fill the 
same thing, why create a 3rd ? wouldn't it be more reasonable to use 
maxspeed:type=default or =unsigned or =nosign for example ?

> 3. removes superfluous country ISO-code

I agree with this point, any preprocessor is able to known that every 
maxspeed limite in a country is related to the default value of this 
country.

that being said, the whole discussion has nothing left with the initial 
topic: is it not so much to migrate source:maxspeed into maxspeed:type 
since source:maxspeed is not the source as in the osm sense but the type 
of panel (or its absence) having effect on the way concerned.
if it is already so difficult to make progress on this point, I find it 
difficult to imagine that an even more important change could lead to 
something other than an additional new scheme and therefore an even 
greater fragmentation is even more duplicated information

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

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

[Kevin Kenny]

On Wed, Sep 19, 2018 at 4:34 PM Tobias Zwick  wrote:
> 2. US interstate in Montana (US-MT):
>  highway=motorway + source:maxspeed=US-MT:interstate
>vs
>  highway=motorway + maxspeed:signed=no + ref~^I
>(maybe ref-starts-with-"I" is not necessary because all interstates
> are tagged as motorways?)

Not all Interstates *ought* to be tagged as motorways. A case in point
is Interstate 93 in Franconia Notch, New Hampshire, which *ought*
to be a trunk (it's a two-lane road with a centre guard rail that was added
long after the initial construction.)

Many motorways are not Interstates. The local law where I live doesn't
special-case Interstates, but rather uses phrasing like 'multi-lane
grade-separated controlled-access highways'.

But that said, if a piece of legislation says, 'Interstate', then it means
specifically 'Interstate', whether motorway or not, and not other motorways.

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

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Jonathon McClung]

Jérôme,

That email seems to be covering a lot of issues that the proposal is 
not trying solve, nor could it solve without first laying the foundation that 
it attempts to set. I’ll narrow in on the thoughts that are most pertinent. You 
stated; “In fact, this is a problem with software solution not a tag.” This is 
most definitely an issue with the tag and not a software issue. The tag 
barrier=toll_booth is currently not specific. In fact, when it is used in the 
case of a non-barrier electronic toll gantry, it is misleading. In its relation 
to routing software there is currently no standard way to tell the routing 
software that this “toll booth” is not a barrier. The advantage of using the 
key highway is that it is clear that there is no barrier. 
“My 2 cents comment is in relation with toll because i have an rfid 
badge and I don't wait a minute. I just slow down to 30km/h to cross the toll 
booth.” A gantry like this is exactly what we are talking about. The most 
modern ones do not require the driver to slow down at all. We are not trying to 
solve every type of problem, we are trying to establish a base and build off of 
it. 
“For information barrier 
=lift_gate 
 and fee 
=yes 
 can be set on paint and 
barrier=toll_booth <> can be a polygon with intersection on your highway.” It 
is a common, but incorrect process to draw polygons over ways. Most validators 
will alert you to let you know that you should not do this. This solution stays 
within the bounds of best practice.
Another thought you mentioned, "I think it's better solution to set 
toll_booth in highway because it's specific.”  We also examined this option, 
but the difference is that this is not a booth.
The picture you provided helpfully showed us what you are referring to. 
However, it is not what we are referring to. We are talking about the 
increasingly common worldwide appearance of the toll gantries on their own. 
Example pictures can be found here 
. 
The last six sentences of the email seem to be advocating for making 
the process more complicated. I am well aware that the tag gantry was proposed, 
though the page does not indicate whether or not it was ever approved or not.


-- 
Jonathon McClung  |  Kaart  |  jonat...@kaartgroup.com 


> On Sep 19, 2018, at 1:30 PM, Jérôme Seigneuret  
> wrote:
> 
> In fact, this is a problem with software solution not a tag. the 
> interpretation is a toll access need to wait a part of time. But if you have 
> badge access you don't wait... and if there is lot of traffic you are 
> depandent of traffic... waiting time is not for me an argument and a 
> limitation caused by existing key value but just the interpretation. My 2 
> cents comment is in relation with toll because i have an rfid badge and I 
> don't wait a minute. I just slow down to 30km/h to cross the toll booth.
> 
> problem is on micro-mapping schema and specifing object with speed crossing 
> badge, crossing with credit card, crossing with money...
> 
> That same problem with traffic transport. If you pocess an abonment you can 
> save time, more than else if it payed with CD and more than other if it payed 
> with money.
> 
> An other work is the number of rapid access because if there only one speed 
> toll an lot of traffic you need wait a time anyway.
> 
> In my opinion, the best solution is on number of rapid access toll vs classic 
> access in same solution of parking numbers of places for specific condition.
> 
> for information barrier 
> =lift_gate 
>  and fee 
> =yes 
>  can be set on paint and 
> barrier=toll_booth <> can be a polygon with intersection on your highway.
> 
> In fact the problem is only an parent key of toll because it's assimilate to 
> a barrier but this is just an obligatory access point for users
> I think it's better solution to set toll_booth in highway because it's 
> specific
> In railway you payed with resevation on railway track between to point A to B 
> on time. Did you learn about toll_booth <> on railway???
> historically  there is also barrier=entrance but you can understand in this 
> case there is no physical object. so barrier or not??? That same with 
> barrier=no Isn't it?
> 
> Other problem are using lift_gate and toll_booth with same point... that 
> schema is problematic.
> 
> Can you proposed solution with twice type access
> 
> exemple for french access to A709 in France
> 

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

[Tobias Zwick]

>> Anyway, for a beginner : is one key even better ? -> should we allow
>> “maxspeed=no_sign” ? Or/and “maxspeed=default” ?
>
> Way too ambiguous to be remotely workable in North America.

Is it? I think what djakk is arguing for, and me as well, is to separate
the information stored in "source:maxspeed":


1. Information about whether there is a sign or not (=whether a
   default speed applies or not)

2. Auxiliary information, if necessary, to automatically infer the
   speed limit from the given OSM tags.

Examples for when no maxspeed sign is in sight:
---

1. Motorway in France (FR):
 highway=motorway + source:maxspeed=FR:motorway
   vs
 highway=motorway + maxspeed:signed=no

2. US interstate in Montana (US-MT):
 highway=motorway + source:maxspeed=US-MT:interstate
   vs
 highway=motorway + maxspeed:signed=no + ref~^I
   (maybe ref-starts-with-"I" is not necessary because all interstates
are tagged as motorways?)

3. Road without asphalt or concrete surface in Quebec (CA-QC):
 source:maxspeed=CA-QC:unpaved
   vs
 maxspeed:signed=no + surface!~asphalt|concrete

4. Road with 4 lanes in Delaware (US-DE):
 source:maxspeed=US-DE:4_laned
   vs
 maxspeed:signed=no + lanes=4

5. Urban road in Germany (DE):
 source:maxspeed=DE:urban
   vs
 maxspeed:signed=no + urban=yes

etc., you get the idea(?)
The tags are just examples.

What are the advantages?


1. separating information about the legal road type from whether
   there is a sign or not

   a) makes it easier for contributors to supply the latter as they do
  not have to know precisely about the current speed limit
  legislation. Good for verifiability.
  (maxspeed:signed=no --- source:maxspeed=XX:a_legal_category)

   b) that legal road type (like whether a road is within a
  built-up area or not) is also an important information, even when
  an explicit speed limit IS signed. For example to determine
  the max allowed speed for other vehicle types such as trucks or
  whether a particular vehicle category is allowed on that kind of
  road
  (a_legal_category=yes  source:maxspeed=XX:a_legal_category)

2. using existent tags (e.g. surface, lanes,...)

   a) removes duplicated information
  (lanes=4 --- source:maxspeed=XX:4_laned)

   b) tries to avoid as much as possible "legal road type" categories,
  as these, like default speed limits, may change anytime and have
  problems with on-the-ground verifiability. Thus: better future-
  proofing.
  (source:maxspeed=AT:living_street does actually not exist anymore
   since legislation change in 2002)

3. removes superfluous country ISO-code. Country boundaries information
   is already available in the OSM database, data users can just use a
   (reverse) geocoder to find where a street is.
   (I wrote Java library recently that does this offline in ~0.1ms)

(Ask me for concrete examples)

On 19/09/2018 17:44, Paul Johnson wrote:
> 
> 
> On Wed, Sep 19, 2018, 10:22 djakk djakk  > wrote:
> 
> Yes Paul, I should not forget the beginners ... 
> 
> I am not a beginner anymore but I still found “source:maxspeed=“ for
> roads a little confusing, as we should use “source=“ only (?) on the
> metadata (on the changeset). 
> 
> 
> Specific keys that don't change often and have verifiable source can
> also have source keys, this would be a good example of that being
> appropriate. 
> 
> Anyway, for a beginner : is one key even better ? -> should we allow
> “maxspeed=no_sign” ? Or/and “maxspeed=default” ?
> 
> 
> Way too ambiguous to be remotely workable in North America.
> 
> 
> 
> ___
> 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] maxspeed:type vs source:maxspeed // StreetComplete

[Jérôme Seigneuret]

On Wed, 19 Sep 2018 at 13:30, Joseph Eisenberg
> mailto:joseph.eisenb...@gmail.com>> wrote:
>
> So on the boundary=administrative admin_level=6 for Rogers
> County, we could have something like maxspeed:type:default=45mph

Impossible in France,
Urban maxspeed area isn't in relation to administrative area. And this
fix the problem only on maxspeed parameter and not on other conditon
of access and what rules you have to respect.
Other problem is road classification in rural territoiries and there
is no city_limit board in all entrance of urban area highway physicaly
because there is no obligation in specific condition

that is why I proposed to use specific key

*highway:legal_type=urban or highway:legal_type:FR=agglomération *

This information is in relation with specific entrance/output city
road sign. But in certains conditon, there no output zone sign. The
typical case is : road is considerate as track legaly but is really
use as an residential condition.

legal information for France is :


   - urban area
   - "zone 30"
   - "zone de recontre" > living_street
   - "voie verte"
   - "chemin de halage" side of waterway=canal or river with boat access
   - "route pour automobile" set with thunk value but in fact that
cause lot of problem with conflict editing

What else... You can see cut on routing schema because you have a
living street in part of secondary highway... That don't make sens but
that is the really because specific key appeared and these specific
new key are just a shortcut to set implicit value that we can set on
historical schema key.

The problem is it's more simple to use highway=living_street in place
of highway=tertiary+maxpeed=20+cycleway=opposite

But in ID or other JOSM is't easy to set predifined type with couple
of key isn't it? There is plugin to set turn restriction

exemple is also container with container_type you need a couple of key
for work fine


Le mer. 19 sept. 2018 à 22:10, Tobias Zwick  a écrit :

> This is France though. The abutters-key would only need to be used in
> the United States in order to infer the default speed limits as only
> there, a difference is made between residence districts and business
> districts. In France and/or the rest of the world, what about perhaps
>
> urban=yes/no?
> (borrowed from source:maxspeed=FR:urban)
>
> But I do get the problem of different definitions of what is
> urban/"built-up area" and what not in different countries. Some
> countries define "built-up area" only within the limits defined by the
> "Welcome to Foo-Town" signs (e.g. Germany), some countries define it by
> the abutters (if there are houses, then it is built-up area, regardless
> of whether it is within city limits or not) and one by whether there is
> street lighting or not (United Kingdom).
>
> So, tagging something like highway:legal_type=built_up or urban=yes
> requires knowledge of how it is defined in the legislation. As much as
> it currently requires knowledge of how urban is defined when tagging
> source:maxspeed=FR:urban.
> I know that you know this, just saying because it is important to
> mention for the discussion here.
>
> On 19/09/2018 21:41, djakk djakk wrote:
> > Sound cool but there may be a gap between the reality and the law :
> > example : it looks like the countryside but legally it is inside the
> > built up area :
> > http://www.mapillary.com/map/im/Dybpz_fHGEmWdLjfG7OMvQ/photo
> > There should be 2 tags : abutters=rural and highway:legal_type=built_up
> >
> >
> > djakk
> >
> >
> > Le mer. 19 sept. 2018 à 21:27, Tobias Zwick  > > a écrit :
> >
> > Okay, so US-American legislation usually differs between "residential
> > district" and "business district" for maxspeed defaults, as opposed
> to
> > "built-up area" in most other countries.
> >
> > Actually, there is a tag to denote that a street is in a residential
> > district or business district. It comes from the early days of OSM
> where
> > people were mapping with their GPS trackers for the lack of available
> > aerial imagery. What about this?:
> >
> > abutters=residential
> > abutters=commercial
> >
> > See https://wiki.openstreetmap.org/wiki/Key:abutters
> >
> > On 19/09/2018 14:08, Greg Troxel wrote:
> > > Tod Fitch mailto:t...@fitchdesign.com>>
> writes:
> > >
> > >>> On Sep 18, 2018, at 6:19 PM, Joseph Eisenberg
> > mailto:joseph.eisenb...@gmail.com>>
> wrote:
> > >>>
> > >>> So on the boundary=administrative admin_level=6 for Rogers
> > County, we could have something like maxspeed:type:default=45mph
> > >>
> > >> Except that more typically there will be different default speed
> > >> limits on each of the various OSM highway classifications. So
> maybe
> > >> something more like “maxspeed:default:residential=25 mph”.
> > >
> > > I am not aware of *unposted* default limits in the US being
> > different by
> > > an entity 

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

[Tobias Zwick]

This is France though. The abutters-key would only need to be used in
the United States in order to infer the default speed limits as only
there, a difference is made between residence districts and business
districts. In France and/or the rest of the world, what about perhaps

urban=yes/no?
(borrowed from source:maxspeed=FR:urban)

But I do get the problem of different definitions of what is
urban/"built-up area" and what not in different countries. Some
countries define "built-up area" only within the limits defined by the
"Welcome to Foo-Town" signs (e.g. Germany), some countries define it by
the abutters (if there are houses, then it is built-up area, regardless
of whether it is within city limits or not) and one by whether there is
street lighting or not (United Kingdom).

So, tagging something like highway:legal_type=built_up or urban=yes
requires knowledge of how it is defined in the legislation. As much as
it currently requires knowledge of how urban is defined when tagging
source:maxspeed=FR:urban.
I know that you know this, just saying because it is important to
mention for the discussion here.

On 19/09/2018 21:41, djakk djakk wrote:
> Sound cool but there may be a gap between the reality and the law :
> example : it looks like the countryside but legally it is inside the
> built up area : 
> http://www.mapillary.com/map/im/Dybpz_fHGEmWdLjfG7OMvQ/photo
> There should be 2 tags : abutters=rural and highway:legal_type=built_up
> 
> 
> djakk
> 
> 
> Le mer. 19 sept. 2018 à 21:27, Tobias Zwick  > a écrit :
> 
> Okay, so US-American legislation usually differs between "residential
> district" and "business district" for maxspeed defaults, as opposed to
> "built-up area" in most other countries.
> 
> Actually, there is a tag to denote that a street is in a residential
> district or business district. It comes from the early days of OSM where
> people were mapping with their GPS trackers for the lack of available
> aerial imagery. What about this?:
> 
> abutters=residential
> abutters=commercial
> 
> See https://wiki.openstreetmap.org/wiki/Key:abutters
> 
> On 19/09/2018 14:08, Greg Troxel wrote:
> > Tod Fitch mailto:t...@fitchdesign.com>> writes:
> >
> >>> On Sep 18, 2018, at 6:19 PM, Joseph Eisenberg
> mailto:joseph.eisenb...@gmail.com>> wrote:
> >>>
> >>> So on the boundary=administrative admin_level=6 for Rogers
> County, we could have something like maxspeed:type:default=45mph
> >>
> >> Except that more typically there will be different default speed
> >> limits on each of the various OSM highway classifications. So maybe
> >> something more like “maxspeed:default:residential=25 mph”.
> >
> > I am not aware of *unposted* default limits in the US being
> different by
> > an entity smaller than state.   In Massachusetts, there are default
> > limits in state statutes, in particularly 30 mph in "thickly settled"
> > areas (also defined in statute).  Some towns have adopted 25 mph in
> > thickly settled areas, and they have signs at the town borders.
> >
> > It's an interesting question at what level to tag individual roads and
> > when to have some way of expressing rules and therefore to expect all
> > data consumers to evaluate the rules.  My quick reaction is that
> > publishing rules for regions smaller than states is going to be too
> > messy, vs just tagging the ways.
> >
> > With respect to maxspeed:default:residential, that's totally
> unworkable
> > in Massachusetts.  The law does not talk about roads or even
> define them
> > as residential or not.   The question for 30 (vs 40) is whether
> the road
> > is "thickly settled", which is
> >
> >   built up with structures devoted to business, or the territory
> >   contiguous to any way where the dwelling houses are situated at such
> >   distances as will average less than two hundred feet between
> them for
> >   a distance of a quarter of a mile or over.
> >
> > So there are many roads that are properly tagged "residential" but are
> > not subject to the lower speed.
> >
> > In Mass, we have speed limit tags on almost all legal roads.  To me,
> > that seems like the most straightforward approach, even if there are
> > also defaults.
> >
> > If the general defaults are intended for routing, that seems more or
> > less ok.  If they are intended to actually provide speed limit
> guidance
> > to drivers, I'm opposed, at least in jurisdictions where they aren't
> > strictly reliable.
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/tagging
> >
> 
> 
> ___
> 

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

[djakk djakk]

An other example :
http://www.mapillary.com/map/im/k43_fyX2AuL594qhVuSY7w/photo
abutter=residential and highway:legal_type=rural


Le mer. 19 sept. 2018 à 21:41, djakk djakk  a écrit :

> Sound cool but there may be a gap between the reality and the law :
> example : it looks like the countryside but legally it is inside the built
> up area :
> http://www.mapillary.com/map/im/Dybpz_fHGEmWdLjfG7OMvQ/photo
> There should be 2 tags : abutters=rural and highway:legal_type=built_up
>
>
> djakk
>
>
> Le mer. 19 sept. 2018 à 21:27, Tobias Zwick  a écrit :
>
>> Okay, so US-American legislation usually differs between "residential
>> district" and "business district" for maxspeed defaults, as opposed to
>> "built-up area" in most other countries.
>>
>> Actually, there is a tag to denote that a street is in a residential
>> district or business district. It comes from the early days of OSM where
>> people were mapping with their GPS trackers for the lack of available
>> aerial imagery. What about this?:
>>
>> abutters=residential
>> abutters=commercial
>>
>> See https://wiki.openstreetmap.org/wiki/Key:abutters
>>
>> On 19/09/2018 14:08, Greg Troxel wrote:
>> > Tod Fitch  writes:
>> >
>> >>> On Sep 18, 2018, at 6:19 PM, Joseph Eisenberg <
>> joseph.eisenb...@gmail.com> wrote:
>> >>>
>> >>> So on the boundary=administrative admin_level=6 for Rogers County, we
>> could have something like maxspeed:type:default=45mph
>> >>
>> >> Except that more typically there will be different default speed
>> >> limits on each of the various OSM highway classifications. So maybe
>> >> something more like “maxspeed:default:residential=25 mph”.
>> >
>> > I am not aware of *unposted* default limits in the US being different by
>> > an entity smaller than state.   In Massachusetts, there are default
>> > limits in state statutes, in particularly 30 mph in "thickly settled"
>> > areas (also defined in statute).  Some towns have adopted 25 mph in
>> > thickly settled areas, and they have signs at the town borders.
>> >
>> > It's an interesting question at what level to tag individual roads and
>> > when to have some way of expressing rules and therefore to expect all
>> > data consumers to evaluate the rules.  My quick reaction is that
>> > publishing rules for regions smaller than states is going to be too
>> > messy, vs just tagging the ways.
>> >
>> > With respect to maxspeed:default:residential, that's totally unworkable
>> > in Massachusetts.  The law does not talk about roads or even define them
>> > as residential or not.   The question for 30 (vs 40) is whether the road
>> > is "thickly settled", which is
>> >
>> >   built up with structures devoted to business, or the territory
>> >   contiguous to any way where the dwelling houses are situated at such
>> >   distances as will average less than two hundred feet between them for
>> >   a distance of a quarter of a mile or over.
>> >
>> > So there are many roads that are properly tagged "residential" but are
>> > not subject to the lower speed.
>> >
>> > In Mass, we have speed limit tags on almost all legal roads.  To me,
>> > that seems like the most straightforward approach, even if there are
>> > also defaults.
>> >
>> > If the general defaults are intended for routing, that seems more or
>> > less ok.  If they are intended to actually provide speed limit guidance
>> > to drivers, I'm opposed, at least in jurisdictions where they aren't
>> > strictly reliable.
>> >
>> > ___
>> > 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] maxspeed:type vs source:maxspeed // StreetComplete

[djakk djakk]

Sound cool but there may be a gap between the reality and the law : example
: it looks like the countryside but legally it is inside the built up area
:
http://www.mapillary.com/map/im/Dybpz_fHGEmWdLjfG7OMvQ/photo
There should be 2 tags : abutters=rural and highway:legal_type=built_up


djakk


Le mer. 19 sept. 2018 à 21:27, Tobias Zwick  a écrit :

> Okay, so US-American legislation usually differs between "residential
> district" and "business district" for maxspeed defaults, as opposed to
> "built-up area" in most other countries.
>
> Actually, there is a tag to denote that a street is in a residential
> district or business district. It comes from the early days of OSM where
> people were mapping with their GPS trackers for the lack of available
> aerial imagery. What about this?:
>
> abutters=residential
> abutters=commercial
>
> See https://wiki.openstreetmap.org/wiki/Key:abutters
>
> On 19/09/2018 14:08, Greg Troxel wrote:
> > Tod Fitch  writes:
> >
> >>> On Sep 18, 2018, at 6:19 PM, Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
> >>>
> >>> So on the boundary=administrative admin_level=6 for Rogers County, we
> could have something like maxspeed:type:default=45mph
> >>
> >> Except that more typically there will be different default speed
> >> limits on each of the various OSM highway classifications. So maybe
> >> something more like “maxspeed:default:residential=25 mph”.
> >
> > I am not aware of *unposted* default limits in the US being different by
> > an entity smaller than state.   In Massachusetts, there are default
> > limits in state statutes, in particularly 30 mph in "thickly settled"
> > areas (also defined in statute).  Some towns have adopted 25 mph in
> > thickly settled areas, and they have signs at the town borders.
> >
> > It's an interesting question at what level to tag individual roads and
> > when to have some way of expressing rules and therefore to expect all
> > data consumers to evaluate the rules.  My quick reaction is that
> > publishing rules for regions smaller than states is going to be too
> > messy, vs just tagging the ways.
> >
> > With respect to maxspeed:default:residential, that's totally unworkable
> > in Massachusetts.  The law does not talk about roads or even define them
> > as residential or not.   The question for 30 (vs 40) is whether the road
> > is "thickly settled", which is
> >
> >   built up with structures devoted to business, or the territory
> >   contiguous to any way where the dwelling houses are situated at such
> >   distances as will average less than two hundred feet between them for
> >   a distance of a quarter of a mile or over.
> >
> > So there are many roads that are properly tagged "residential" but are
> > not subject to the lower speed.
> >
> > In Mass, we have speed limit tags on almost all legal roads.  To me,
> > that seems like the most straightforward approach, even if there are
> > also defaults.
> >
> > If the general defaults are intended for routing, that seems more or
> > less ok.  If they are intended to actually provide speed limit guidance
> > to drivers, I'm opposed, at least in jurisdictions where they aren't
> > strictly reliable.
> >
> > ___
> > 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] Feature Proposal - Voting - Toll Gantry

[Jérôme Seigneuret]

In fact, this is a problem with software solution not a tag. the
interpretation is a toll access need to wait a part of time. But if you
have badge access you don't wait... and if there is lot of traffic you are
depandent of traffic... waiting time is not for me an argument and a
limitation caused by existing key value but just the interpretation. My 2
cents comment is in relation with toll because i have an rfid badge and I
don't wait a minute. I just slow down to 30km/h to cross the toll booth.

problem is on micro-mapping schema and specifing object with speed crossing
badge, crossing with credit card, crossing with money...

That same problem with traffic transport. If you pocess an abonment you can
save time, more than else if it payed with CD and more than other if it
payed with money.

An other work is the number of rapid access because if there only one speed
toll an lot of traffic you need wait a time anyway.

In my opinion, the best solution is on number of rapid access toll vs
classic access in same solution of parking numbers of places for specific
condition.

for information barrier =
lift_gate  and
fee =yes
 can be set on paint and
barrier=toll_booth can be a polygon with intersection on your highway.

In fact the problem is only an parent key of toll because it's assimilate
to a barrier but this is just an obligatory access point for users
I think it's better solution to set toll_booth in highway because it's
specific
In railway you payed with resevation on railway track between to point A to
B on time. Did you learn about toll_booth on railway???
historically  there is also barrier=entrance but you can understand in this
case there is no physical object. so barrier or not??? That same with
barrier=no Isn't it?

Other problem are using lift_gate and toll_booth with same point... that
schema is problematic.

Can you proposed solution with twice type access

exemple for french access to A709 in France
http://montrajet.deplacement-a9.fr/uploads/images//point-44/picto-7-barriere-de-peage-baillargues.jpg
you can see 1 rapid access right and left
in opposite direction there is 3 speed access left (for vehicule with
specifi maxheight) and 2 speed access on right (for increase traffic speed
for hgv)

that is just my reflection on toll_booth.

For you proposed key, I think you can cut element in twice

highway=grantry+toll=yes and add you speed conditon or stop conditon and it
respond to your case.
grantry is also a proposal
https://wiki.openstreetmap.org/wiki/Proposed_features/Gantry

you can set all you need on point in intersection with gantry

*gantry *can be also use for direction information or message with
electronic information

The problem, and I think you understand where I want go, would be on
combination of information on object in same position.




Le mer. 19 sept. 2018 à 19:33, Jonathon McClung  a
écrit :

> The issue is mostly with how the current standard (as stated here
> https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dtoll_booth
> ) impacts
> routing. This is said on the proposal page here "Many current routing
> softwares add a delay to trip time when encountering the tag barrier
> =toll_booth
> . However,
> the delay on these more modern toll collection systems is significantly
> less; not requiring the driver to stop in most cases. In effect, this means
> that many drivers will be routed onto a slower route.” This is the major
> difference. Of course the way itself should be tagged toll=yes. This is a
> clean way to a) show where the toll begins and b) give the routing software
> something to account for on the way.
>
> At the end of your email you talk about alternate names. We discussed many
> names, but ultimately landed on toll_gantry because the meaning of the word
> toll is immediately apparent. The term gantry was chosen because it’s
> meaning is specific and less ambiguous than “toll bridge" the other common
> name for these fixtures. Much of this is discussed on the proposal’s page
>  and 
> discussion
> page
> 
> .
>
>
> --
> Jonathon McClung  |  Kaart  |  jonat...@kaartgroup.com
>
>
> On Sep 19, 2018, at 10:59 AM, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> wrote:
>
> I don't really understand the difference
>
> toll_both is a vending machine (or human) with lift gate barrier.  It is
> just an other type of object because in other case you can set really the
> gantry as line and set on point type camera 

Re: [Tagging] landuse for government offices ?

[Kevin Kenny]

What appears to be practice here, although I have only a few mapped
examples, is to have office=government appear on the (multi)polygon
representing the grounds, and not just on the building. I concede that
if you have a single large campus with offices of many agencies, the
subtags don't work, so I'm not opposed to a new tag for the landuse.
I'm simply concerned whether the handful of local examples that I
managed to turn up were mistagged.

The landuse also is perhaps better in that it's a more appropriate tag
for 'government' facilities such as a highway maintenance garage. In
some of the villages around here, the highway maintenance, police,
fire brigade, and village government are all in the same building.
I've paid a traffic ticket in front of a justice of the peace who was
seated at a judge's bench in the corner of a firehouse, with the
engines backed out into the car park while court was in session. Got
to love a village of four hundred souls in the middle of nowhere.
On Mon, Sep 17, 2018 at 1:35 PM OSMDoudou
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>
> Hello,
>
> The "landuse=commercial" page [1] says "area may consists of offices,
> administration", whereas the "landuse" page [2] says "Government services
> and businesses should not use this tag".
>
> How to tag a piece of land where governmental several office buildings are
> situated ?
>
> For example, a set of Service Public Fédéral (SPF) buildings, which are
> government offices. [3]
>
> [1] https://wiki.openstreetmap.org/wiki/Tag:landuse=commercial
> [2] https://wiki.openstreetmap.org/wiki/Key:landuse
> [3] https://www.openstreetmap.org/#map=19/50.44476/3.95168
>
>
> ___
> 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] maxspeed:type vs source:maxspeed // StreetComplete

[Tobias Zwick]

Okay, so US-American legislation usually differs between "residential
district" and "business district" for maxspeed defaults, as opposed to
"built-up area" in most other countries.

Actually, there is a tag to denote that a street is in a residential
district or business district. It comes from the early days of OSM where
people were mapping with their GPS trackers for the lack of available
aerial imagery. What about this?:

abutters=residential
abutters=commercial

See https://wiki.openstreetmap.org/wiki/Key:abutters

On 19/09/2018 14:08, Greg Troxel wrote:
> Tod Fitch  writes:
> 
>>> On Sep 18, 2018, at 6:19 PM, Joseph Eisenberg  
>>> wrote:
>>>
>>> So on the boundary=administrative admin_level=6 for Rogers County, we could 
>>> have something like maxspeed:type:default=45mph
>>
>> Except that more typically there will be different default speed
>> limits on each of the various OSM highway classifications. So maybe
>> something more like “maxspeed:default:residential=25 mph”.
> 
> I am not aware of *unposted* default limits in the US being different by
> an entity smaller than state.   In Massachusetts, there are default
> limits in state statutes, in particularly 30 mph in "thickly settled"
> areas (also defined in statute).  Some towns have adopted 25 mph in
> thickly settled areas, and they have signs at the town borders.
> 
> It's an interesting question at what level to tag individual roads and
> when to have some way of expressing rules and therefore to expect all
> data consumers to evaluate the rules.  My quick reaction is that
> publishing rules for regions smaller than states is going to be too
> messy, vs just tagging the ways.
> 
> With respect to maxspeed:default:residential, that's totally unworkable
> in Massachusetts.  The law does not talk about roads or even define them
> as residential or not.   The question for 30 (vs 40) is whether the road
> is "thickly settled", which is
> 
>   built up with structures devoted to business, or the territory
>   contiguous to any way where the dwelling houses are situated at such
>   distances as will average less than two hundred feet between them for
>   a distance of a quarter of a mile or over.
> 
> So there are many roads that are properly tagged "residential" but are
> not subject to the lower speed.
> 
> In Mass, we have speed limit tags on almost all legal roads.  To me,
> that seems like the most straightforward approach, even if there are
> also defaults.
> 
> If the general defaults are intended for routing, that seems more or
> less ok.  If they are intended to actually provide speed limit guidance
> to drivers, I'm opposed, at least in jurisdictions where they aren't
> strictly reliable.
> 
> ___
> 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] maxspeed:type vs source:maxspeed // StreetComplete

[Philip Barnes]

On Wed, 2018-09-19 at 21:16 +0200, Tobias Zwick wrote:
> This is a good argument against tagging an explicit maxspeed=X when
> there is actually no speed limit sign around (X is what the OSM
> mapper
> by his knowledge about the law thinks should be the default limit
> here).
> 
> Unfortunately, this is still common practice because of the lack of a
> scheme for tagging explicitly that the maxspeed is not signed.

If we went to that extreme, we would have very few speed limits mapped
in Europe.

Phil (trigpoint

> 
> 
> On 19/09/2018 09:47, Philip Barnes wrote:
> > And if the default actually applies, or has it been overriden by
> > local
> > signage.
> > 
> > I am not convinced that a default limit helps, if no speed limit
> > has
> > been surveyed I would prefer that box not to be displayed in my
> > app.
> > a. It will not give me wrong and possibly costly information.
> > b. It makes it obvious that I should survey and map the limit.
> > 
> > Phil (trigpoint)
> > 
> > On 19 September 2018 07:10:27 BST, Graeme Fitzpatrick
> >  wrote:
> > 
> > 
> > 
> > On Wed, 19 Sep 2018 at 13:30, Joseph Eisenberg
> > mailto:joseph.eisenb...@gmail.com>
> > > wrote:
> > 
> > So on the boundary=administrative admin_level=6 for Rogers
> > County, we could have something like
> > maxspeed:type:default=45mph
> > 
> > 
> > Just after crossing over the border into the state of
> > Queensland,
> > you have this
> > sign: https://www.google.com/maps/@-28.1592952,153.4932922,3a,7
> > 5y,288.32h,90t/data=!3m6!1e1!3m4!1sXT0hBPanAoGnfz9N-
> > Ugbyw!2e0!7i13312!8i6656
> >  > 8.32h,90t/data=%213m6%211e1%213m4%211sXT0hBPanAoGnfz9N-
> > Ugbyw%212e0%217i13312%218i6656>
> > (Incidentally, I think 7 of the 8 Australian states &
> > territories
> > have the same limits?)
> > 
> > I understand (I think!) that your system would set this as a
> > default
> > for all Qld roads?
> > 
> > But based on what? How does OSM know that this stretch of road
> > is in
> > either a rural or a built-up area?
> >  
> > Thanks
> > 
> > Graeme
> > 
> > 
> > -- 
> > Sent from my Android device with K-9 Mail. Please excuse my
> > brevity.
> > 
> > 
> > ___
> > 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] maxspeed:type vs source:maxspeed // StreetComplete

[Tobias Zwick]

This is a good argument against tagging an explicit maxspeed=X when
there is actually no speed limit sign around (X is what the OSM mapper
by his knowledge about the law thinks should be the default limit here).

Unfortunately, this is still common practice because of the lack of a
scheme for tagging explicitly that the maxspeed is not signed.


On 19/09/2018 09:47, Philip Barnes wrote:
> And if the default actually applies, or has it been overriden by local
> signage.
> 
> I am not convinced that a default limit helps, if no speed limit has
> been surveyed I would prefer that box not to be displayed in my app.
> a. It will not give me wrong and possibly costly information.
> b. It makes it obvious that I should survey and map the limit.
> 
> Phil (trigpoint)
> 
> On 19 September 2018 07:10:27 BST, Graeme Fitzpatrick
>  wrote:
> 
> 
> 
> On Wed, 19 Sep 2018 at 13:30, Joseph Eisenberg
> mailto:joseph.eisenb...@gmail.com>> wrote:
> 
> So on the boundary=administrative admin_level=6 for Rogers
> County, we could have something like maxspeed:type:default=45mph
> 
> 
> Just after crossing over the border into the state of Queensland,
> you have this
> sign: 
> https://www.google.com/maps/@-28.1592952,153.4932922,3a,75y,288.32h,90t/data=!3m6!1e1!3m4!1sXT0hBPanAoGnfz9N-Ugbyw!2e0!7i13312!8i6656
> 
> 
> (Incidentally, I think 7 of the 8 Australian states & territories
> have the same limits?)
> 
> I understand (I think!) that your system would set this as a default
> for all Qld roads?
> 
> But based on what? How does OSM know that this stretch of road is in
> either a rural or a built-up area?
>  
> Thanks
> 
> Graeme
> 
> 
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> 
> 
> ___
> 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] landuse for government offices ?

[SelfishSeahorse]

On Tue, 18 Sep 2018 at 23:48, Clifford Snow  wrote:
>
> I would accept civic_admin as well.
>
> Markus - do you want to revive the proposal? I'd like to see this become a 
> approved tag.

I don't really have experience in this but i'll try. I'm just going to
ask the author of the (draft) proposal first if he doesn't mind if i
continue it.

Regards
Markus

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

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

[Mark Wagner]

On Wed, 19 Sep 2018 13:54:47 +0200
Tobias Zwick  wrote:

> This does not present a problem:
> 
> > The first set  
> 
> Well, as you write yourself, they may be authorized to set own speed
> limits, but they need to signpost it.
> 
> > The second  
> 
> So these are the type of regulations I mean with "default speed
> limits".
> 
> > The third law  
> 
> As Martin Koppenhoefer stated on another discussion branch, this kind
> of paragraph in legislation is not specific to the US. All/most
> legislations have a sentence like this - it only differs how a breach
> of this is persecuted. But well, Martin Koppenhoefer and Colin Smale
> already wrote what there is to say about it.

RCW 46.61.405, 46.61.410, and 46.61.415 all require that an engineering
study be performed before setting the speed limit.  Thus, for the vast
majority of roads with signed limits, a highway engineer has determined
that the signed limit is a "reasonable and prudent" speed under
ordinary conditions.

My point is that no such guarantee exists for roads without speed limit
signs.  Yes, the numeric limit for something like Glenwood Road might
be 50 mph, but the road was designed around farm trucks going no more
than 20 mph, and has the tight curves, short sight lines, and poor
surface quality you'd expect for that speed.

--
Mark

> On 19/09/2018 07:15, Mark Wagner wrote:
> > On Tue, 18 Sep 2018 20:36:06 +0200
> > Tobias Zwick  wrote:
> >   
> >> From your anecdote, it seems, an implicit speed limit tagging
> >> scheme is even more important in the US than for example in the
> >> UK  
> > 
> > In my part of the US, a meaningful implicit speed limit tagging
> > scheme is impossible, due to the three sets of laws regarding speed
> > limits.
> > 
> > The first set is RCW 46.61.405, 46.61.410, 46.61.415, and 46.61.419,
> > which give various people the authority to set signed speed limits,
> > obedience to which is required by RCW 46.61.050.
> > 
> > The second is RCW 46.61.400(2), which establishes default speeds of
> > 25 MPH on city streets, 50 MPH on county roads, and 60 MPH on state
> > highways.  This would seem rather comprehensive, except for:
> > 
> > The third law: RCW 46.61.400(1).  "No person shall drive a vehicle
> > on a highway at a speed greater than is reasonable and prudent
> > under the conditions and having regard to the actual and potential
> > hazards then existing."
> > 
> > As a highway engineer pointed out to me recently, most county roads,
> > especially unpaved ones, are designed around a speed limit of
> > "reasonable and prudent".  The 50 MPH limit established by RCW
> > 46.61.400(2)(b) simply sets a firm upper boundary; it's quite
> > possible to get a speeding ticket at a lower speed.
> > 
> > Sure, you can put a number on any road.  But for most rural roads
> > without speed-limit signs, the number is unrelated to how fast you
> > can drive on that road.
> >   
> 
> 
> ___
> 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] maxspeed:type vs source:maxspeed // StreetComplete

[Philip Barnes]

On Wed, 2018-09-19 at 18:04 +0200, Colin Smale wrote:
> In many countries in Europe, the "Welcome to XXX" sign as you enter a
> town/village has the effect of delineating the "built-up area" for
> traffic purposes and introduces a specific speed limit, without any
> numbers being mentioned. In the countries I know in Northern Europe
> it means "maxspeed=50 kmh" until you leave the town/village (unless
> otherwise indicated of course). And that is independent of the type
> of road by the way. On a motorway you will not pass one of these
> official signs, so you carry on at 130 or whatever. The sign would be
> on the exit ramps.
> The built-up area for traffic law purposes is therefore often non-
> contiguous, made up of lots of polygons. You just have to know if you
> are in or out of a built-up area, because it makes a difference to
> many things about traffic laws (not just maxspeed).
>  
When joining a motorway you will see the international chopsticks
symbol which tell you that the national motorway speed limit applies.
https://www.mapillary.com/app/?lat=52.60005784739699=-1.19589832816
87308=17=Gkpjh6SE0kU_Yw96YfXNQg=photo
In the UK roads that are National Speed Limit are indicated by a white
circle with a black diagonal line indicating the start of the national
speed limit, this is 60mph on single carriageways and 70 mph on dual
carriageways.
https://www.mapillary.com/app/?lat=52.863630348111315=-2.7200549019
88078=17=4aM-U0vHuiOEqF2lWHBjbQ=photo
We use the maxspeed:type tag to indicate that we have observed this
sign and interpreted it as gb:nsl_single/gb:nsl_dual or
gb:nsl:motorway.
Phil (trigpoint)



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

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Jonathon McClung]

The issue is mostly with how the current standard (as stated here 
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dtoll_booth 
) impacts routing. 
This is said on the proposal page here "Many current routing softwares add a 
delay to trip time when encountering the tagbarrier 
=toll_booth 
. However, the 
delay on these more modern toll collection systems is significantly less; not 
requiring the driver to stop in most cases. In effect, this means that many 
drivers will be routed onto a slower route.” This is the major difference. Of 
course the way itself should be tagged toll=yes. This is a clean way to a) show 
where the toll begins and b) give the routing software something to account for 
on the way. 

At the end of your email you talk about alternate names. We discussed 
many names, but ultimately landed on toll_gantry because the meaning of the 
word toll is immediately apparent. The term gantry was chosen because it’s 
meaning is specific and less ambiguous than “toll bridge" the other common name 
for these fixtures. Much of this is discussed on the proposal’s page 
 and 
discussion page 
.
 


-- 
Jonathon McClung  |  Kaart  |  jonat...@kaartgroup.com 


> On Sep 19, 2018, at 10:59 AM, Jérôme Seigneuret  
> wrote:
> 
> I don't really understand the difference
> 
> toll_both is a vending machine (or human) with lift gate barrier.  It is just 
> an other type of object because in other case you can set really the gantry 
> as line and set on point type camera or other information object.
> 
> camera as set in relation there is an other subject in France "Ecotaxe 
> gantry" 
> 
> highway can be set with fee=yes if this is just that you wan't
> 
> there is also speed tall access with RFID toll badge  ("Télépéage" for 
> frenchies) 
> 
> in other way if it's a camera you can set camera type 
> there is speed_camera why not  simply highway=atc_camera
> 
> I think this is only in relation with highway. Isn't It?
> 
> 
> 
> 
> Le mer. 19 sept. 2018 à 17:55, Jonathon McClung  > a écrit :
>   Hello OSM Tagging List!
> 
>   Two weeks have come and gone and now the proposal for 
> highway=toll_gantry is up for vote!
>  
>   Please visit 
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Toll_Gantry 
>  and cast 
> your vote. If you missed this proposal the first time, still have concerns, 
> or still have questions, please join the discussion. Otherwise, we look 
> forward to seeing your votes!
> 
>   Thanks!
> 
> -- 
> Jonathon McClung  |  Kaart  |  jonat...@kaartgroup.com 
>  
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging 
> 
> 
> 
> -- 
> Cordialement,
> Jérôme Seigneuret
> ___
> 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] maxspeed:type vs source:maxspeed // StreetComplete

[Paul Johnson]

On Wed, Sep 19, 2018, 10:22 djakk djakk  wrote:

> Yes Paul, I should not forget the beginners ...
>
> I am not a beginner anymore but I still found “source:maxspeed=“ for roads
> a little confusing, as we should use “source=“ only (?) on the metadata (on
> the changeset).
>

Specific keys that don't change often and have verifiable source can also
have source keys, this would be a good example of that being appropriate.

Anyway, for a beginner : is one key even better ? -> should we allow
> “maxspeed=no_sign” ? Or/and “maxspeed=default” ?
>

Way too ambiguous to be remotely workable in North America.

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

Re: [Tagging] Feature Proposal - Voting - Toll Gantry

[Jérôme Seigneuret]

I don't really understand the difference

toll_both is a vending machine (or human) with lift gate barrier.  It is
just an other type of object because in other case you can set really the
gantry as line and set on point type camera or other information object.

camera as set in relation there is an other subject in France "Ecotaxe
gantry"

highway can be set with fee=yes if this is just that you wan't

there is also speed tall access with RFID toll badge  ("Télépéage" for
frenchies)

in other way if it's a camera you can set camera type
there is speed_camera why not  simply highway=atc_camera

I think this is only in relation with highway. Isn't It?




Le mer. 19 sept. 2018 à 17:55, Jonathon McClung  a
écrit :

> Hello OSM Tagging List!
>
> Two weeks have come and gone and now the proposal for highway=toll_gantry
> is up for vote!
>
> Please visit
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Toll_Gantry and
> cast your vote. If you missed this proposal the first time, still have
> concerns, or still have questions, please join the discussion. Otherwise,
> we look forward to seeing your votes!
>
> Thanks!
>
> --
> Jonathon McClung  |  Kaart  |  jonat...@kaartgroup.com
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


-- 
Cordialement,
Jérôme Seigneuret
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Colin Smale]

In many countries in Europe, the "Welcome to XXX" sign as you enter a
town/village has the effect of delineating the "built-up area" for
traffic purposes and introduces a specific speed limit, without any
numbers being mentioned. In the countries I know in Northern Europe it
means "maxspeed=50 kmh" until you leave the town/village (unless
otherwise indicated of course). And that is independent of the type of
road by the way. On a motorway you will not pass one of these official
signs, so you carry on at 130 or whatever. The sign would be on the exit
ramps. 

The built-up area for traffic law purposes is therefore often
non-contiguous, made up of lots of polygons. You just have to know if
you are in or out of a built-up area, because it makes a difference to
many things about traffic laws (not just maxspeed).

On 2018-09-19 16:28, Jérôme Seigneuret wrote:

> Hi, tagging list  
> I just join it. 
> 
> For your information there is part of proposed tagging schema in french 
> subject discuss with @djakk.dj...@gmail.com  
> 
> https://lists.openstreetmap.org/pipermail/talk-fr/2018-September/090189.html 
> 
> Values of legal type can be thinking in specific territory area and resolve 
> "in my opinion" lot of case and subject in relation to access, maxspeed, and 
> legal dimension. the last term is "the case" of lot of problem of tagging 
> because it can't be appreciated just with maxspeed and access definition. 
> 
> All cases will be deliberate. Speak with law school faculty or a lawyer can 
> help us to see all cases. 
> 
> Jérôme 
> 
> Le mer. 19 sept. 2018 à 15:57, Paul Johnson  a écrit : 
> 
> On Wed, Sep 19, 2018, 08:27 djakk djakk  wrote: 
> 
> By the way, we should de-correlate the legal status of an highway from the 
> highway tag : with the key highway:legal_type, values : business_area or 
> residential_area or an other local legal classification. A highway=tertiary 
> could also be highway:legal_type=residential_area 
> 
> This seems like it would be way less complicated and way easier to 
> troubleshoot and way easier to approach when you're new to the project to 
> just use source:maxspeed=* to explain the context. 
> ___
> 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] Feature Proposal - Voting - Toll Gantry

[Jonathon McClung]

Hello OSM Tagging List!

Two weeks have come and gone and now the proposal for 
highway=toll_gantry is up for vote!
 
Please visit 
https://wiki.openstreetmap.org/wiki/Proposed_Features/Toll_Gantry 
 and cast 
your vote. If you missed this proposal the first time, still have concerns, or 
still have questions, please join the discussion. Otherwise, we look forward to 
seeing your votes!

Thanks!

-- 
Jonathon McClung  |  Kaart  |  jonat...@kaartgroup.com 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[djakk djakk]

Yes Paul, I should not forget the beginners ...

I am not a beginner anymore but I still found “source:maxspeed=“ for roads
a little confusing, as we should use “source=“ only (?) on the metadata (on
the changeset).

Anyway, for a beginner : is one key even better ? -> should we allow
“maxspeed=no_sign” ? Or/and “maxspeed=default” ?


djakk


Le mer. 19 sept. 2018 à 16:28, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> Hi, tagging list
> I just join it.
>
> For your information there is part of proposed tagging schema in french
> subject discuss with @djakk.dj...@gmail.com 
>
>
> https://lists.openstreetmap.org/pipermail/talk-fr/2018-September/090189.html
>
> Values of legal type can be thinking in specific territory area and
> resolve "in my opinion" lot of case and subject in relation to access,
> maxspeed, and legal dimension. the last term is "the case" of lot of
> problem of tagging because it can't be appreciated just with maxspeed and
> access definition.
>
> All cases will be deliberate. Speak with law school faculty or a lawyer
> can help us to see all cases.
>
> Jérôme
>
>
> Le mer. 19 sept. 2018 à 15:57, Paul Johnson  a
> écrit :
>
>>
>>
>> On Wed, Sep 19, 2018, 08:27 djakk djakk  wrote:
>>
>>> By the way, we should de-correlate the legal status of an highway from
>>> the highway tag : with the key highway:legal_type, values : business_area
>>> or residential_area or an other local legal classification. A
>>> highway=tertiary could also be highway:legal_type=residential_area
>>>
>>
>> This seems like it would be way less complicated and way easier to
>> troubleshoot and way easier to approach when you're new to the project to
>> just use source:maxspeed=* to explain the context.
>> ___
>> 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] maxspeed:type vs source:maxspeed // StreetComplete

[Jérôme Seigneuret]

Hi, tagging list
I just join it.

For your information there is part of proposed tagging schema in french
subject discuss with @djakk.dj...@gmail.com 

https://lists.openstreetmap.org/pipermail/talk-fr/2018-September/090189.html

Values of legal type can be thinking in specific territory area and resolve
"in my opinion" lot of case and subject in relation to access, maxspeed,
and legal dimension. the last term is "the case" of lot of problem of
tagging because it can't be appreciated just with maxspeed and access
definition.

All cases will be deliberate. Speak with law school faculty or a lawyer can
help us to see all cases.

Jérôme


Le mer. 19 sept. 2018 à 15:57, Paul Johnson  a écrit :

>
>
> On Wed, Sep 19, 2018, 08:27 djakk djakk  wrote:
>
>> By the way, we should de-correlate the legal status of an highway from
>> the highway tag : with the key highway:legal_type, values : business_area
>> or residential_area or an other local legal classification. A
>> highway=tertiary could also be highway:legal_type=residential_area
>>
>
> This seems like it would be way less complicated and way easier to
> troubleshoot and way easier to approach when you're new to the project to
> just use source:maxspeed=* to explain the context.
> ___
> 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] maxspeed:type vs source:maxspeed // StreetComplete

[Paul Johnson]

On Wed, Sep 19, 2018, 08:27 djakk djakk  wrote:

> By the way, we should de-correlate the legal status of an highway from the
> highway tag : with the key highway:legal_type, values : business_area or
> residential_area or an other local legal classification. A highway=tertiary
> could also be highway:legal_type=residential_area
>

This seems like it would be way less complicated and way easier to
troubleshoot and way easier to approach when you're new to the project to
just use source:maxspeed=* to explain the context.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[djakk djakk]

By the way, we should de-correlate the legal status of an highway from the
highway tag : with the key highway:legal_type, values : business_area or
residential_area or an other local legal classification. A highway=tertiary
could also be highway:legal_type=residential_area


djakk



Le mer. 19 sept. 2018 à 14:47, djakk djakk  a écrit :

> Hello !
>
> There is also speed limit areas, a sign is posted at the entrance of the
> area.
>
> Imagine that a big part of Paris becomes a 30km/h area. Is it possible to
> create a big polygon tagged with maxspeed=30, each street inside inherits
> the maxspeed value of the big polygon ? (to escape the inheritance, simply
> tag a segment of street with maxspeed=50 for example)
>
>
> djakk
>
>
>
> Le mer. 19 sept. 2018 à 14:22, Paul Johnson  a
> écrit :
>
>> On Wed, Sep 19, 2018 at 7:18 AM Greg Troxel  wrote:
>>
>>>
>>> Philip Barnes  writes:
>>>
>>> > And if the default actually applies, or has it been overriden by local
>>> signage.
>>> >
>>> > I am not convinced that a default limit helps, if no speed limit has
>>> been surveyed I would prefer that box not to be displayed in my app.
>>> > a. It will not give me wrong and possibly costly information.
>>> > b. It makes it obvious that I should survey and map the limit.
>>> >
>>> > Phil (trigpoint)
>>>
>>> Seconded.  It's actively harmful to display an incorrect limit.
>>> Defaults will inevitably lead to it
>>
>>
>> In practice, this tends to be easy to weed out, as exceptions aren't
>> common (in an overall view of centerline road miles) and quickly dispatched
>> in a short series of surveys or even by armchair if there's OpenStreetCam,
>> Mapillary or Bing Streetside imagery available.
>> ___
>> 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] Draft Proposal: Default Langauge Format

[djakk djakk]

Hello !

I have in mind my trouble when driving back from Amsterdam toward France. I
knew I had to pass through Lille but I did not see it on the directional
signs. (No gps device back in the days ;-) ) I understood at last close to
the border that the Rijsel I saw all the time on the signs means Lille >_<

Rijsel is not used in France. But it would be very useful to display it on
a map as it it used only several kilometers from the city.


djakk


Le mer. 19 sept. 2018 à 09:57, Jo  a écrit :

> Every street in Brussels HAS a name:fr tag. They also ALL have a name:nl
> tag.
>
> An IPA representation also needs information about the language it is for.
> A name, even spelled with the exact same characters will be pronounced
> differently by a French speaker compared to a Ducht speaker. Sometimes very
> differently, sometimes it's simply a matter of which syllable to stress.
>
> Polyglot
>
> Op wo 19 sep. 2018 om 04:43 schreef Joseph Eisenberg <
> joseph.eisenb...@gmail.com>:
>
>> Paul,
>>
>> Thank you for your comments.
>> Have you read the complete Proposal page
>> ?
>> Perhaps I need to improve the wording to clarify some of your concerns
>>
>> >”I'd rather have local languages mapped rather than the language the
 renderer 'should' use.”

 By recording each name in a separate “name:=*” tag, database
 users and map makers will be able to pick the best name for their audience.

>>>
>>> The best name for the audience is the one which matches the signage.  It
>>> does me no good to see an English
>>> translation of a Russian street sign.
>>>
>>
>> This is true if your database use case is rendering a map for a local
>> audience. That's why the Openstreetmap Carto style renders names this way.
>> This proposal will not change the way names are rendered on the standard
>> map, except in the rare case where, for example, "name:fr=*" is present on
>> a feature in France but the "name=*" tag is missing. In this case it will
>> now render properly.
>>
>> But not all names are street or shop names. There are internationally
>> know features, like Mt Everest and the Yellow River, which have well-known
>> names in many names, which are quite different than the locally used name.
>> Take a look at the current rendering of Nepal or China. The Openstreetmap
>> Carto style is useful if you are in Nepal and want to find a sign point you
>> towards Mt Everest, but a person sitting at their computer in Brazil will
>> have trouble finding the mountain on the standard map style.
>>
>> The French style already renders names in French preferentially, but this
>> loses the information about the locally used name. I agree that this is a
>> problem!
>> But with the current use of names, it's not possible to make an
>> international map style that shows French names and the locally name at the
>> same time.
>> If you try to render "name:fr=*" and "name=*" together, you'll render the
>> French name twice for every street in Brussels
>>
>>
>>> The only thing the map should render is the name as it is displayed on
>>> signage.
>>>
>>
>> For local routing yes, for Openstreetmap Carto yes, but all applications?
>> Not always
>>
>>
>>> It would also be useful if the IPA characters representing how a local
>>> would pronounce that name is present so applications could feed that
>>> to text-to-speech.
>>>
>>
>> Yes! IPA is a great idea. I believe "name:ipa=*" could work for this.
>> Want to write up a proposal? :-)
>>
>>
>>> It is also somewhat useful, for multilingual signage, to use name:xx and
>>> name:yy to hold the individual
>>> language components of that name.
>>>
>>
>> You've got it! That's exactly what we want to encourage. If every street
>> in Brussels has name:fr=xx and name:nl=yy, the French map style could
>> render both.
>> ( Or being the French, they might just render "name:fr=yy", but
>> there's nothing to be done about that. )
>>
>>>
>>> The local name still needs to be specified so that database users know
 what name or names are actually used “on the ground” vs foreign names. The
 default language format tag makes this possible, but separates this
 function from the name=* tag. And the proposal includes a language:local
 tag so that all local names can be shown, even those that are less common
 or in a minority language.

>>>
>>> No, no and thrice no.
>>>
>>
>> ??? What are you objecting to here? The "language:local=" tag?
>> This will not be rendered by Openstreetmap Carto style or anyone really.
>> It just lets database users that certain languages are actually locally
>> used names, vs foreign names.
>>
>> For example, Puncak Trikora (id) / Wilhelmina Top (nl) / Mount Trikora
>> (en) is the 2nd or 3rd tallest mountain in Indonesia. It's currently tagged
>> with name="Puncak Trikora", which is appropriate, because that's the name
>> used in Indonesian, the official langauge, and would be 

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

[djakk djakk]

Hello !

There is also speed limit areas, a sign is posted at the entrance of the
area.

Imagine that a big part of Paris becomes a 30km/h area. Is it possible to
create a big polygon tagged with maxspeed=30, each street inside inherits
the maxspeed value of the big polygon ? (to escape the inheritance, simply
tag a segment of street with maxspeed=50 for example)


djakk



Le mer. 19 sept. 2018 à 14:22, Paul Johnson  a écrit :

> On Wed, Sep 19, 2018 at 7:18 AM Greg Troxel  wrote:
>
>>
>> Philip Barnes  writes:
>>
>> > And if the default actually applies, or has it been overriden by local
>> signage.
>> >
>> > I am not convinced that a default limit helps, if no speed limit has
>> been surveyed I would prefer that box not to be displayed in my app.
>> > a. It will not give me wrong and possibly costly information.
>> > b. It makes it obvious that I should survey and map the limit.
>> >
>> > Phil (trigpoint)
>>
>> Seconded.  It's actively harmful to display an incorrect limit.
>> Defaults will inevitably lead to it
>
>
> In practice, this tends to be easy to weed out, as exceptions aren't
> common (in an overall view of centerline road miles) and quickly dispatched
> in a short series of surveys or even by armchair if there's OpenStreetCam,
> Mapillary or Bing Streetside imagery available.
> ___
> 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] maxspeed:type vs source:maxspeed // StreetComplete

[Tobias Zwick]

This is an interesting idea (inspired by the ongoing discussion about
mapping language borders?), but unfortunately it wouldn't work.

Sorry for linking to this all the time but it is really necessary in
order to understand the big picture:
https://wiki.openstreetmap.org/wiki/Default_speed_limits

It wouldn't work because legislation on max speed is not that easy. Some
points:

1. OSM highway classifications (secondary,tertiary,...) do not and
   cannot follow the same scheme as how the roads are grouped for the
   purpose of defining different max speeds in legislation.

   Examples:
   - In California (US-CA), the default speed limit for residence
 districts and business districts is 25 mph. But there is no
 highway=business (etc.)
   - In Indiana (US-IN), the default speed limit on US interstates is
 70 mph. Now, not all highway=motorway are interstates and not
 all interstates are necessarily highway=motorway.

2. Max default speeds can depend not only on the road type / area but
   also on vehicle type, its designation and its properties (weight, no
   of seats, with trailer? ...), furthermore even on the time of day and
   weather condition.

   Examples: See Portugal (PT), see Poland (PL), European countries

3. (As hinted at by the last point) what road type category applies can
   not always be determined by looking at one tag (a "classification"
   of some kind) only.

   Examples:
   - In California (US-CA), any road with 2 or more lanes in *each*
 direction has a default speed limit of 65 mph
   - In Alabama (US-AL), the default speed limit for roads without
 alphalt or concrete surface is 35 mph (usually it is 55 mph).
   - In Germany (DE), there is no speed limit on dual carriageways
 and single carriageways with 2 or more lanes in each direction
 for passenger cars, independent on whether they are classified
 as motorways or motorroads or not

Cheers
Tobias

On 19/09/2018 08:01, Tod Fitch wrote:
> 
>> On Sep 18, 2018, at 6:19 PM, Joseph Eisenberg  
>> wrote:
>>
>> So on the boundary=administrative admin_level=6 for Rogers County, we could 
>> have something like maxspeed:type:default=45mph
> 
> Except that more typically there will be different default speed limits on 
> each of the various OSM highway classifications. So maybe something more like 
> “maxspeed:default:residential=25 mph”.
> 
> But I imagine there are other types of tags that might benefit from the 
> ability to give defaults for a geographic area. So possibly it would be 
> better to have “default:maxspeed:residential=25 mph” where and entire 
> “default:*” namespace is created. For California something like:
> 
> “default:maxspeed = 65 mph” // State wide maximum for all roads unless 
> otherwise tagged or overridden by a more specific default
> “default:maxspeed:primary = 55 mph”// More specific default speed limits 
> specific OSM road classifications
> “default:maxspeed:secondary = 55 mph”
> “default:maxspeed:tertiary = 55 mph”
> “default:maxspeed:unclassified = 30 mph”
> “default:maxspeed:residential = 30 mph”
> “default:maxspeed:service = 15 mph”
> 
> 
>> On Sep 18, 2018, at 10:15 PM, Mark Wagner  wrote:
>>
>> . . .
>>
>> The third law: RCW 46.61.400(1).  "No person shall drive a vehicle on a
>> highway at a speed greater than is reasonable and prudent under the
>> conditions and having regard to the actual and potential hazards then
>> existing."
>>
>> As a highway engineer pointed out to me recently, most county roads,
>> especially unpaved ones, are designed around a speed limit of
>> "reasonable and prudent".  The 50 MPH limit established by RCW
>> 46.61.400(2)(b) simply sets a firm upper boundary; it's quite possible
>> to get a speeding ticket at a lower speed.
>>
>> Sure, you can put a number on any road.  But for most rural roads
>> without speed-limit signs, the number is unrelated to how fast you can
>> drive on that road.
>>
> 
> California, and I suspect most if not all other states, has a reasonable and 
> prudent clause in the speed statutes too. So depending on conditions, 
> especially weather conditions, theoretically you can get a speeding ticket 
> while driving under the signed or prima facia speed limit.
> 
> However I think that is a diversionary argument that basically implies that 
> we can’t tag any road with a speed limit because the default or signed speed 
> limit can be trumped by a reasonable and prudent clause in the motor vehicle 
> code.
> 
> I am a little curious about the highway engineer’s statement though. While 
> not a civil engineer, I’ve had some interest in the field and the highway 
> design books on my shelf (admittedly pretty old ones) all work off a design 
> speed that is a specific number. Not a nebulous “reasonable and proper”. The 
> design speed used to compute required sight distances, turn radii, ruling and 
> maximum grades, etc.
> 
> 
> 
> 
> ___
> Tagging mailing list
> 

Re: [Tagging] landuse for government offices ?

[egil]

+1

On 9/18/18 11:47 PM, Clifford Snow wrote:

I would accept civic_admin as well.

Markus - do you want to revive the proposal? I'd like to see this 
become a approved tag.



On Tue, Sep 18, 2018 at 1:15 PM OSMDoudou 
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com 
> wrote:


I'll go for civic_admin. Sounds specific enough. Thx.


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



--
@osm_seattle
osm_seattle.snowandsnow.us 
OpenStreetMap: Maps with a human touch

___
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] maxspeed:type vs source:maxspeed // StreetComplete

[Paul Johnson]

On Wed, Sep 19, 2018 at 7:18 AM Greg Troxel  wrote:

>
> Philip Barnes  writes:
>
> > And if the default actually applies, or has it been overriden by local
> signage.
> >
> > I am not convinced that a default limit helps, if no speed limit has
> been surveyed I would prefer that box not to be displayed in my app.
> > a. It will not give me wrong and possibly costly information.
> > b. It makes it obvious that I should survey and map the limit.
> >
> > Phil (trigpoint)
>
> Seconded.  It's actively harmful to display an incorrect limit.
> Defaults will inevitably lead to it


In practice, this tends to be easy to weed out, as exceptions aren't common
(in an overall view of centerline road miles) and quickly dispatched in a
short series of surveys or even by armchair if there's OpenStreetCam,
Mapillary or Bing Streetside imagery available.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Paul Johnson]

On Wed, Sep 19, 2018 at 7:09 AM Greg Troxel  wrote:

> Tod Fitch  writes:
>
> >> On Sep 18, 2018, at 6:19 PM, Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
> >>
> >> So on the boundary=administrative admin_level=6 for Rogers County, we
> could have something like maxspeed:type:default=45mph
> >
> > Except that more typically there will be different default speed
> > limits on each of the various OSM highway classifications. So maybe
> > something more like “maxspeed:default:residential=25 mph”.
>
> I am not aware of *unposted* default limits in the US being different by
> an entity smaller than state.   In Massachusetts, there are default
> limits in state statutes, in particularly 30 mph in "thickly settled"
> areas (also defined in statute).  Some towns have adopted 25 mph in
> thickly settled areas, and they have signs at the town borders.
>

Kansas and Oklahoma definitely do, often putting a specific default limit
in their town's motor vehicle code.  Tulsa does this, and it's in the top
1% largest of US cities.


> It's an interesting question at what level to tag individual roads and
> when to have some way of expressing rules and therefore to expect all
> data consumers to evaluate the rules.  My quick reaction is that
> publishing rules for regions smaller than states is going to be too
> messy, vs just tagging the ways.
>

Streamlines things, too, on the data consumer end.


> In Mass, we have speed limit tags on almost all legal roads.  To me,
> that seems like the most straightforward approach, even if there are
> also defaults.
>

I tend to agree, also makes it unambiguous where a smaller jurisdiction has
a different default than the one it is inside of, especially if there's
weirdness where the smaller jurisdiction is higher than the larger one for
some reason.


> If the general defaults are intended for routing, that seems more or
> less ok.  If they are intended to actually provide speed limit guidance
> to drivers, I'm opposed, at least in jurisdictions where they aren't
> strictly reliable.


AFAICT, the only places that have huge, state-or-national default limits
that don't get too messy to map as default on an area would be the EU,
everywhere else doesn't seem to be anywhere near as organized on a large
scale.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Greg Troxel]

Philip Barnes  writes:

> And if the default actually applies, or has it been overriden by local 
> signage.
>
> I am not convinced that a default limit helps, if no speed limit has been 
> surveyed I would prefer that box not to be displayed in my app.
> a. It will not give me wrong and possibly costly information.
> b. It makes it obvious that I should survey and map the limit.
>
> Phil (trigpoint) 

Seconded.  It's actively harmful to display an incorrect limit.
Defaults will inevitably lead to it.

Using them for routing is ok.

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

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

[Greg Troxel]

Colin Smale  writes:

> A "maximum" speed does not mean an "advised" speed. If you are driving
> at an unsuitable speed, below the posted maximum, in Europe you will not
> get a ticket for "speeding" as such but you may get one for "dangerous
> driving" or something similar. The obligation to drive in a safe way
> overrides all other more specific limitations. Think of overtaking -
> just because it's not prohibited, doesn't make it safe (reasonable and
> prudent). 

Mostly agreed, but in the US you can get a speeding citation in this
case.  But usually you won't.

> There is no point in trying to reflect this "reasonable and prudent"
> stuff in OSM. We should stick to the objective limits, by virtue of
> signposting and/or statutes.

Certainly I agree that trying to encode reaasonable and prudent is
crazy.

From my US driving, I would agree that encoding the actual posted or
legal limit as maxspeed is entirely satisfactory for the purpose of
communicating limits to drivers.  For routing, it's necessary to know
that sometimes typical speeds are faster, in order to get good routes
(e.g. 45 mph posted, traffic normally 65, vs another road posted 40 mph,
traffic normally 43 mph).  Needing to use a slower prudent speed for
routing happens very rarely (around me).

In the UK, I found that the default 60 mph out-of-town limit was often
faster than I considered safe, and there a lower maxspeed:practical for
routing is in order.   US-only drivers will find this surprising.


Finally, I wonder how much of this is all about streetcomplete users
being asked to input limits when there aren't signs but there are laws.
OSM's notion of verifiability has in my mind (generally, not this
discussion) been expressed too strictly; looking up the law and noting
lack of signs is entirely adequate as verification for entering limits.



Overall, I think my most useful point is that maxspeed about the law and
speeds for routing are separate issues.

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

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

[Greg Troxel]

Tod Fitch  writes:

>> On Sep 18, 2018, at 6:19 PM, Joseph Eisenberg  
>> wrote:
>> 
>> So on the boundary=administrative admin_level=6 for Rogers County, we could 
>> have something like maxspeed:type:default=45mph
>
> Except that more typically there will be different default speed
> limits on each of the various OSM highway classifications. So maybe
> something more like “maxspeed:default:residential=25 mph”.

I am not aware of *unposted* default limits in the US being different by
an entity smaller than state.   In Massachusetts, there are default
limits in state statutes, in particularly 30 mph in "thickly settled"
areas (also defined in statute).  Some towns have adopted 25 mph in
thickly settled areas, and they have signs at the town borders.

It's an interesting question at what level to tag individual roads and
when to have some way of expressing rules and therefore to expect all
data consumers to evaluate the rules.  My quick reaction is that
publishing rules for regions smaller than states is going to be too
messy, vs just tagging the ways.

With respect to maxspeed:default:residential, that's totally unworkable
in Massachusetts.  The law does not talk about roads or even define them
as residential or not.   The question for 30 (vs 40) is whether the road
is "thickly settled", which is

  built up with structures devoted to business, or the territory
  contiguous to any way where the dwelling houses are situated at such
  distances as will average less than two hundred feet between them for
  a distance of a quarter of a mile or over.

So there are many roads that are properly tagged "residential" but are
not subject to the lower speed.

In Mass, we have speed limit tags on almost all legal roads.  To me,
that seems like the most straightforward approach, even if there are
also defaults.

If the general defaults are intended for routing, that seems more or
less ok.  If they are intended to actually provide speed limit guidance
to drivers, I'm opposed, at least in jurisdictions where they aren't
strictly reliable.

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

[Tagging] Feature Proposal - RFC - Free drinking water by private entities

[bkil]

I'd like to discuss three related proposals and two separate ones that
can be confused with the others. In all the below cases, the
availability is tied to the opening_hours of the containing POI.

Five separate proposals could have been created, but I feel that the
concepts and words describe these are so close, it is best to have a
good overview.

I'm open to suggestions both related to the tags themselves and how we
should structure and document this proposal in the wiki.

https://wiki.openstreetmap.org/wiki/Proposed_features/Free_drinking_water_by_private_entities

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

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

[Tobias Zwick]

This does not present a problem:

> The first set

Well, as you write yourself, they may be authorized to set own speed
limits, but they need to signpost it.

> The second

So these are the type of regulations I mean with "default speed limits".

> The third law

As Martin Koppenhoefer stated on another discussion branch, this kind of
paragraph in legislation is not specific to the US. All/most
legislations have a sentence like this - it only differs how a breach of
this is persecuted. But well, Martin Koppenhoefer and Colin Smale
already wrote what there is to say about it.

On 19/09/2018 07:15, Mark Wagner wrote:
> On Tue, 18 Sep 2018 20:36:06 +0200
> Tobias Zwick  wrote:
> 
>> From your anecdote, it seems, an implicit speed limit tagging scheme
>> is even more important in the US than for example in the UK
> 
> In my part of the US, a meaningful implicit speed limit tagging scheme
> is impossible, due to the three sets of laws regarding speed limits.
> 
> The first set is RCW 46.61.405, 46.61.410, 46.61.415, and 46.61.419,
> which give various people the authority to set signed speed limits,
> obedience to which is required by RCW 46.61.050.
> 
> The second is RCW 46.61.400(2), which establishes default speeds of
> 25 MPH on city streets, 50 MPH on county roads, and 60 MPH on state
> highways.  This would seem rather comprehensive, except for:
> 
> The third law: RCW 46.61.400(1).  "No person shall drive a vehicle on a
> highway at a speed greater than is reasonable and prudent under the
> conditions and having regard to the actual and potential hazards then
> existing."
> 
> As a highway engineer pointed out to me recently, most county roads,
> especially unpaved ones, are designed around a speed limit of
> "reasonable and prudent".  The 50 MPH limit established by RCW
> 46.61.400(2)(b) simply sets a firm upper boundary; it's quite possible
> to get a speeding ticket at a lower speed.
> 
> Sure, you can put a number on any road.  But for most rural roads
> without speed-limit signs, the number is unrelated to how fast you can
> drive on that road.
> 


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

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

[Tobias Zwick]

> (Incidentally, I think 7 of the 8 Australian states & territories have
> the same limits?)

Almost. Western Australia and Northern Territory has 110 km/h, Tasmania
100 km/h only on concrete or asphalt surface and 80 km/h otherwise;
Northern Territory furthermore sets the speed limit within built-up
areas to 60 km/h.

I am linking this often, but it is really necessary to get on the same
page: https://wiki.openstreetmap.org/wiki/Default_speed_limits

On 19/09/2018 08:10, Graeme Fitzpatrick wrote:
> 
> 
> On Wed, 19 Sep 2018 at 13:30, Joseph Eisenberg
> mailto:joseph.eisenb...@gmail.com>> wrote:
> 
> So on the boundary=administrative admin_level=6 for Rogers County,
> we could have something like maxspeed:type:default=45mph
> 
> 
> Just after crossing over the border into the state of Queensland, you
> have this
> sign: 
> https://www.google.com/maps/@-28.1592952,153.4932922,3a,75y,288.32h,90t/data=!3m6!1e1!3m4!1sXT0hBPanAoGnfz9N-Ugbyw!2e0!7i13312!8i6656
> 
> (Incidentally, I think 7 of the 8 Australian states & territories have
> the same limits?)
> 
> I understand (I think!) that your system would set this as a default for
> all Qld roads?
> 
> But based on what? How does OSM know that this stretch of road is in
> either a rural or a built-up area?
>  
> Thanks
> 
> Graeme
> 
> 
> ___
> 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] maxspeed:type vs source:maxspeed // StreetComplete

[Colin Smale]

A "maximum" speed does not mean an "advised" speed. If you are driving
at an unsuitable speed, below the posted maximum, in Europe you will not
get a ticket for "speeding" as such but you may get one for "dangerous
driving" or something similar. The obligation to drive in a safe way
overrides all other more specific limitations. Think of overtaking -
just because it's not prohibited, doesn't make it safe (reasonable and
prudent). 

There is no point in trying to reflect this "reasonable and prudent"
stuff in OSM. We should stick to the objective limits, by virtue of
signposting and/or  statutes.

On 2018-09-19 09:51, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 19. Sep 2018, at 08:01, Tod Fitch  wrote:
>> 
>> California, and I suspect most if not all other states, has a reasonable and 
>> prudent clause in the speed statutes too. So depending on conditions, 
>> especially weather conditions, theoretically you can get a speeding ticket 
>> while driving under the signed or prima facia speed limit.
>> 
>> However I think that is a diversionary argument that basically implies that 
>> we can't tag any road with a speed limit because the default or signed speed 
>> limit can be trumped by a reasonable and prudent clause in the motor vehicle 
>> code.
> 
> I'd guess most jurisdictions will have a clause like this, Italy and Germany 
> have them as well, but unless you are involved in an accident you won't get 
> into problems as long as you respect the signposted or default limits. There 
> may be different implicit limits for certain weather conditions (e.g. 50kph 
> if visibility is inferior to 50m), but this is not comparable to vague 
> indications like "reasonable".
> 
> 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] Draft Proposal: Default Langauge Format

[Jo]

Every street in Brussels HAS a name:fr tag. They also ALL have a name:nl
tag.

An IPA representation also needs information about the language it is for.
A name, even spelled with the exact same characters will be pronounced
differently by a French speaker compared to a Ducht speaker. Sometimes very
differently, sometimes it's simply a matter of which syllable to stress.

Polyglot

Op wo 19 sep. 2018 om 04:43 schreef Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> Paul,
>
> Thank you for your comments.
> Have you read the complete Proposal page
> ?
> Perhaps I need to improve the wording to clarify some of your concerns
>
> >”I'd rather have local languages mapped rather than the language the
>>> renderer 'should' use.”
>>>
>>> By recording each name in a separate “name:=*” tag, database users
>>> and map makers will be able to pick the best name for their audience.
>>>
>>
>> The best name for the audience is the one which matches the signage.  It
>> does me no good to see an English
>> translation of a Russian street sign.
>>
>
> This is true if your database use case is rendering a map for a local
> audience. That's why the Openstreetmap Carto style renders names this way.
> This proposal will not change the way names are rendered on the standard
> map, except in the rare case where, for example, "name:fr=*" is present on
> a feature in France but the "name=*" tag is missing. In this case it will
> now render properly.
>
> But not all names are street or shop names. There are internationally know
> features, like Mt Everest and the Yellow River, which have well-known names
> in many names, which are quite different than the locally used name. Take a
> look at the current rendering of Nepal or China. The Openstreetmap Carto
> style is useful if you are in Nepal and want to find a sign point you
> towards Mt Everest, but a person sitting at their computer in Brazil will
> have trouble finding the mountain on the standard map style.
>
> The French style already renders names in French preferentially, but this
> loses the information about the locally used name. I agree that this is a
> problem!
> But with the current use of names, it's not possible to make an
> international map style that shows French names and the locally name at the
> same time.
> If you try to render "name:fr=*" and "name=*" together, you'll render the
> French name twice for every street in Brussels
>
>
>> The only thing the map should render is the name as it is displayed on
>> signage.
>>
>
> For local routing yes, for Openstreetmap Carto yes, but all applications?
> Not always
>
>
>> It would also be useful if the IPA characters representing how a local
>> would pronounce that name is present so applications could feed that
>> to text-to-speech.
>>
>
> Yes! IPA is a great idea. I believe "name:ipa=*" could work for this. Want
> to write up a proposal? :-)
>
>
>> It is also somewhat useful, for multilingual signage, to use name:xx and
>> name:yy to hold the individual
>> language components of that name.
>>
>
> You've got it! That's exactly what we want to encourage. If every street
> in Brussels has name:fr=xx and name:nl=yy, the French map style could
> render both.
> ( Or being the French, they might just render "name:fr=yy", but
> there's nothing to be done about that. )
>
>>
>> The local name still needs to be specified so that database users know
>>> what name or names are actually used “on the ground” vs foreign names. The
>>> default language format tag makes this possible, but separates this
>>> function from the name=* tag. And the proposal includes a language:local
>>> tag so that all local names can be shown, even those that are less common
>>> or in a minority language.
>>>
>>
>> No, no and thrice no.
>>
>
> ??? What are you objecting to here? The "language:local=" tag?
> This will not be rendered by Openstreetmap Carto style or anyone really.
> It just lets database users that certain languages are actually locally
> used names, vs foreign names.
>
> For example, Puncak Trikora (id) / Wilhelmina Top (nl) / Mount Trikora
> (en) is the 2nd or 3rd tallest mountain in Indonesia. It's currently tagged
> with name="Puncak Trikora", which is appropriate, because that's the name
> used in Indonesian, the official langauge, and would be recognized by most
> people in the country. But there is also a local name in the Lani language,
> which is only known to people who live closest to the mountain and isn't
> used on any offical signs. This language:local= tag would show that the
> Lani name for the mountain is in fact a local name, not a foreign language
> name.
>
> It's probably not a tag that will be used much in Europe, where minority
> languages often have official recognition and signage, but it will be quite
> helpful in parts of the world with many languages, particularly for
> mountains and rivers that may have foreign names from the 

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

[Martin Koppenhoefer]

sent from a phone

> On 19. Sep 2018, at 08:01, Tod Fitch  wrote:
> 
> California, and I suspect most if not all other states, has a reasonable and 
> prudent clause in the speed statutes too. So depending on conditions, 
> especially weather conditions, theoretically you can get a speeding ticket 
> while driving under the signed or prima facia speed limit.
> 
> However I think that is a diversionary argument that basically implies that 
> we can’t tag any road with a speed limit because the default or signed speed 
> limit can be trumped by a reasonable and prudent clause in the motor vehicle 
> code.


I’d guess most jurisdictions will have a clause like this, Italy and Germany 
have them as well, but unless you are involved in an accident you won’t get 
into problems as long as you respect the signposted or default limits. There 
may be different implicit limits for certain weather conditions (e.g. 50kph if 
visibility is inferior to 50m), but this is not comparable to vague indications 
like “reasonable”.

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

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

[Philip Barnes]

And if the default actually applies, or has it been overriden by local signage.

I am not convinced that a default limit helps, if no speed limit has been 
surveyed I would prefer that box not to be displayed in my app.
a. It will not give me wrong and possibly costly information.
b. It makes it obvious that I should survey and map the limit.

Phil (trigpoint) 

On 19 September 2018 07:10:27 BST, Graeme Fitzpatrick  
wrote:
>On Wed, 19 Sep 2018 at 13:30, Joseph Eisenberg
>
>wrote:
>
>> So on the boundary=administrative admin_level=6 for Rogers County, we
>> could have something like maxspeed:type:default=45mph
>
>
>Just after crossing over the border into the state of Queensland, you
>have
>this sign:
>https://www.google.com/maps/@-28.1592952,153.4932922,3a,75y,288.32h,90t/data=!3m6!1e1!3m4!1sXT0hBPanAoGnfz9N-Ugbyw!2e0!7i13312!8i6656
>(Incidentally, I think 7 of the 8 Australian states & territories have
>the
>same limits?)
>
>I understand (I think!) that your system would set this as a default
>for
>all Qld roads?
>
>But based on what? How does OSM know that this stretch of road is in
>either
>a rural or a built-up area?
>
>Thanks
>
>Graeme

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 19. Sep 2018, at 03:19, Joseph Eisenberg  
> wrote:
> 
> So on the boundary=administrative admin_level=6 for Rogers County, we could 
> have something like maxspeed:type:default=45mph


and if your app shows the wrong speed limit you simply have to check 
additionally all admin entities around you to fix it. And if the boundary 
breaks you won’t have speed limits anymore (or limits from the wrong admin 
entity). It would be a top down approach, and I don’t believe it would be 
better than what we currently do, if we used inheritance for properties like 
speed limits. It doesn’t work well with our general system (people observing 
locally, flat system without too much abstraction).

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

Re: [Tagging] Stormwater outlet into stream

[Jonathon Rossi]

Thanks Graeme.


> I did this:
> https://www.openstreetmap.org/node/5213660838#map=19/-28.07783/153.42664
> for one stormwater drain nearby.
>

I don't quite understand the way extending to the north in your example
tagged just man_made=yes and surface=grass, is that the underground pipe
joining to the rest of the network?

Would that work for your purposes?
>

Regarding the node on the end, yes I think it should work. I always viewed
man_made=pipeline for legit big pressurised pipelines but I can't see any
harm using it for stormwater drains especially that some get really big.

man_made=pipeline
location=underground
substance=rainwater

The wiki page says man_made=pipeline shouldn't be applied to nodes but
there are already nearly 4000 so that can change, or if I have a decent
idea which way the underground pipes go (easy for the big ones) just map a
short way.

Thinking about how this would apply to other waterways I've mapped, I
currently map the streams or drains that pass under roads which rainwater
passes through like below, these are quite similar but with a completely
different tagging scheme.

waterway=drain or stream
tunnel=culvert
layer=-1

Do we use waterway=* where it is a naturally occurring stream but humans
earthfilled the location with a concrete culvert and put a road over the
top but that is still part of the earth's waterways of the creek system.
Can't be true because waterway=drain is for man made waterways.

This tagging also appears valid for a big stormwater drain where you can
walk into it:

waterway=drain
tunnel=flooded
location=underground
(https://wiki.openstreetmap.org/wiki/Tag:tunnel%3Dflooded)

Unfortunately it doesn't render in any way, so there's nothing showing on
> the map to indicate that there's anything there, until you go into edit
> mode :-(
>

I'm not too worried about rendering. In the past I've left a note on the
first node because these drain outlets usually can't be seen from aerial
imagery and many times the creek directly where it pours doesn't even look
like a creek from aerial imagery, so the intention was to capture the
information to ensure armchair mappers don't "fix" the creek.

As usual each time I post on the mailing list it opens a can of worms and I
learn too much about all the different possible tags :).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Stormwater outlet into stream

[Andrew Harvey]

I agree with https://www.openstreetmap.org/node/5213660838

location=underground
man_made=pipeline
substance=rainwater

I think it's okay to place this on a node if you don't know the
location the pipeline goes underground, even if the tags were meant
for ways.

Personally I would just add a way a few meters long to the end of the
stream and tag that, instead of a node.

But I'd omit the name unless it has one, "Stormwater easement" is more
a description than a name.
On Wed, 19 Sep 2018 at 16:16, Graeme Fitzpatrick  wrote:
>
>
>
> On Wed, 19 Sep 2018 at 13:04, Jonathon Rossi  wrote:
>>
>> I've come across the desire to map a stormwater outlet at the beginning of a 
>> stream a few times now and have failed to find an appropriate tag to place 
>> on the node.
>
>
> Hi Jono
>
> I did this: 
> https://www.openstreetmap.org/node/5213660838#map=19/-28.07783/153.42664 for 
> one stormwater drain nearby.
>
> Would that work for your purposes?
>
> Unfortunately it doesn't render in any way, so there's nothing showing on the 
> map to indicate that there's anything there, until you go into edit mode :-(
>
> Thanks
>
> Graeme
> ___
> 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] Stormwater outlet into stream

[Graeme Fitzpatrick]

On Wed, 19 Sep 2018 at 13:04, Jonathon Rossi  wrote:

> I've come across the desire to map a stormwater outlet at the beginning of
> a stream a few times now and have failed to find an appropriate tag to
> place on the node.
>

Hi Jono

I did this:
https://www.openstreetmap.org/node/5213660838#map=19/-28.07783/153.42664
for one stormwater drain nearby.

Would that work for your purposes?

Unfortunately it doesn't render in any way, so there's nothing showing on
the map to indicate that there's anything there, until you go into edit
mode :-(

Thanks

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

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

[Graeme Fitzpatrick]

On Wed, 19 Sep 2018 at 13:30, Joseph Eisenberg 
wrote:

> So on the boundary=administrative admin_level=6 for Rogers County, we
> could have something like maxspeed:type:default=45mph


Just after crossing over the border into the state of Queensland, you have
this sign:
https://www.google.com/maps/@-28.1592952,153.4932922,3a,75y,288.32h,90t/data=!3m6!1e1!3m4!1sXT0hBPanAoGnfz9N-Ugbyw!2e0!7i13312!8i6656
(Incidentally, I think 7 of the 8 Australian states & territories have the
same limits?)

I understand (I think!) that your system would set this as a default for
all Qld roads?

But based on what? How does OSM know that this stretch of road is in either
a rural or a built-up area?

Thanks

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

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

[Tod Fitch]

> On Sep 18, 2018, at 6:19 PM, Joseph Eisenberg  
> wrote:
> 
> So on the boundary=administrative admin_level=6 for Rogers County, we could 
> have something like maxspeed:type:default=45mph

Except that more typically there will be different default speed limits on each 
of the various OSM highway classifications. So maybe something more like 
“maxspeed:default:residential=25 mph”.

But I imagine there are other types of tags that might benefit from the ability 
to give defaults for a geographic area. So possibly it would be better to have 
“default:maxspeed:residential=25 mph” where and entire “default:*” namespace is 
created. For California something like:

“default:maxspeed = 65 mph” // State wide maximum for all roads unless 
otherwise tagged or overridden by a more specific default
“default:maxspeed:primary = 55 mph”// More specific default speed limits 
specific OSM road classifications
“default:maxspeed:secondary = 55 mph”
“default:maxspeed:tertiary = 55 mph”
“default:maxspeed:unclassified = 30 mph”
“default:maxspeed:residential = 30 mph”
“default:maxspeed:service = 15 mph”


> On Sep 18, 2018, at 10:15 PM, Mark Wagner  wrote:
> 
> . . .
> 
> The third law: RCW 46.61.400(1).  "No person shall drive a vehicle on a
> highway at a speed greater than is reasonable and prudent under the
> conditions and having regard to the actual and potential hazards then
> existing."
> 
> As a highway engineer pointed out to me recently, most county roads,
> especially unpaved ones, are designed around a speed limit of
> "reasonable and prudent".  The 50 MPH limit established by RCW
> 46.61.400(2)(b) simply sets a firm upper boundary; it's quite possible
> to get a speeding ticket at a lower speed.
> 
> Sure, you can put a number on any road.  But for most rural roads
> without speed-limit signs, the number is unrelated to how fast you can
> drive on that road.
> 

California, and I suspect most if not all other states, has a reasonable and 
prudent clause in the speed statutes too. So depending on conditions, 
especially weather conditions, theoretically you can get a speeding ticket 
while driving under the signed or prima facia speed limit.

However I think that is a diversionary argument that basically implies that we 
can’t tag any road with a speed limit because the default or signed speed limit 
can be trumped by a reasonable and prudent clause in the motor vehicle code.

I am a little curious about the highway engineer’s statement though. While not 
a civil engineer, I’ve had some interest in the field and the highway design 
books on my shelf (admittedly pretty old ones) all work off a design speed that 
is a specific number. Not a nebulous “reasonable and proper”. The design speed 
used to compute required sight distances, turn radii, ruling and maximum 
grades, etc.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging