Re: [Tagging] track smoothness/quality

[Mateusz Konieczny]

7 lip 2019, 01:57 od bradha...@fastmail.com:

> What wiki are you looking at?   At 
> https://wiki.openstreetmap.org/wiki/Key:tracktype,  grade5 says
> "Soft.
> Almost always an unimproved track lacking hard materials, same as surrounding 
> soil. "
>
> What if the surrounding soil is hard materials???
> Clearly written by someone that has not seen rocky soil.
>
There is already "almost". I think that it would
be ok to use different criteria for road on a bare rock.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] track smoothness/quality

[brad]

That is true if the terrain is agreeable.  Often it is steep and a very 
loose rocky surface so 4wd is necessary.  Even if it isn't very steep, 
since it is not maintained very often, if at all, erosion creates 
hazards in the road also requiring 4wd or at least a very high clearance 
vehicle.


*"Tracktype* is a measure of how well-maintained a track or other minor 
road is..."



On 7/6/19 6:21 PM, Joseph Eisenberg wrote:
I would think that an unimproved track across naturally solid rock or 
naturally well-compacted gravel would not be tracktype=grade5 - while 
it might be bumpy, it’s probably passable by any vehicke with 
sufficient clearance and tire size, even when wet, unlike a track of 
unimproved clay, silt or loam which requires 4wd or is simply 
impassable when it rains? But I’m not an expert on 4wd.


On Sun, Jul 7, 2019 at 8:58 AM brad > wrote:


What wiki are you looking at?   At
https://wiki.openstreetmap.org/wiki/Key:tracktype, grade5 says
"Soft.
Almost always an unimproved track lacking hard materials, same as
surrounding soil. "

What if the surrounding soil is hard materials???
Clearly written by someone that has not seen rocky soil.

Brad

On 7/3/19 2:09 AM, Mark Wagner wrote:
> Option 3 won't work.  Locally, tracks come in two basic types:
>
> 1) A logging road created by a work crew with a bulldozer.  Cut down
> any trees, scrape off any remaining vegetation, level the road
> side-to-side, and call it done.  These roads range in quality from
> "easily passable by a passenger car" to "high-clearance
> four-wheel-drive vehicle required".
>
> 2) A ranch road created by a truck driving the same route repeatedly
> for years.  These are generally fairly smooth, but the older
ones are
> only passable by a high-clearance truck because of the central ridge
> between the tracks.
>
> According to the wiki, these are uniformly "grade5" ("Almost
always an
> unpaved track lacking additional materials, same surface as
surrounding
> terrain."), although calling them "soft" is misleading, since
the local
> soil produces a rock-hard surface during the summer and fall (and a
> muddy one during spring melt). They're tagged pretty much at
random as
> anything from "grade1" to "grade5".
>


___
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] Rethinking Map Features

[Joseph Eisenberg]

From the talk page:

>I propose to tackle the varying quality of this page in different languages by 
>changing Map
>Features to a single multilingual page that outputs its text in the user’s 
>preferred interface
>language.

>The tag tables can be generated from Taginfo/Taglists. For the best results it 
>should be
>possible to set the description of each tag in each language ahead of writing 
>a long-form
>documentation page.

>The introduction becomes a translatable {{int:…}} string, the message for each 
>language
>transcluding a template of the actual introduction.

>The section headings and table headers also become {{int:…}} messages.

>--Andrew (talk) 11:47, 5 July 2019 (UTC)

>Generating the tables from taginfo taglists is a good idea. But {{int:…}} 
>would require the
>translations to live in the MediaWiki: namespace, which is only editable by 
>administrators.'
>While that's reasonable for widely used templates, elements like the 
>introduction to this
>page are only relevant to a single page. If we rely on taginfo taglists, then 
>there's not as
>much to translate manually as part of the page anyways. – Minh Nguyễn  22:06, 
>6 July
>2019 (UTC)

I partially agree with Minh's comments. It would be easier to maintain
the page if the descriptions came directly from the description=*
field in the ValueDescription box on each Tag page. This would also
make it clear that a feature can't be added to Map Features without a
wiki page (something that happens surprisingly often).

I've been trying to updated the translated Indonesian Map Features
page. The biggest problem is that you need to check each of the newly
added features on the English page to check if they are actually
approved or de facto tags, rather than a new tag that was added
without discussion. I've already removed a number of tags from the
amenities section that were added without discussion in the past 2
years, but there are several more that should be discussed and status
changed to "De facto"'

My understanding is that tags on the Map Features page should be
status = De facto or status = approved, for consistency.

Perhaps it's possible to include an icon or text column on the Map
Features page that states the status of each tag, Approved, De facto,
In use, Proposed etc.? This would make it easier to find tags that
still need discussion

Joseph

On 7/7/19, Andrew Hain  wrote:
> I have been working on a scheme to improve the cross-language quality of Map
> Features.
> [https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features]
>
> Of course the page may deserve a bigger or deeper rethink.
>
> --
> Andrew
> Talk:Map Features - OpenStreetMap

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

Re: [Tagging] track smoothness/quality

[Joseph Eisenberg]

I would think that an unimproved track across naturally solid rock or
naturally well-compacted gravel would not be tracktype=grade5 - while it
might be bumpy, it’s probably passable by any vehicke with sufficient
clearance and tire size, even when wet, unlike a track of unimproved clay,
silt or loam which requires 4wd or is simply impassable when it rains? But
I’m not an expert on 4wd.

On Sun, Jul 7, 2019 at 8:58 AM brad  wrote:

> What wiki are you looking at?   At
> https://wiki.openstreetmap.org/wiki/Key:tracktype,  grade5 says
> "Soft.
> Almost always an unimproved track lacking hard materials, same as
> surrounding soil. "
>
> What if the surrounding soil is hard materials???
> Clearly written by someone that has not seen rocky soil.
>
> Brad
>
> On 7/3/19 2:09 AM, Mark Wagner wrote:
> > Option 3 won't work.  Locally, tracks come in two basic types:
> >
> > 1) A logging road created by a work crew with a bulldozer.  Cut down
> > any trees, scrape off any remaining vegetation, level the road
> > side-to-side, and call it done.  These roads range in quality from
> > "easily passable by a passenger car" to "high-clearance
> > four-wheel-drive vehicle required".
> >
> > 2) A ranch road created by a truck driving the same route repeatedly
> > for years.  These are generally fairly smooth, but the older ones are
> > only passable by a high-clearance truck because of the central ridge
> > between the tracks.
> >
> > According to the wiki, these are uniformly "grade5" ("Almost always an
> > unpaved track lacking additional materials, same surface as surrounding
> > terrain."), although calling them "soft" is misleading, since the local
> > soil produces a rock-hard surface during the summer and fall (and a
> > muddy one during spring melt). They're tagged pretty much at random as
> > anything from "grade1" to "grade5".
> >
>
>
> ___
> 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] track smoothness/quality

[brad]

What wiki are you looking at?   At 
https://wiki.openstreetmap.org/wiki/Key:tracktype,  grade5 says

"Soft.
Almost always an unimproved track lacking hard materials, same as 
surrounding soil. "


What if the surrounding soil is hard materials???
Clearly written by someone that has not seen rocky soil.

Brad

On 7/3/19 2:09 AM, Mark Wagner wrote:

Option 3 won't work.  Locally, tracks come in two basic types:

1) A logging road created by a work crew with a bulldozer.  Cut down
any trees, scrape off any remaining vegetation, level the road
side-to-side, and call it done.  These roads range in quality from
"easily passable by a passenger car" to "high-clearance
four-wheel-drive vehicle required".

2) A ranch road created by a truck driving the same route repeatedly
for years.  These are generally fairly smooth, but the older ones are
only passable by a high-clearance truck because of the central ridge
between the tracks.

According to the wiki, these are uniformly "grade5" ("Almost always an
unpaved track lacking additional materials, same surface as surrounding
terrain."), although calling them "soft" is misleading, since the local
soil produces a rock-hard surface during the summer and fall (and a
muddy one during spring melt). They're tagged pretty much at random as
anything from "grade1" to "grade5".




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

Re: [Tagging] Feature Proposal - RFC - waterway=tidal_channel

[Warin]

On 07/07/19 00:38, Joseph Eisenberg wrote:

How are handled the concepts of intermittence and direction of the flow in
the tagging?
Should we use intermittent=yes and direction=both, or are they implied by
waterway=tidal_channel?
...only recommend the use of intermittent=yes on
channels which are fully empty at low tide time.

Thank you for bringing this up

I agree that most tidal channels are not intermittent, because they
tend to have a small amount of water flowing towards the sea at low
tide. It could be reasonable to use intermittent=yes on small tidal
channels that are completely dry at low tide.


These area of no water at low tide could be better mapped if OSM had a method 
for tagging the low tide mark.
Would be handy for some beaches, particularly where the tide is large and the 
area has a small slope creating a large area between high and low tides.





Bidirectional water flow (that is, the direction of water flow
reverses at different times in the tidal cycle) should be implied by
the tag waterway=tidal_channel, though there may be rare exceptions.annel'.


If the flow is not 'tidal' then it should not be tagged 'tidal_channel". No 
exceptions?



I don't know if the tag "direction=both" is used commonly with
waterways. There's no wiki page to describe this tag, and the page
Key:direction doesn't mention direction=both, though it's used 20,000
times. More common is to add the tag "tidal=yes" to river estuaries
which are clearly affected by the tides, though this does not
necessary require reversal of water flow direction.

The wiki page for waterway=tidal_channel should mention that
"tidal=yes" is implied.

-Joseph


Other channels will have a lower level but won't be empty.

Let me know how do you feel about this

All the best

François

Le sam. 6 juil. 2019 à 14:43, Joseph Eisenberg 
a écrit :


I'd like to vote on the proposal for waterway=tidal_channel soon

If you haven't read the page yet, please check and add any  comments
or bring up any problems that might have been missed.


https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel

"Definition:A natural intertidal waterway in mangroves, salt marshes
and tidal flats with water flow in the direction of the tide"

-Joseph




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

Re: [Tagging] track smoothness/quality

[brad]

Here's one,
https://www.dropbox.com/s/agj4njek1r35vnz/2018-10-03-13.06.54r.jpg?dl=0
Maybe gets some maintenance every 10 or 20 years or so.  It is probably 
never soft, so it doesn't fit any tracktype definition. It is still used 
for a couple of  mines (worked by 1 or 2 people), but mostly 
recreational use.   This is higher altitude than most, but not unusual 
in the western US.


I think tracktype as specified is only useful for a small portion of the 
world.  Useful for flat, wet regions.



On 7/2/19 11:02 PM, Mateusz Konieczny wrote:

...

2) Take the leading sentence mentioning Solid/Soft out of the
tracktype description (or de-emphasize it)

I am dubious about redefining extremely
popular tags. For start - can you link
some photos of places where current
definition is a problem?

The best would be photos on licenses
allowing upload to OSM Wiki or
Wikimedia Commons.

___
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] lit=yes/no threshold

[Michael Patrick]

> lit=weak is too subjective.
> disclaimer: I am trying to make lit=yes/no definition more precise as
> part of my grant
> https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849

There is a lot of open access academic literature on your topic, covering
objective measures and both subjective indicators and how to derive
objective means from subjective factors. There is also more than a few
international and national design standards, guidelines, and other to form
the basis of your own 'definition'.

For example "Pedestrian and bike path illumination for safety and security:
empirical pre- and  post-field studies by a university team" at
https://www.witpress.com/Secure/elibrary/papers/UT13/UT13060FU1.pdf


You'd probably be okay using the 10 lux indicated by the Illuminating
Engineering Society. But considering that the illuminate area is uneven ( a
notion also covered in the standard ) and usually fairly extensive, and
illumination measurement is a technical skill, and it is a moving target
because of the daily cycle and weather, it probably isn't practical o
expect some member of the general public to collect the data.

However, there is also a considerable work that has been done for measuring
direct and ambient light levels by remote sensing, and correlating those
with on the ground conditions - the only practical way to cover any
significant area since values can be accumulated over time ( by hour to
seasonal ). See
https://ars.els-cdn.com/content/image/1-s2.0-S036013231830550X-fx1_lrg.jpg
and
https://res.mdpi.com/remotesensing/remotesensing-10-01964/article_deploy/html/images/remotesensing-10-01964-g001.png

It still leaves the question how you'd apply any data to a way element - do
you break it into smaller segments to apply differing values as they change
along the route?

Also, what is the specific use case? i.e. is 'lit' really a proxy for some
aspect of safety or reassurance, in which case the illumination level
doesn't matter at all, rather the unevenness, sight lines, and other
factors that affect a (only?) pedestrian's feeling of reassurance and
safety. For instance, no matter how bright a path itself is lit, if that
lighting  produces impenetrable shadows within arms length of my path, it
feels dangerous - an conversely, a unlit wide open field of short grass
feels perfectly safe.

This is a well researched topic, since, like 1285, when English King Edward
I forced property owners to clear highway edges of trees and shrubs. :-)

Michael Patrick
Geographer



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Maxweight wiki page changes

[Warin]

On 06/07/19 22:23, Martin Koppenhoefer wrote:


sent from a phone


On 6. Jul 2019, at 14:00, Tobias Zwick  wrote:

I am pretty sure myself that hgv are defined differently: as goods vehicles with a "gross 
vehicle weight rating" (gvwr), a.k.a. "gross vehicle mass" (gvm) or plainly said 
maximum laden weight above 3.5t


+1
no idea how it is regulated in the UK, on the continent it is gross vehicle 
mass.



In NSW Australia the regulations are:

Light traffic Roads

You must not use any road with a load limit sign if the total weight of your 
vehicle is the same as, or heavier than, the weight
shown on the sign.

You may use a light traffic road when that road is your destination for a 
pick-up or delivery and there is no alternative
route.

LOAD LIMIT SIGN

You must not drive past a BRIDGE LOAD LIMIT (GROSS MASS) sign or GROSS LOAD 
LIMIT sign if  the total of  the gross mass (in tonnes) of
your vehicle, and any vehicle connected to it, is more than the gross mass 
indicated in the sign.

--
So the signs here beside the road/bridge relate to the actual weigh limit of 
the road/bridge.. not the weight limits of the vehicle.


The driver would be held responsible if found to be over the weigh limit of the 
road/bridge.
  

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

Re: [Tagging] JOSM's "suspicious" path data warnings

[Mateusz Konieczny]

7 lip 2019, 00:07 od matkoni...@tutanota.com:

> 6 lip 2019, 23:52 od dieterdre...@gmail.com:
>
>>
>>
>> sent from a phone
>>
>>> On 6. Jul 2019, at 23:41, Mateusz Konieczny  wrote:
>>>
>>> It sounds like bicycle=yes, at least that is
>>> how such objects are tagged in Poland.
>>>
>>
>>
>> at least in Germany there is a difference between bicycle=yes on a footway 
>> (it means they must not ride faster than walking speed and give way to 
>> pedestrians) and bicycle=designated which means it is a dedicated shared way 
>> and pedestrians and cyclists are on the same level.
>>
>> Or in order words, with yes it is still a footway with an exception for 
>> bicycles, while with dedicated it becomes a mixed-use way.
>>
> It is the same in Poland, though on
> bicycle=designated, foot=designated,
> segregated=no pedestrians have priority
> over pedestrians
>
pedestrians have priority over cyclists, sorry___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] JOSM's "suspicious" path data warnings

[Mateusz Konieczny]

6 lip 2019, 23:52 od dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 6. Jul 2019, at 23:41, Mateusz Konieczny  wrote:
>>
>> It sounds like bicycle=yes, at least that is
>> how such objects are tagged in Poland.
>>
>
>
> at least in Germany there is a difference between bicycle=yes on a footway 
> (it means they must not ride faster than walking speed and give way to 
> pedestrians) and bicycle=designated which means it is a dedicated shared way 
> and pedestrians and cyclists are on the same level.
>
> Or in order words, with yes it is still a footway with an exception for 
> bicycles, while with dedicated it becomes a mixed-use way.
>
It is the same in Poland, though on
bicycle=designated, foot=designated,
segregated=no pedestrians have priority
over pedestrians___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] JOSM's "suspicious" path data warnings

[Martin Koppenhoefer]

sent from a phone

> On 6. Jul 2019, at 23:41, Mateusz Konieczny  wrote:
> 
> It sounds like bicycle=yes, at least that is
> how such objects are tagged in Poland.


at least in Germany there is a difference between bicycle=yes on a footway (it 
means they must not ride faster than walking speed and give way to pedestrians) 
and bicycle=designated which means it is a dedicated shared way and pedestrians 
and cyclists are on the same level.

Or in order words, with yes it is still a footway with an exception for 
bicycles, while with dedicated it becomes a mixed-use way.

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

Re: [Tagging] JOSM's "suspicious" path data warnings

[Mateusz Konieczny]

6 lip 2019, 22:31 od vosc...@gmail.com:
> In IT it is legally essentially a footway on which cyclists are tolerated, 
> but the pedestrians have always priority to the extend that if there are too 
> many pedestrians the cyclists have to dismount, and always have to ride at 
> moderate velocities. These mixed paths are not obligatory for cyclists when 
> there is a parallel road.
>
It sounds like bicycle=yes, at least that is
 how such objects are tagged in Poland.
(Now getting rare as traffic sign
combination used for that was deprecated).___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Test prep centres and cram schools as amenity=prep_school?

[marc marc]

Le 06.07.19 à 15:17, Joseph Eisenberg a écrit :
> provide after-school additional instruction

why it isn't still a school with another min_age/max_age
or any additional tag ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Rethinking Map Features

[Andrew Hain]

I have been working on a scheme to improve the cross-language quality of Map 
Features. 
[https://wiki.openstreetmap.org/wiki/Talk:Map_Features#Reimagining_Map_Features]

Of course the page may deserve a bigger or deeper rethink.

--
Andrew
Talk:Map Features - OpenStreetMap 
Wiki
amenity=school rendering colour. amenity=school is displayed in the page as a 
light-purple area for ways, whereas mapnik renders them as a pale yellow colour
wiki.openstreetmap.org

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

Re: [Tagging] JOSM's "suspicious" path data warnings

[Volker Schmidt]

  >"Suspicious tag combination highway=cycleway together with
> foot=designated, use highway=path"
>
I interpreted this as invition to use the "neutral" tagging scheme based on
highway=path + foot=designated + bicycle=designated + segregted0yes|no
which is the tagging scheme that JOSM implicitly promote

 This is incorrect. A cycleway tag can be used on a shared path, one
> which can have a designation for other
>  transport modes, such as a Public Right of Way for walkers.
>
I would not say it's is incorrect. It is biased and inviting users to use
one of several competing mapping schemes for maping mixed-use
foot-cycleways.

Anyway, the most important thing from a routing point of view is to provide
all necessary information like legal access, surface, smoothness, width,
lit.
And when it comes to detail there are nuances in meaning. For example, the
(nearly) identical signs for shared foot-cycleways in in IT and DE have
different meaning:
In DE it means "shared" as both cyclists and pedestrians have equal rights
and obligations, and there is also the obligation for cyclists to use it
if it runs parallel to a road, just like a bicycle-only way
In IT it is legally essentially a footway on which cyclists are tolerated,
but the pedestrians have always priority to the extend that if there are
too many pedestrians the cyclists have to dismount, and always have to ride
at moderate velocities. These mixed paths are not obligatory for cyclists
when there is a parallel road.

OSM tagging does not reflect these finer differences.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] JOSM's "suspicious" path data warnings

[Mateusz Konieczny]

6 lip 2019, 14:59 od tagging@openstreetmap.org:
> >"Suspicious tag combination highway=cycleway together with foot=designated, 
> >use highway=path"
>
>     This is incorrect. A cycleway tag can be used on a shared path, one which 
> can have a designation for other
>     transport modes, such as a Public Right of Way for walkers.
>
Is it better than 
highway=path
bicycle=designated
foot=designated
?___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Maxweight wiki page changes

[Minh Nguyen]

On 2019-07-06 04:49, Colin Smale wrote:
It is an intrinsic danger of international projects that words mean 
different things to different people. Hence the importance of keeping 
things objective, and recording facts, rather than judgements. It's 
about what things ARE, not what they are CALLED. It really doesn't 
matter if the tag uses "unladen" or "empty" or "tare" or indeed 
"abc001". What is important is that the chosen tag is well-defined, so 
people can translate the data to what it does (or does not) imply.

For example (my definition):
Bogie = composite of 2..n axles sharing a common load-bearing mechanism. 
Not to be confused with a Close-Coupled Axle Group where each axle has 
its own independent load-bearing mechanism.
With unladen/tare/empty, this is probably not exactly the same as kerb 
weight (Mass In Running Order), which includes things like fuel in the 
tank. Or is it "dry weight" without even the weight of the brake fluid? 
Is it defined as weight, or is it actually legally speaking mass? Which 
value is most easily accessible for mappers? Which value is most useful 
to data consumers?


This is an important point. Your average non-British layperson mapping 
businesses who happens to come across a weight restriction sign won't 
initially know the distinction between an axle and a bogie (guilty as 
charged), let alone tare and dry weight, so there's quite a risk of 
mistagging. Editor fields with human-readable labels can mitigate this 
risk somewhat, but after a modicum of research, I'm still unsure as to 
whether the signposted "empty weight" differs from "curb weight".


Personally, as an American, I don't have a problem with calling it 
either "empty" or "unladen" weight. I initially confused bogies with 
axles on the wiki, owing to "tandem" being much more common here, but I 
still find "unladen" to be self-explanatory, if slightly exotic. Maybe 
I've spent too much time pondering the maximum airspeed velocity of 
certain birds.


Are there any jurisdictions that make a distinction between specific 
definitions of "tare", "empty", "curb", or "dry" weight in weight 
restrictions? If not, there's no need to overdefine the tag. We already 
handwave about the definition of maxweight: does it refer to the weight 
of the portion of the vehicle currently on the bridge, or the entire 
vehicle? Different jurisdictions probably have differing definitions 
while using similar signs. Even the difference between empty and gross 
weight is insignificant for most trucks. [1]


To account for empty weight restrictions, a navigation application would 
have to ask the trucker their empty weight or perhaps the truck's 
make/model/configuration. It seems to me that the more important 
consideration is whether the application presents the user with the 
correct terminology. Whether the underlying data is based on uniform 
definitions internationally would be more important for analysis use 
cases, I suppose, but anyone trying to shoehorn the U.S. system of 
weight restrictions into a coherent international system is in for a 
world of hurt. [1]


[1] 
https://www.energy.gov/eere/vehicles/fact-621-may-3-2010-gross-vehicle-weight-vs-empty-vehicle-weight

[2] https://wiki.openstreetmap.org/wiki/Key:maxweight#United_States_2

--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] JOSM's "suspicious" path data warnings

[marc marc]

Le 06.07.19 à 14:59, Dave F via Tagging a écrit :
>  > use highway=path"
> This is incorrect <...> on a shared path

Funny to say that a shared PATH mapped with highway=PATH is incorrect.
we already have this discussion several times on talk-fr, it's often
the same scenario:
- a cyclist considers that it is a cycle path with these *** pedestrians 
that is embedded
- a pedestrian thinks the opposite
the only coherent is imho highway=path foot=designated 
cycleway=designated segrated=yes/no.

if you think that English legislation makes it inappropriate and you 
make it a josm ticket, don't forget to specify that it is only English 
legislation
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Test prep centres and cram schools as amenity=prep_school?

[Minh Nguyen]

On 2019-07-06 06:17, Joseph Eisenberg wrote:

In May, yumean1119 suggested tagging Japanese "cram schools" as either
office=educational_institution + education = cram_school
or amenity=prep_school

And then iD and the name_suggestion_index started using amenity=prep_school


I added some test prep center and cram school chains to NSI [1] because 
I was dismayed at seeing so many of them tagged as ordinary schools. [2] 
The naming is admittedly unfortunate, but on the bright side, there 
doesn't seem to have been much confusion with college preparatory 
schools. Yay for presets. [3]


The NSI entry means it's easier for mappers to identify individual cram 
schools as being affiliated with these chains, as opposed to being 
college preparatory schools. So if there is consensus on a replacement 
tag, the existing features can be migrated either manually or 
automatically with more confidence than before.


[1] https://github.com/osmlab/name-suggestion-index/pull/2630
[2] http://overpass-turbo.eu/s/KuE
[3] https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dprep_school


I think that "education=*" is not yet supported as a key, so we should
use either amenity= or office= with "=tutoring" - for cram schools
that provide after-school additional instruction, an "=test_prep" for
facilities that only provide preparation for certain tests, like
Kaplan in the USA.


office=tutoring isn't a great fit, because then we can't easily 
distinguish these centers (some of which are just as large as 
neighborhood elementary schools) from independent tutors' offices.


Another term for these establishments is "supplementary education 
center", but that risks confusion with some other kinds of supplementary 
education. [3] And despite the "school" in "cram school", some of these 
establishments are educational institutions only inasmuch as acupuncture 
is healthcare [4], which is to say, debatable.


Incidentally, there's already a documented after_school tag used with 
kindergartens and childcare centers. [5] Not all test prep centers are 
after-school programs -- some are geared toward professional 
examinations -- but I think the overlap suggests that we should just go 
with something in amenity=* until we get around to overhauling 
everything with an education=* key.


[3] https://en.wikipedia.org/wiki/Supplementary_school
[4] 
https://wiki.openstreetmap.org/wiki/Key:healthcare#Specialities_for_healthcare.3Dalternative

[5] https://wiki.openstreetmap.org/wiki/Key:after_school

--
m...@nguyen.cincinnati.oh.us


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

Re: [Tagging] JOSM's "suspicious" path data warnings

[Dave F via Tagging]

On 06/07/2019 14:08, Andy Townsend wrote:
Where any editor gives incorrect suggestions I'd suggest raising a 
ticket with the editor concerned about it.  I've done that a couple of 
times in the past with JOSM and the issues have been resolved almost 
immediately.


Obviously it helps to provide a bit of background as to why and in 
what circumstances a particular suggestion is incorrect.


I agree, but I wanted to check with a wider audience that I haven't 
grabbed the wrong end of the stick. I'm more than happy to be proved wrong.


Plus you don't always get a *balanced* viewpoint from those who directly 
wrote the code.  iD 


DaveF



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

Re: [Tagging] New sections added to "Good Practice" page?

[marc marc]

Le 06.07.19 à 14:52, bkil a écrit :
> We would need something like: housed_in=vehicle

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

Re: [Tagging] New sections added to "Good Practice" page?

[Mateusz Konieczny]

14 169 building=houseboat

6 lip 2019, 16:31 od joseph.eisenb...@gmail.com:

>> ... we could use something like building=boat,
>> building=caravan or building=vehicle, but it is unfortunate that none
>> of these can be understood to be buildings in any sense of the word.
>>
>
> building=static_caravan is common for mobile homes and caravans (aka
> trailers) which are semi-permanently located in one place. Tagged on
> ways 132, 566 times:
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dstatic_caravan
>
> building=ship has been used 356 times, and building=boat 166 times -
> not as common, per TagInfo.
>
> ___
> 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] shared planter where you can harvest for free

[joost schouppe]

I like your suggestion, Jason.

Also, indeed I meant the operator of this specific thing is a person, not
"let's change the definition of operator=*" :)

Op vr 5 jul. 2019 21:28 schreef Jmapb via Tagging :

> On 7/5/2019 3:08 PM, Paul Allen wrote:
>
> I read joost's comment as "The operator of this map object is a specific
> private citizen"
> not as a redefinition of "operator."
>
> Hah, probably. Regardless, I do think that Les Incroyables
> Comestibles/Incredible Edibles fits better under the brand key, or maybe
> network, than operator -- because it sounds like the organization simply
> organizes, and does not actually do the upkeep.
>
> Anyway, my suggestion for these free produce spots would be
> amenity=public_produce, similar to amenity=public_bookcase.
>
> Jason
> ___
> 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] New sections added to "Good Practice" page?

[Martin Koppenhoefer]

sent from a phone
> On 6. Jul 2019, at 16:31, Joseph Eisenberg  wrote:
> 
> building=static_caravan is common for mobile homes and caravans (aka
> trailers) which are semi-permanently located in one place. Tagged on
> ways 132, 566 times:
> https://wiki.openstreetmap.org/wiki/Tag:building%3Dstatic_caravan
> 
> building=ship has been used 356 times, and building=boat 166 times -
> not as common, per TagInfo



still, 356 static ships mapped this way seem significant, there are much fewer 
of these compared to static caravans in the world.

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

Re: [Tagging] Feature Proposal - RFC - waterway=tidal_channel

[François Lacombe]

Le sam. 6 juil. 2019 à 16:39, Joseph Eisenberg 
a écrit :

>
> I don't know if the tag "direction=both" is used commonly with
> waterways. There's no wiki page to describe this tag, and the page
> Key:direction doesn't mention direction=both, though it's used 20,000
> times. More common is to add the tag "tidal=yes" to river estuaries
> which are clearly affected by the tides, though this does not
> necessary require reversal of water flow direction.
>

It seems there was communication issues during past proposals.
flow_direction was introduced by sinks proposal in 2017 :
https://wiki.openstreetmap.org/wiki/Tag:flow_direction%3Dboth
direction=both was mentioned in waterway=pressurised proposal to solve
situations when water goes down and can be pumped back in water pumped
power plants
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Hydropower_water_supplies#Pumped_storage_power_plants
Sounds like flow_direction is more suitable to deal with water flows

Apart from this issue, tidal=yes isn't the best option (recent discussions
had show that yes/no only tags should be completed with more representative
values)
What about flow_direction=tidal ?

All the best

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

Re: [Tagging] lit=yes/no threshold

[Volker Schmidt]

Just two additional aspects from my own experience on bicycle, to make
things even more complicated:

1) cycle and foot path illumintion dramatically depends on the presence of
leaves on the trees that are planted along the road. (don't get me wrong: I
like trees)

2) another effect which is very annoying and normally completely neglected
by road designers: in many cases cycle paths are being constructed in a way
that you have to pedal against  the car flow on the "wrong" side of the
road, i.e. you get the full blast of the assymmertic headlights of the
oncoming motor vehicles on the main carriageway. Your are effectively blind
even with high level of surface illumination. This is the price you pay two
have two-way cycle paths on one side of the road (which is the desired
situation from the daytime-use point of view).


On Sat, 6 Jul 2019 at 15:05, bkil  wrote:

> In many parts of Hungary, vegetation can overshadow street lights,
> especially if they are placed high enough. They may make efforts to
> protect roads against this, but they rarely consider footways. Hence I
> know a lot of streets where road illumination is fair, but the
> sidewalk right beside it (maybe 1-2m from the road) is dark along the
> majority of the road.
>
> I also agree with Martin's definition of being lit and I usually do it
> like that.
>
> I don't split ways by the centimeter to specify illumination - if a
> stretch of path has too many shadows, you need to bring your own
> lights anyway, so I consider that not being lit.
>
> On Sat, Jul 6, 2019 at 2:39 PM Martin Koppenhoefer
>  wrote:
> >
> >
> >
> > sent from a phone
> >
> > > On 6. Jul 2019, at 14:07, Tobias Zwick  wrote:
> > >
> > > The least subjective definition is to map the physical presence of
> street lanterns on the way, not the light they emit. (This definition
> (though) would mean that a footway close to a lit street would be mapped as
> unlit as long as it does not have own lanterns.)
> >
> >
> > the presence of street lights indicates the road could be lit, it has no
> implications whether it is actually lit. For example last summer I went to
> an island where all streets had relatively new street lights, but half the
> island they kept them off so that light pollution was reduced.
> >
> > In small villages in Germany, street lights are often turned off at a
> certain time (e.g. after 23h), etc.
> >
> >
> > Cheers, Martin
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] lit=yes/no threshold

[Mateusz Konieczny]

6 Jul 2019, 14:07 by o...@westnordost.de:

>> I am trying to make lit=yes/no definition more precise
>>
>
> I think that your suggestions would make the definition actually less precise 
> because they add a fair level of subjectiveness: "necessary to bring your own 
> light"
>
> The least subjective definition is to map the physical presence of street 
> lanterns on the way, not the light they emit. (This definition (though) would 
> mean that a footway close to a lit street would be mapped as unlit as long as 
> it does not have own lanterns.)
>
This may be less subjective but would be quite pointless - there are many, many 
cases (at least in my city) 
where many footways are well lit without dedicated lanterns.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - waterway=tidal_channel

[Joseph Eisenberg]

> How are handled the concepts of intermittence and direction of the flow in
> the tagging?
> Should we use intermittent=yes and direction=both, or are they implied by
> waterway=tidal_channel?
> ...only recommend the use of intermittent=yes on
> channels which are fully empty at low tide time.

Thank you for bringing this up

I agree that most tidal channels are not intermittent, because they
tend to have a small amount of water flowing towards the sea at low
tide. It could be reasonable to use intermittent=yes on small tidal
channels that are completely dry at low tide.

Bidirectional water flow (that is, the direction of water flow
reverses at different times in the tidal cycle) should be implied by
the tag waterway=tidal_channel, though there may be rare exceptions.

I don't know if the tag "direction=both" is used commonly with
waterways. There's no wiki page to describe this tag, and the page
Key:direction doesn't mention direction=both, though it's used 20,000
times. More common is to add the tag "tidal=yes" to river estuaries
which are clearly affected by the tides, though this does not
necessary require reversal of water flow direction.

The wiki page for waterway=tidal_channel should mention that
"tidal=yes" is implied.

-Joseph

> Other channels will have a lower level but won't be empty.
>
> Let me know how do you feel about this
>
> All the best
>
> François
>
> Le sam. 6 juil. 2019 à 14:43, Joseph Eisenberg 
> a écrit :
>
>> I'd like to vote on the proposal for waterway=tidal_channel soon
>>
>> If you haven't read the page yet, please check and add any  comments
>> or bring up any problems that might have been missed.
>>
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel
>>
>> "Definition:A natural intertidal waterway in mangroves, salt marshes
>> and tidal flats with water flow in the direction of the tide"
>>
>> -Joseph
>>
>> ___
>> 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] New sections added to "Good Practice" page?

[Joseph Eisenberg]

> ... we could use something like building=boat,
> building=caravan or building=vehicle, but it is unfortunate that none
> of these can be understood to be buildings in any sense of the word.

building=static_caravan is common for mobile homes and caravans (aka
trailers) which are semi-permanently located in one place. Tagged on
ways 132, 566 times:
https://wiki.openstreetmap.org/wiki/Tag:building%3Dstatic_caravan

building=ship has been used 356 times, and building=boat 166 times -
not as common, per TagInfo.

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

Re: [Tagging] Maxweight wiki page changes

[Tobias Zwick]

Ok, it seems that "unladen" is somewhat favoured here on the list because it is 
more precise, more common and conforms with the wording in the (UK) legislation.

I'll change the one mention in the wiki of "maxemptyweight" to 
"maxunladenweight".

Cheers
Tobias

On 06/07/2019 14:17, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
>> On 6. Jul 2019, at 12:53, Tobias Zwick  wrote:
>>
>> So "unladen" is the word used in UK legislation? Do you have a link?
>> Even if "unladen" is most commonly used in UK, I still find "empty" better 
>> because it is easier to understand what it means for non native speakers 
>> (simpler word).
> 
> 
> to me unladen seems more specific (I am not a native speaker of course), 
> empty could mean more things (seats removed? No gasoline in the tank?) 
> although I agree unladen also leaves it open whether it is with petrol or 
> without.
> 
> Ciao, 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] Test prep centres and cram schools as amenity=prep_school?

[Joseph Eisenberg]

To summarize,

In January, Javbw  mentioned amenity=cram_school for these "juku" cram
schools, e.g. brand Komon

In February, office=tutoring was suggested by Jmapb, perhaps with
tutoring=test_prep for those focused on test preparation only

In March, Warin added the suggestion of education=tutoring, however
not everyone agrees if all these facilities provide education, or if
education=* is a good key.

In May, yumean1119 suggested tagging Japanese "cram schools" as either
office=educational_institution + education = cram_school
or amenity=prep_school

And then iD and the name_suggestion_index started using amenity=prep_school

I think that "education=*" is not yet supported as a key, so we should
use either amenity= or office= with "=tutoring" - for cram schools
that provide after-school additional instruction, an "=test_prep" for
facilities that only provide preparation for certain tests, like
Kaplan in the USA.

Joseph

On 7/5/19, Jmapb via Tagging  wrote:
> On 7/5/2019 2:16 AM, Joseph Eisenberg wrote:
>> So, what's a better term for a test prep centre, cramp school, or
>> tutoring office? There the rarely used tag office=tutoring, but that
>> doesn't quite cover a place like Kaplan or Kumon -
>> https://au.kumonglobal.com/ - https://www.kaptest.com/
>>
>> amenity=test_prep
>> amenity=cram_school
>> office=test_prep
>> amenity=tutoring
>>
>> Other options?
>
> See previous discussions this year:
>
> https://lists.openstreetmap.org/pipermail/tagging/2019-January/042561.html
> https://lists.openstreetmap.org/pipermail/tagging/2019-February/042983.html
> https://lists.openstreetmap.org/pipermail/tagging/2019-March/043617.html
> https://lists.openstreetmap.org/pipermail/tagging/2019-May/045457.html
>
> J
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] JOSM's "suspicious" path data warnings

[Andy Townsend]

On 06/07/2019 13:59, Dave F via Tagging wrote:

Hi
Unsure if these validation warnings on uploading a changeset in JOSM 
are new or I've never noticed them before:


>"Suspicious tag combination highway=cycleway together with 
foot=designated, use highway=path"


    This is incorrect. A cycleway tag can be used on a shared path, 
one which can have a designation for other

    transport modes, such as a Public Right of Way for walkers.

Where any editor gives incorrect suggestions I'd suggest raising a 
ticket with the editor concerned about it.  I've done that a couple of 
times in the past with JOSM and the issues have been resolved almost 
immediately.


Obviously it helps to provide a bit of background as to why and in what 
circumstances a particular suggestion is incorrect.


Best Regards,

Andy



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

Re: [Tagging] JOSM's "suspicious" path data warnings

[Martin Koppenhoefer]

sent from a phone

> On 6. Jul 2019, at 14:59, Dave F via Tagging  
> wrote:
> 
> Anybody know when & why these were introduced?


IIRR, it was like 10-20 years ago.
You should be able to find more information on the path page in the wiki.

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

Re: [Tagging] lit=yes/no threshold

[bkil]

In many parts of Hungary, vegetation can overshadow street lights,
especially if they are placed high enough. They may make efforts to
protect roads against this, but they rarely consider footways. Hence I
know a lot of streets where road illumination is fair, but the
sidewalk right beside it (maybe 1-2m from the road) is dark along the
majority of the road.

I also agree with Martin's definition of being lit and I usually do it
like that.

I don't split ways by the centimeter to specify illumination - if a
stretch of path has too many shadows, you need to bring your own
lights anyway, so I consider that not being lit.

On Sat, Jul 6, 2019 at 2:39 PM Martin Koppenhoefer
 wrote:
>
>
>
> sent from a phone
>
> > On 6. Jul 2019, at 14:07, Tobias Zwick  wrote:
> >
> > The least subjective definition is to map the physical presence of street 
> > lanterns on the way, not the light they emit. (This definition (though) 
> > would mean that a footway close to a lit street would be mapped as unlit as 
> > long as it does not have own lanterns.)
>
>
> the presence of street lights indicates the road could be lit, it has no 
> implications whether it is actually lit. For example last summer I went to an 
> island where all streets had relatively new street lights, but half the 
> island they kept them off so that light pollution was reduced.
>
> In small villages in Germany, street lights are often turned off at a certain 
> time (e.g. after 23h), etc.
>
>
> Cheers, Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

[Tagging] JOSM's "suspicious" path data warnings

[Dave F via Tagging]

Hi
Unsure if these validation warnings on uploading a changeset in JOSM are 
new or I've never noticed them before:


>"Suspicious tag combination highway=cycleway together with 
foot=designated, use highway=path"


    This is incorrect. A cycleway tag can be used on a shared path, one 
which can have a designation for other

    transport modes, such as a Public Right of Way for walkers.

    Some erroneously believe footway,cycleway or bridleway signifies 
some kind of priority or authority which

    automatically excludes other transport modes. It doesn't.
    It's an indication of the number of different modes allowed to use 
them. Of course there are variations on this,

    which can be clarified with relevant 'access' & 'designation' tags.

    Many are rescinding the use of 'path' as, well, it's just a 
confusing, duplicating late comer

    https://www.openstreetmap.org/user/Richard/diary/20333

    Note the major renders make no distinction between 'path' & 'footway'

>"unnecessary tag - foot=yes/designated is unnecessary for highway=footway"

    This is also incorrect. As an example It's used to distinguish 
between constructed footways through housing
    estates or those signed with 'footpath' from, say, worn grass 
around the perimeter of a farmers field where they

    allows dog walkers to exercise.

Anybody know when & why these were introduced?


DaveF





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

Re: [Tagging] Feature Proposal - RFC - waterway=tidal_channel

[François Lacombe]

Hi Joseph,

Thank you for having relevantly chosen a different word from canal.

One question, which doesn't necessarily imply error on the current version
of the proposal
How are handled the concepts of intermittence and direction of the flow in
the tagging?
Should we use intermittent=yes and direction=both, or are they implied by
waterway=tidal_channel?

Id' find interesting to only recommend the use of intermittent=yes on
channels which are fully empty at low tide time.
Other channels will have a lower level but won't be empty.

Let me know how do you feel about this

All the best

François

Le sam. 6 juil. 2019 à 14:43, Joseph Eisenberg 
a écrit :

> I'd like to vote on the proposal for waterway=tidal_channel soon
>
> If you haven't read the page yet, please check and add any  comments
> or bring up any problems that might have been missed.
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel
>
> "Definition:A natural intertidal waterway in mangroves, salt marshes
> and tidal flats with water flow in the direction of the tide"
>
> -Joseph
>
> ___
> 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] New sections added to "Good Practice" page?

[bkil]

Floating restaurants, hotels and event halls are pretty common in
Budapest. Some fancy ones even offer budget daily lunch menus.

https://www.a38.hu/en

If we interpreted the intention, semantics and usage patters of
building=* in OSM, we could use something like building=boat,
building=caravan or building=vehicle, but it is unfortunate that none
of these can be understood to be buildings in any sense of the word.
We would need something like:
housed_in=vehicle
contained_in=vehicle
enclosed_in=vehicle
hosted_in=vehicle

This seems to be the most generic term that applies:
structure=vehicle/boat/cart/tent/building/...
https://en.wikipedia.org/wiki/Structure#Load-bearing

On Sat, Jul 6, 2019 at 1:26 AM Fernando Trebien
 wrote:
>
> On Mon, Jul 1, 2019 at 5:33 PM bkil  wrote:
> > Be my guest:
> > intermittent=yes
> > ephemeral=yes
> > building=no
> > permanent=no
> > movable=yes
> > stationary=no
> > caravan=yes
> > mount=trailer
> > support=wheels
> > foundation=no
> >
> > https://en.wikipedia.org/wiki/Floating_restaurant
> > https://en.wikipedia.org/wiki/Houseboat
>
> Pure fun. Closest I've ever done was a floating restaurant [1], which
> had been there for 6 months when I mapped and is there ever since, but
> could be gone tomorrow. Also, where I live, there are many weekly
> public markets licensed by the prefecture. The main one is a major
> meeting point for the locals [2]. The only thing you find there during
> weekdays are the signs stating the name, time and location of the
> event.
>
> caravan=* is related to access rights [3].
>
> [1] https://www.openstreetmap.org/way/560511031
> [2] Main one: https://www.openstreetmap.org/node/2267135759
> [3] https://wiki.openstreetmap.org/wiki/Key:caravan
>
> --
> Fernando Trebien
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Use bbq=yes/no or barbecue_grill=yes/no with campsites?

[Joseph Eisenberg]

Re: > basic picnic tables where you can provide your own mini grill

It looks like we can propose "bring_own_bbq=yes" for that situation

Re: > some fixed on a post grills

Do you think this should be "bbq=yes" or "barbecue_grill=yes"?

-Joseph

On 7/6/19, Nita S.  wrote:
> One caravan park I am familiar with has three types: basic picnic tables
> where you can provide your own mini grill, some fixed on a post grills, and
> a single large motorized rotating spit type grill.

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

Re: [Tagging] Feature Proposal - RFC - waterway=tidal_channel

[Joseph Eisenberg]

I'd like to vote on the proposal for waterway=tidal_channel soon

If you haven't read the page yet, please check and add any  comments
or bring up any problems that might have been missed.

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel

"Definition:A natural intertidal waterway in mangroves, salt marshes
and tidal flats with water flow in the direction of the tide"

-Joseph

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

Re: [Tagging] lit=yes/no threshold

[Martin Koppenhoefer]

sent from a phone

> On 6. Jul 2019, at 14:07, Tobias Zwick  wrote:
> 
> The least subjective definition is to map the physical presence of street 
> lanterns on the way, not the light they emit. (This definition (though) would 
> mean that a footway close to a lit street would be mapped as unlit as long as 
> it does not have own lanterns.)


the presence of street lights indicates the road could be lit, it has no 
implications whether it is actually lit. For example last summer I went to an 
island where all streets had relatively new street lights, but half the island 
they kept them off so that light pollution was reduced.

In small villages in Germany, street lights are often turned off at a certain 
time (e.g. after 23h), etc.


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

Re: [Tagging] lit=yes/no threshold

[Martin Koppenhoefer]

sent from a phone

> On 6. Jul 2019, at 12:35, Colin Smale  wrote:
> 
> Instead of creating artificial boundaries quantising shades of grey into 
> black and white, why not make it more objective and record the light level in 
> lux on the centre line of the road? Or would it be better to do that on the 
> footpath? That would complicate matters because the two sides of the road may 
> differ.


how would you do this? Usually street lighting is not very homogeneous, 
especially on footways (where the information is most interesting, because 
vehicles bring their own lights anyway), you can only measure the amount of 
light at a single spot, but you will surely get very different measurements 
according to the exact location you choose.

My criterion for pedestrian spaces lit or not would be: can you see dog poo, or 
a hole in the ground? If not it is not (sufficiently) lit.

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

Re: [Tagging] Maxweight wiki page changes

[Martin Koppenhoefer]

sent from a phone

> On 6. Jul 2019, at 12:53, Tobias Zwick  wrote:
> 
> So "unladen" is the word used in UK legislation? Do you have a link?
> Even if "unladen" is most commonly used in UK, I still find "empty" better 
> because it is easier to understand what it means for non native speakers 
> (simpler word).


to me unladen seems more specific (I am not a native speaker of course), empty 
could mean more things (seats removed? No gasoline in the tank?) although I 
agree unladen also leaves it open whether it is with petrol or without.

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

Re: [Tagging] lit=yes/no threshold

[Tobias Zwick]

> I am trying to make lit=yes/no definition more precise

I think that your suggestions would make the definition actually less precise 
because they add a fair level of subjectiveness: "necessary to bring your own 
light"

The least subjective definition is to map the physical presence of street 
lanterns on the way, not the light they emit. (This definition (though) would 
mean that a footway close to a lit street would be mapped as unlit as long as 
it does not have own lanterns.)

Tobias 

On July 6, 2019 12:24:18 PM GMT+02:00, Mateusz Konieczny 
 wrote:
>Some cases of lit=yes are clear (direct lighting of street/footway by
>lamps)
>
>Some cases of lit=no are clear (no lighting whatsoever)
>
>But in cities there is also often strong or weak ambient light, for
>example:
>
>- carriageway is directly lit with so powerful light that spillover
>light
>makes footway well lit - clearly lit=yes
>
>- spillover light is quite dim but enough to comfortably walk - also
>lit=yes
>
>- there is some ambient light, but not enough to walk without own
>source of light - lit=no
>
>- there is an ambient light, one can carefully walk, but only slowly,
>people with poor eyesight needs their own source of light - lit=no (?)
>
>Overall, I am considering adding to
>https://wiki.openstreetmap.org/wiki/Key:lit
>
>recommendation to consider "is it necessary to bring your own light
>source to see it properly"
>as recommended threshold for footways/paths.
>
>Any problems with that or ideas for a better threshold between lit=yes
>and lit=no?
>
>disclaimer: I am trying to make lit=yes/no definition more precise as
>part of my grant
>https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849

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

Re: [Tagging] lit=yes/no threshold

[Paul Allen]

On Sat, 6 Jul 2019 at 12:42, Mateusz Konieczny 
wrote:

It is not feasible to do for a typical mapper to record "light level in
> lux".
>

Sadly, however, it is the only objective way of specifying the light
level.  And even then, it's
easy to do it wrong if you don't account for the angle of incidence.  Aim
the sensor at the
light and you'll get a higher reading than if you lay it flat on the ground.

but it is not helping with problem what would be a good threshold between
> lit=yes and lit=no
> on footways
>

In the UK, BS 5266 requires a minimum illumination of 1 lux along the
centre line of
escape routes.  Up until 2011, BS 5266 required a minimum of 0.2 lux along
the centre
line of escape routes.

IIRC, the 0.2 lux figure was approximately equivalent to the light of the
full moon, which
was deemed adequate for some work in shipyards during WW II.  Certainly
it's more
than necessary to take an unhurried stroll along a footpath after your eyes
have
acclimatized to the darkness.  It may be the minimum that was once
considered
adequate to allow evacuation from a dark building after a power cut (no
time for eyes
to acclimatize) but it's not the minimum needed to follow a reasonable
footpath if you're
not in a hurry.

So it is preferable that everyone has their own definition of what is
> lit=no/yes and
> recommend that "in case of doubt is it lit=yes or lit=no feel free to
> choose either"?
>

It's hard for most mappers to accurately measure.  It's hard to agree on a
suitable
figure, because the amount of light necessary depends very much on the
nature of the
path (an asphalted footpath can be safely followed with far less light than
is required for
an unmade path over rocky terrain).  OTOH, if there are lights along the
path, it is clear that it is lit.
If it's the sidewalk of a lit road, it's lit.  In any other cases, it's
probably safer to say it's unlit.

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

Re: [Tagging] Maxweight wiki page changes

[Tobias Zwick]

>Unladen weight is used in European countries to apply only to goods
>vehicles, either 3.5t or 7.5t, and is tagged as hgv=no/destination.

Are you absolutely sure about this?

I am pretty sure myself that hgv are defined differently: as goods vehicles 
with a "gross vehicle weight rating" (gvwr), a.k.a. "gross vehicle mass" (gvm) 
or plainly said maximum laden weight above 3.5t

...  and also documented it this way on the Key:hgv page

Tobias

On July 6, 2019 1:38:34 PM GMT+02:00, Philip Barnes  
wrote:
>
>
>On Saturday, 6 July 2019, Warin wrote:
>> On 06/07/19 19:46, Colin Smale wrote:
>> >
>> > On 2019-07-06 10:48, Warin wrote:
>> >
>> >> On 06/07/19 18:16, Colin Smale wrote:
>> >>>
>> >>> On 2019-07-06 05:03, Warin wrote:
>> >>>
>> >>> On 05/07/19 19:33, Mateusz Konieczny wrote:
>> >>>
>> >>> 3 Jul 2019, 12:52 by o...@westnordost.de:
>> >>>
>> >>> 1.1 At the examples: for max empty weight, I propose
>the
>> >>> key maxemptyweight. It suggests itself.
>> >>>
>> >>> Added, with link back to this post
>> >>>
>> >>>
>> >>> Here that would be called "maximum Tare weight". In the UK? 
>> >>>
>> >>> Probably "maximum unladen weight." "Tare" does exist as a word,
>and 
>> >>> is frequently used in logistics (empty weight of containers etc)
>but 
>> >>> AFAIK not in the context of traffic regulations.
>> >>>
>> >>
>> >> Possibly not where you are.. but
>> >>
>> >> "registrable light motor vehicle means a motor vehicle that is 
>> >> registrable and has a tare mass that is not greater than 2,794 
>> >> kilograms."
>> >>
>> >> From
>https://www.legislation.nsw.gov.au/#/view/regulation/2017/451/full
>> >>
>> >> And also in other traffic legislation in Australia...
>> >>
>> >> In the UK?
>> >>
>> >> "(h)the manner in which the tare weight of road vehicles, or of
>road 
>> >> vehicles of any particular class or description is to be
>determined. "
>> >> from https://www.legislation.gov.uk/ukpga/1985/72
>> >>
>> >>
>> > That is not a traffic regulation, that's about metrology. And by
>the 
>> > way, I am speaking as a Brit, so native speaker and somewhat 
>> > conversant with the laws and legal system. As I said, the word
>"tare" 
>> > does exist, and is used in certain specific contexts. But in 
>> > connection with road vehicles, everybody in the UK speaks of
>Unladen 
>> > Weight.
>> >
>> > https://www.gov.uk/vehicle-weights-explained
>> >
>> 
>> Ok.
>> Here trucks have small signs on there side, they state the tare
>weight 
>> and gvw. I think these are used to confirm the vehicle is not
>overloaded 
>> when inspected (we have both mobile and stationary testing).
>> Also tare is used to specify the maximum tare weight of a trailer
>that 
>> inexperienced drivers can use, and that is a road regulation. It may 
>> also be used for other things.
>> A fairly common term here.
>> 
>> -
>> Further nit picking..
>> The "Unladen weight" is usually done without fuel but in all other
>ways 
>> ready for the road -i.e. includes spare tyre/s, tools, battery,
>coolant, 
>> oil etc etc. ???
>> I think some manufactures sales brochures quote figures without some
>of 
>> these to make it appear that they have greater load carrying
>capabilities.
>> Again this may vary from place to place around the world.
>> 
>> 
>> I would be happy with "unladen weight" rather than "empty weight".
>> As for "maximum" .. I would use "limit" similar to the use of "speed 
>> limit". So it would become "unladen weight limit".
>> 
>> I don't think I have ever seen a sign limiting the unladen weight ..
>it 
>> is always a limit on the total weight that the structure is rated
>for.
>> So I don't think there is much point in discussing it? At least not
>from 
>> my limited knowledge.
>>
>Unladen weight is used in European countries to apply only to goods
>vehicles, either 3.5t or 7.5t, and is tagged as hgv=no/destination.
>
>It has nothing to do with structures, it is to prevent heavy goods
>vehicles taking short cuts through residential areas.
>
>It only apples to goods vehicles, as you need buses to have access.
>
>Phil (trigpoint)

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

Re: [Tagging] Maxweight wiki page changes

[Colin Smale]

On 2019-07-06 12:53, Tobias Zwick wrote:

> So "unladen" is the word used in UK legislation? Do you have a link?

http://www.legislation.gov.uk/uksi/1986/1078/regulation/24/made 

> Even if "unladen" is most commonly used in UK, I still find "empty" better 
> because it is easier to understand what it means for non native speakers 
> (simpler word).
> 
> In the US, "empty" seems to be most commonly used, as it is also written on 
> the signs while at the same time, the word is not exclusively known/used in 
> the US - unlike mall, freeway, etc.
> 
> "maxbogieweight" caused confusion earlier and was misunderstood as synonymous 
> to "maxaxleload" recently. "maxemptyweight" I think does not need 
> documentation to clarify what it stands for, "maxunladenweight" might.

It is an intrinsic danger of international projects that words mean
different things to different people. Hence the importance of keeping
things objective, and recording facts, rather than judgements. It's
about what things ARE, not what they are CALLED. It really doesn't
matter if the tag uses "unladen" or "empty" or "tare" or indeed
"abc001". What is important is that the chosen tag is well-defined, so
people can translate the data to what it does (or does not) imply. 

For example (my definition): 
Bogie = composite of 2..n axles sharing a common load-bearing mechanism.
Not to be confused with a Close-Coupled Axle Group where each axle has
its own independent load-bearing mechanism. 

With unladen/tare/empty, this is probably not exactly the same as kerb
weight (Mass In Running Order), which includes things like fuel in the
tank. Or is it "dry weight" without even the weight of the brake fluid?
Is it defined as weight, or is it actually legally speaking mass? Which
value is most easily accessible for mappers? Which value is most useful
to data consumers? 

> In the end, UK naming should usually win, but maybe "empty vehicle weight" 
> does not sound so exotic to British ears?

Empty sounds OK to me from a linguistic perspective.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Maxweight wiki page changes

[Paul Allen]

On Sat, 6 Jul 2019 at 12:26, Philip Barnes  wrote:

> Unladen is certainly the used, and understood, way of expressing such
> restrictions in the UK.
>
> https://www.gov.uk/vehicle-weights-explained
>
>
Off topic, and not your fault, but that is an explanation that isn't
entirely free from ambiguity and illogic.

The unladen weight excludes passengers but includes items needed for
ordinary operation.  Is
the driver a passenger or an item needed for ordinary operation?  Or both?
Or neither?

It doesn't include the weight of batteries in an electric vehicle.  I can
understand excluding
fuel, since a petrol/diesel/hydrogen vehicle may be operated with a tank
that's nearly empty
but batteries are a dead weight as much as the chassis is.  What would be
far more sensible
and consistent with the exclusion of fuel would be to include the batteries
(items needed for
ordinary operation) but to exclude the almost infinitesimally-small extra
mass created by charging
the batteries (subtle point of physics: energy, of any kind, has mass).

The law is an ass.  A simplified explanation of the law is a bigger ass.

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

Re: [Tagging] lit=yes/no threshold

[Mateusz Konieczny]

6 Jul 2019, 12:35 by colin.sm...@xs4all.nl:

>
> What problem are you trying to fix here? Usually it is pretty obvious if a 
> street has artificial lighting or not. 
>
>
Unclear desired tagging for footways lit by spillover lighting. As I mentioned 
it is usually obvious
but there are cases where it is not clear.

For example https://www.openstreetmap.org/way/26116023#map=18/50.06730/19.88864 

is path on top of embankment, without own lighting, poorly lit by street lamps 
on a street below it.

Or https://www.openstreetmap.org/way/238304937#map=16/50.0738/19.8891 
 - cycleway
along well lit road but so far away that lighting is poor and faint

Or https://www.openstreetmap.org/way/161706262#map=18/50.05869/19.91701 
 lit only 
by ambient
city light.

In most cases I already tagged something, but it would be nice to check 
whatever it is at least 
sort-of similar to what others would map.

> Instead of creating artificial boundaries quantising shades of grey into 
> black and white, why not make it more objective and record the light level in 
> lux on the centre line of the road?
>
It is not feasible to do for a typical mapper to record "light level in lux".

> Also, don't forget that whether a road is "lit" or not has consequences for 
> traffic regulations, at least in the UK. There is a specific definition 
> associated with this.
>
I found it,

"A road's speed limit is 30 mph (48 km/h) if the road's street lights are "[not 
placed] 
more than 200 yards apart" in England  
and Wales  or "not more than 185 metres" 
in Scotland ;"
https://en.wikipedia.org/wiki/Road_speed_limits_in_the_United_Kingdom#cite_note-80
 


but it is not helping with problem what would be a good threshold between 
lit=yes and lit=no
on footways

>
> My vote is to leave lit=* alone!
>
>
So it is preferable that everyone has their own definition of what is 
lit=no/yes and
 recommend that "in case of doubt is it lit=yes or lit=no feel free to choose 
either"?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] lit=yes/no threshold

[Warin]

On 06/07/19 20:47, Ferdinand Schicke wrote:


What I couldsee work would be to have additional lit=* values like 
lit=weak or lit=spillover or lit=10lux




I tired to use my mobile phone to gauge the amount of night light .. it 
did not work very well at all!


lit=weak is too subjective.

I too would leave lit alone. Either it is lit or it is not.

If you need some measure of 'lit' then I suggest if a map (OSM 
reference) cannot be read by the present light level then it is not lit.




*From: *Mateusz Konieczny 
*Sent: *Samstag, 6. Juli 2019 12:26
*To: *Tagging 
*Subject: *[Tagging] lit=yes/no threshold

Some cases of lit=yes are clear (direct lighting of street/footway by 
lamps)


Some cases of lit=no are clear (no lighting whatsoever)

But in cities there is also often strong or weak ambient light, for 
example:


- carriageway is directly lit with so powerful light that spillover light

makes footway well lit - clearly lit=yes

- spillover light is quite dim but enough to comfortably walk - also 
lit=yes


- there is some ambient light, but not enough to walk without own

source of light - lit=no

- there is an ambient light, one can carefully walk, but only slowly,

people with poor eyesight needs their own source of light - lit=no (?)

Overall, I am considering adding to 
https://wiki.openstreetmap.org/wiki/Key:lit


recommendation to consider "is it necessary to bring your own light 
source to see it properly"


as recommended threshold for footways/paths.

Any problems with that or ideas for a better threshold between lit=yes 
and lit=no?


disclaimer: I am trying to make lit=yes/no definition more precise as 
part of my grant


https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849



___
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] Maxweight wiki page changes

[Philip Barnes]

On Saturday, 6 July 2019, Warin wrote:
> On 06/07/19 19:46, Colin Smale wrote:
> >
> > On 2019-07-06 10:48, Warin wrote:
> >
> >> On 06/07/19 18:16, Colin Smale wrote:
> >>>
> >>> On 2019-07-06 05:03, Warin wrote:
> >>>
> >>> On 05/07/19 19:33, Mateusz Konieczny wrote:
> >>>
> >>> 3 Jul 2019, 12:52 by o...@westnordost.de:
> >>>
> >>> 1.1 At the examples: for max empty weight, I propose the
> >>> key maxemptyweight. It suggests itself.
> >>>
> >>> Added, with link back to this post
> >>>
> >>>
> >>> Here that would be called "maximum Tare weight". In the UK? 
> >>>
> >>> Probably "maximum unladen weight." "Tare" does exist as a word, and 
> >>> is frequently used in logistics (empty weight of containers etc) but 
> >>> AFAIK not in the context of traffic regulations.
> >>>
> >>
> >> Possibly not where you are.. but
> >>
> >> "registrable light motor vehicle means a motor vehicle that is 
> >> registrable and has a tare mass that is not greater than 2,794 
> >> kilograms."
> >>
> >> From https://www.legislation.nsw.gov.au/#/view/regulation/2017/451/full
> >>
> >> And also in other traffic legislation in Australia...
> >>
> >> In the UK?
> >>
> >> "(h)the manner in which the tare weight of road vehicles, or of road 
> >> vehicles of any particular class or description is to be determined. "
> >> from https://www.legislation.gov.uk/ukpga/1985/72
> >>
> >>
> > That is not a traffic regulation, that's about metrology. And by the 
> > way, I am speaking as a Brit, so native speaker and somewhat 
> > conversant with the laws and legal system. As I said, the word "tare" 
> > does exist, and is used in certain specific contexts. But in 
> > connection with road vehicles, everybody in the UK speaks of Unladen 
> > Weight.
> >
> > https://www.gov.uk/vehicle-weights-explained
> >
> 
> Ok.
> Here trucks have small signs on there side, they state the tare weight 
> and gvw. I think these are used to confirm the vehicle is not overloaded 
> when inspected (we have both mobile and stationary testing).
> Also tare is used to specify the maximum tare weight of a trailer that 
> inexperienced drivers can use, and that is a road regulation. It may 
> also be used for other things.
> A fairly common term here.
> 
> -
> Further nit picking..
> The "Unladen weight" is usually done without fuel but in all other ways 
> ready for the road -i.e. includes spare tyre/s, tools, battery, coolant, 
> oil etc etc. ???
> I think some manufactures sales brochures quote figures without some of 
> these to make it appear that they have greater load carrying capabilities.
> Again this may vary from place to place around the world.
> 
> 
> I would be happy with "unladen weight" rather than "empty weight".
> As for "maximum" .. I would use "limit" similar to the use of "speed 
> limit". So it would become "unladen weight limit".
> 
> I don't think I have ever seen a sign limiting the unladen weight .. it 
> is always a limit on the total weight that the structure is rated for.
> So I don't think there is much point in discussing it? At least not from 
> my limited knowledge.
>
Unladen weight is used in European countries to apply only to goods vehicles, 
either 3.5t or 7.5t, and is tagged as hgv=no/destination.

It has nothing to do with structures, it is to prevent heavy goods vehicles 
taking short cuts through residential areas.

It only apples to goods vehicles, as you need buses to have access.

Phil (trigpoint)
-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Maxweight wiki page changes

[Warin]

On 06/07/19 19:46, Colin Smale wrote:


On 2019-07-06 10:48, Warin wrote:


On 06/07/19 18:16, Colin Smale wrote:


On 2019-07-06 05:03, Warin wrote:

On 05/07/19 19:33, Mateusz Konieczny wrote:

3 Jul 2019, 12:52 by o...@westnordost.de:

1.1 At the examples: for max empty weight, I propose the
key maxemptyweight. It suggests itself.

Added, with link back to this post


Here that would be called "maximum Tare weight". In the UK? 

Probably "maximum unladen weight." "Tare" does exist as a word, and 
is frequently used in logistics (empty weight of containers etc) but 
AFAIK not in the context of traffic regulations.




Possibly not where you are.. but

"registrable light motor vehicle means a motor vehicle that is 
registrable and has a tare mass that is not greater than 2,794 
kilograms."


From https://www.legislation.nsw.gov.au/#/view/regulation/2017/451/full

And also in other traffic legislation in Australia...

In the UK?

"(h)the manner in which the tare weight of road vehicles, or of road 
vehicles of any particular class or description is to be determined. "

from https://www.legislation.gov.uk/ukpga/1985/72


That is not a traffic regulation, that's about metrology. And by the 
way, I am speaking as a Brit, so native speaker and somewhat 
conversant with the laws and legal system. As I said, the word "tare" 
does exist, and is used in certain specific contexts. But in 
connection with road vehicles, everybody in the UK speaks of Unladen 
Weight.


https://www.gov.uk/vehicle-weights-explained



Ok.
Here trucks have small signs on there side, they state the tare weight 
and gvw. I think these are used to confirm the vehicle is not overloaded 
when inspected (we have both mobile and stationary testing).
Also tare is used to specify the maximum tare weight of a trailer that 
inexperienced drivers can use, and that is a road regulation. It may 
also be used for other things.

A fairly common term here.

-
Further nit picking..
The "Unladen weight" is usually done without fuel but in all other ways 
ready for the road -i.e. includes spare tyre/s, tools, battery, coolant, 
oil etc etc. ???
I think some manufactures sales brochures quote figures without some of 
these to make it appear that they have greater load carrying capabilities.

Again this may vary from place to place around the world.


I would be happy with "unladen weight" rather than "empty weight".
As for "maximum" .. I would use "limit" similar to the use of "speed 
limit". So it would become "unladen weight limit".


I don't think I have ever seen a sign limiting the unladen weight .. it 
is always a limit on the total weight that the structure is rated for.
So I don't think there is much point in discussing it? At least not from 
my limited knowledge.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Maxweight wiki page changes

[Philip Barnes]

Unladen is certainly the used, and understood, way of expressing such 
restrictions in the UK.

https://www.gov.uk/vehicle-weights-explained

Phil (trigpoint)

On Saturday, 6 July 2019, Tobias Zwick wrote:
> So "unladen" is the word used in UK legislation? Do you have a link?
> Even if "unladen" is most commonly used in UK, I still find "empty" better 
> because it is easier to understand what it means for non native speakers 
> (simpler word).
> 
> In the US, "empty" seems to be most commonly used, as it is also written on 
> the signs while at the same time, the word is not exclusively known/used in 
> the US - unlike mall, freeway, etc.
> 
> "maxbogieweight" caused confusion earlier and was misunderstood as synonymous 
> to "maxaxleload" recently. "maxemptyweight" I think does not need 
> documentation to clarify what it stands for, "maxunladenweight" might.
> 
> In the end, UK naming should usually win, but maybe "empty vehicle weight" 
> does not sound so exotic to British ears?
> 
> Tobias
> 
> On July 6, 2019 11:46:33 AM GMT+02:00, Colin Smale  
> wrote:
> >On 2019-07-06 10:48, Warin wrote:
> >
> >> On 06/07/19 18:16, Colin Smale wrote: 
> >> 
> >> On 2019-07-06 05:03, Warin wrote: 
> >> On 05/07/19 19:33, Mateusz Konieczny wrote: 
> >> 3 Jul 2019, 12:52 by o...@westnordost.de: 
> >> 1.1 At the examples: for max empty weight, I propose the key
> >maxemptyweight. It suggests itself. 
> >> Added, with link back to this post
> >
> >Here that would be called "maximum Tare weight". In the UK? 
> >
> >Probably "maximum unladen weight." "Tare" does exist as a word, and is
> >frequently used in logistics (empty weight of containers etc) but AFAIK
> >not in the context of traffic regulations. 
> >Possibly not where you are.. but 
> >
> >"registrable light motor vehicle means a motor vehicle that is
> >registrable and has a tare mass that is not greater than 2,794
> >kilograms." 
> >
> >From  
> >https://www.legislation.nsw.gov.au/#/view/regulation/2017/451/full
> >
> >And also in other traffic legislation in Australia... 
> >
> >In the UK?
> >
> >"(h)the manner in which the tare weight of road vehicles, or of road
> >vehicles of any particular class or description is to be determined. "
> >from https://www.legislation.gov.uk/ukpga/1985/72 
> >
> >That is not a traffic regulation, that's about metrology. And by the
> >way, I am speaking as a Brit, so native speaker and somewhat conversant
> >with the laws and legal system. As I said, the word "tare" does exist,
> >and is used in certain specific contexts. But in connection with road
> >vehicles, everybody in the UK speaks of Unladen Weight. 
> >
> >https://www.gov.uk/vehicle-weights-explained
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Maxweight wiki page changes

[Tobias Zwick]

So "unladen" is the word used in UK legislation? Do you have a link?
Even if "unladen" is most commonly used in UK, I still find "empty" better 
because it is easier to understand what it means for non native speakers 
(simpler word).

In the US, "empty" seems to be most commonly used, as it is also written on the 
signs while at the same time, the word is not exclusively known/used in the US 
- unlike mall, freeway, etc.

"maxbogieweight" caused confusion earlier and was misunderstood as synonymous 
to "maxaxleload" recently. "maxemptyweight" I think does not need documentation 
to clarify what it stands for, "maxunladenweight" might.

In the end, UK naming should usually win, but maybe "empty vehicle weight" does 
not sound so exotic to British ears?

Tobias

On July 6, 2019 11:46:33 AM GMT+02:00, Colin Smale  
wrote:
>On 2019-07-06 10:48, Warin wrote:
>
>> On 06/07/19 18:16, Colin Smale wrote: 
>> 
>> On 2019-07-06 05:03, Warin wrote: 
>> On 05/07/19 19:33, Mateusz Konieczny wrote: 
>> 3 Jul 2019, 12:52 by o...@westnordost.de: 
>> 1.1 At the examples: for max empty weight, I propose the key
>maxemptyweight. It suggests itself. 
>> Added, with link back to this post
>
>Here that would be called "maximum Tare weight". In the UK? 
>
>Probably "maximum unladen weight." "Tare" does exist as a word, and is
>frequently used in logistics (empty weight of containers etc) but AFAIK
>not in the context of traffic regulations. 
>Possibly not where you are.. but 
>
>"registrable light motor vehicle means a motor vehicle that is
>registrable and has a tare mass that is not greater than 2,794
>kilograms." 
>
>From  
>https://www.legislation.nsw.gov.au/#/view/regulation/2017/451/full
>
>And also in other traffic legislation in Australia... 
>
>In the UK?
>
>"(h)the manner in which the tare weight of road vehicles, or of road
>vehicles of any particular class or description is to be determined. "
>from https://www.legislation.gov.uk/ukpga/1985/72 
>
>That is not a traffic regulation, that's about metrology. And by the
>way, I am speaking as a Brit, so native speaker and somewhat conversant
>with the laws and legal system. As I said, the word "tare" does exist,
>and is used in certain specific contexts. But in connection with road
>vehicles, everybody in the UK speaks of Unladen Weight. 
>
>https://www.gov.uk/vehicle-weights-explained

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

Re: [Tagging] lit=yes/no threshold

[Ferdinand Schicke]

What I couldsee work would be to have additional lit=* values like lit=weak or 
lit=spillover or lit=10lux

From: Mateusz Konieczny
Sent: Samstag, 6. Juli 2019 12:26
To: Tagging
Subject: [Tagging] lit=yes/no threshold

Some cases of lit=yes are clear (direct lighting of street/footway by lamps)

Some cases of lit=no are clear (no lighting whatsoever)

But in cities there is also often strong or weak ambient light, for example:

- carriageway is directly lit with so powerful light that spillover light
makes footway well lit - clearly lit=yes

- spillover light is quite dim but enough to comfortably walk - also lit=yes

- there is some ambient light, but not enough to walk without own
source of light - lit=no

- there is an ambient light, one can carefully walk, but only slowly,
people with poor eyesight needs their own source of light - lit=no (?)

Overall, I am considering adding to https://wiki.openstreetmap.org/wiki/Key:lit
recommendation to consider "is it necessary to bring your own light source to 
see it properly"
as recommended threshold for footways/paths.

Any problems with that or ideas for a better threshold between lit=yes and 
lit=no?

disclaimer: I am trying to make lit=yes/no definition more precise as part of 
my grant
https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849

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

Re: [Tagging] lit=yes/no threshold

[Colin Smale]

What problem are you trying to fix here? Usually it is pretty obvious if
a street has artificial lighting or not. Instead of creating artificial
boundaries quantising shades of grey into black and white, why not make
it more objective and record the light level in lux on the centre line
of the road? Or would it be better to do that on the footpath? That
would complicate matters because the two sides of the road may differ. 

I would say, don't over-engineer the model, and keep it fit for purpose.
The more complexity you add to these rules, the lower the compliance
will be. 

Also, don't forget that whether a road is "lit" or not has consequences
for traffic regulations, at least in the UK. There is a specific
definition associated with this. If you break that link, there will be
another interminable discussion about retagging. 

My vote is to leave lit=* alone! 

On 2019-07-06 12:24, Mateusz Konieczny wrote:

> Some cases of lit=yes are clear (direct lighting of street/footway by lamps) 
> 
> Some cases of lit=no are clear (no lighting whatsoever) 
> 
> But in cities there is also often strong or weak ambient light, for example: 
> 
> - carriageway is directly lit with so powerful light that spillover light 
> makes footway well lit - clearly lit=yes 
> 
> - spillover light is quite dim but enough to comfortably walk - also lit=yes 
> 
> - there is some ambient light, but not enough to walk without own 
> source of light - lit=no 
> 
> - there is an ambient light, one can carefully walk, but only slowly, 
> people with poor eyesight needs their own source of light - lit=no (?) 
> 
> Overall, I am considering adding to 
> https://wiki.openstreetmap.org/wiki/Key:lit 
> recommendation to consider "is it necessary to bring your own light source to 
> see it properly" 
> as recommended threshold for footways/paths. 
> 
> Any problems with that or ideas for a better threshold between lit=yes and 
> lit=no? 
> 
> disclaimer: I am trying to make lit=yes/no definition more precise as part of 
> my grant 
> https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849 
> ___
> 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] lit=yes/no threshold

[Mateusz Konieczny]

Some cases of lit=yes are clear (direct lighting of street/footway by lamps)

Some cases of lit=no are clear (no lighting whatsoever)

But in cities there is also often strong or weak ambient light, for example:

- carriageway is directly lit with so powerful light that spillover light
makes footway well lit - clearly lit=yes

- spillover light is quite dim but enough to comfortably walk - also lit=yes

- there is some ambient light, but not enough to walk without own
source of light - lit=no

- there is an ambient light, one can carefully walk, but only slowly,
people with poor eyesight needs their own source of light - lit=no (?)

Overall, I am considering adding to https://wiki.openstreetmap.org/wiki/Key:lit 

recommendation to consider "is it necessary to bring your own light source to 
see it properly"
as recommended threshold for footways/paths.

Any problems with that or ideas for a better threshold between lit=yes and 
lit=no?

disclaimer: I am trying to make lit=yes/no definition more precise as part of 
my grant
https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/368849
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Maxweight wiki page changes

[Colin Smale]

On 2019-07-06 10:48, Warin wrote:

> On 06/07/19 18:16, Colin Smale wrote: 
> 
> On 2019-07-06 05:03, Warin wrote: 
> On 05/07/19 19:33, Mateusz Konieczny wrote: 
> 3 Jul 2019, 12:52 by o...@westnordost.de: 
> 1.1 At the examples: for max empty weight, I propose the key maxemptyweight. 
> It suggests itself. 
> Added, with link back to this post

Here that would be called "maximum Tare weight". In the UK? 

Probably "maximum unladen weight." "Tare" does exist as a word, and is
frequently used in logistics (empty weight of containers etc) but AFAIK
not in the context of traffic regulations. 
Possibly not where you are.. but 

"registrable light motor vehicle means a motor vehicle that is
registrable and has a tare mass that is not greater than 2,794
kilograms." 

>From  
https://www.legislation.nsw.gov.au/#/view/regulation/2017/451/full

And also in other traffic legislation in Australia... 

In the UK?

"(h)the manner in which the tare weight of road vehicles, or of road
vehicles of any particular class or description is to be determined. "
from https://www.legislation.gov.uk/ukpga/1985/72 

That is not a traffic regulation, that's about metrology. And by the
way, I am speaking as a Brit, so native speaker and somewhat conversant
with the laws and legal system. As I said, the word "tare" does exist,
and is used in certain specific contexts. But in connection with road
vehicles, everybody in the UK speaks of Unladen Weight. 

https://www.gov.uk/vehicle-weights-explained___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Maxweight wiki page changes

[Warin]

On 06/07/19 18:16, Colin Smale wrote:


On 2019-07-06 05:03, Warin wrote:


On 05/07/19 19:33, Mateusz Konieczny wrote:

3 Jul 2019, 12:52 by o...@westnordost.de:

1.1 At the examples: for max empty weight, I propose the key
maxemptyweight. It suggests itself.

Added, with link back to this post


Here that would be called "maximum Tare weight". In the UK?


Probably "maximum unladen weight." "Tare" does exist as a word, and is 
frequently used in logistics (empty weight of containers etc) but 
AFAIK not in the context of traffic regulations.




Possibly not where you are.. but

"registrable light motor vehicle means a motor vehicle that is 
registrable and has a tare mass that is not greater than 2,794 kilograms."


From https://www.legislation.nsw.gov.au/#/view/regulation/2017/451/full

And also in other traffic legislation in Australia...

In the UK?

"(h)the manner in which the tare weight of road vehicles, or of road 
vehicles of any particular class or description is to be determined. "

from https://www.legislation.gov.uk/ukpga/1985/72


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

Re: [Tagging] Maxweight wiki page changes

[Colin Smale]

On 2019-07-06 05:03, Warin wrote:

> On 05/07/19 19:33, Mateusz Konieczny wrote: 
> 3 Jul 2019, 12:52 by o...@westnordost.de: 
> 1.1 At the examples: for max empty weight, I propose the key maxemptyweight. 
> It suggests itself. 
> Added, with link back to this post

Here that would be called "maximum Tare weight". In the UK? 

Probably "maximum unladen weight." "Tare" does exist as a word, and is
frequently used in logistics (empty weight of containers etc) but AFAIK
not in the context of traffic regulations.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Christmas shop

[Joseph Eisenberg]

It’s fine to make up new values in the “shop” key, so “shop=christmas”
would work: already used 14 times.

I think party shops are different.

On Sat, Jul 6, 2019 at 3:51 PM Graeme Fitzpatrick 
wrote:

> Just mapping a Christmas shop  https://christmasshack.com.au/, which, as
> the name suggests!, is a shop that operates year round selling Christmas
> decorations & supplies of various sorts.
>
> Best option I could find to tag it is
> https://wiki.openstreetmap.org/wiki/Tag:shop=party
>
> Wondering if there would be any point to expanding the very bare entry to
> include "types" (using that terrible word again!) of party: Christmas,
> fancy dress, fireworks (?) & so on with lot's of examples that I can't
> think of or don't know!
>
> 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

[Tagging] Christmas shop

[Graeme Fitzpatrick]

Just mapping a Christmas shop  https://christmasshack.com.au/, which, as
the name suggests!, is a shop that operates year round selling Christmas
decorations & supplies of various sorts.

Best option I could find to tag it is
https://wiki.openstreetmap.org/wiki/Tag:shop=party

Wondering if there would be any point to expanding the very bare entry to
include "types" (using that terrible word again!) of party: Christmas,
fancy dress, fireworks (?) & so on with lot's of examples that I can't
think of or don't know!

Thanks

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

Re: [Tagging] Use bbq=yes/no or barbecue_grill=yes/no with campsites?

[Graeme Fitzpatrick]

On Sat, 6 Jul 2019 at 16:27, Joseph Eisenberg 
wrote:

>
> Should we use bbq=yes or barbecue_grill=yes with campsites, caravan
> sites and camp pitches to specify the presence of a grill that can be
> used for bbq / grilling?
>

I would go for barbecue_grill=yes to show that there is "something" provded.

bbq=yes means that you are allowed to cook outside your caravan / tent,
usually using your own gas bbq

Thanks

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

Re: [Tagging] one feature one element

[Joseph Eisenberg]

>> *"For example, use the feature leisure=picnic_site with the property
>> tag drinking_water=yes, instead of using the separate feature tag
>> amenity=drinking_water on the same node or area."
>>
>> This example is a bad idea and mappers shouldn't be encouraged to do
>> so. amenity=drinking_water is far more popular tag and replacing it
>> with drinking_water=yes may hurt data consumers.
>
> I don't think it is an issue of replacing it. But where the location of
> the drinking water is unknown?

Right. It's great to map amenity=drinking_water on a node at the exact
position of a drinking fountain or water tap.

But if you want to say that a leisure=picnic_site has access to
drinking water without creating a separate node, then use the approved
and popular tag drinking_water=yes on the same area or node as the
picnic_site.

The key drinking_water has been used over 60,000 times and was
approved in a well-developed proposal back in 2014, so I picked this
example for the page.

But if there is a better example (eg atm=yes and amenity=atm?) feel
free to change it.

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

Re: [Tagging] Use bbq=yes/no or barbecue_grill=yes/no with campsites?

[Joseph Eisenberg]

Another user added bring_own_bbq=yes as a suggestion on the amenity=bbq page

But, getting back to the original question, which I need answered for
my draft proposal Proposed_features/Campsite_properties:

Should we use bbq=yes or barbecue_grill=yes with campsites, caravan
sites and camp pitches to specify the presence of a grill that can be
used for bbq / grilling?

On 7/6/19, Warin <61sundow...@gmail.com> wrote:
> On 06/07/19 02:28, Jmapb via Tagging wrote:
>> On 7/5/2019 10:56 AM, Joseph Eisenberg wrote:
>>> I don't think it would be necessary to combine "bbq=no" and
>>> "bring_own_bbq=yes" - if a feature such as a leisure=picnic_site is
>>> tagged "bring_own_bbq=yes" that is sufficient. The tag "bbq=no", like
>>> most tags with value "no", can be omitted.
>>
>> This is true. A better phrasing of the problem would be bbq=yes combined
>> with bring_own_bbq=yes. Does bbq=yes imply static bbq equipment, or just
>> permission to bbq that's further refined by the bring_own_bbq=yes tag?
>
> To me
>
> bbq=yes means there is a physical bbq there and I can use it. To have a
> physical presence and not being able to use it is foolish.
>
> bbq=no means I cannot bbq here, I don't think have never used it.
>
> If there s a need to specify the bbq is permitted but you have to bring
> your own (BYO is a common abbreviation here) then a new value?
> bbq=bring_your_own???
>
>
>>
>> In my mind, the *only* reason bbq=yes would mean the presence of a grill
>> is by echoing the amenity=atm/atm=yes pattern. But I don't think that
>> pattern works particularly well in this case. And as you pointed out in
>> your translation of the German wiki page, even amenity=bbq is already
>> used both ways, for equipment and permission: "One distinguishes between
>> free barbecue areas, where you have to take care of the grill yourself
>> and fixed barbecue areas with existing grill..." -- but there's no
>> indicating of *how* one distinguishes between the two. Obviously at one
>> point we didn't care to tag the difference, but now that we do, I don't
>> see any clear way of tagging all three possibilities
>> (grill/byo-grill/both) using the current tags.
>
> bbq:cooking_surface=grill/plate/* ??
> where plate is a continuous surface for cooking on, like a fixed pan,
> these usually drain to some point for cleaning.
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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