Re: [Tagging] Feature Proposal - RFC - Campsite properties

[Joseph Eisenberg]

It's been a week since the RFC for this proposal focused on campsites
and related tourism features. It which would:

1) Deprecate booking=* (use reservation=* instead)

2)  Deprecate bbq=* (use barbecue_grill=* instead).

3) Create new wiki pages:
amenity=greywater_drain
amenity=power_supply
amenity=bear_box
scout=yes/no
waste_disposal=yes/no
bear_box=yes/no
greywater_drain=yes/no

And add new values to these pages:
Key:parking - add parking=yes/no
Key:capacity=* - capacity:tents/caravans/static_caravans would be mentioned

That's a lot of changes. So if anyone dislikes one of these changes,
please say so, so that I can separate it out into it's own proposal.

However, if all of these are non-controversial, I think it's okay to
discuss and vote on them all together, to save time for everyone.

-Joseph


On 8/22/19, Joseph Eisenberg  wrote:
> Please comment on this proposal for additional properties and features
> to be used in campsite, caravan site and camp pitch areas:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Campsite_properties
>
> Main changes:
>
> Deprecate booking=* (use reservation=* instead)
> Deprecate bbq=* (use barbecue_grill=* instead).
>
> The main issues:
>
> reservation=* vs Booking=* - both tags have been used, but the tag
> reservation=* is much more common and is a better known term in
> English.
>
> bbq=yes vs barbecue_grill=yes - the tag bbq=yes/no matches the common
> tag amenity=bbq, but it is somewhat ambiguous: does it mean there is a
> grill there, or that you can bring your own? Both tags are about
> equally common currently.
>
> tents= vs maxtents=* vs capacity:tents=* - there are 3 ways to
> tag how many tents are permitted at a campground or camp pitch. The
> last one is picked because it is the most widely used, and least
> ambiguous, and it allows tents=yes/no to be simpler, without numbers
> included as values.
>
> amenity=dryer vs amenity=clothes_dryer - the first is more common, the
> later appears to have been proposed for a clothes-line like outdoor
> structure, rather than a mechanical dryer, in Russia:
> RU:Tag:amenity=clothes_dryer
>
> This is the list of new wiki pages that would be created:
>
> amenity=greywater_drain
> amenity=power_supply
> amenity=bear_box
> scout=yes/no
> waste_disposal=yes/no
> bear_box=yes/no
> greywater_drain=yes/no
>
> And these pages would get new values
> Key:parking - add parking=yes/no
> capacity:tents/caravans/static_caravans would be mentioned on
> Key:capacity=*
>
> - Joseph
>

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Warin]

On 29/08/19 09:21, François Lacombe wrote:


Le jeu. 29 août 2019 à 01:01, Graeme Fitzpatrick 
mailto:graemefi...@gmail.com>> a écrit :



I've just had a quick play on TagInfo & protect_class &
protection_title, plus a couple of others, all refer to protected
areas of one type or another


Current usage on OSM is clear and I don't question this
This proposal is an opportunity to be sure we're choosing the most 
appropriate word regarding what the target is.


 How about reserving IP_class or IP_protection? Would seem to
cover it nicely (especially if they're not actually used!)


According to what Paul said, ingress_protection would be better. 
ip_protection is redundant (p of protection + "protection")


Then we shouldn't have simple protection=* for this proposal but 
_protection too.

As N of IUCN means Nature, what about nature_protection?


+1 for nature_protection. Says what it is?




Le jeu. 29 août 2019 à 01:05, Kevin Kenny > a écrit :



If people insist, I'd go to 'protected_area:category', but I consider
that to be rather too verbose, and I'm not sure that it's worth it to
avoid the minimal risk of namespace pollution.


Effort is appreciable, but there is no need to introduce namespace here
Currently I'd be in favour of removing at least _class or _type 
suffixes as it doesn't bring additional information.


Class and type add nothing, don't use them.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New proposal draft to simplify the mapping of farm buildings (stables)

[Warin]

On 29/08/19 09:45, Joseph Eisenberg wrote:

Re: > "The best I could come up with was  landuse=farmland +
produce=live_animal + animal=chicken"

It's more common to use landuse=farmyard for poultry farms, and if you
use produce=* it's more common to specify eggs, meat or live_animal=*
depending on what is sold.


I would see landuse=farmyard as an enclosed area associated with sheds etc.

If 'free range' then I would use landuse=farmland as this would be a larger 
area.
Some 'free range' properties have travelling sheds that are moved along with 
the live stock to enable use of various farmyards thus they are free of the 
usual farmyard buildings.





To specify that the farmyard is a poultry farm: farmyard=poultry,
animal=chicken, or livestock=poultry (or =chicken) are sometimes used.

As mentioned a week or two ago, there are a couple of different ways
to describe areas like paddocks for horses, cattle yards, sheepfolds,
poultry yards, etc, and for specifying pasture areas used for certain
animals.

Mostly these are on landuse=farmyard or landuse=meadow

See thread starting in:
https://lists.openstreetmap.org/pipermail/tagging/2019-August/047500.html

1) landuse=meadow + meadow=pasture (9000 uses), =paddock (300 uses); -
not specific

2) landuse=animal_keeping + animal_keeping=horse, =cow, =sheep (2232
uses, 1855 are =horse)

3) landuse=farmyard + farmyard=feedlot, =poultry, =cattle yard, =dairy
etc (1500 uses)

4) animal=yes + landuse=meadow/farmyard/etc; values =chicken, =cow,
=cattle, =goat, =sheep, etc (2137 uses with meadow/farmyard - but
"=yes" is most of them, and it's also used for zoo animal, pets)

5) produce=* + landuse=meadow/farmyard/etc; common values milk, =eggs,
=cheese, =meat, =live_animal, or rarely = (190 uses)

6)  livestock=* + landuse=meadow/farmyard/etc.; values =cattle,
=poultry, =horse, =pig, =chicken (132 uses)

Also see crop=* + landuse=meadow/farmyard; values =,
=poultry, =dairy, -=fish, =milk, etc - (poultry 468 times, dairy 187,
fish 64 - but I wouldn't use "crop=" this way myself)

(For aquaculture, most common is: landuse=aquaculture +
aquaculture=; egg =shrimp, =fish, =seaweed, etc.)

On 8/29/19, Martin Koppenhoefer  wrote:


sent from a phone


On 29. Aug 2019, at 00:34, Graeme Fitzpatrick 
wrote:

The preferences range from free-range chickens
https://www.google.com/search?newwindow=1=1242=603=isch=1=dv1mXaqGAY6UvQSrmrHoBA=free+range+chicken+farm=free+range+chicken_l=img.3.1.0l10.741863.743719..746741...0.0..0.334.2142.0j6j3j1..01..gws-wiz-img...0i7i30.SutsHdHWImU



“free_range” as a term would work for pigs as well:
https://www.google.com/search?q=free+range+pig+farm

Not sure it is needed if we look at used tagging, it could be described e.g.
with these tags:
landuse=meadow or farmland
meadow or farmland=pasture
animal=pig / cow / sheep / chicken / turkey / goose / ostrich / poultry (if
you want to be less specific) / ...

(“animal” is less established tagging)
Is pasture as a term ok for a small area? Inside a farmyard, how would a
animal enclosure be tagged like? If pigsty is the value for an area with
outside area and a building, which is the key?
split the farmyard landuse and add
farmyard=pigsty?
The farm as an entity could be represented by a place=farm area, if
splitting the landuse is a concern.

Cheers Martin





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




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

Re: [Tagging] New proposal draft to simplify the mapping of farm buildings (stables)

[Joseph Eisenberg]

Re: > "The best I could come up with was  landuse=farmland +
produce=live_animal + animal=chicken"

It's more common to use landuse=farmyard for poultry farms, and if you
use produce=* it's more common to specify eggs, meat or live_animal=*
depending on what is sold.

To specify that the farmyard is a poultry farm: farmyard=poultry,
animal=chicken, or livestock=poultry (or =chicken) are sometimes used.

As mentioned a week or two ago, there are a couple of different ways
to describe areas like paddocks for horses, cattle yards, sheepfolds,
poultry yards, etc, and for specifying pasture areas used for certain
animals.

Mostly these are on landuse=farmyard or landuse=meadow

See thread starting in:
https://lists.openstreetmap.org/pipermail/tagging/2019-August/047500.html

1) landuse=meadow + meadow=pasture (9000 uses), =paddock (300 uses); -
not specific

2) landuse=animal_keeping + animal_keeping=horse, =cow, =sheep (2232
uses, 1855 are =horse)

3) landuse=farmyard + farmyard=feedlot, =poultry, =cattle yard, =dairy
etc (1500 uses)

4) animal=yes + landuse=meadow/farmyard/etc; values =chicken, =cow,
=cattle, =goat, =sheep, etc (2137 uses with meadow/farmyard - but
"=yes" is most of them, and it's also used for zoo animal, pets)

5) produce=* + landuse=meadow/farmyard/etc; common values milk, =eggs,
=cheese, =meat, =live_animal, or rarely = (190 uses)

6)  livestock=* + landuse=meadow/farmyard/etc.; values =cattle,
=poultry, =horse, =pig, =chicken (132 uses)

Also see crop=* + landuse=meadow/farmyard; values =,
=poultry, =dairy, -=fish, =milk, etc - (poultry 468 times, dairy 187,
fish 64 - but I wouldn't use "crop=" this way myself)

(For aquaculture, most common is: landuse=aquaculture +
aquaculture=; egg =shrimp, =fish, =seaweed, etc.)

On 8/29/19, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 29. Aug 2019, at 00:34, Graeme Fitzpatrick 
>> wrote:
>>
>> The preferences range from free-range chickens
>> https://www.google.com/search?newwindow=1=1242=603=isch=1=dv1mXaqGAY6UvQSrmrHoBA=free+range+chicken+farm=free+range+chicken_l=img.3.1.0l10.741863.743719..746741...0.0..0.334.2142.0j6j3j1..01..gws-wiz-img...0i7i30.SutsHdHWImU
>>
>
>
> “free_range” as a term would work for pigs as well:
> https://www.google.com/search?q=free+range+pig+farm
>
> Not sure it is needed if we look at used tagging, it could be described e.g.
> with these tags:
> landuse=meadow or farmland
> meadow or farmland=pasture
> animal=pig / cow / sheep / chicken / turkey / goose / ostrich / poultry (if
> you want to be less specific) / ...
>
> (“animal” is less established tagging)
> Is pasture as a term ok for a small area? Inside a farmyard, how would a
> animal enclosure be tagged like? If pigsty is the value for an area with
> outside area and a building, which is the key?
> split the farmyard landuse and add
> farmyard=pigsty?
> The farm as an entity could be represented by a place=farm area, if
> splitting the landuse is a concern.
>
> Cheers Martin
>
>
>
>

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[François Lacombe]

Le jeu. 29 août 2019 à 01:01, Graeme Fitzpatrick  a
écrit :

>
> I've just had a quick play on TagInfo & protect_class & protection_title,
> plus a couple of others, all refer to protected areas of one type or another
>

Current usage on OSM is clear and I don't question this
This proposal is an opportunity to be sure we're choosing the most
appropriate word regarding what the target is.


>  How about reserving IP_class or IP_protection? Would seem to cover it
> nicely (especially if they're not actually used!)
>

According to what Paul said, ingress_protection would be better.
ip_protection is redundant (p of protection + "protection")

Then we shouldn't have simple protection=* for this proposal but
_protection too.
As N of IUCN means Nature, what about nature_protection?

Le jeu. 29 août 2019 à 01:05, Kevin Kenny  a
écrit :

>
> If people insist, I'd go to 'protected_area:category', but I consider
> that to be rather too verbose, and I'm not sure that it's worth it to
> avoid the minimal risk of namespace pollution.


Effort is appreciable, but there is no need to introduce namespace here
Currently I'd be in favour of removing at least _class or _type suffixes as
it doesn't bring additional information.

All the best

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Joseph Eisenberg]

Re: > change the key to 'protection_category='

That would be fine.

Re: > 'protected_area:category'

No thank you; no need to add :type or :category suffixes to keys. You
could use 'protected_area=*' as the key. It has the disadvantage of
already being used a couple of hundred times, but the current values
are not terrible:
https://taginfo.openstreetmap.org/keys/protected_area

But overall, I think protection_class=* is fine.

On 8/29/19, Kevin Kenny  wrote:
> On Wed, Aug 28, 2019 at 6:21 PM Paul Allen  wrote:
>> To be honest, I'd not expect a national park to be protected from liquid
>> or particulate ingress,
>> nor an electrical enclosure to impose restrictions on building houses
>> within it.  Nor do I expect
>> even micro-mappers to document the IP rating of electrical enclosures they
>> map.  The only
>> thing we really need to worry about is namespace collision, and that's
>> usually dealt with by
>> a first-come/first-served approach.
>>
>>> Let's see if Kevin wishes to take care of this
>>
>> If he can, that would be good.  If he can't, then anyone who needs to map
>> the International
>> Protection rating of electrical enclosures will have to come up with a
>> different tag. :)
>
> As Paul observes, the collision seems pretty far-fetched. I'm sure
> that there are all sorts of non-geographic things that are protected
> from something or other and may admit of classes of protection. I
> can't imagine any of those being associated with a
> boundary=protected_area (or national_park, or aboriginal_lands), and I
> don't intend 'protection_class' to stand alone.
>
> I _am_ tempted to change the name to 'protection_category' because
> that's IUCN's term, and then discuss on the Wiki that 'recreation',
> 'culture', and 'hazard' expand upon the IUCN vocabulary to encompass
> types of protection that the International Union for the Conservation
> of *Nature* does not recognize (these protections, in general, apply
> to sites that are substantially altered from a natural state and for
> which returning them to a natural state may not be an objective).
>
> If people insist, I'd go to 'protected_area:category', but I consider
> that to be rather too verbose, and I'm not sure that it's worth it to
> avoid the minimal risk of namespace pollution.
>
> --
> 73 de ke9tv/2, Kevin
>
> ___
> 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 proposal draft to simplify the mapping of farm buildings (stables)

[Martin Koppenhoefer]

sent from a phone

> On 29. Aug 2019, at 00:34, Graeme Fitzpatrick  wrote:
> 
> The preferences range from free-range chickens 
> https://www.google.com/search?newwindow=1=1242=603=isch=1=dv1mXaqGAY6UvQSrmrHoBA=free+range+chicken+farm=free+range+chicken_l=img.3.1.0l10.741863.743719..746741...0.0..0.334.2142.0j6j3j1..01..gws-wiz-img...0i7i30.SutsHdHWImU
>  


“free_range” as a term would work for pigs as well:
https://www.google.com/search?q=free+range+pig+farm

Not sure it is needed if we look at used tagging, it could be described e.g. 
with these tags:
landuse=meadow or farmland 
meadow or farmland=pasture
animal=pig / cow / sheep / chicken / turkey / goose / ostrich / poultry (if you 
want to be less specific) / ...

(“animal” is less established tagging)
Is pasture as a term ok for a small area? Inside a farmyard, how would a animal 
enclosure be tagged like? If pigsty is the value for an area with outside area 
and a building, which is the key?
split the farmyard landuse and add
farmyard=pigsty?
The farm as an entity could be represented by a place=farm area, if splitting 
the landuse is a concern.

Cheers Martin 



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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

On Wed, Aug 28, 2019 at 6:21 PM Paul Allen  wrote:
> To be honest, I'd not expect a national park to be protected from liquid or 
> particulate ingress,
> nor an electrical enclosure to impose restrictions on building houses within 
> it.  Nor do I expect
> even micro-mappers to document the IP rating of electrical enclosures they 
> map.  The only
> thing we really need to worry about is namespace collision, and that's 
> usually dealt with by
> a first-come/first-served approach.
>
>> Let's see if Kevin wishes to take care of this
>
> If he can, that would be good.  If he can't, then anyone who needs to map the 
> International
> Protection rating of electrical enclosures will have to come up with a 
> different tag. :)

As Paul observes, the collision seems pretty far-fetched. I'm sure
that there are all sorts of non-geographic things that are protected
from something or other and may admit of classes of protection. I
can't imagine any of those being associated with a
boundary=protected_area (or national_park, or aboriginal_lands), and I
don't intend 'protection_class' to stand alone.

I _am_ tempted to change the name to 'protection_category' because
that's IUCN's term, and then discuss on the Wiki that 'recreation',
'culture', and 'hazard' expand upon the IUCN vocabulary to encompass
types of protection that the International Union for the Conservation
of *Nature* does not recognize (these protections, in general, apply
to sites that are substantially altered from a natural state and for
which returning them to a natural state may not be an objective).

If people insist, I'd go to 'protected_area:category', but I consider
that to be rather too verbose, and I'm not sure that it's worth it to
avoid the minimal risk of namespace pollution.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Graeme Fitzpatrick]

On Thu, 29 Aug 2019 at 08:21, Paul Allen  wrote:

> On Wed, 28 Aug 2019 at 22:50, François Lacombe 
> wrote:
>
>> Thats a detail, official document stands for International Protection
>> https://texa-co.ir/wp-content/uploads/2017/04/IEC-60529.pdf (see §4 page
>> 18)
>>
>
> You're right.  I've only ever encountered "IP" expanded as Ingress
> Protection, which makes
> sense.
>

It requires at least a strong context to not be confused with any other
>> protection classification system.
>>
>
> To be honest, I'd not expect a national park to be protected from liquid
> or particulate ingress,
> nor an electrical enclosure to impose restrictions on building houses
> within it.  Nor do I expect
> even micro-mappers to document the IP rating of electrical enclosures they
> map.  The only
> thing we really need to worry about is namespace collision, and that's
> usually dealt with by
> a first-come/first-served approach.
>

I've just had a quick play on TagInfo & protect_class & protection_title,
plus a couple of others, all refer to protected areas of one type or another


>  If he can't, then anyone who needs to map the International
> Protection rating of electrical enclosures will have to come up with a
> different tag. :)
>

How about reserving IP_class or IP_protection? Would seem to cover it
nicely (especially if they're not actually used!)

Thanks

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Joseph Eisenberg]

Re: “anyone who needs to map the International Protection rating of
electrical enclosures will have to come up with a different tag”

+1

No need to worry about this.

Joseph

On Thu, Aug 29, 2019 at 7:21 AM Paul Allen  wrote:

> On Wed, 28 Aug 2019 at 22:50, François Lacombe 
> wrote:
>
>>
>> Le mer. 28 août 2019 à 19:09, Paul Allen  a écrit :
>>
>>>
>>> Nope, Ingress Protection.  It's an international standard, though.
>>>
>> Thats a detail, official document stands for International Protection
>> https://texa-co.ir/wp-content/uploads/2017/04/IEC-60529.pdf (see §4 page
>> 18)
>>
>
> You're right.  I've only ever encountered "IP" expanded as Ingress
> Protection, which makes
> sense.  Now I've done some digging, I found the Wikipedia talk page where
> they suspect
> the authors of the standard made an error.  One commenter pointed out that
> "International
> Protection" would be about preventing warfare.  Another commenter said
> that when he
> worked on translating a standard he encountered many errors.  Even so, the
> official
> document covering testing of enclosures for the degree of protection they
> offer to the
> ingress of liquids and particulates says, as an aside, that IP stands for
> "International
> Protection" and not the "Ingress Protection" that would make more sense.
>
> If we can avoid confusion, we should.  I'm not sure that this does.
>>>
>> It requires at least a strong context to not be confused with any other
>> protection classification system.
>>
>
> To be honest, I'd not expect a national park to be protected from liquid
> or particulate ingress,
> nor an electrical enclosure to impose restrictions on building houses
> within it.  Nor do I expect
> even micro-mappers to document the IP rating of electrical enclosures they
> map.  The only
> thing we really need to worry about is namespace collision, and that's
> usually dealt with by
> a first-come/first-served approach.
>
> Let's see if Kevin wishes to take care of this
>>
>
> If he can, that would be good.  If he can't, then anyone who needs to map
> the International
> Protection rating of electrical enclosures will have to come up with a
> different tag. :)
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New proposal draft to simplify the mapping of farm buildings (stables)

[Graeme Fitzpatrick]

On Thu, 29 Aug 2019 at 01:02, Paul Allen  wrote:

>
>
>> https://media.gettyimages.com/photos/pigs-are-seen-in-a-pigsty-at-a-farm-in-pluduno-western-france-on-2-picture-id465455096
>>
>
> As far as I can tell, that's classes as a piggery in British English.  And
> since it's far more common
> than the old style sty, I think we probably need to acknowledge it.
>

 Yep, I'd agree with piggery


> more happy pigs to be found here (supposedly)
>> https://www.naturalpigfarming.com/low%20res%2060/IMG_1385.jpg
>>
>
> And that is a pig pen.  But, according to some, also a pig sty.  An
> enclosure rather than a building.
>

This time, I'd go sty, although pen would also be OK. The one's I've seen
in farmyards have had a rudimentary roof in one corner, with the rest being
dirt or mud!

beforehand or not, the wiki page ought to list it as a type of farm
> building.
>
> Do we have a good way of mapping enclosures?  There are sheep folds as
> well as pig pens.
>

The other big one (literally!) is chickens.

The preferences range from free-range chickens
https://www.google.com/search?newwindow=1=1242=603=isch=1=dv1mXaqGAY6UvQSrmrHoBA=free+range+chicken+farm=free+range+chicken_l=img.3.1.0l10.741863.743719..746741...0.0..0.334.2142.0j6j3j1..01..gws-wiz-img...0i7i30.SutsHdHWImU


through barns
https://www.nuformdirect.com/media/photo-gallery/agricultural-gallery/poultry/attachment/29/

to cages
https://www.google.com/search?newwindow=1=1242=603=isch=1=YgBnXeemKtSUwgO99YXwBA=cage+chicken+farm=cage+chicken+farm_l=img.3..0j0i7i30j0i8i30l2.86091.86494..87756...0.0..0.289.885.0j2j2..01..gws-wiz-img.-Gyaug_TO5c=0ahUKEwjn34ftzqbkAhVUinAKHb16AU4Q4dUDCAY=5

The few commercial chicken farms I've mapped, the best I could come up with
was
landuse=farmland + produce=live_animal + animal=chicken

Thanks

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Paul Allen]

On Wed, 28 Aug 2019 at 22:50, François Lacombe 
wrote:

>
> Le mer. 28 août 2019 à 19:09, Paul Allen  a écrit :
>
>>
>> Nope, Ingress Protection.  It's an international standard, though.
>>
> Thats a detail, official document stands for International Protection
> https://texa-co.ir/wp-content/uploads/2017/04/IEC-60529.pdf (see §4 page
> 18)
>

You're right.  I've only ever encountered "IP" expanded as Ingress
Protection, which makes
sense.  Now I've done some digging, I found the Wikipedia talk page where
they suspect
the authors of the standard made an error.  One commenter pointed out that
"International
Protection" would be about preventing warfare.  Another commenter said that
when he
worked on translating a standard he encountered many errors.  Even so, the
official
document covering testing of enclosures for the degree of protection they
offer to the
ingress of liquids and particulates says, as an aside, that IP stands for
"International
Protection" and not the "Ingress Protection" that would make more sense.

If we can avoid confusion, we should.  I'm not sure that this does.
>>
> It requires at least a strong context to not be confused with any other
> protection classification system.
>

To be honest, I'd not expect a national park to be protected from liquid or
particulate ingress,
nor an electrical enclosure to impose restrictions on building houses
within it.  Nor do I expect
even micro-mappers to document the IP rating of electrical enclosures they
map.  The only
thing we really need to worry about is namespace collision, and that's
usually dealt with by
a first-come/first-served approach.

Let's see if Kevin wishes to take care of this
>

If he can, that would be good.  If he can't, then anyone who needs to map
the International
Protection rating of electrical enclosures will have to come up with a
different tag. :)

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[François Lacombe]

Le mer. 28 août 2019 à 19:09, Paul Allen  a écrit :

> But IP ratings are regarded as environmental protection ratings.  So that
> has the same problem.
> "Environmental protection" can mean "protecting the environment" or
> "protecting things from the
> environment."
>

Seems legit
This will need further thinking, maybe someone else will get the proper key
name


>
> Nope, Ingress Protection.  It's an international standard, though.
>
Thats a detail, official document stands for International Protection
https://texa-co.ir/wp-content/uploads/2017/04/IEC-60529.pdf (see §4 page 18)

If we can avoid confusion, we should.  I'm not sure that this does.
>
It requires at least a strong context to not be confused with any other
protection classification system.

Let's see if Kevin wishes to take care of this

All the best

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

Re: [Tagging] Feature Proposal - RFC - traffic_calming=dynamic_bump

[Dave Swarthout]

Thanks for a nice job on the proposal. The new tag seems appropriate as
well. I have not seen anything like this in my travels but it sounds like a
wonderful idea.

Cheers,

Dave

On Wed, Aug 28, 2019 at 12:34 PM simson.gert...@gmail.com <
simson.gert...@gmail.com> wrote:

> The wording "bump" is ok in my eyes for the lowered hatch type too because:
>
> -after you roll down the inclined plane the edge "bumpes" you up again
> -I don't think the word "bump" necessarily implies the direction up or a
> direction at all.
> -The brand name of the device on the pictures is "Actibump"
>
> Regards
>
> Am 28.08.2019 um 21:14 schrieb Anton Klim:
> > Thanks for the proposal, this is something I haven’t heard of before!
> > Not sure if “bump” would be suitable for those that slide down beneath
> the surface? Maybe traffic_calming=dynamic/variable?
> >
> > Regards
> > Ant
> >
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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

[Tagging] Fw: Feature Proposal - RFC - cash_withdrawal

[amilopowers]

Hello

Thanks for your help and time you spent improving my proposal.

On Thursday evening about 20:00 UTC I plan to go to voting stage.

If you would like to add comments this is the right time. You need more time to 
work on this or know someone interested that needs time? - No problem let me 
know I'll wait longer then.

Again the link: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Cash_withdrawal

With my best regards
Ueli aka amilopowers


Sent from ProtonMail, encrypted email based in Switzerland.

‐‐‐ Original Message ‐‐‐
Am Samstag, August 24, 2019 8:13 AM schrieb :

> Hello Everyone
> 

> My proposal went from draft to rfc: 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Cash_withdrawal
> 

> Definition:
> There are more and more supermarkets, kiosks, convenience shops, railway 
> ticket offices and others where you can get cash at the cashier (checkout). 
> They are not an ATM because they are either operated by an employee (till) or 
> you use a device that is primarily a self-service checkout. I most cases I 
> know, the services are limited to specific banks, cards or networks and you 
> usually can't get money if you are from abroad. Furthermore there is a system 
> called "Sonect". With the app of their service you can get cash at kiosks and 
> other places such as bars and convenience shops.
> 

> I am happy to read your further comments.
> 

> With my best regards
> Ueli aka amilopowers
> 

> 
> Sent from ProtonMail, encrypted email based in Switzerland.

signature.asc
Description: PGP signature


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

Re: [Tagging] Feature Proposal - RFC - traffic_calming=dynamic_bump

[simson.gert...@gmail.com]

The wording "bump" is ok in my eyes for the lowered hatch type too because:

-after you roll down the inclined plane the edge "bumpes" you up again
-I don't think the word "bump" necessarily implies the direction up or a 
direction at all.

-The brand name of the device on the pictures is "Actibump"

Regards

Am 28.08.2019 um 21:14 schrieb Anton Klim:

Thanks for the proposal, this is something I haven’t heard of before!
Not sure if “bump” would be suitable for those that slide down beneath the 
surface? Maybe traffic_calming=dynamic/variable?

Regards
Ant



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

Re: [Tagging] Feature Proposal - RFC - traffic_calming=dynamic_bump

[Anton Klim]

Thanks for the proposal, this is something I haven’t heard of before!
Not sure if “bump” would be suitable for those that slide down beneath the 
surface? Maybe traffic_calming=dynamic/variable?

Regards
Ant

> 28 авг. 2019 г., в 21:54, "simson.gert...@gmail.com" 
>  написал(а):
> 
> Hello,
> 
> sorry it seems the html email type was not suitable for the mailing list. 
> Here is the email again in plain text:
> 
> I created a proposal. Please comment if you have comments.
> 
> Definition: A dynamic traffic calming whose impact depends on the drivers 
> actual speed
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:traffic_calming%3Ddynamic_bump
> 
> Best Regards,
> 
> Klumbumbus
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

[Tagging] Feature Proposal - RFC - traffic_calming=dynamic_bump

[simson.gert...@gmail.com]

Hello,

sorry it seems the html email type was not suitable for the mailing 
list. Here is the email again in plain text:


I created a proposal. Please comment if you have comments.

Definition: A dynamic traffic calming whose impact depends on the 
drivers actual speed


https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:traffic_calming%3Ddynamic_bump

Best Regards,

Klumbumbus


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

[Tagging] Feature Proposal - RFC - traffic_calming=dynamic_bump

[simson.gert...@gmail.com]

  
  
Hello,

I created a proposal. Please comment if you have comments.

Definition:
  A dynamic traffic calming whose impact depends on the drivers
  actual speed

https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Tag:traffic_calming%3Ddynamic_bump
Best Regards,
Klumbumbus

  


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

Re: [Tagging] Merging tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes

[s8evq]

No further comments have been made to the current version 
(https://wiki.openstreetmap.org/wiki/Template:Tagging_scheme_for_hiking_and_foot_route_relations)
 of the merged tagging schemes. If it's okay for everyone I would start 
transcluding it on the four pages (Hiking, route=hiking, route=foot and Walking 
routes)

On Tue, 20 Aug 2019 11:48:23 +0100, Paul Allen  wrote:

> On Tue, 20 Aug 2019 at 08:50, s8evq  wrote:
> 
> >
> >
> > On Sat, 17 Aug 2019 14:34:20 +0100, Paul Allen  wrote:
> >
> > > > A map with copyright permitting OSM to make use of its data.  There are
> > > several walks near  me which appear on maps published by the county
> > council or tourist board.
> > > Copyright does  not permit me to make use of those maps.
> >
> > If it's government maps with permission, you could argue the case.
> 
> 
> Nope.  Not for these.  Because the base map is explicitly copyright
> Ordnance Survey.  The route
> marking isn't itself copyright OS (I don't think) but copyright the county
> council (not explicitly,
> but the UK is a signatory to the Berne Convention).  But even with explicit
> permission from the
> council to use the route info on the map, I'd not use it because of the
> underlying OS map
> unless the OS also gave the OK.
> 
> 
> > But I'm especially afraid a lot of "not so official" routes would be
> > entered that way. I once found a kayak club had entered it's weekend trip
> > in OSM.
> >
> 
> According to the wiki, local routes are permitted.  All levels of walking
> route from trans-national
> to local.
> 
> Another argument against mapping based on other maps with permission is
> > that it's a lot harder to verify. If we only map based on the presence of
> > physical markers on the ground, other mappers who pass by might be able to
> > spot mistakes or omission. On the other hand, when something is mapped
> > based of an online PDF, I'm afraid it will not get double checked so
> > quickly anymore.
> >
> 
> The walks I mentioned use public footpaths, which are explicitly marked as
> such.  Signs or
> waymarks where they connect to a highway, waymarks as necessary along the
> way.  Other
> countries may do it differently, but here public footpaths are marked and
> even local walking
> clubs don't use routes which are not public footpaths unless the landowner
> has given
> explicit permission (in which case they will eventually become official
> public footpaths by
> dint of usage and marked as such).
> 
> -- 
> Paul
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Paul Allen]

On Wed, 28 Aug 2019 at 17:47, François Lacombe 
wrote:

>
> As both the topic of the proposal and the IP norm are approximately at the
> same semantic distance of "protection class" term,
>

Reasonable point.

that's why I recommend to move to "environment_protection=*" (or something
> like this) to be more focused on what is actually described.
>

But IP ratings are regarded as environmental protection ratings.  So that
has the same problem.
"Environmental protection" can mean "protecting the environment" or
"protecting things from the
environment."

IP stands for International Protection
>

Nope, Ingress Protection.  It's an international standard, though.

Even if protection class is a misnomer, I find risky to use it as this for
> a completely different topic, that's my 2 cts.All the best
>

If we can avoid confusion, we should.  I'm not sure that this does.

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[François Lacombe]

Le mer. 28 août 2019 à 18:15, Paul Allen  a écrit :

> "Protection class" is something of a misnomer when it comes to IEC 60529,
> since it specifies
> a level of ingress protection (hence the "I" and "P" in the designation)
> against water and
> dust.  It does, as a side-effect, have some bearing on the possibility of
> contact of dangerous
> parts by fingers, but that is largely incidental.  And while you may have
> seen it referred to
> as "protection class" it seems more common to refer to it as "ingress
> protection class."
>

Hi Paul,
As both the topic of the proposal and the IP norm are approximately at the
same semantic distance of "protection class" term, that's why I recommend
to move to "environment_protection=*" (or something like this) to be more
focused on what is actually described.
IP stands for International Protection, which indeed consist in limiting
ingress of foreign object or water in a given enclosure.

Even if protection class is a misnomer, I find risky to use it as this for
a completely different topic, that's my 2 cts.
All the best

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Paul Allen]

On Wed, 28 Aug 2019 at 16:50, François Lacombe 
wrote:

>
> I've noticed a potential conflict with protection degrees defined in IEC
> 60529 norm (IP-XY numbers seen on many electronic appliances), also called
> "protection class".
>

"Protection class" is something of a misnomer when it comes to IEC 60529,
since it specifies
a level of ingress protection (hence the "I" and "P" in the designation)
against water and
dust.  It does, as a side-effect, have some bearing on the possibility of
contact of dangerous
parts by fingers, but that is largely incidental.  And while you may have
seen it referred to
as "protection class" it seems more common to refer to it as "ingress
protection class."

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[François Lacombe]

Hi all,

This proposal sounds good in the field of knowledge it covers and I would
certainly go for it when vote will be open.

I've noticed a potential conflict with protection degrees defined in IEC
60529 norm (IP-XY numbers seen on many electronic appliances), also called
"protection class".
Could you please consider this contribution to RFC please?
https://wiki.openstreetmap.org/wiki/Talk:Proposal:_Named_protection_class_for_protected_areas#Potential_conflict_with_IEC_60529_degrees_of_protection

All the best

François

Le dim. 18 août 2019 à 15:43, Joseph Eisenberg 
a écrit :

> Kevin,
>
> The proposal looks pretty good.
>
> When you've finished editing, please make a clear list off all the
> new, proposed tags, in one place. Also please clarify what pages are
> being edited and if protect_class=* is being deprecated by this
> proposal.
>
> It might make sense to deprecate all values of protect_class other
> than 1 to 6, since those numbers at least correspond to the IUCN
> numbers and most are fairly commonly used, while the higher numbers
> are rare and confusing. Over time, if protection_class becomes much
> more popular, the protect_class:1 to 6 might also become obsolete, but
> for the short term it might be difficult to change them all right
> away.
>
> One thing is that you write in one place that
> protection_class=condition should maybe just be
> protection_class=hazard, to replace the current protect_class=15 and
> 16, "Location Condition" and "Longtime Hazard Area". I think this
> makes sense.
>
> Re: protect_class=24, "Political protection", you might need to talk
> to the folks in Brazil who are using this tag. Not all of them were
> happy with using boundary=aborignal_lands instead, if I recall
> correctly, but perhaps this could change.
>
> Thanks for working on this. I think it's worth doing, since most of
> the protect_class values have never really become used, and their
> meaning is not very clear.
>
> On 8/18/19, Kevin Kenny  wrote:
> > .As has already been discussed at some length in the thread on tagging
> > of State Parks in the US, I've been working on a proposal for a
> > 'protection_class=*' key to replace 'protect_class=*'. It replaces the
> > seven numeric codes from IUCN (plus a zoo of codes that OSM appears to
> > have cut out of whole cloth) with 'protection_object=*', whose values
> > are drawn from a group of word-oriented codes that, it is hoped, will
> > be more mnemonic. (The proposal to describe State Parks as protected
> > areas was reasonably well received except for the issue that it
> > depended on the numeric 'protect_class=*' to describe the protection.)
> >
> > The proposal has now reached a state where I think it can be opened
> > for a formal RFC, and can be found at
> >
> https://wiki.openstreetmap.org/wiki/Proposal:_Named_protection_class_for_protected_areas
> > .
> >
> > Of course, I'll monitor both this list and the talk page for the Wiki
> > page for comments, and try to address whatever comes up.
> > --
> > 73 de ke9tv/2, Kevin
> >
> > ___
> > 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] New proposal draft to simplify the mapping of farm buildings (stables)

[Paul Allen]

On Wed, 28 Aug 2019 at 15:37, Martin Koppenhoefer 
wrote:

>
> With regard to pig sty referring to an outdoor enclosure: the dictionary
> says it can mean both, a small building or outside area where pigs are
> kept. This is similar to German where, AFAIK, the outdoor areas associated
> with an animal building, may be comprised in the term (be seen as part of
> it).
>

I suppose it depends which dictionary you look at.  Also, English
dictionaries are descriptive,
not prescriptive.  It seems common (to me, but this isn't a topic I
generally discuss, so
it's not a good statistical sample) that sty usually refers to a building
and pen to an enclosure,
but the dictionaries I've looked at say sty means either building or
enclosure.

AFAIK this is a “modern” pigsty (not very suitable for the animals,
> although they live in small families they don’t have earth to move), it’s
> called slatted floor type.
>
> https://media.gettyimages.com/photos/pigs-are-seen-in-a-pigsty-at-a-farm-in-pluduno-western-france-on-2-picture-id465455096
>

As far as I can tell, that's classes as a piggery in British English.  And
since it's far more common
than the old style sty, I think we probably need to acknowledge it.
Whether we need a formal vote
beforehand or not, the wiki page ought to list it as a type of farm
building.

more happy pigs to be found here (supposedly)
> https://www.naturalpigfarming.com/low%20res%2060/IMG_1385.jpg
>

And that is a pig pen.  But, according to some, also a pig sty.  An
enclosure rather than a building.
Do we have a good way of mapping enclosures?  There are sheep folds as well
as pig pens.

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

Re: [Tagging] New proposal draft to simplify the mapping of farm buildings (stables)

[Martin Koppenhoefer]

sent from a phone

> On 28. Aug 2019, at 14:40, Paul Allen  wrote:
> 
> According to google translate, it's "pig flats," but I suspect it's being 
> literal rather
> than giving the equivalent English term.  I'd probably map it as 
> building=piggery + 
> levels=n.


maybe there isn’t an English equivalent, these multistorey industrial style 
animal farms are a Dutch invention as far as I know and you cannot find them in 
many other places. Sometimes there may even be facilities included within the 
same structure for slaughtering and putting the meat in cans or package it 
otherwise for transportation and sale (at least I have seen concepts for this 
20 years ago, so they will likely have it now).


With regard to pig sty referring to an outdoor enclosure: the dictionary says 
it can mean both, a small building or outside area where pigs are kept. This is 
similar to German where, AFAIK, the outdoor areas associated with an animal 
building, may be comprised in the term (be seen as part of it). Let me add that 
outdoor areas for animals aren’t the most frequent way of keeping them, sadly, 
they used to be rare in my area and are not yet the standard now either.

AFAIK this is a “modern” pigsty (not very suitable for the animals, although 
they live in small families they don’t have earth to move), it’s called slatted 
floor type.
https://media.gettyimages.com/photos/pigs-are-seen-in-a-pigsty-at-a-farm-in-pluduno-western-france-on-2-picture-id465455096

from the outside it may look like this:
https://www.wolfsystem.at/assets/WOLF-AT/WOLF-System/Produktsparten/Agrarbau/Staelle/_resampled/ResizedImageWyI3MDgiLCI0NjIiXQ/WOLFSystem-Agrarbau-Staelle-Schweinestaelle.jpg

more happy pigs to be found here (supposedly)
https://www.naturalpigfarming.com/low%20res%2060/IMG_1385.jpg

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

Re: [Tagging] New proposal draft to simplify the mapping of farm buildings (stables)

[Paul Allen]

On Wed, 28 Aug 2019 at 13:05, Peter Elderson  wrote:

> Pig ark:  https://www.youtube.com/watch?v=Rb4wTc79jY8
>

I wish you hadn't said that.  It forced me to do some googling.

Apparently, a pig sty isn't necessarily a building but is more usually an
enclosure.
Essentially it's a synonym for a pig pen.  I always thought a pig sty was a
building.
OSM wiki thinks a pig sty is a building.  It's not.  Which complicates
matters, at
least to the extent that we'll probably have to accept that OSM uses sty to
mean a building housing pigs and not an enclosure for pigs.

Further complication: the buildings used to confine pigs in small stalls
are piggeries
(piggery has a few usages according to taginfo).

Nederland has "varkensflats" ie multi-storey "appartment buildings" for
> pigs.  Wouldn't know a proper term for that in English though. I've seen it
> translated as "pig tower",
>

I've never even heard of those and have no idea what the English term is,
or even if there
is one.  According to google translate, it's "pig flats," but I suspect
it's being literal rather
than giving the equivalent English term.  I'd probably map it as
building=piggery +
levels=n.


> but that term googles to https://images.app.goo.gl/WMeG3kychr7kokw7A
>

:)

We use "stal" (~stable) for various, but not all farm animals. I think they
> need to have an average of 4 limbs reaching from the body to the ground, in
> order to live in a 'stal'. Fish and poultry are excluded.
>

Sounds about right for the original English meaning of stable.

To compensate, teenagers are granted the right to live in a "stal" as long
> as their brain is rewiring for adulthood.
>

Here we would use pigsty rather than stable. :)

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

Re: [Tagging] New proposal draft to simplify the mapping of farm buildings (stables)

[Peter Elderson]

Pig ark:  https://www.youtube.com/watch?v=Rb4wTc79jY8
Nederland has "varkensflats" ie multi-storey "appartment buildings" for
pigs.  Wouldn't know a proper term for that in English though. I've seen it
translated as "pig tower", but that term googles to
https://images.app.goo.gl/WMeG3kychr7kokw7A
We use "stal" (~stable) for various, but not all farm animals. I think they
need to have an average of 4 limbs reaching from the body to the ground, in
order to live in a 'stal'. Fish and poultry are excluded. To compensate,
teenagers are granted the right to live in a "stal" as long as their brain
is rewiring for adulthood.

Fr gr Peter Elderson


Op wo 28 aug. 2019 om 13:29 schreef Paul Allen :

> On Wed, 28 Aug 2019 at 08:29, Martin Koppenhoefer 
> wrote:
>
>>
>> > On 27. Aug 2019, at 23:00, Paul Allen  wrote:
>> >
>> > Oh, and you say that a sty is for pigs (correct) and a sty is for cows
>> (incorrect)
>>
>> probably just a copy +paste problem, and should have been cowshed
>>
>
> Yeah, that was my thought, too.  But given the nature of the rest of it, I
> wasn't certain.
>
> This appears to be a typical language issue: in German there is one word
>> (de:Stall) which is used for the “house” of many animals, e.g. cows, pigs,
>> horses and chicken. To a German it seems complicated having completely
>> different words for it,
>
>
> Ah.  That would explain the thinking behind it.  But not the lack of
> thought given to the
> infeasibility of hijacking a tag used several thousand times.
>
>
>> but as we use English tags, where stable is dedicated for horses, it
>> would be misleading and unnatural for the rest of the mappers to use it for
>> cowsheds or pigsties. I am also opposing this proposal.
>>
>
> Technically, in English, a stable is for any kind of livestock.  But in
> common usage it has long
> meant a place for horses.  I doubt you'd find many British English
> speakers who would think
> of a stable as anything other than for horses.  Ask them what's kept in a
> stable and the
> answer won't be "animals" it will be "horses."
>
> If he were to propose some other value (I can't think of one) for a
> generic livestock-holding
> building then I would have less reason to object to the proposal.  But I
> probably would still
> object - we have 24,000 stables and 9,900 cowsheds.  Pigs don't get many
> mentions, and
> we have a strange mix of names for buildings for them (what's a
> pig_ark?).  There are
> over 1,300 chicken_coops.  It would be a lot of pain to switch with very
> little gain that I
> can see.  Maybe he could make a persuasive argument for it.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New proposal draft to simplify the mapping of farm buildings (stables)

[Martin Koppenhoefer]

sent from a phone

> On 28. Aug 2019, at 13:26, Paul Allen  wrote:
> 
> If he were to propose some other value (I can't think of one) for a generic 
> livestock-holding
> building then I would have less reason to object to the proposal.  But I 
> probably would still
> object - we have 24,000 stables and 9,900 cowsheds.  Pigs don't get many 
> mentions, and
> we have a strange mix of names for buildings for them (what's a pig_ark?).  
> There are
> over 1,300 chicken_coops.  It would be a lot of pain to switch with very 
> little gain that I
> can see.  Maybe he could make a persuasive argument for it.


there are many interesting properties that could be tagged with regard to 
animal keeping, e.g. the kind of cowshed (e.g. distinguishing between cattle in 
chains and freely moving), or even more if you think about chicken.

Is someone already tagging the EU reference numbers for farmyards with organic 
production certification? It has to be labeled on the produce and would be cool 
if you could search on the map where your eggs or steak come from ;-)

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

Re: [Tagging] New proposal draft to simplify the mapping of farm buildings (stables)

[Paul Allen]

On Wed, 28 Aug 2019 at 08:29, Martin Koppenhoefer 
wrote:

>
> > On 27. Aug 2019, at 23:00, Paul Allen  wrote:
> >
> > Oh, and you say that a sty is for pigs (correct) and a sty is for cows
> (incorrect)
>
> probably just a copy +paste problem, and should have been cowshed
>

Yeah, that was my thought, too.  But given the nature of the rest of it, I
wasn't certain.

This appears to be a typical language issue: in German there is one word
> (de:Stall) which is used for the “house” of many animals, e.g. cows, pigs,
> horses and chicken. To a German it seems complicated having completely
> different words for it,


Ah.  That would explain the thinking behind it.  But not the lack of
thought given to the
infeasibility of hijacking a tag used several thousand times.


> but as we use English tags, where stable is dedicated for horses, it would
> be misleading and unnatural for the rest of the mappers to use it for
> cowsheds or pigsties. I am also opposing this proposal.
>

Technically, in English, a stable is for any kind of livestock.  But in
common usage it has long
meant a place for horses.  I doubt you'd find many British English speakers
who would think
of a stable as anything other than for horses.  Ask them what's kept in a
stable and the
answer won't be "animals" it will be "horses."

If he were to propose some other value (I can't think of one) for a generic
livestock-holding
building then I would have less reason to object to the proposal.  But I
probably would still
object - we have 24,000 stables and 9,900 cowsheds.  Pigs don't get many
mentions, and
we have a strange mix of names for buildings for them (what's a pig_ark?).
There are
over 1,300 chicken_coops.  It would be a lot of pain to switch with very
little gain that I
can see.  Maybe he could make a persuasive argument for it.

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

Re: [Tagging] New tag office=consulting was added to Map Features

[marc marc]

Le 28.08.19 à 11:19, Joseph Eisenberg a écrit :
> New description is 'An office for a consulting firm, 
> providing expert professional advice to other companies."

at least a tag to specify the activity should be provided,
because with the current description, an accounting, IT security, 
agricultural consulting, marketing audit can all have this tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] New tag office=consulting was added to Map Features

[Joseph Eisenberg]

Another user just created the page
https://wiki.openstreetmap.org/wiki/Tag:office%3Dconsulting and added
the tag to Map_Features

It's been used since 2012, with over 100 uses since 2013 and now is up
over 600, but it didn't have a page before.

New description is 'An office for a consulting firm, providing expert
professional advice to other companies."

Does this look ok?

We recently discussed whether values of office=* (along with shop=*,
craft=*, building=*)  could be created and added to Map Features
without discussion, though there was not clear consensus on this.

See https://lists.openstreetmap.org/pipermail/tagging/2019-July/046869.html
and continuation in
https://lists.openstreetmap.org/pipermail/tagging/2019-August/046895.html

Joseph

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

Re: [Tagging] Garmin waypoints and routes (was: "Roles of route members" and before that "Merging tagging scheme on wiki pages of Hiking")

[Peter Elderson]

Then again, OsmAnd does have a snap-to-road switch. When this is on,
looking at the map when routing along a gpx-track does show the turns as
arrows on the roads. When the track does not follow any accessible road
(according to the OSM map), the arrows show a way around. It shows this for
the whole gpx-track in advance. If you stray from the track, the arrows
guide you back to the track,  and the voice directions do the same. Also,
the remaining distance and time to reach destination are recalculated. So I
think it actually does perform routing.
Still, it needs a linear sorted gpx-track, and I intend to provide those.
I'm not waiting for each and every app, program, device and site to
implement their own supersmart algorithms to produce a linear route from a
possibly chaotic and incosistent nested route relation. If standard
extraction software becomes available to do this, I will be very, very
happy. I am also more than willing to help develop such software (specs,
design, testing, applying), and I am sorry I can't program it myself!

(as a first step, a plugin for JOSM woud be safe and relatively easy I
think? May it could take a route relation containing start- and end nodes,
then perform the ingenious trick with routing where members of the relation
get very high weight, then write the result back (to JOSM, not OSM).
Advanced sorting!

Fr gr Peter Elderson


Op wo 21 aug. 2019 om 20:46 schreef Peter Elderson :

> I have to correct myself: I thought OsmAnd really performed routing when
> navigating using a gpx trail. It doesn't, I tested it today. It translates
> turns in the track into screen messgaes and spoken text messages, without
> doing anything with the map. So it will send you into a ravine if your
> track goes there.
> But it can route you to the start of your track, and when you go
> off-track, it routes you back on track.
>
> All the more reason why the gpx should be a correctly ordered single chain.
>
> Fr gr Peter Elderson
>
>
> Op di 20 aug. 2019 om 16:57 schreef Peter Elderson :
>
>> Andy Townsend :
>>
>> On 19/08/2019 19:04, Peter Elderson wrote:
>>
>>
>> Ok, I accept I just don't know how it's done. So how is that done? How do
>> I tell my Garmin to guide me along, say, the Limes trail through the
>> Netherlands?
>>
>> Essentially, you'd just look at the screen and follow that!  I tend to
>> use waypoints for an idea of things like "how long will it be until I get
>> to where I'm going to stop for lunch", not for "turn left here because
>> route XYZ turns left here", because you can see on the screen that route
>> XYZ "turns left here".
>>
>>
>> So it’s not done. The osm route is not used to route. You can see it and
>> keep yor dot on the line, but the navigating device does not navigate along
>> the route. It can navigate, it has the route, but it does not do it unless
>> I create gpx from the route, send that to the device, which then recreates
>> the route from the gpx.
>>
>> If you want to add a series of waypoints and route along those then you
>> can, but want you can't typically do with one of the hiking-oriented
>> Garmins is follow a particular feature.  You could create an OSM-based
>> Garmin map that forced a device to route along a trail at the expense of
>> any other paths, but I certainly wouldn't want to do that as it would stop
>> me from leaving the trail to eat in a nearby town.
>>
>>
>> Nothing stops you from leaving the route, and I expect the device to
>> route me back to the track afterwards. And it does, and so does OsmAnd.
>>
>> Creating a Garmin route from a GPX file is possible, but probably
>> impractical, as you'd need to restrict the number of points.  Apparently my
>> GPSMap 64 supports 200 routes with 250 points per route, and up to 5000
>> waypoints in total.
>>
>> If only there were a way to store permanent routes in, say, a mapping
>> database, which could be used to determine what ways to follow...
>>
>> You only need to load the section(s) for the next day or a few days.
>> Afterwards, just remove them. No problem. I have had no problems to load
>> the via degli dei as 7 sections, each a day’s walk. No restrictions
>> necessary.
>>
>> I also loaded these in OsmAnd and had it guide me all the way
>> voice-in-ear, ie not having to look at the screen at all.
>>
>> Where Garmin on-device routing is really useful is for when you need to
>> get to somewhere but don't have an on-screen route to follow - for example
>> if the weather's turned and you need to abort a previously planned route
>> and get another route to your destination from where you currently are.
>> It's also useful where there are natural obstacles like rivers, where the
>> distance on foot may be significantly more than the as-the-crow-flies
>> distance.
>>
>> Best Regards,
>>
>> Andy
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>

Re: [Tagging] New proposal draft to simplify the mapping of farm buildings (stables)

[Martin Koppenhoefer]

sent from a phone

> On 27. Aug 2019, at 23:00, Paul Allen  wrote:
> 
> Oh, and you say that a sty is for pigs (correct) and a sty is for cows 
> (incorrect)


probably just a copy +paste problem, and should have been cowshed 


> 
> Introduce a new value for building that means "building for livestock of a 
> kind that will
> be specified in a subtag" and you might have a chance of success.  Hijacking
> building=stable is almost guaranteed to fail.


+1
This appears to be a typical language issue: in German there is one word 
(de:Stall) which is used for the “house” of many animals, e.g. cows, pigs, 
horses and chicken. To a German it seems complicated having completely 
different words for it, but as we use English tags, where stable is dedicated 
for horses, it would be misleading and unnatural for the rest of the mappers to 
use it for cowsheds or pigsties. I am also opposing this proposal.


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