Re: [Tagging] Perimeter of a pitch

[Warin]

On 23/5/23 09:36, Graeme Fitzpatrick wrote:





On Mon, 22 May 2023 at 22:43, Marc_marc  wrote:


but what's the playing area ?


Yep, good question, with no across-the-board answer!

As you say, you can play tennis from "outside" the court, but in most 
ball games, if the ball (& sometimes player) crosses the marked line, 
that's out!
In cricket and soccer the ball and player can be 'outside' the marked 
line but in the air. Only when the player touches the ground are they 
'out'.


& then for cricket, the "cricket pitch" itself is a small rectangular 
strip in the middle of the field, but the game uses the entire area of 
the field, while the boundaries of the field are an essential feature 
of the game.



Err cricket uses less area than Australian Rules Football and sometimes 
the two cohabit a facility.


So the cricket 'field' will be smaller than that football field.

Where cricket and soccer occur together there are sometimes 2 soccer 
fields with the cricket pitch in between the two soccer fields. The 
cricket field does no take on the outer boundaries of the 2 soccer fields..



Does the 'playing area' of chess include the table and seats?

Then think of water and snow skiing...


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

Re: [Tagging] Picnic_table with barbecue table extension.

[Warin]

On 23/5/23 04:00, Dave F via Tagging wrote:

https://snipboard.io/H5FYGT.jpghttps://snipboard.io/H5FYGT.jpgHi
I've a leisure=picnic_table but has an extended table top made of 
metal to accommodate disposable barbecues.


Can anybody recommend a sub-tag that's more descriptive than barbecue=yes?



To me barbecue=yes would imply there is a bbq there not that I would 
have to bring my own?


See

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dbbq

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


And - more relevant - from the above page

"bring_own_bbq=yes – tag proposed[1] and considered as a good idea[2] 
for places where one is allowed to bring barbecue, but there is no grill 
or firepit provided on site.


    As of 2020, there are >10 instances of bbq=bring_your_own [3], 
compared to 1-digit of bring_own_bbq=yes [4]."






https://wiki.openstreetmap.org/wiki/Tag:leisure%3Dpicnic_table

https://snipboard.io/H5FYGT.jpghttps://snipboard.io/H5FYGT.jpg

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

Re: [Tagging] Tagging proposal On Wheels app 3 - Parking spaces for

[Warin]

On 22/5/23 22:46, Marc_marc wrote:

Le 15.05.23 à 18:47, ro...@onwheelsapp.com a écrit :

Hi everyone,

So if I understand correct most parking spaces are mapped as polygons?


yes
https://taginfo.openstreetmap.org/tags/amenity=parking_space

I don't see the problem to add a width and length tag to a 
parking_space node,


there is no problem except to be aware that this is the least common 
schema and the one that gives the least information, and that 
therefore any contributor can convert a width=A length=B into a 
surface object having this dimension and which will also give a 
position of this object in relation to the others (does the parking 
space touch the neighbouring parking_space, does it touch a kerb, etc)


because this is more detailed info about the dimensions of a parking 
space,

that is actually measured by people on site with a measure tape.
the polygon data is not accurate enough to really use for our app.


I don't understand this argument despite the fact that to repeat it :
a node width=A length=B is not more precise than a polygon
with thoses dimensions



The polygon gives the orientation - could be parallel to the road or at 
some angle.


I prefer the polygon, more trouble to map but you can use imagery to get 
it.





Are there other apps that add info about parking places as polygons and
extract dimension info from the polygon data?


most map style, including osm-carto (the main style on osm.org)






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

Re: [Tagging] Coach parking

[Warin]

On 9/6/23 20:26, Martin Koppenhoefer wrote:


sent from a phone


On 9 Jun 2023, at 12:04, Greg Troxel  wrote:

I can't find it either.  I remembered that JOSM presets have a lot more
detail than the wiki.  But I checked, and I don't see anything about
"coaches" (which I think is the word in EU for what we Yanks would call
"bus", a large vehicle that can transport say 40 people).


there is tourist_bus (a bus class  vehicle which is not a psv).
In the EU a bus is a motor vehicle with more than 8+1 seats



The difference between a coach and a bus?

A 'coach' is intended for long distance transport - so more comfortable, 
provision for luggage and possibly an on board toilet.


A 'bus' is usually shorter distances example commuting to and from work.


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

Re: [Tagging] amenity=bbq without grill/grate ?

[Warin]

On 24/2/23 00:09, Matija Nalis wrote:

Recently, https://wiki.openstreetmap.org/wiki/Key:grate has been documented
with some 232 uses, to map whether `leisure=firepit` and `amenity=bbq` have a
grate (AKA cooking grate / grill / cooking grid).

While it might be useful for `leisure=firepit`, I do not think it makes sense
for `amenity=bbq` at all.



Most, if not all, of the public bbqs near me don't have a grill, they 
have a flat plate that you cook on. This makes it easier to clean as 
there is nowhere for scraps to go and hide.


Anyone for a tag hot_plate=yes/no???


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

Re: [Tagging] Coach parking

[Warin]

On 10/6/23 00:13, Anne-Karoline Distel wrote:

That's what I mean, tourist busses.  I see now that there is a tag
(https://wiki.openstreetmap.org/wiki/Key:tourist_bus), but my point is
that it should also be rendered with a bus/ coach symbol. Also, they are
often seasonal, at least in Ireland, so during the winter, can be used
by cars, but during the season, only for coaches. How do we map that?
seasonal=May-October (according to signage), but somehow connected to
the "tourist_bus" key?

Anne



That could be a conditional tagging thing... possibly

parking:conditional=motor_vehicle @ (seasonal=winter) ???


then follow it with similar for bus.



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

[Tagging] duplicate road routes one named the other referenced

[Warin]

Hi,

I came across a duplicate of a road route.


Both have the same number of members.

One has the name, the other has the reference.

I delete one placing the relevant tags on the other.

https://www.openstreetmap.org/relation/540719

https://www.openstreetmap.org/relation/540719https://www.openstreetmap.org/relation/3081392/history


Question:

Is there a reason why 2 road route relations are required - one for the 
name the other for the ref???


Note the duplicate was created some 10 years ago ..  there may have been 
a rendering issue back then...



I did look on tag info and ~ 90% had name and ~ 75% had references .. so 
both name and ref must be used on some of these routes in OSM.


 I checked another main road nearby ,,, and came up with a similar but 
more complex situation.



The name Hume Highway is on 
https://www.openstreetmap.org/relation/2103184 no ref tag. (entire 
length covered)


The name 'Hume Highway (northbound)' is on 
https://www.openstreetmap.org/relation/9436122 (south of Albury)



The reference is on;


https://www.openstreetmap.org/relation/14879845 (north of Albury)

https://www.openstreetmap.org/relation/2103183 (north of Albury) .. 
could be a duplicate of the above


https://www.openstreetmap.org/relation/240718 (south of Albury)


I'd have to look harder for more infor on the Hume Hwy situation. But 
the Snowy Mountains Highway is fairly clear cut.






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

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Warin]

On 21/6/23 09:50, Graeme Fitzpatrick wrote:




On Tue, 20 Jun 2023 at 22:11, Greg Troxel  wrote:


  an air rifle is not a firearm, in English, because there is no
  combustion


Unfortunately, in Australia at least, air rifles are actually 
officially classed as firearms! :-(




NSW legal definition of firearm;

Firearms Act 1996 section 4 "as a gun, or other weapon, that is (or at 
any time was) capable of propelling a projectile by means of an 
explosive, and includes a blank fire firearm, or an air gun, but does 
not include a paintball marker within the meaning of the Paintball Act 
2018 or anything declared by the regulations not to be a firearm".


UK Firearms Act 1968  the expression “firearm” means—

(a)a lethal barrelled weapon (see subsection (1B));

(b)a prohibited weapon;

(c)a relevant component part in relation to a lethal barrelled weapon or 
a prohibited weapon (see subsection (1D));


(d)an accessory to a lethal barrelled weapon or a prohibited weapon 
where the accessory is designed or adapted to diminish the noise or 
flash caused by firing the weapon;]


and so much of section 1 of this Act as excludes any description of 
firearm from the category of firearms to which that section applies 
shall be construed as also excluding component parts of, and accessories 
to, firearms of that description.




[F3(1B)In subsection (1)(a), “lethal barrelled weapon” means a barrelled 
weapon of any description from which a shot, bullet or other missile, 
with kinetic energy of more than one joule at the muzzle of the weapon, 
can be discharged.


(1C)Subsection (1) is subject to section 57A (exception for airsoft guns).]


-

I note the absence of 'fire' in the above definitions. Explosions can be 
had from compressed gas.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shop=gun shop=guns shop=weapons shop=firearms

[Warin]

On 27/6/23 18:47, Martin Koppenhoefer wrote:


sent from a phone


On 26 Jun 2023, at 20:50, Minh Nguyen  wrote:

For what it's worth, the Sporting Goods Retailers subindustry in NAICS includes "gun 
shops".


what’s the category for multi role combat aircraft or heavy battletanks?



NATO had a part number for a warship .. with crew and 7 days of 
supplies... along with lots of other part numbers e.g. for washers, 
bolts, nuts, paint, etc.


Never went looking for a gun, bomb etc.. but someone made a mistake with 
a part number and stores rang them up wanting to know where they wanted 
the warship with crew etc delivered .. they ordered from the 6th floor 
of an inland building.



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

Re: [Tagging] [Talk-GB] Fords and how to provide information to help with routing apps

[Warin]

On 5/7/23 03:38, Mateusz Konieczny via Tagging wrote:




Jul 4, 2023, 17:05 by tagging@openstreetmap.org:

On Tue, Jul 04, 2023 at 03:14:47PM +0100, Ian Dent wrote:

Previously it was tagged as ford=impassable but this isn't a
valid value and


On reflection, that doesn't seem such a bad tag.

ford=impassable makes no sense

ford is by definition a passable place across waterway, if
something is impassable then it is not a ford



Many 'fords' in Australia are normally dry.

When the river runs high those fords can become impassable for quite 
some time .. weeks..


Those who travel there know this, those that don't .. well the Police 
normally place 'Road Closed' signs out.



Walking routes that cross streams suffer the same at times, usually a 
delay of a day or two will see the water level recede to an acceptable 
level and rate of flow.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

[Warin]

On 7/8/23 07:20, Timothy Noname wrote:
I thinks it's definitely valuable to map areas where there is no 
coverage at all as it's a safety issue




For safety sake it is best to assume there will be no cell phone 
coverage. The battery could go flat, the phone could be lost, drowned or 
damaged. If you need a way of making an emergency signal then EPIRB/PRB 
is the way to go.



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

Re: [Tagging] [RFC] Feature Proposal - Cell Phone Reception

[Warin]

On 8/8/23 04:32, Marc_marc wrote:

Hello,

Le 06.08.23 à 21:18, NickKatchur via Tagging a écrit :
https://wiki.openstreetmap.org/wiki/Proposal:Cell_reception 


I'm a bit amused, or rather disappointed, to read comments like
"it's complicated to estimate the number of reception bars because
it depends on the phone". Were these kinds of comments made after 
reading the proposal or simply in reaction to the headline?

the proposal isn't about encoding the number of reception bars.

I don't see what problem there would be in me entering that my 
dentist's surgery has no GSM reception, nothing ever, I don't see what 
lack

of objectivity there would be in encoding this in osm.

I don't see what problem there would be in saying that another POI has 
major reception problems but that it still works, it doesn't matter if 
you have 2 bars and I have 3, it doesn't change the fact that it's

much less than the average you'd expect in this kind of place.
and so the =no and =limited values seem to me to be much more 
objective than some route classifications





Not all phones are created equal.

An Australian cell service provider rates some phones as better for 
country and regional area reception. If you have one of these you are 
more likely to rate a connection 'good' instead of 'limited' and 
'limited' instead of 'no'.


https://www.telstra.com.au/mobile-phones/blue-tick


Of course my phone is 'blue ticked'.



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

Re: [Tagging] Tagging for the renderer : One-way "flow" bicycle tracks

[Warin]

On 9/9/23 17:31, Volker Schmidt wrote:
Be careful: oneway=* is a legal access tag, only valid for vehicles, 
not for pedestrians.



Some pedestrian barriers are 'oneway' .. for example turnstiles at train 
stations where the turnstile only allows travel if a card/ticket is 
produced. I know of another in a very large public park .. gates are 
locked around sunset but you can get out using the turnstile, yes it 
does have imposing walls



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

[Tagging] Postal verses locational addresses

[Warin]

HI,

I am coming across cases of OSM entered addresses on buildings that are 
some kilometers from the nominated address location. These appear to be 
'gated communities', 'retirement villages' and possibly other things 
that use some official address and thus keep deliveries from going to 
the actual location but going through the office.


I can probably lump all of a group together in some kind of relation 
(e.g. landuse) that would reduce the warnings down from many to one. But 
I wonder if these postal addresses would be better entered in some other 
way. One issue is a routers to some address having more than one result 
- all with the same address..


Ideas?



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

Re: [Tagging] Postal verses locational addresses

[Warin]

On 12/9/23 03:57, Greg Troxel wrote:

The fundamental issue is that there are postal addresses and what might
be called "civil addresses" or "physical addresses" ('locational' I
understand but is not normal English usage).
I could not think of a better descriptive 'word' for what I wanted to 
express.

  In the US, we also have
"911 dispatchable location" which is all about getting there physically
and is US-bureaucatic-speak.

OSM has decided to tag postal addresses on address points.   I find this
an odd choice, and I think it really doesn't mean this, as companies
that use PO boxes are not tagged that way, but with the street address.

The only fix I think of is to have a separate set of tags paddr: and a
rule that those should be set if they are different from the addr: tags
(which are postal).  except postcode, which is a postal-only.



Err the zip/postcode in the UK is a (small) physical area. It is used by 
truck delivery drivers to enter into their GPS to find a route to the 
delivery point. See 
https://en.wikipedia.org/wiki/Postcodes_in_the_United_Kingdom


Possibly the OSM addr thinking is based on the UK where the postal 
address is the physical location?There maybe exceptions to this in the 
UK too?




All in all I think it was a mistake to tag postal addresses.  Maybe we
can just redefine addr:foo to be the physical address, except
addr:postcode is the code assigned by the government/monopoly delivery
service.  And then add some mailing address tag for things that need
them.



I do think OSM is more of a location data base. Imaging a personal visit 
to these places with addresses quite some distance (miles) away .. 
nasty. And some of them have more than two locations...



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

Re: [Tagging] Postal verses locational addresses

[Warin]

On 14/9/23 04:50, Marc_marc wrote:

Le 13.09.23 à 19:21, Jez Nicholson a écrit :

OSM addresses are physical, 'locational' addresses


ok

it is the anomalous postal addresses that need to have their own 
schemeif at all.


some mapper in France are using contact:* for that (and also
some contact:addr for a kind of number+street and sometime CP+city)

note that no (including fr) app is known for using that
and due the fact that some mappers also put physical/locational 
addresses into contact:*, you can't know what this info represents 
without having the other addr:* object with the same address

to compare the distance between the 2



Comparing the difference between the two and it still may not be 
determined.



Perhaps

contact:postal:street=* etc. could do the job and be reasonably obvious? 
Yes there would need to be a good wiki page to say that these are 
postal/delivery addresses rather than the physical location of the 
feature, and then changes to the addr: wiki pages ... The changes to 
addr pages I see as clarification of the usual practice and normal 
circumstance. He use of contact:postal:*=* would only be for the 
exceptions?



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

Re: [Tagging] Proposal: Use description instead of name for route relations

[Warin]

On 17/10/23 04:17, Paul Johnson wrote:
Presently, it's common for route relations to have names that violate 
"name is only the name" and "name is not ref" and "name is not 
description" rules for name=* tags.



I don't find it common in 'my area' of mapping. One or two examples 
would demonstrate the situation?



In any case:

The name tag is used on may things for example; buildings, parks, 
schools, highways ...


The use of the name tag as 'name only' applies where ever the name tag 
is used. This is similar for other tags such as elevation, width, colour 
etc. No matter what feature they are used on the tags carry the same 
characteristics and restrictions. It is not necessary to repeat 
these characteristics and restrictions for every main feature.





On Sun, Oct 8, 2023, 10:24 Volker Schmidt  wrote:

Could you give some more examples to illustrate what the problem
is that you want to resolve.


On Sun, 8 Oct 2023, 00:23 Kevin Kenny, 
wrote:



On Sat, Oct 7, 2023 at 4:50 PM Andrew Hain
 wrote:

I have started a new proposal: that the name tag should be
restricted to the same meaning for route relations that it
has on other elements and that the description tag should
be used otherwise.


The proposal is unclear and appears to deprecate route and way
names of a form that are common around here for what I
consider to be good reasons. (In any case, 'description'
appears to be an inappropriate tag for whatever it is you are
proposing.) More details on the talk page.
-- 
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___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Use description instead of name for route relations

[Warin]

On 17/10/23 23:22, Paul Johnson wrote:



On Tue, Oct 17, 2023 at 4:51 AM Warin <61sundow...@gmail.com> wrote:


On 17/10/23 04:17, Paul Johnson wrote:

Presently, it's common for route relations to have names that
violate "name is only the name" and "name is not ref" and "name
is not description" rules for name=* tags.



I don't find it common in 'my area' of mapping. One or two
examples would demonstrate the situation?


In any case:

The name tag is used on may things for example; buildings, parks,
schools, highways ...

The use of the name tag as 'name only' applies where ever the name
tag is used. This is similar for other tags such as elevation,
width, colour etc. No matter what feature they are used on the
tags carry the same characteristics and restrictions. It is not
necessary to repeat these characteristics and restrictions for
every main feature.

Routes have names, too!  For example, here's the relation for OK 51, 
named for the name of the route. 
https://www.openstreetmap.org/relation/3108562


Meanwhile, I 40 in Arkansas has a good example of a name that is 
actually a ref and a description, not a name. 
https://www.openstreetmap.org/relation/6843700


 Finally, OK 19 is an example of a properly described no-name route. 
https://www.openstreetmap.org/relation/7479405



Ok. I still don't see a necessity of repeating the name tag information 
inside the relation tag... Will you also repeat the ref tag information, 
the description tag information? How about the surface tag, maxspeed tag 
etc etc..


In some cases where I have come across it I have simply stated 'The name 
tag is for the name only. See 
https://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only' and I 
follow it up by making the correction/s. Don't think I have ever had an 
argument about it.


The https://www.openstreetmap.org/relation/331438 use of the name tag 
goes back 14 years ago ... to a mapper who was only just starting out.. 
The ref tag came along some 3 years later... You may find similar 
historical sources for the use of the name tag...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Use description instead of name for route relations

[Warin]

On 18/10/23 19:15, Mateusz Konieczny via Tagging wrote:




Oct 18, 2023, 09:30 by 61sundow...@gmail.com:


On 17/10/23 23:22, Paul Johnson wrote:



On Tue, Oct 17, 2023 at 4:51 AM Warin <61sundow...@gmail.com> wrote:


On 17/10/23 04:17, Paul Johnson wrote:

Presently, it's common for route relations to have names
that violate "name is only the name" and "name is not ref"
and "name is not description" rules for name=* tags.



I don't find it common in 'my area' of mapping. One or two
examples would demonstrate the situation?


In any case:

The name tag is used on may things for example; buildings,
parks, schools, highways ...

The use of the name tag as 'name only' applies where ever the
name tag is used. This is similar for other tags such as
elevation, width, colour etc. No matter what feature they are
used on the tags carry the same characteristics and
restrictions. It is not necessary to repeat
these characteristics and restrictions for every main feature.

Routes have names, too!  For example, here's the relation for OK
51, named for the name of the route.
https://www.openstreetmap.org/relation/3108562

Meanwhile, I 40 in Arkansas has a good example of a name that is
actually a ref and a description, not a name.
https://www.openstreetmap.org/relation/6843700

 Finally, OK 19 is an example of a properly described no-name
route. https://www.openstreetmap.org/relation/7479405



Ok. I still don't see a necessity of repeating the name tag
information inside the relation tag...

this proposal wants to remove wrong advise that advocates adding fake 
names to

relations

maybe just removing this bad advise without proposal would be a good idea



Arrr now I see it !

This only applies to the 'name' 'advice' on PTv2

https://wiki.openstreetmap.org/wiki/Public_transport#Service_routes

has

"name = /:  → "/

/
/

That would mean the name tag contains the information already in the 
other tags... redundant.


The Australian 'India Pacific' train journey has the name 'India 
Pacific' .. no 'train', nor ref nor from nor to...


 The Russian 'Trans Siberian' train journey .. South African 'Blue 
Train' etc etc.. none of these real names translate to the above PTv2 
'name'.



Does this proposal only apply to the PTv2??? If so why not say so?

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

Re: [Tagging] Proposal: Use description instead of name for route relations

[Warin]

On 20/10/23 10:32, Paul Johnson wrote:



On Wed, Oct 18, 2023 at 2:31 AM Warin <61sundow...@gmail.com> wrote:


On 17/10/23 23:22, Paul Johnson wrote:



On Tue, Oct 17, 2023 at 4:51 AM Warin <61sundow...@gmail.com> wrote:


On 17/10/23 04:17, Paul Johnson wrote:

Presently, it's common for route relations to have names
that violate "name is only the name" and "name is not ref"
and "name is not description" rules for name=* tags.



I don't find it common in 'my area' of mapping. One or two
examples would demonstrate the situation?


In any case:

The name tag is used on may things for example; buildings,
parks, schools, highways ...

The use of the name tag as 'name only' applies where ever the
name tag is used. This is similar for other tags such as
elevation, width, colour etc. No matter what feature they are
used on the tags carry the same characteristics and
restrictions. It is not necessary to repeat
these characteristics and restrictions for every main feature.

Routes have names, too!  For example, here's the relation for OK
51, named for the name of the route.
https://www.openstreetmap.org/relation/3108562

Meanwhile, I 40 in Arkansas has a good example of a name that is
actually a ref and a description, not a name.
https://www.openstreetmap.org/relation/6843700

 Finally, OK 19 is an example of a properly described no-name
route. https://www.openstreetmap.org/relation/7479405



Ok. I still don't see a necessity of repeating the name tag
information inside the relation tag... Will you also repeat the
ref tag information, the description tag information? How about
the surface tag, maxspeed tag etc etc..

The name of the route has nothing to do with the name of the member ways.



Confusing is probably the issue here?

I am taking of 'the name tag' possibly I should have said the 'OSM key 
name' .. https://wiki.openstreetmap.org/wiki/Key:name


Not taking of any individual feature with a 'name tag'.

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

Re: [Tagging] Proposal: Use description instead of name for route relations

[Warin]

On 22/10/23 19:56, Martin Koppenhoefer wrote:


sent from a phone


On 20 Oct 2023, at 10:23, Mateusz Konieczny via Tagging 
 wrote:

maybe just removing this bad advise without proposal would be a good idea

+1
___



Issue: that wording is in the approved proposal for PTv2 ...

Removing the wording is 'a good idea' .. but that would go against the 
approved proposal .. catch 22.



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

Re: [Tagging] shops for display

[Warin]

On 21/11/23 06:56, Anne-Karoline Distel wrote:


have the windows covered in decals to advertise that they have moved or
to advertise local sights or whatever.




In the above case move the shop data to the new location and then add 
shop=vacant to this previous location. This would stop map users 
mistaking the 'sign' as the 'shop'.



The other use of the 'shop' location is for advertising as others have 
noted.



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

Re: [Tagging] Feature proposal - RFC - Documenting feet as an an optional elevation unit

[Warin]

On 29/1/24 06:30, Philip Barnes wrote:

The legal definition of a foot is of course  0.348 m.

"Since an international agreement in 1959, the foot is defined as 
equal to exactly 0.3048 metres'.


Phil (trigpoint)



NPL has a nice history on length measurement

http://resource.npl.co.uk/docs/educate_explore/posters/bg_historyoflength_poster.pdf


Even in the USA the survey foot is depreciated.

https://amerisurv.com/2023/02/09/the-deprecation-of-the-us-survey-foot/

Depreciation in the US may be 'complete', at least in government 
circles, in 2025...







On 28 January 2024 18:57:45 GMT, Minh Nguyen 
 wrote:


Vào lúc 04:08 2024-01-28, Greg Troxel đã viết:

Minh Nguyen  writes:

Vào lúc 19:50 2024-01-27, Brian M. Sperlongano đã viết:

Uh so I did the math, and unless I've got this wrong,
the difference between survey feet and international
feet for tagging, let's say, Mount Everest, is less
than seven one-hundredths of an inch.  So I'm really
not even sure why we're discussing it beyond the fact
that we're all nerds about this sort of thing. 


You got me. :-) The actual proposal doesn't mention the
foot's two definitions at all, and so far I'm planning to
keep it that way. 


I think it's important to be definitionally correct, even if
it doesn't really matter. It's a slippery slope, and pretty
soon \pi is 3. 


Poor Indiana. ;-) The definition of the foot would apply to the '
and ft abbreviations in every context, not just the ele=* key, so
I'd suggest considering it separately, probably without the
formality of a vote. The main unit symbol listing has come
together more informally over the years. [1] Sooner or later,
OpenHistoricalMap will have a lot of fun with this issue... [1]
https://wiki.openstreetmap.org/wiki/Map_features/Units

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

[Tagging] airport taqs

[Warin]

Hi

Typically on an airport the planes parking position is marked by a small 
circle, the is usually tagged with aeroway=parking_position - 
https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dparking_position. I 
believe this should only be a node, not a way.


Some have mapped the planes path leading to the parking position as an 
aeroway=parking_position, I think it would be better to tag it with 
aeroway=taxiway or (low usage so may not render) taxilane.


https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dtaxiway

https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dtaxilane



Thoughts???


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

Re: [Tagging] tagging "loose" paving stones

[Warin]

On 18/2/24 05:52, Anne-Karoline Distel via Tagging wrote:


Judging from those photographs, they would be material=sett, but the 
surface is not the same, as I said, the stones have some room to 
wiggle, there is no filler in between the stones.


On 17/02/2024 18:41, Yves via Tagging wrote:

Surface=Paved is generic.


+1


paved includes things like concrete, asphalt.


Unpaved is the opposite such as earth, dirt, sand.


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

Re: [Tagging] clootie trees/ rag trees

[Warin]

On 4/3/24 07:48, Anne-Karoline Distel via Tagging wrote:


Hello there,

does anyone have any opinions about how to map what is called clootie/ 
cloughtie/ cloutie trees in Scotland and rag trees or raggedy bushes 
in Ireland?




There are things like 'Fairy Bridge on the Isle of Man ' mapped as a 
tourist attraction https://www.openstreetmap.org/node/10169482883



Some trees are hung with various things too ...


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

Re: [Tagging] Highway classification in Antarctica

[Warin]

The problem is 'tagging for the render', people see this large blank 
area and cannot see what they are looking for because the render will 
not show such a low importance feature.



This also occurs in other areas where there is sparse populations. The 
people who make and maintain renders occupy areas with dense or at least 
denser populations so have set the renders so they are not overwhelmed...


A solution would be adjusting what is rendered based on the rendered 
density - the less density of rendered features could make the render 
should more features even when the features are of 'less importance'. 
The renders could do this dynamically, adjusting for the density on the 
fly, presently there is one setting for 'all the world'.





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

Re: [Tagging] Highway classification in Antarctica

[Warin]

On 26/4/24 03:40, Mateusz Konieczny via Tagging wrote:




Apr 25, 2024, 16:16 by fernando.treb...@gmail.com:

I also think that such changes also imply corrections to the following
section regarding how importance is to be assessed by mappers:

https://wiki.openstreetmap.org/wiki/Key:highway#Assumptions

Particularly this sentence:

"In a region with poor infrastructure, a road of highest importance,
forming the main road network there, should be highway=trunk,
regardless of being a high-quality wide asphalt road or a low-quality
narrow track worse than highway=service in other regions."

The consensus here seems not aligned with this. This section also
references the following proposal:

https://wiki.openstreetmap.org/wiki/Proposal:Highway_key_voting_importance

Whose summary says:

"the general definition of highway=* should be changed to importance
for the road grid (hierarchical position in the interconnecting
network) instead of physical attributes"

What is missing is a statement about whether one starts judging such
networks by importance from the top (trunk downwards) or from the
bottom (tertiary upwards).

Antarctica has no real road network so missing top levels of road classes
is fine.

It is also missing roads between major large cities because it has no
major large cities.

If very big island has no roads at all except single small road between
two houses it does not mean it is highway=trunk road.



A can of worms...

Many of the hiking routes I have looked at use beach sections over sand. 
There is no visible 'path' yet the 'path' exists, not always in the same 
place people tend to take whatever route they like - away from the water 
or getting their toes wet. I have tagged these sections as not visible 
and made them as straight as possible to imply that it is a 'route' 
rather than a formed track.


Towns and villages also have an 'importance' level too... a place can be 
of more 'importance' that another place despite having the same 
population. The importance could be gained by having better medical 
facilities, better airport etc.


These kind of discussions have been had in Australia and I would think 
Africa, Russia ...


Please consider your own experience with less dense areas before 
condemning some flexibility in adapting things to suit other parts of 
the world?




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

Re: [Tagging] How to Tag Steps in a Bridleway

[Warin]

Horses are good at handling various obstacles.

If you can find a local 'horse trial' go along and look. Yes it is a 
competition... But I don't map them as they are usually on private 
property.




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

Re: [Tagging] breads of bakeries

[Warin]

On 3/5/24 16:07, Graeme Fitzpatrick wrote:




On Thu, 2 May 2024 at 21:21, bkil +a...@gmail.com> wrote:


Yes, that would be even better.
sells:bread=wholemeal:x;y;wholemeal:z


But if you're selling ="white variety-a", "wholemeal variety-a", 
"multi-grain variety-a", "gluten-free variety-a", then the same for 
varieties b, c & so on, I can see a 255-character limit approaching 
rapidly!





A google for bread varieties got;
    Arepa
    Baguette
    Bagel
    Brioche
    Ciabatta
    Challah
    English Muffin
    Focaccia
    Hokkaido
    Irish Soda Bread
    Multigrain
    Naan
    Paratha
    Pita
    Potato
    Quick Bread
    Rye
    Sourdough
    White
    Whole Wheat


My local supermnaket has

Rye Sourdough, Lindseed & Rye Sourdough, wholemeal Sourdough... and 
probably others that I have forgotten...



So??? ... bread:sourdough:content=rye/white/wholemeal/multigrain/* and 
similar for others???
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag a campground drop box for payment of camping or parking fees?

[Warin]

On 23/5/24 09:58, Bryce Nesbitt wrote:

What's a good way to tag a payment drop box,
of the type used in the USA for campgrounds?

You typically put money in an envelope, tear of a tab, and dop the payment
into a metal tube slot.



In addition to cash payments payment by credit card should be 
considered. Some national parks require a payment at the entry point, 
when not maned then there is a payment box .. so I'd not limit it to 
campsites/parking but cover everything?



?? man_made??=payment_point

then

payment:*=* etc..


Most of these are either at the entrance of can be found by a visual 
search... I'd not map them unless they are difficult to find.



See:
Camping In A National Park Made Easy: 9 Essential Tips - Southerner 
Says 

And:
Tag:tourism=camp_site - OpenStreetMap Wiki 



___
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] Two way street, but entry of motor vehicles blocked at one end. Relation correct? Tagging correct?

[Warin]

On 22/5/24 01:19, Martin Koppenhoefer wrote:



Am Di., 21. Mai 2024 um 15:01 Uhr schrieb Mateusz Konieczny via 
Tagging :


In such case I would typically place such tags on
a short section (meter or two) of way near end where
such restriction is applied.



the restriction is not applied to a section, it is applied to a point, 
you may not cross the sign in this direction.





Most of the ones here are a section of at least a car length, allows a 
car to pull in but not obstruct a U turning car from the restricted 
direction.


So a section would be appropriate for this situation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] maxweight : x tons exept for bus

[Warin]

On 9/9/24 16:58, Alberto Nogaro via Tagging wrote:
I somehow doubt that the traffic sign specifies the maximum actual 
weight, most likely it sets the maximum permitted weight of the 
vehicle at full load, as specified by the manufacturer.
In my country the signs specify the maximum weight that is permitted on 
the way (usually a bridge).


It has nothing to do with the vehicle specification.

The sign is there to stop the destruction of the way through overloading 
the structure, thus an unload hgv may meet the required weight limit and 
use the way, but when loaded exceed the weigh limit and not be able to 
use the same way.



For manufactures weigh limits in OSM see maxweightrating
https://wiki.openstreetmap.org/wiki/Key:maxweightrating




For a traffic sign "maxweight x tons except for bus"' situation the wiki 
is, for once, fairly clear



maxweight=x (where x is the relevant number with any units applicable)
maxweight:conditional=none @ bus

The above assumes a bus is permitted.. (I find that a problem myself) if 
a bus is not permitted (I think this would be more typical?) then


bus=no
maxweight=x (where x is the relevant number with any units applicable)







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

Re: [Tagging] maxweight : x tons exept for bus

[Warin]

On 9/9/24 19:39, Martin Koppenhoefer wrote:

Am Mo., 9. Sept. 2024 um 10:55 Uhr schrieb Warin <61sundow...@gmail.com>:

It has nothing to do with the vehicle specification.

The sign is there to stop the destruction of the way through
overloading
the structure, thus an unload hgv may meet the required weight
limit and
use the way, but when loaded exceed the weigh limit and not be
able to
use the same way.



it may depend on the area, but around here restrictions relating to 
actual weight are rather rare, because they are impractical to verify, 
while weight ratings can be seen in the vehicle documents and are easy 
to check.


Public and private weigh brides exist in Australia, portable and fixed 
ones are used by the roads authority to check vehicles are not 
overloaded. So these are both practical,do exist and get used. Weigh 
limits on bridges are like speed limits, so there is a legal obligation 
to know the actual weigh or at least that the weight is well below the 
limit for the bridge.


 In the UK weigh bridges are not unusual  at suppliers to document the 
weight of goods supplied along with checking the vehicles maximum weight 
is not exceeded.



Is this yet another tag that has been 'misinterpreted'?

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

Re: [Tagging] maxweight : x tons exept for bus

[Warin]

On 9/9/24 22:43, Alberto Nogaro via Tagging wrote:

And have you ever seen a signs which specifies the maximum weight that is
permitted on a bridge, also allow some class of vehicles to exceed that
weight rating?



No, weight limits that I have seen have no exceptions.



-Original Message-
From: Warin <61sundow...@gmail.com>
Sent: lunedì 9 settembre 2024 10:51
To: tagging@openstreetmap.org
Subject: Re: [Tagging] maxweight : x tons exept for bus

In my country the signs specify the maximum weight that is permitted on the
way (usually a bridge).




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

Re: [Tagging] maxweight : x tons exept for bus

[Warin]

On 10/9/24 20:46, Marc_marc via Tagging wrote:

Le 09.09.24 à 10:51, Warin a écrit :
For a traffic sign "maxweight x tons except for bus"' situation the 
wiki is, for once, fairly clear


maxweight=x (where x is the relevant number with any units applicable)
maxweight:conditional=none @ bus


on which page precisely ?
the problem is that the wiki describes the most minority case, the 
alternatives I mentioned in my message, particularly maxweight:bus, 
are 10x more numerous, hence my message.



OSM page https://wiki.openstreetmap.org/wiki/Key:maxweight


Yes .. I looked further after your message and found maxweight:bus=none 
too... that is a fair way down the page...



I got 'maxweight:conditional=none' from just before the section titled 
'Basic example' a fair way up the page.


"unlikely to find place where one is actually allowed to drive vehicles 
without any weight limits. However, it is the value used with 
maxweight:conditional=none @ * so should be treated as meaning defaults 
apply."


The meaning of 'defaults apply' would be local legal defaults .. I think.


--

My perceived confusion is between the keys

maxweight=* and

maxweightrating=*


The second one to me is preferred for the vehicle manufactures gross 
vehicle weight while the first is for the maximum permissible weight on 
a way (usually a bridge) normally specified to prevent damage to the way.






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

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Warin]

On 30/5/20 12:48 am, Volker Schmidt wrote:
My main point is that out there are things that consist of visible 
objects plus objects which have left visible traces, and also some 
pieces that have been completely erased, but of which we have 
documented knowledge of where they once were. The entire thing makes 
sense only with all its parts. These things be of interest for some 
end users of OSM data, and hence, if someone has gone to the length of 
mapping them, should find space in OSM.
In my view a general rule that any mapper can erase any object from 
the map, when he does not see any trace of it, is certainly not 
correct , he may be removing parts of the thing thsat only with all 
its partsmakes sense.



Where an old railway line has been built over by houses, factories, 
shops and roads I see no reason to retain the (historical) information 
in OSM.


The old railway station that still exists at one end - yes, but where 
there is nothing, not even a hint, left then no.



Anyway i am against removing apparently useless data without 
consultation with the author, with the exception of clear errors.




Disagree.

Once the data is in OSM it is no longer the 'property' of the author or 
following editors.


If I am not certain of something I'll ask the author/flowing editors but 
where I know something is wrong I'll change it without consultation.



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

Re: [Tagging] [Talk-us] Heavily-wooded residential polygons

[Warin]

On 29/5/20 8:01 am, Mateusz Konieczny via Tagging wrote:




May 28, 2020, 23:54 by stevea...@softworkers.com:

"treed farmland" or "heavily wooded residential" prove slightly
problematic to OSM tagging.

Map tree-covered area (landuse=forest) and map farmland 
(landuse=farmland) or

residential (landuse=residential).

Yes, the same area may be tree covered and residential at the same time.

Yes, "tree-covered area" meaning for landuse=forest mismatches strict 
meanning

of bot landuse and forest.


I differ.


I would use natural=wood for the tree coverage.

Then there is no conflict with a landuse tag.

And natural=wood does mean tree covered ... and the key natural 
incorporates 'non natural' i.e things altered or managed by man.



The key landuse should be to used describe the primary use of land by 
humans, not the land cover but it's use.


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

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Warin]

On 2/6/20 11:52 am, Phake Nick wrote:



在 2020年6月2日週二 09:26，Warin <61sundow...@gmail.com 
<mailto:61sundow...@gmail.com>> 寫道：


On 30/5/20 12:48 am, Volker Schmidt wrote:
> My main point is that out there are things that consist of visible
> objects plus objects which have left visible traces, and also some
> pieces that have been completely erased, but of which we have
> documented knowledge of where they once were. The entire thing
makes
> sense only with all its parts. These things be of interest for some
> end users of OSM data, and hence, if someone has gone to the
length of
> mapping them, should find space in OSM.
> In my view a general rule that any mapper can erase any object from
> the map, when he does not see any trace of it, is certainly not
> correct , he may be removing parts of the thing thsat only with all
> its partsmakes sense.


Where an old railway line has been built over by houses, factories,
shops and roads I see no reason to retain the (historical)
information
in OSM.

The old railway station that still exists at one end - yes, but where
there is nothing, not even a hint, left then no.


Except, it is relatively common for traces of old railway remain 
visible even after new development (e.g. house, factory, shop, road) 
have been made on top of their original site.


In the case I am thinking of it is not one house, one factory, one shop, 
one road ... there are many. There is no sign left in this area. Gone. 
Totally vanished.



So that cabnot be used as a criteria to determine whether that should 
be removed or not although the exact situation varies a lot in each 
individual cases.


> Anyway i am against removing apparently useless data without
> consultation with the author, with the exception of clear errors.



Disagree.

Once the data is in OSM it is no longer the 'property' of the
author or
following editors.

If I am not certain of something I'll ask the author/flowing
editors but
where I know something is wrong I'll change it without consultation.

If you are not sure of the use or validity of something then it would 
also be a good idea to ask those who might know about it.



How much time do you think I should spend searching for these people who 
might know of it? And then once found how much time should I spend 
trying to contact them?



Think about what you are asking an unpaid mapper to do?

I would think contacting the author and/or past editors of the item in 
OSM is enough.



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

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Warin]

On 2/6/20 9:44 pm, Paul Allen wrote:
On Tue, 2 Jun 2020 at 12:23, Volker Schmidt > wrote:


Anyway the examples you find in OSM are few and in all cases I
know the completely erased bits are a tiny part of the overall
ex-railway.


There are three ex-railways in my area (possibly more). Even though the
rail part of those railways has mostly been removed, the way part of those
railways is still mostly in evidence.  Apart from embankments, 
cuttings, bridges
and tunnels there are the green corridors - either tree-lined hedges 
or trails cut
through woods. Some sections have been repurposed as footpaths and/or 
cycle
paths.  A few short sections have been resurrected as heritage 
railways.  The places
where all traces have been removed and build over are very few and far 
between.


I could delete those tiny sections of ex-railway that somebody spent time
mapping, but then it loses the coherence that aids understanding (unless I
shove the pieces into some sort of relation).

I understand the perspective of the purists, and one day a purist may come
along and remove sections where all traces have gone. But I have other 
things

I could be mapping so I won't bother doing it myself.

--
Paul




Here is an entry by some one who thinks it should be in OSM ...

Way: former Ballarat - Buninyong line (802945247)

  Tags:
    "name"="former Ballarat - Buninyong line"
    "embankment"="yes"
    "railway"="razed"
    "ruined:railway"="rail"


If you look you will see that this 'embankment' does not EXIST ... there 
are two car parks over it that show no sign of any embankment. There is 
a building over it ... roads ... it does not exist.


Yet the person 'maps' it.

Note I put it into OHM some 2 years ago and removed it from OSM. Should 
I report them to DWG?


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

Re: [Tagging] Overlapping naturals

[Warin]

On 3/6/20 5:37 am, Florian Lohoff wrote:


For me overlapping natural or landuses are broken. An area can either
be a natural=wood or a landuse=farmland. You cant include the same
area in two types of usages or naturals.


You can.

Farm land here can have trees to shelter animals from wind/sun and also to 
provide a wildlife corridor/refuge.
So an area of landuse=farmland with an inner or overlap of natural=wood can be 
correct.

An area of landuse=farmland with any other landuse could be wrong. However some 
areas are used for more than one thing.


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

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Warin]

On 6/6/20 8:02 am, Volker Schmidt wrote:

I need to reopen this thread.

 I do object strongly to the invitation to remove the 
razed/dismantled-railway tag in the case of railway tracks have been 
replaced by roads with the same geometry. To the contrary this is one 
of the more fortunate cases where the original route has been 
conserved, and it is easy to travel along a historical railroad.
I admit that I have a faible for industrial archeology (like former 
railways, watermills, old canals) but they do have touristic value and 
for that reason should be in OSM.



As a general tourist I would have no interest in traveling along a 
railway route here nothing remains of the railway.


If something remains then map the remains, not the bits that no longer 
exist.


Where an old railway route passes through private residential houses, 
commercial buildings, car parking area .. I don't think that should be 
in OSM yet people map it...


A historian/archeologist may have interest in documenting the old 
railway route and facilities, they can and should use OHM.





.


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

Re: [Tagging] Overlapping naturals

[Warin]

On 5/6/20 10:06 pm, Mateusz Konieczny via Tagging wrote:

And you are missing

(1) word "mainly"
(2) "Note: Two values of landuse=* may be view as not strictly land use.
   These are landuse=grass and landuse=forest. Please refer to the 
pages

   of these for more information."



As usual I disagree with  both those misuse of the key landuse.

The value landuse=forest should not be used for any tree covered area 
... use the existing value natural=wood for that, even if 'managed'.


See https://wiki.openstreetmap.org/wiki/Forest for more discussion on 
this topic.



-

Grass misuse is historical. It can also be tagged landcover=grass.


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

Re: [Tagging] [Talk-us] Heavily-wooded residential polygons

[Warin]

On 3/6/20 7:22 am, Mateusz Konieczny via Tagging wrote:




Jun 2, 2020, 20:16 by stevea...@softworkers.com:

"this IS residential landuse." (Not COULD BE, but IS). Yes, this
land might be "natural" now, including being "treed," but I could
still build a patio and bbq there after perhaps cutting down some
trees, it is my residential land and I am allowed to do that,
meaning it has residential use, even if it is "unimproved" presently.

It is a residential property, not a residential landuse.



I have a few trees on my residential property. I use then for; shade, to 
sit under, to have a BBQ under, read a book under, think about things. 
People park their cars, caravans and boats under them.


They are part of my home ... they are used by me ... as my residence.

If trees are to be excluded from OSM residential landuse, will grass and 
flowers be removed too? Are only buildings to be mapped as residential 
landuse in OSM? I think that would be ridiculous.




These facts do add to the difficulty: OSM doesn't wish to appear
to be removing property rights from residential landowners (by
diminishing landuse=residential areas)

Are there people somehow believing that edits in OSM affect property 
rights and may remove them?

That is ridiculous.

but at the same time, significant portions of these areas do
remain in a natural state, while distinctly and presently "having"
residential landuse.

For me and in my region (Poland) it would be treated as a clearly 
incorrect mapping.



Parks here can have scrub, trees, grass and /or flowers - that does not 
mean they are not parks because of the land cover.


I would contend similar consideration by held for residential landuse.

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

Re: [Tagging] [Talk-us] Heavily-wooded residential polygons

[Warin]

On 5/6/20 10:46 am, Greg Troxel wrote:


Sure.  I tend to think that if something is semantically sensible and
can be represented, it's good to tag it, and then rendering is another
story.  I think pretty much everyone agrees that landuse=residential and
natural=wood are both sensible to represent.  And that how they ought to
be rendered in a general purpose landuse/landcover style is much less
settled.


Rendering is another area.

My view: the render has to decide what is more 'important' - land cover or land 
use and then how to each group.

I note how the land use military is mapped - strips so the land cover under it 
could be seen. If all land use were map similarity then that could work.

Alternatively land cover could be represented as a symbol like tree areas 
symbol. Loose the background colours for all land covers and use symbols.
Land uses would then be solid covers. Does not work for wwater so I think this 
would lead to more problems.

I think I prefer the land use mapped as less 'important' - thus land cover gets 
solid colours...

---
Whatever the renders decide we should map what is there, residential with or 
without trees, grass, flowers, scrub, whatever.


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

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Warin]

On 7/6/20 1:52 am, Martin Koppenhoefer wrote:



sent from a phone


On 6. Jun 2020, at 03:58, Jack Armstrong  wrote:


The wiki permits the mapping of reality, on-the-ground, as it is in 
the world today. OSM should reflect what exists today, not decades 
ago. If there is something that remains of a previous railroad, then 
it can be mapped in some way. If there is /*nothing* *remaining*/ of 
what used to be a railroad, it should be out-of-scope.




whether you find traces might depend how hard you look for them. In 
most cases there will be something left of a railroad, but you might 
not be able to recognize it or you will simply not see it because the 
traces are rare.



How hard you look for them? I would hope that does not extend to ground 
penetrating radar that is used to find old buildings that used to exist?



Where something has been demolished and replaced with something else, 
should the old thing remain in OSM?



And yes I am thinking of old railway routes that have gone and been 
replaced with roads/rail trails etc.



To me - the old thing is no longer there, the new thing has overlay-ed 
it and replaces it. If people want to map old things .. well their place 
should be in OHM not OSM.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Warin]

On 7/6/20 1:31 am, Jarek Piórkowski wrote:

On Sat, 6 Jun 2020 at 11:23, Andy Townsend  wrote:

On 06/06/2020 16:18, Phake Nick wrote:
在 2020年6月6日週六 11:03，Warin <61sundow...@gmail.com> 寫道：

As a general tourist I would have no interest in traveling along a
railway route here nothing remains of the railway.

OSM is not *only* for general tourist.

I bet even a general tourist would be interested if they could be assured that 
a route was flat :)

And didn't have buildings or factories built on it ;)


Home owners would not be happy with tourists walking through lunch because OSM 
has a tourist/railline line through their house.

Factory OH&S people would be very upset with tourists walking through the 
factory because OSM has a tourist/railline line through the factory.
The tourists would not be impressed with the 'railway' either if there was 
nothing 'railway' to see, even if the route is flat.

A general tourist walking along a road that has no sign of a railway would not 
be impressed if it were shown as a railway on OSM.
Other road users would be perplexed if the road were shown as a railway...



If it's a recognized route that's signposted as something like
"Historical Railway Trail" then it can be a relation.


As a walking route, yes. It is no longer a railway, that is in the past.


  If it's not
signposted and there's no trace of it left on the ground, what exactly
is being mapped?


History?


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

Re: [Tagging] Education reform - a minor change on my proposal

[Warin]

On 6/6/20 9:04 pm, Erkin Alp Güney wrote:

I have changed how buildings in the campus should be tagged.





Some suggestions?

Just use 'outer boundary' rather than try to cover all the different 
kinds of outer boundaries that may exist.


===How to tag individual schools in this scheme===

Outer boundary of a school is tagged accordingly with education tag.

Buildings should not have education key if that key is the same as the 
outer boundary.


Note that the outer boundary could be a relation.


Add radio to the teaching medium, in case these still exist in some part 
of the world. They used to exist in Australia but that has now 
transferred over to satellite internet - so 'online' may cover it.


| optional || {{Tag|medium}} || face-to-face/postal/online/radio || Is 
it a face-to-face school or a distance education institute?




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

Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

[Warin]

On 31/5/20 9:20 am, Graeme Fitzpatrick wrote:




Yes, there are 1000 things in the Australian bush that'll kill you 
:-), but none of them will actually eat you! (not even Drop Bears! 
https://australianmuseum.net.au/learn/animals/mammals/drop-bear/ :-)) 
Same applies to (virtually?) all of Western Europe, but how about 
North America, Africa, Asia & so on? Do we have / need a way of 
tagging that bears (or whatever) may be encountered while walking in 
this area?





A dead carcass will be deposed of in the Australian bush by animals, 
birds and/or insects.


So, yes your dead body will be eaten in the Australian bush... in some 
places quite quickly. Usually bones and hair will be left behind some of 
it as scat.



As for tagging 'dangerous areas' .. areas that pose danger such as some 
favelas cannot be tagged in OSM. I see the same logic applied to 
dangerous areas caused by wildlife.


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

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Warin]

On 8/6/20 10:57 pm, Volker Schmidt wrote:

Warin, Jack,

your comments are really off my main point.
We have an unfinished mailing-list thread where we have different 
opinions on whether a razed (on the ground) railway can be mapped in 
OSM. In the middle of that discussion the abandoned railway wiku page 
gets completely rewritten by one of the participants in the thread 
explicitly stating that razed railways should be /removed/ from OSM.

This is basically against good practice in OSM.
In addition the statement that where roads trace razed/dismantled 
railways, the reference to the fact that they do, should be removed is 
clearly wrong. Worldwide there are many thousands of km of roads and 
cycle routes that retrace exactly former railway lines . what is wrong 
with adding railway=dismantled (orrazed)  to the ways that make up the 
road or the cycle route.


Railway installations are major sites present in our environment,



The point is they are no longer 'in our environment' .. they are gone, 
no longer here, vanished.


The one I am thinking of has visible things at one end and a few bits 
elsewhere, those I would leave on OSM as they 'exist'.


But to map it where there is nothing left.. to me that is deceptive. The 
other mapper has extended one of the things I left mapped so that an 
embankment runs over roads, through car-parks, a building and a playing 
field. That does not exist now, it may have decades ago ... but not 
today and not for quite a few years.



and there is no good reason to remove them from the map, whether they 
are actively used or only indirectly "visible".

Just two other observations to put this in context:
We have plenty of underground water courses, oil or gas pipelines 
where only few objects on the surface indicate their underground 
existence - no-one would object to having them in the map data, 
including the underground parts.


Agreed - because they exist. I know there is an underground railway near 
me because I use it, it is not viable 'on the ground'. There is a 
drainage channel near me that I can see as entry and exit places .. its 
precise route I don't know so I use the est sources to estimate its 
route. I do my best to map things that exist. I don't think OSM is the 
place for things that no longer exist in any physical way.



Another completely different indication that old stuff could be of 
interest to tourists: when I moved to the UK from continental Europe 
in 1978 I was positively surprised to see, on the standard OS maps for 
hikers, references to Roamn and Saxon sites galore, tyipiclley in the 
form of "site of ..." and of many country paths and tracks labeled 
with their Roman or Saxon names, even though the present-day structure 
is much younger - they only retrace the Roman way like the present-day 
street in the first example on the wiki page retraces a former railway..



If there is something to see there .. then map that. I would not map a 
railway as a railway if all that can be seen is a board that has 
information about the old railway, I would map it as a tourist sign only 
- not a railway.


Similar for Roamn and Saxon sites, if there is something present today, 
map it... nothing there then nothing on OSM, put it in OHM.




BTW I am not saying that OSM map data are incomplete without mapping 
old raylways, I am only asking to not remove those that are mapped, 
and to not write in the wiki that they should be removed.
BTW 2: wiki pages in general should not invite mappers to remove 
already mapped objects, but only correct mapping errors.



On Sat, 6 Jun 2020 at 05:03, Warin <61sundow...@gmail.com 
<mailto:61sundow...@gmail.com>> wrote:


On 6/6/20 8:02 am, Volker Schmidt wrote:
> I need to reopen this thread.
>
>  I do object strongly to the invitation to remove the
> razed/dismantled-railway tag in the case of railway tracks have
been
> replaced by roads with the same geometry. To the contrary this
is one
> of the more fortunate cases where the original route has been
> conserved, and it is easy to travel along a historical railroad.
> I admit that I have a faible for industrial archeology (like former
> railways, watermills, old canals) but they do have touristic
value and
> for that reason should be in OSM.


As a general tourist I would have no interest in traveling along a
railway route here nothing remains of the railway.

If something remains then map the remains, not the bits that no
longer
exist.

Where an old railway route passes through private residential houses,
commercial buildings, car parking area .. I don't think that
should be
in OSM yet people map it...

A historian/archeologist may have interest in documenting the old
railway route and facilities, they can and should use OHM.

Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

[Warin]

On 9/6/20 12:15 am, Paul Allen wrote:
On Mon, 8 Jun 2020 at 14:48, Mateusz Konieczny via Tagging 
mailto:tagging@openstreetmap.org>> wrote:



Jun 8, 2020, 15:05 by pla16...@gmail.com :


The whole world is dangerous.  Just label the entire planet as
a hazard.


railway=abandoned
hazard=tagging_discussions


+1


+1

"Mostly harmless but infuriating" ?

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

Re: [Tagging] Features underwater (inside reservoirs)

[Warin]

On 8/6/20 10:14 pm, Paul Allen wrote:
On Mon, 8 Jun 2020 at 10:33, Cornelis > wrote:



With these tags and the surrounding footways the bridge is treatey
as normal (foot)way by OSRM and graphhopper, altough it only falls
dry roughly every other autumn. Is this a tagging issue that may
be resolved with correct/additional tags? After reading the
discussion I think at least three tags should be added:

Then some questions on other tags currently in use:
• historic=bridge seems ok to me, but I'm not sure if it is a
conflict with building=bridge. Do I have to choose either one?


They are not mutually exclusive.  If it is a tourist attraction then 
it could

also have tourism=attraction.

• intermittent seems to only be in use with water bodies, as far
as i can tell after reading the wiki article.
• seasonal is somewhat related with intermittent but in use for
other things as well. Should I remove these two, nonetheless?


Neither seem appropriate to me.  However, what you should have is 
access=no
to prevent routers from including it in walking routes. What you could 
do, to

show it is occasionally usable (if it is), is something like:

    access=no
    access:conditional=yes @ (above water)



I would keep seasonal but make it more specific

seasonal=autumn

Conditional key does not look to have text base entry ... might be 
better to use opening hours?


opening_hours= "above water" ???


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

Re: [Tagging] [Talk-us] Heavily-wooded residential polygons

[Warin]

On 8/6/20 10:16 pm, Mateusz Konieczny via Tagging wrote:




Jun 6, 2020, 06:20 by 61sundow...@gmail.com:

On 3/6/20 7:22 am, Mateusz Konieczny via Tagging wrote:




Jun 2, 2020, 20:16 by stevea...@softworkers.com
:

"this IS residential landuse." (Not COULD BE, but IS). Yes,
this land might be "natural" now, including being "treed,"
but I could still build a patio and bbq there after perhaps
cutting down some trees, it is my residential land and I am
allowed to do that, meaning it has residential use, even if
it is "unimproved" presently.

It is a residential property, not a residential landuse.



I have a few trees on my residential property. I use then for;
shade, to sit under, to have a BBQ under, read a book under, think
about things. People park their cars, caravans and boats under them.

They are part of my home ... they are used by me ... as my residence.

If trees are to be excluded from OSM residential landuse, will
grass and flowers be removed too? Are only buildings to be mapped
as residential landuse in OSM? I think that would be ridiculous.



These facts do add to the difficulty: OSM doesn't wish to
appear to be removing property rights from residential
landowners (by diminishing landuse=residential areas)

Are there people somehow believing that edits in OSM affect
property rights and may remove them?
That is ridiculous.

but at the same time, significant portions of these areas do
remain in a natural state, while distinctly and presently
"having" residential landuse.

For me and in my region (Poland) it would be treated as a clearly
incorrect mapping.



Parks here can have scrub, trees, grass and /or flowers - that
does not mean they are not parks because of the land cover.

I would contend similar consideration by held for residential
landuse.

Yes, landuse=residential may include areas with tree, I fully agree here.

But "portions of these areas do remain in a natural state" with 
residential status limited
solely to legal status (land ownership, legal right to build something 
there and start using

this land as landuse=residential) cases seem quite dubious to me.



As far as I know some of the trees are 'natural' on my place... I still 
use them.


How do you know that the 'residential status' is limited to the legal 
and not additionally used for the personal enjoyment of the people 
residing there?




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

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Warin]

On 9/6/20 12:10 pm, Jack Armstrong wrote:


On 8/6/20 10:57 pm, Volker Schmidt wrote:


The point is they are no longer 'in our environment' .. they are
gone, no longer here, vanished.



At times this discussion reminds me of a heated argument over whether 
a thing was a dead parrot or not ;)


https://www.dailymotion.com/video/x2hwqnp




I, for one, have been drawing on that. If only for my own amusement.


https://www.youtube.com/watch?v=vZw35VUBdzo

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

Re: [Tagging] Features underwater (inside reservoirs)

[Warin]

On 9/6/20 1:10 pm, Jarek Piórkowski wrote:

On Mon, 8 Jun 2020 at 22:13, Warin <61sundow...@gmail.com> wrote:

On 8/6/20 10:14 pm, Paul Allen wrote:

 access=no
 access:conditional=yes @ (above water)

Conditional key does not look to have text base entry ... might be better to 
use opening hours?
opening_hours= "above water" ???

:conditional is widely used for mapping:
https://taginfo.openstreetmap.org/search?q=conditional



But :conditional = yes @ some text does not meet the specification of 
:conditional as per the wiki.
Is there anything to say :conditional will accept text entries and 
those are be used by any render?
The key opening_hours does accept text based entries as per the wiki. I think 
some renders do accept the text entries?


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

Re: [Tagging] [OSM-talk] Should we map things that do not exist?

[Warin]

On 9/6/20 6:46 pm, Martin Koppenhoefer wrote:


sent from a phone


On 9. Jun 2020, at 03:40, Warin <61sundow...@gmail.com> wrote:

Similar for Roamn and Saxon sites, if there is something present today, map 
it... nothing there then nothing on OSM, put it in OHM


Warin, can you give an example for something historic that is not there any 
more in reality and should be removed from OpenStreetMap? Through all the years 
I have never encountered anything like this mapped in OpenStreetMap.



Way: former Buninyong line (802945258)

Way: Buninyong Line (802945251)

Way: Ballarat - Buninyong line (168429101)


Note I put these in OHM ~2 years ago.


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

Re: [Tagging] Features underwater (inside reservoirs)

[Warin]

On 9/6/20 9:30 pm, Paul Allen wrote:
On Tue, 9 Jun 2020 at 09:24, Warin <61sundow...@gmail.com 
<mailto:61sundow...@gmail.com>> wrote:



But :conditional = yes @ some text does not meet the
specification of :conditional as per the wiki.


From 
https://wiki.openstreetmap.org/wiki/Key:access#Access_time_and_other_conditional_restrictions


    For a full description and more examples, please see the 
conditional restrictions page.


The page https://wiki.openstreetmap.org/wiki/Conditional_restrictions
isn't as clear as it could be in defining the syntax.  I went by these 
examples:


Road condition: For example, *wet*, *snow*. It is noted that the 
condition *wet* corresponds to *:wet* in e.g. maxspeed:wet 
<https://wiki.openstreetmap.org/w/index.php?title=Key:maxspeed:wet&action=edit&redlink=1>=*. 
Using *wet* as a condition is recommended in order to streamline the 
syntax of restriction tags ("maxspeed:wet" was introduced at a time 
when no proper way of tagging conditional restrictions existed).


User group: The restriction relates to a specific user group, e.g. 
doctor, disabled, emergency, female.


From those, it appears that the condition is free-form text except for 
cases

like opening hours.



Opening_hours provides for free form text.


From https://wiki.openstreetmap.org/wiki/Key:opening_hours#Summary_syntax


*comment:* |"|text|"|

   A short comment (wrapped in |"| but not containing any |"| within)
   showing applicable restrictions or specifications, e.g. |"children
   only"|, |"limited service"|, or |"reservation by phone"|.
   This comment is intended to be displayed in applications and not to
   be interpreted automatically.



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

Re: [Tagging] Help explain the difference between path and track

[Warin]

To me in OSM a 'path' has always been too narrow for a motor car (4WD or not) 
to pass.
If it is wide enough for a car then it is not a 'path' in OSM so they must be 
tagged in some other way.

Descriptions of 'path':


On 10/6/20 5:53 am, brad wrote:

"If a path is wide enough for 4-wheel-vehicles (wider than 2 m), and
 it is not legally signposted or otherwise only allowed for
 pedestrians, cyclists or horseriders, it is often better tagged as a
 highway =track 
  orhighway =service 
.

 "


 to this:

 "If a path is wide enough for 4-wheel-vehicles (wider than 2 m), it
 is often better tagged as ahighway =track 
  orhighway =service 
.

 "



Or possibly:

A path should not be wide enough for 4-wheel-vehicles (wider than 2 m),for these wider ways see highway 
=track 
  orhighway =service 
.




On 10/6/20 10:29 am, Kevin Kenny wrote:

On Tue, Jun 9, 2020 at 6:13 PM Tod Fitch  wrote:


The two major factions seem to be set in their ways: “It is only a track if it 
is used for agriculture or forestry” on one side. “It has the same physical 
characteristics as a track, so it is a track even if it is currently used for 
hiking, bicycling, riding horses, or by ATVs” on the other side.

That also spills into is it a track or a service (driveway)? Depends on if it 
goes to a barn or a house! But I can’t tell without trespassing, how can I map 
it?

First step, I think, is to be less pedantic about function on things that look 
exactly like a track. Mappers in all the areas I’ve looked at will tag a way 
that is unpaved and about the width of a four wheeled vehicle as a track 
regardless of current use. Maybe it is being used as a driveway. Maybe it is 
being used as a bicycling/hiking/equestrian trail. Maybe it accesses a field. 
Maybe it hasn’t been used for a while and just hasn’t decayed or been overgrown 
into nothing. Who knows? But it looks like a track. Saying that the way “isn’t 
for forestry or agricultural use” so it can’t be a track is worthless: Real 
world mappers have voted otherwise with their tagging.

In terms of function, 'track' and 'service' (with or without
'driveway') are practically interchangeable - at least in terms of
what they provide to the road network. They're both distinguished by
the fact that they don't 'go anywhere'. They typically serve only a
single establishment - public roads that serve multiple establishments
are typically at least 'unclassified'.



In Australia the word 'track' is used in a much broader sense than that used in 
the OSM wiki.

The OSM tagging practice in Australia uses 'track' in that same broader sense - 
so not just agriculture and forestry but also other operators/uses e.g. 
National Parks.
Some of these 'tracks' were put in to enable fire fighting - usually locally 
called 'fire trails'.
Maps generally show these in the same way as forestry trails hence the 
preference to tag them the same way in OSM as 'we' are used to seeing them 
rendered that way.

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

Re: [Tagging] Features underwater (inside reservoirs)

[Warin]

On 10/6/20 11:12 pm, Paul Allen wrote:
On Wed, 10 Jun 2020 at 02:13, Warin <61sundow...@gmail.com 
<mailto:61sundow...@gmail.com>> wrote:


On 9/6/20 9:30 pm, Paul Allen wrote:

From those, it appears that the condition is free-form text
except for cases
like opening hours.


Opening_hours provides for free form text.

I expressed my point unclearly.  It appears from the examples that the
condition is free-form text.  However, when the condition specifies
opening hours then those hours should be expressed in the standard
form for opening_hours.  That opening_hours allows free-form text is
a digression.  Unless you were seriously suggesting that we
abuse opening_hours as a way of introducing free-form text into
a condition even though it appears (to me, at least) that conditions
permit free-form text anyway.


? Abuse opening_hours by 'introducing' free form text? It is allowed, so 
not an introduction nor an abuse.


I was not aware that condition allowed free form text. Both tags are 
poorly documented for this on the wiki.




Do you concur that a conditional such as "(low water)" is permissible?  If
so, do you agree that it is a better solution than "seasonal" or 
"intermittent"?



Yes, I think so, but the documentation for free form text is not clear. 
Is open_hours better? I don't know.




Using "seasonal" is unhelpful because low water is possible (if unlikely)
during all seasons.  Using "intermittent" is somewhat better.

But both "seasonal" and "intermittent" are (currently) only defined as
applying to water(ish) features themselves, not to things that are under
those features.  Changes would have to be made to routers to allow
either seasonal or intermittent to be interpreted correctly when applied
to ways.  Routers already (I hope) interpret conditionals.



 Some roads are closed in winter but this could be applied as either 
seasonal or conditional depending on the mapper.


I think I have tagged some but cannot recall which way I did it.

Would be usefull to do a tag info search for the more popular one and 
then document it on the wiki.


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

Re: [Tagging] Replace the "DecoTurf" value

[Warin]

On 13/6/20 7:03 am, Steve Lee wrote:
"DecoTurf" is not a common name, but a brand name. It  is also not a 
genericized trademark. We may need a broader term to classify 
surfaces. "Hardcourt" seems to be used exclusively for tennis courts, 
literally does not refer to a certain material. However, most of 
hardcourt surface are acrylic based, which is one of the ITF's 
classification of tennis court surface types. So I think "acrylic"  is 
a suitable value to classify the surface of the courts.



Acrylic I tend to associate with paint and plastics.


From satellite imagery I simply used 'paved' where I can determine it 
is not a 'natural' surface.



Only some ~600 uses of DecoTurf.

Only some ~20 uses of Hardcourt.

Surface is used some 31,000,000 times so the above 2 may not be rendered 
anyway being such a small proportion.. possibly lumped into 'paved' if 
anyone bothers.




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

Re: [Tagging] Charging stations

[Warin]

On 15/6/20 1:37 am, patata wrote:

Currently socket:type1 and socket:type2 are not clarifying if the
station has a cable or we must bring our own.
Since the connector is not necessarily a socket,


Agreed.


it is being discussed
on our telegram group https://t.me/openchargemap to change all sockets
into connector. Only add socket or cable where it needs to be
differentiated.

Examples :
connector:type1:socket
connector:type2:cable
connector:ccs
connector:chademo


Where a cable exists (is present) then why not tag :

cable=yes/no/ length (in metres)  ???

Cables would be wired in to prevent theft?

On one one OSM entry there should be one connector with any required cable tag 
(and voltage/amperage etc)?

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

Re: [Tagging] Should we map things that do not exist?

[Warin]

On 15/6/20 1:09 am, Volker Schmidt wrote:
Regarding power lines: it is helpful mapping razed power lines as 
razed and not removing them completely, because in many cases some of 
the satellite pictures still show the towers, or at least the concrete 
foundations. This way you avd resurrection.



Where it no longer exits on satellite imagery?


I think that can be removed with out fear of someone restoring it from 
imagery available to OSM editors.




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

Re: [Tagging] Should we map things that do not exist?

[Warin]

On 14/6/20 10:59 pm, Niels Elgaard Larsen wrote:

Martin Koppenhoefer:

==
Warin, can you give an example for something historic that is not
there any more in reality and should be removed from OpenStreetMap?
Through all the years I have never encountered anything like this
mapped in OpenStreetMap.



Repeating my previous post - just so it can be seen that I replied.

Way: former Buninyong line (802945258)



Way: Buninyong Line (802945251)



Way: Ballarat - Buninyong line (168429101)





Note I put these in OHM ~2 years ago.


==

I have deleted some powerlines tagged
as removed.


Typically because they have been removed and replaced with
underground lines, which are correctly mapped.

I might take a year before traces of the poles are completely gone as
farmes plow over the spots and put new crops there.

But lines in the air will be removed without a trace.

And of course highways are changed all the time.
When a 4-way intersection is replaced with a roundabout we de not keep
the four pieces of the road inside the roundabout tagged as razed. We
have the history for that.

___
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] nhd tags - documentation page review

[Warin]

Try
https://www.openstreetmap.org/changeset/3382975

~ 10 years ago.

On 15/6/20 7:52 am, Jo wrote:
If you enabled expert mode, you can download from Overpass directly 
into JOSM.


Polyglot

On Sun, Jun 14, 2020, 23:29 Mateusz Konieczny via Tagging 
mailto:tagging@openstreetmap.org>> wrote:





Jun 14, 2020, 22:55 by vosc...@gmail.com :

Is it not possible to get people who were involved in the
original import to check these.things?

Good idea, any idea how to identify accounts that added this tags
into OSM?

Standard way to to this failed - loading all objects tagged with
this in Overpass Turbo
would fail - 600 MB of data would crash browser.

Next idea is to hunt for various download areas across USA, but I
hope for a better method.

without knowing what information these codes carry ore once
carried,

That is why I created pages documenting what kind of info is
stored in imported tags
___
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] bicycle_parking=? for stands where handlebar is used to hold bicycle in position

[Warin]

On 16/6/20 4:30 am, Hidde Wieringa wrote:


Good evening,

In the region where I live there are 657 objects tagged with 
amenity=bicycle_parking, of which 457 have no bicycle_parking tag at 
all. I would say that classification of the bicycle_parking is 
undertagged in general.


 Under tagged, yes. Generally I don't bother - use what is there and 
get on with it (sorry if that offends).


I have not noted any handlebar bicycle parking here in Australia.


I'd not botehr with formal approval - see how it goes in the wild.



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

Re: [Tagging] charging stations

[Warin]

On 15/6/20 10:26 pm, Paul Allen wrote:
On Mon, 15 Jun 2020 at 10:29, Johannes Werner via Tagging 
mailto:tagging@openstreetmap.org>> wrote:



cable=yes/no/length seems like a great idea. It does however not
solve OPs problem that a cable is not a socket.


However, a cable at a charging station will have a connector at the 
free end.

The cable does not end with bare wires.



I'd think one end of the cable is fixed to the charging station.

Specifying the connector needs to be done for ether a cable or a fixed 
connection.




The question then is how to designate that connector.  Is it a plug or 
a socket?

The answer is not as clear as many think.  See
https://en.wikipedia.org/wiki/Electrical_connector#Plug_and_socket_connectors

Despite what the Wikipedia article says, the terminology isn't as 
clear-cut as

it implies and different industries have different, conflicting naming
conventions.  Within a single industry different naming conventions may be
applied to different styles of connectors.

Some go by the contact type, with males contacts being plugs and female
contacts being sockets, but hermaphroditic connectors and mixed-contact
connectors complicate things.  Some go by fixed vs free, with fixed 
connectors
being jacks and free connectors being plugs, but by that convention a 
standard

power extension lead has two plugs, but one of those two plugs looks like
a wall socket except it's not fixed to a wall.

Where a coupling mechanism is involved, such as the coupling ring on
a circular connector, some industries will refer to the connector with
the coupling ring as a plug and the connector it mates with as a socket.
The connector with the coupling ring is always free, the mating connector
may be fixed or free.

That's just scratching the surface.  Is the connector at the end of 
the cable
a plug or a jack or a socket or a free receptacle or something else?  
It depends

what the specification for that particular type of connector (such as
Chademo) calls it.

It's probably safer to tag the connector type (Chademo, etc.) and not try
to decide whether it's a plug or socket or receptacle or jack.



What ever connector type it should be compatible with the car 
connector/cable jack/jill/plug/socket/male/female/etc. So I'd not worry 
about it until there is some problem somewhere that requires a tag, 
until then leave it off.




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

Re: [Tagging] Rail segment in a bike route

[Warin]

Normal OSM access is assumed to be access=yes, where some access is 
restricted then in OSM it should be marked *=no.


So where a train forbids bicycle transport then bicycle=no should be 
applied or some local default of bicycle=no on trains be documented.


Locally to me some trains require the bicycle to be boxed, but not all 
trains require this. None of this to my knowledge is OSM tagged here, 
many train routes have not been mapped in OSM so this detail is of a 
much lower priority.


On 19/6/20 10:33 pm, Peter Elderson wrote:
I think a bicycle route can not declare a rail route to be 
bicycle=yes. I think you should verify that the train is bicycle=yes 
before you call it a transfer. If it isn't, you can't declare it to be 
a part of your waymarked bicycle route, can you?


Apart from that, if a router uses the bicycle route relation, it 
should alway check the ways themselves for access, no matter what the 
route relation says.


Fr gr Peter Elderson


Op vr 19 jun. 2020 om 14:02 schreef Francesco Ansanelli 
mailto:franci...@gmail.com>>:


Dear Volker and Peter,

I agree with you both...
The question was born for a bike+train (funicular actually), but
it can be implemented in a generic way to fix similar cases.
Insead of interrupting the relation on the railway, we can put
the other public transport one as a member with a "transfer" role.
Of course, I assume the transfer relation will have 1 or 2 common
points with our trip (stops):
let's say a train starts from station A, but we take it at station
B with our bike, we get off at station C, but the last station
will be Z.
I don't think this could be an issue, but should be considered for
any future implementation.
Transfer relations should also consider the parent's relation type
(ex. route=bicycle, implies bicycle=yes on the train route).
What do you think?

Francesco

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


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



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

Re: [Tagging] "Feature Proposal - RFC - Qanat"

[Warin]

On 20/6/20 9:35 am, Martin Koppenhoefer wrote:



sent from a phone

On 20. Jun 2020, at 00:59, Joseph Guillaume 
 wrote:


I just wanted to emphasise that this proposal isn't really about 
whether to tag qanats - it's about whether to tag them with 
man_made=qanat or waterway=canal+canal=qanat.


There's already 1000 tagged, and they're very patchy geographically. 
It's quite likely there's upwards of 100,000


It would be great to be able to formally deprecate man_made=qanat 
before it becomes de facto.


Hopefully we can get enough interest in this issue for the vote to be 
convincing.



The issue with waterway=qanat could be that it is only applicable to 
those structures that still carry water, while many of them will not 
be in a working state, or maybe I’m misguided?


I could imagine using historic=aqueduct with a subtag aqueduct=qanat 
for all of them, and add the waterway tag to distinguish working from 
nonworking?



The use of the lifecycle prefixes should be used.

disused:*=* for things that can easily be put back into use.

abandoned:*=* for things that require a lot of work and $ to be put back 
into use


and so on.


disused:waterway=canal+canal=qanat ???

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

Re: [Tagging] Is there any case of valid numeric addr:housename - for example addr:housename?

[Warin]

On 30/6/20 11:16 pm, Martin Koppenhoefer wrote:


sent from a phone


On 30. Jun 2020, at 15:08, Mateusz Konieczny via Tagging 
 wrote:

Is there some chance that any of them is valid?


IMHO not, these are likely autocompletion bloopers.



Highly likely these are errors. However it is not impossible that a number 
could be used as a house name.


  I’d support an automatic retagging effort to addr:housenumber (unless there 
is already a different housenumber)


I would not support auto retagging. Contact the mappers and ask them.
I have come across one or two of these, contacted the mapper and one mapper 
agreed that it was an error.
The other mapper argued, settled by web search evidence that it was not the 
name.


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

Re: [Tagging] How to map terrace buildings with names

[Warin]

On 9/7/20 12:44 am, Martin Koppenhoefer wrote:


sent from a phone


On 8. Jul 2020, at 16:17, Matthew Woehlke  wrote:

Really? If Alice and Bob each own 50% of "Fairview Heights Apartments", you 
would expect that there are legal property records indicating exactly which half of said 
complex is owner by Alice and which half is owned by Bob? (Note that the *tenants* don't 
own *any* of it.)


both is possible, each one can own a precise list of apartments, or both can 
own 50% of all apartments.



Here apartments are usually sold separately, each as a title dead.
Other than 100% ownership it would be highly unusual for a  50% ownership other 
than by the entire thing being owned by a firm and an individual/firm owning 
50% of the 100% owning firm.





For condominiums, AFAIK, the *definition* of condominium vs. townhouse is that 
you only own a specific *interior* space and *not* the exterior.


welcome to OpenStreetMap, mapping the whole world. You are looking at the 
details in a specific jurisdiction.




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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Warin]

On 10/7/20 9:30 pm, Peter Elderson wrote:
Looks like humus is a component of soil. So I think soil covers it, 
being a top layer consisting of mixed organic and mineral matter.


To me it is hard to imagine an area as permanently natural=bare_soil. 
Wouldn't there always be some kind of vegetation within a year?



Not always.

Sorry to say but some soils have been so polluted combined with the 
resulting soil erosion vegetation has taken some decades to come back.


See https://en.wikipedia.org/wiki/Queenstown,_Tasmania#Ecology




Best, Peter Elderson


Op vr 10 jul. 2020 om 12:42 schreef Michael Montani 
mailto:michael.mont...@un.org>>:


I agree it could be considered as humus. The distinction between
organic soil and humus is ambiguous according to
https://en.wikipedia.org/wiki/Humus , but I think it is general
enough to target mostly organic soil.

Shall we consider to add this specification on the tagging? Or
would humus be considered as bare soil anyway?

Thanks

--
*Michael Montani*
GIS Consultant,/Client Solutions Delivery Section/
*Service for Geospatial Information and Telecommunications
Technologies*
United Nations Global Service Centre
United Nations Department of Operational Support

Brindisi|Phone: +39 0831 056985|Mobile: +39
3297193455|Intermission: 158 6985
E-mail:michael.mont...@un.org |www.ungsc.org





*Da:* Peter Elderson mailto:pelder...@gmail.com>>
*Inviato:* venerdì 10 luglio 2020 12:02
*A:* Tag discussion, strategy and related tools
mailto:tagging@openstreetmap.org>>
*Oggetto:* Re: [Tagging] Feature Proposal - RFC - (Ground)
Organic without any mineral, would you still call that soil?

Vr gr Peter Elderson


Op vr 10 jul. 2020 om 11:55 schreef Martin Koppenhoefer
mailto:dieterdre...@gmail.com>>:



sent from a phone

> On 10. Jul 2020, at 11:39, Mateusz Konieczny via Tagging
mailto:tagging@openstreetmap.org>>
wrote:
>
> Why it would be natural=bare_ground rather than
natural=bare_soil?


+1,
I also disagree that “soil can be organic or mineral”. It has
typically both, organic and mineral components, but organic
components are a hard requirement. Otherwise it would be sand,
or rock, or silt or clay or loam etc. (depending on grain size/s).

Cheers Martin





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

Re: [Tagging] Feature Proposal - RFC - (Ground)

[Warin]

Most Australian deserts cannot be mapped as a consistent land cover but 
as a patchwork combination of differing land covers. As such mapping the 
land cover is a time intensive task and given the usefulness of such 
information compared to other priorities is not something that would be 
done any time soon.



 On 14/7/20 7:47 am, Joseph Eisenberg wrote:
Many desert climates can be mapped as natural=sand (for dunes and 
other areas of sand), natural=bare_rock (for bedrock and large 
stones), natural=scree, natural=shingle, or natural=heath (for areas 
of dwarf shrubs), but we still need a tag for unvegetated areas which 
are not sand, rock, stones or vegetation. While these areas are rare 
in many climates, they can cover fairly large spots in some very dry 
areas, and we should provide more precise tagging since 
"natural=desert" could be any of these things (or even natural=scrub)


– Joseph




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

Re: [Tagging] Intermittent highways?

[Warin]

I too would suggest opening_hours.

Seasonal is related to the climate and the climate does vary from one 
year to the next and may be why the tag has a 'loose description'. An 
annual festival is not usually held for an entire climatic season, so I 
would not use it for them. Similar argument with intermittent with the 
added argument that it is not water related.


On 15/7/20 8:48 am, Justin Tracey wrote:
If the festival is held at some date expressible using the opening 
hours syntax, you could use the "open hours" tag[0] or add conditions 
to the "access" tags[1]. Though these tend to represent temporary 
accessibility, not temporary existence the way "intermittent" or 
"seasonal"[2] do. I'll also note that "seasonal" is already used for 
non-waterway features, and depending on how much one wishes to stretch 
the definition of "season" (which is already a pretty loose concept, 
even on OSM), it could maybe be used here too?


 - Justin

[0] https://wiki.openstreetmap.org/wiki/Key:opening_hours

[1] https://wiki.openstreetmap.org/wiki/Key:access

[2] https://wiki.openstreetmap.org/wiki/Key:seasonal


On 2020-07-14 12:22 p.m., John Sturdy wrote:
I've been adding some detail to a site that is used annually for a 
festival (not happening this year because of Covid-19), where there 
are paths in the same place year after year, but the paths are not 
there when the festival is not happening, although increased wear on 
the ground around them is probably visible much of the time.


Does it make sense to map such paths, perhaps borrowing the 
"intermittent" tag from waterway tagging?


__John






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

Re: [Tagging] Intermittent highways?

[Warin]

On 15/7/20 5:07 pm, Martin Koppenhoefer wrote:



sent from a phone


On 15. Jul 2020, at 00:49, Justin Tracey  wrote:

If the festival is held at some date expressible using the opening 
hours syntax, you could use the "open hours" tag[0] or add conditions 
to the "access" tags



I would not use opening_hours tag to represent the temporary existence 
of ways if this should mean that the ways are only there some weeks of 
the year.


If the thing is permanently scheduled event then it is not a temporary 
event.


Temporary: Lasting for only a limited period of time; not permanent. 
Source - Oxford Dictionary.


Opening hours have no restriction to being more or less than some 
proportion of a year.



Similarly, access is about legal access and not physical existence. 
With the established schemes, you could use conditional on the 
highway, like highway:conditional=footway/service/path @ Time

it is not common, but someone else already had this idea as well:
https://taginfo.openstreetmap.org/keys/highway%3Aconditional



As you say - not common and probably not rendered/used by any application.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Edited the wiki for building=terrace

[Warin]

On 18/7/20 3:29 pm, Skyler Hawthorne wrote:

Hi everyone,

A couple weeks ago, I started a thread regarding how to tag terrace 
buildings when the entire building has a name. I proposed an 
alternative tagging scheme to handle such cases, and others where it's 
clear that the building is one cohesive unit.


As a result of that discussion, I made some edits to the wiki page for 
building=terrace. A review and any feedback is welcome, as are further 
edits if there is further clarification in order, or if there is 
strong objection to the tagging scheme described.

--



In Australia.

A row of terrace houses were commonly built by the one builder in the 
same style and usually in similar floor plans (usually mirrored pairs).


Once built they were sold off as individual homes.


Over time various changes have been made to individual homes. However 
the shared sidewalls have remained as they are structural to the buildings.


Some adjacent houses have been combined into one home usually retaining 
the frontal appearance of two houses and the perimeter of the shared 
side wall.


--

To my knowledge a terrace house MUST share the side walls with the 
adjacent terrace house in the original construction, obviously excluding 
the two end houses. This is not clearly stated in the OSM page.


In rare cases a single terrace house remains as the others have been 
demolished. These are still terrace houses as identified by the 
construction, style, size and floor plan conforming to others in the area.



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

Re: [Tagging] Tagging motorcycle parking

[Warin]

On 23/7/20 6:42 am, Matthew Woehlke wrote:

On 22/07/2020 16.32, Martin Koppenhoefer wrote:

Am Mi., 22. Juli 2020 um 21:11 Uhr schrieb Matthew Woehlke:

Right now the only option seems to be to model the lot as two separate
entities, one which excludes the motorcycle spaces, and one which is
*only* the motorcycle spaces which could be amenity=motorcycle_parking.
Is this really the best way?


I am usually doing it like this (separate entities), it also seems most
useful for drivers / riders, because each group can see where are their
parking lots.


So... I'm not sure I agree with that. Maybe it's different in !US, but 
in the US, motorcycles can (generally) park in any car parking space. 
If we're going to use that argument, why do we have capacity:disabled, 
or indeed capacity:*, rather than modeling those spaces as separate lots?




You asked for 'better' without defining what better means to you.
To me it is 'better' to know where these things are (requires more work 
by the mapper) rather than that they are somewhere inside some area 
(requires less work by the mapper).


Disabled parking to me is 'better' mapped as a separate thing, as is 
truck parking etc.


While a motorcycle may legal park where a car parking space is the same 
cannot be said of a motorcycle parking space given  the usual sized of 
the things.



Tags may be available for those who cannot be bothered with the detail, 
similar observations may be made for surface=paved vs surface=concrete etc.



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

Re: [Tagging] Hiking "guideposts" painted on rocks, trees etc.

[Warin]

On 21/7/20 9:04 pm, Michal Fabík wrote:

Hi,
in some parts of the world, it's common practice to paint guidepost 
information (destinations, distances etc.) on rock faces, trees, walls 
and similar existing surfaces, rather than use purpose-made plates 
attached to a pole. (Example: 
https://osm.fit.vutbr.cz/fody/files/21255.jpg)



In addition to paint some are carved into the material (I am thinking of 
sandstone rock, trees do grow over inscriptions).



I would not be too worried by this as the renders probably will not be 
bothered to show such detail.




Do you think that these warrant their own tagging style?



No. The material the guidepost is made from is of lesser importance to 
the fact that it is a 'guidepost'.


Or is it acceptable to use information=guidepost, maybe with an 
additional tag (although I can't think of one off the top of my head)?


material=rock/sandstone/*


I know of some 'guideposts' that have no written inscription but conform 
to a style and colour that identifies them to a particular trail, 
similar to the white blaze of the AT. Yes, these are timber posts that 
guide walkers using arrow symbols so the term 'guidepost' suits.



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

Re: [Tagging] Farmlands subject to rotation of crops

[Warin]

On 22/7/20 12:53 am, Michael Montani wrote:

Dear all,

I wanted to check with you which is the best way to map farmlands 
subject to rotation of crops. An example could be of a farmland used 
for general crop in one part of the year and left it at rest for the 
remaining part of the year, being actually used as a meadow for 
animals grazing there.


Which would be the best way to tag such area?




landuse=farmland

Optionally add?
description=crop rotation
produce=crop (this is non specific... possibly add detail with 
produce=wheat,barley,crop is specific crops are known?)

comment=crop rotation

When a field is fallow then I would not use farmland=meadow as this is 
incorrect ... unless it is truly used as animal grazing or harvesting 
the plants. Some crop lands are used after harvesting from grazing of 
animals but this is a temporary thing that is a small percentage of the 
time, so I don't map it.. too much to keep upto date and that would be 
confusing for maps that don't update on a weekly basis.




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

Re: [Tagging] Feature Proposal - RFC - UPRN & USRN

[Warin]

On 27/7/20 5:58 am, Rob Nickerson wrote:

Hi all,

Mappers in the United Kingdom are looking to agree two tags for 
mapping 'Unique Property Reference Numbers' and 'Unique Street 
Reference Numbers'. To support this effort I volunteered to create the 
relevant proposal pages on the wiki.


To view and comment on these please see:

https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:uprn
https://wiki.openstreetmap.org/wiki/Proposed_features/ref:GB:usrn

These pages have already been posted to talk-gb and talk-ie (for 
Northern Ireland) a few days ago. As long as there are no major 
blockers here, we will move to the voting stage shortly.




1) minimum time for comments is 2 weeks... don't be in  hurry.


See  https://wiki.openstreetmap.org/wiki/Key:ref In particular the wide 
use of *ref:** as a namespace 
 prefix.


The namespace prefix is crowed with country specific uses so I would see 
any objection here to this new use should also address the proliferation 
of country specfic existing uses too.



Record hottest temperature for attic place.
_
_
/According to scientific study, global warming in the Arctic is 
happening twice as fast as for the rest of the planet./

/
/
/For the second day in a row, the archipelago registered 21.2 degrees 
Celsius in the afternoon, just under the 21.3 degrees recorded in 1979, 
meteorologist Kristen Gislefoss told AFP./

/
/
//
/Later in the afternoon, however, at around 6pm local time, it recorded 
21.7 degrees, setting a new all-time record./

/
/
/The island group, dominated by Spitzbergen the only inhabited isle in 
the northern Norway archipelago, sits 1,000 kilometres from the North Pole./


https://timesofmalta.com/articles/view/highest-ever-temperature-recorded-in-norwegian-arctic-archipelago.807546
Record hottest temperature for attic place.
_
_
/According to scientific study, global warming in the Arctic is 
happening twice as fast as for the rest of the planet./

/
/
/For the second day in a row, the archipelago registered 21.2 degrees 
Celsius in the afternoon, just under the 21.3 degrees recorded in 1979, 
meteorologist Kristen Gislefoss told AFP./

/
/
//
/Later in the afternoon, however, at around 6pm local time, it recorded 
21.7 degrees, setting a new all-time record./

/
/
/The island group, dominated by Spitzbergen the only inhabited isle in 
the northern Norway archipelago, sits 1,000 kilometres from the North Pole./


https://timesofmalta.com/articles/view/highest-ever-temperature-recorded-in-norwegian-arctic-archipelago.807546


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

Re: [Tagging] kerb=regular vs. raised

[Warin]

On 31/7/20 12:42 am, Joseph Eisenberg wrote:
In Indonesia, Costa Rica, Peru and Mexico, it is common to find 30cm 
kerbs in older neighborhoods. In Nicaragua there were some that were 
at least 45 cm high, in Leon or Granada.


Tropical countries with heavy rainfall often do this to avoid flooding.



Also occurs near desert areas as they get 5 years rain fall in a day or 
two.


Broken Hill has regular (normal, expected) curb heights of 25 cm, where 
as Sydney has 15 cm .. not only are these in the same country but also 
in the same state.



The word 'regular' is a poor choice for this tagging.

What is being tagged is the wheelchair/stroller/wheelbarrow 
accessibility of the curb. That is what should be implied by the tagging 
used.



Much easier to tag the numerical height of the curb as this avoids the 
confusion of words, particularly with different languages, cultures and 
climates.







On Thu, Jul 30, 2020 at 7:02 AM Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:


Am Do., 30. Juli 2020 um 10:13 Uhr schrieb Philip Barnes
mailto:p...@trigpoint.me.uk>>:

when reading the term raised kerb I’d rather think about
something like 25-40cm, while 4 cm surely wouldn’t be
considered “raised”

At that height even a fit able bodied person would need to
think about crossing them.



that's why it could be interesting to tag it. If we had a
hierarchy lowered, regular, raised, it would make sense.


In built up areas typical raised kerbs are upto 15cm, being a
sad geek I have just measured the kerb outside, 12cm which is
certainly in my experience normal.



ok, then make it regular: 315

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] kerb=regular vs. raised

[Warin]

On 2/8/20 5:41 pm, Martin Koppenhoefer wrote:


sent from a phone


On 2. Aug 2020, at 03:55, Warin <61sundow...@gmail.com> wrote:

Much easier to tag the numerical height of the curb as this avoids the 
confusion of words, particularly with different languages, cultures and 
climates.


this would require a lot of measurements, while a few classes of heights could 
generally be determined by looking at it. It also might require splitting the 
kerbs when there a variations of just a few centimeters. While tagging actual 
heights explicitly is fine, it is not a general alternative to tagging lowered 
kerb / higher than normally expected kerb.


The point is that a 'normally expected curb' may be a considerable obstacle to 
a wheelchair person. And the purpose of this tagging is to indicate wheelchair 
access difficulties.

If someone wants to map those variations, let them. Most curb heights are not 
mapped, indeed most curbs are not mapped.
So having someone spend time mapping minor variations may indicate that they 
think this is important.
 
Once the 'regular' curb height is measured then it is a simple matter, for most who are not concerned with minor variations, to estimate curbs of similar height in the same area.


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

Re: [Tagging] Feature Proposal - Voting - (Ground: natural=bare_soil)

[Warin]

On 4/8/20 7:17 am, Joseph Eisenberg wrote:
Everyone, the voting period for natural=bare_ground is still open for 
4 more days.


I would recommend voting "no" on the current definition, unfortunately.

As mentioned above, the current definition is far too broad, and could 
easily be construed to include areas under construction, areas of bare 
soil due to use by people as a pathway or road area,
These are 'land use' not 'land cover' and can be tagged separately. They 
are orthogonal.
and many sorts of arid and semi-natural areas, including those that 
are partially covered by shrubs, heath, grass or other sparse vegetation,


The question is, what is dominate? An area of trees that is mostly trees 
should be tagged as trees, if it is mostly bear earth then tagged as 
bare earth...


OSM already has areas of combined trees and shrubs where the general 
guide used is tag what is dominate. No need to single this proposal with 
partial coverings as it applies to all of the present OSM tagging.



or even areas of farmland that are currently fallow.

Again a land use not a land cover.


Please see the discussion and objections on 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Ground


I think it is a good idea to have a way to tag bare soil which is not 
sand (natural=sand) or mostly stones (natural=shingle/scree) or mud, 
but we need a clear, limited definition which does not fit with 
human-use areas like roads, dirt parking lots, construction sites, 
abandoned quarries etc, and there needs to be more consideration about 
when the tag should be used instead of natural=heath and natural=scrub 
in arid regions where there are scattered bushes.


For the proposal author, I would suggest mapping some local features 
in your area which would fit the proposed definition, and then come 
back with photos plus aerial imagery of the areas which ought to be 
mapped with this tag. So far it has been mostly hypothetical, which 
makes it hard to understand which sorts of landscapes would qualify 
for this tag.



I think this is similar to the tags surface=earth and surface=dirt, both 
are poorly defined.


Perhaps these 2 tags would be better as surface=soil???


The proposal sates "An area covered by soil" so it should be natural=soil.

The description could then be "The upper layer of the planet earth being 
a material typically consisting of a mixture of organic remains, clay, 
and rock particles." ???



Of course the usual exclusions apply;

majority is soil

where a more detailed value applies, use it eg natural=clay if the 
majority of the area is covered by clay.






- Joseph Eisenberg

On Mon, Jul 27, 2020 at 5:58 AM Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>> wrote:




sent from a phone

> On 27. Jul 2020, at 13:41, Michael Montani
mailto:michael.mont...@un.org>> wrote:
>
> I eventually found on-the-ground images of the feature I would
like to propose / map.


are these suggested to be represented as polygons? How would the
border be determined? I looks from the imagery as if there is a
smooth transition of these „features“ and neighbouring land which
isn’t completely bare. Did you try to map some of these and if
yes, could you please post a link to an area where a few are mapped?

Transitions from, say, trees to shrubs also occur. The guide is to map 
what is dominate, when domination changes is where the 'border' is. OSM 
does not have tagging for mixed areas, if you want it .. propose it?



Cheers Martin 



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

Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

[Warin]

On 8/8/20 10:54 am, Andy Townsend wrote:

Hello,

This is a question that actually arose out of a "how to tag" argument 
that's come to the attention of the DWG in the USA, but it's actually 
easy to describe in terms of data in the UK that I'm familiar with, so 
I'll do that.


https://www.openstreetmap.org/node/12004813 is a 
"public_transport=stop_position" for a local station and is part of 
https://www.openstreetmap.org/relation/6396491 among other relations.  
The problem is that train lengths vary, and there are a number of stop 
positions, each of which are actually signed on the platform for the 
benefit of the drivers.  From memory I think that there's at least a 
2-car stop, a 4 car stop and 6/8 and 10/12 car stops.  The problem is 
that the current node doesn't correspond to any of them.



Why is the front of the vehicle (bus, train, ferry.. and possibly 
others) mapped?


Would it not be better to map the thing most usefull to most people? 
That would be where passengers get on/off, on multiple exit vehicles 
like train then the average of these positions could be used.


Trains here of varying lengths tend to place the middle of the train at 
the middle of the platform - thus it is consistent for any train length. 
The only exceptions are where the platform is shorter than the train so 
the train stops such that the designated car/carriage is centered on the 
platform - thus it is still a consistent location for OSM.





Maybe the "correct" answer is none of the above?  With a "local 
mapper" hat on I've managed to avoid PTv2 since it basically isn't 
relevant anywhere I normally map things, largely because I don't tend 
to do that near any actual public transport infrastructure, but with a 
DWG hat on I haven't been able to avoid the question, hence me asking 
here.



I have mapped a few bus routes and 'corrected' some PTV2 trains... but 
I'd not hold them up as 'best' examples... only ones that are 'better' 
than what was there before and probably the simplest way that I could 
see to do it.



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

Re: [Tagging] Feature Proposal - RFC - Takeaway drinks shops

[Warin]

On 8/8/20 8:29 am, Martin Koppenhoefer wrote:

I still believe shop=bubble_tea is suitable, as these are specific shops where 
you can get only bubble tea. Although bubble tea is something to drink, I would 
rather think of it as a specific kind of sweets, than as a shop where you can 
get a beverage.
Amenity could also be suitable, if you prefer this, especially if the shop is 
welcoming customers to sit down and consume on the premises.



Not all shop=* welcome customer consumption. e.g. shop=supermarket, 
greengrocer, chocolate, convenience.

Shop is a much more specific key compared to the key amenity, I think being 
more specific is a good thing and would support shop over amenity where it is 
applicable.

 




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

Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

[Warin]

On 10/8/20 7:06 pm, Ture Pålsson via Tagging wrote:
Here in Stockholm, trains seem to line up one end of the train with 
one end of the platform. Usually, that's the end where the entrance 
is, but sometimes there are entrances at both ends, so if you arrive 
just in time at an unfamiliar station and find that it's a short 
train, you may be in for a run...



A good reason to map that end in OSM.

So 'local variations' maybe needed.


(BTDT, with a day hike rucksack...)



A day hike is not much of a load.

An overnight hike is a little more, 7 days more still. 10 days is my 
limit... too heavy after that.




2020-08-10 09:20 skrev Warin:

[...]
Why is the front of the vehicle (bus, train, ferry.. and possibly
others) mapped?

Would it not be better to map the thing most usefull to most people?
That would be where passengers get on/off, on multiple exit vehicles
like train then the average of these positions could be used.

Trains here of varying lengths tend to place the middle of the train
at the middle of the platform - thus it is consistent for any train
length. The only exceptions are where the platform is shorter than the
train so the train stops such that the designated car/carriage is
centered on the platform - thus it is still a consistent location for
OSM.


___
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] Fwd: Re[2]: PTv2 public_transport=stop_position for stop positions that vary based on train length

[Warin]

On 11/8/20 9:25 am, 80hnhtv4agou--- via Tagging wrote:
one of the points that i talked about, that no one has answered yet is 
what about someone not local

who just puts 400 + unverified stops on platforms and there all wrong.


If you find something wrong - correct it.


If the things mapped are deceitful, malicious etc then report it to the 
DWG to prevent more of the same.


If the things mapped are better than what was there before then I would 
call them improvements and thus beneficial, no point in being upset by it.


Being local is not a requirement to map, get over it. Local knowledge is 
beneficial as it aids mapping things that have local characteristics - 
like where trains stop.


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

Re: [Tagging] Fwd: Re[2]: PTv2 public_transport=stop_position for stop positions that vary based on train length

[Warin]

On 11/8/20 1:11 pm, 80hnhtv4agou--- via Tagging wrote:

the train or trains do not stop where he says they do,

Do they stop at the platform? Yes.
So stop positions maybe mapped.


and i am talking about 400 +,
unverified platforms. which is 200 + stations,
Unverified? Verified by the existing signs? This maybe 'out of date' but 
still verifiable.


How 'inaccurate' are the present stop positions?
How precise is the mapped position required?

Were there stop positions there before?

Is it not better to have some indication rather than nothing?



"They will stay there for ever" unless someone improves them.




Monday, August 10, 2020 9:33 PM -05:00 from Warin
<61sundow...@gmail.com>:
On 11/8/20 9:25 am, 80hnhtv4agou--- via Tagging wrote:

one of the points that i talked about, that no one has answered
yet is what about someone not local
who just puts 400 + unverified stops on platforms and there all
wrong.


If you find something wrong - correct it.

If the things mapped are deceitful, malicious etc then report it
to the DWG to prevent more of the same.

If the things mapped are better than what was there before then I
would call them improvements and thus beneficial, no point in
being upset by it.

Being local is not a requirement to map, get over it. Local
knowledge is beneficial as it aids mapping things that have local
characteristics - like where trains stop.




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

Re: [Tagging] tourism=caravan_site versus tourism=camp_site: camping with a tent

[Warin]

On 15/8/20 4:49 am, Hidde Wieringa wrote:


Good day,

I am having trouble with the tourism tags caravan_site and camp_site, 
specifically for the use case of finding a place to camp with a tent 
(so not a caravan or a camper van).


My goal is to differentiate the two tags. Both tags allow tents, and 
both allow camper vans and caravans. Both tags may or may not provide 
facilities such as toilets, water, electricity, et cetera. In 
practice, the only thing that differentiates a pitch for a tent versus 
a pitch for a caravan or camper van, is the ground underneath (tents 
require some sort of soft material like grass). This differentiating 
property is not mentioned at all in the Wiki.


- The tag tents=yes/no (only listed in the camp_site Wiki) would be a 
good way to find a place to camp with a tent, but almost none of the 
caravan_site have this tag. All camp_sites in OSM I have camped on, 
allowed tents.
- Some of the caravan_site have been tagged with amenity=parking or 
even surface=asphalt and this would mean that camping with a tent is 
definitely not possible.
- I noticed that both of the tags have status 'de facto', and no 
proposals have been made for the definition of said tags. I found an 
abandoned proposal [1] that has a good discussion about camping [2].
- Some camp_sites have a 'nested' polygon with a caravan_site. This 
seems logical, and the caravan_site can be ignored, and the camp_site 
can be used for camping with a tent.


Statistics from TagInfo: camp_site has ~100,000 uses, and caravan_site 
has ~30,000 uses.


I ran a quick Overpass query for a small number of caravan sites (~15) 
[3]. Some of them note on their website that camping with a tent is 
possible, and the surface of the pitches seems to be grass. I am 
wondering if these should be re-tagged as camp_site, or if I am 
missing something.


My opinion would be that a camp_site should allow staying overnight 
with many types of vehicles/tents, indicated by the tags listed 
clearly on the wiki of camp_site. A caravan_site would allow staying 
overnight with vehicles only, and not allow camping with a tent. 
Concretely the sentence "They may also have some space for tents." on 
[4] is the problem. Replacing the sentence on the wiki with "Camping 
with a tent is not possible." would remove any ambiguity 
differentiating these tags.


Any comments are welcome. I am willing to update the wiki or draft a 
proposal for differentiating these two tags, if necessary.


Kind regards,
/Hidde Wieringa/

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Extend_camp_site
[2] 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Extend_camp_site#caravan_site_separated.3F 

[3] https://tyrasd.github.io/overpass-turbo 


[4] https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcaravan_site



The web site https://opencampingmap.org/#10/48.6100/8.2400/0/1/bef is an 
attempt to encourage mapping of camp and caravan site attributes...



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

Re: [Tagging] tourism=caravan_site versus tourism=camp_site: camping with a tent

[Warin]

On 15/8/20 10:54 am, Graeme Fitzpatrick wrote:
But what do you do for a place, called a Camping Ground, that is a big 
area of grass, mostly without defined "pitches" & where you can camp 
anyway you like: sleep in your car; on the ground; in a tent / camper 
trailer / caravan / motorhome?



Local context. If you camp in some, most?, German camp grounds you are 
give a designated pitch and 'must' only use that pitch. Adels Grove in 
Queensland, Australia also use the same system. But most Australian camp 
ground allow you to pitch anywhere.



For the anywhere and anything camp grounds, tents=yes and caravans=yes 
fit... IIRC there was something for camper trailers? There is nothing 
for car_camp=yes/no as yet.



While tents=yes/no works and is acceptable tent:capacity=* is more 
detailed. For most Australian camp grounds the capacity would be hard to 
determine, so I just use tents=yes/no.




Any period is acceptable, from one night only up to "by discussion 
with management", although permanent residents aren't allowed.


Thanks

Graeme



On 14. Aug 2020, at 22:24, Martin Koppenhoefer
mailto:dieterdre...@gmail.com>> wrote:


Both tags allow tents, and both allow camper vans and caravans.



interesting, I would have expected a caravan site to not permit
tents by default.



actually the caravan site puts it a little differently than the
above summary:

“ They may also have some space for tents. If a site is primarily
for tents, it should be tagged as tourism
=camp_site
”




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

Re: [Tagging] Feature Proposal - Voting - kerb=regular

[Warin]

On 22/8/20 12:56 am, Supaplex wrote:


I see that I have probably chosen an unfavorable solution to solve the 
problem described. Many seem to accept the basic problem: There is 
only one qualitative category for all kerbs with a height of over ~3 
cm, although in reality there is a significant difference.


I see two alternatives to the proposed solution:

a) (as suggested in the vote section) Deprecate the category "raised" 
and introduce two /new/ values ​​to differentiate it (eg "heightened" 
vs. "regular" or "medium" if there is sematic criticism of "regular")
b) Keep the existing categories, accept that the term "raised" has so 
far included both normal and raised kerbs and merely introduce an 
explicit tag to distinguish /actually/ raised kerbs (e.g. "heightened").


What do you think? Any other or further suggestions?



Rather than use words that are relative to personal perceptions .. why 
not use numbers to say what you mean?



 curb:height=under_3_cm

curb:height=over_3_cm

 curb:height=3_cm_to_10_cm

curb:height=8_cm_to_15_cm


Would that be acceptable? It avoids the words and is readily understood. 
It could lead to people inserting new values... but that is always the 
case, at least with the numbers the new values would be understood.



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

Re: [Tagging] Hands Off !, respect my (our) space

[Warin]

Off list.

This has ABSOLUTELY NOTHING TO DO WITH THE TAGGING LIST.

Desist.

On 25/8/20 12:50 am, 80hnhtv4agou--- via Tagging wrote:
In ID, on your profile page is, Other nearby users, and the home 
location, map
the point is other locals based on my (our) edits know where we 
(I) live, but come on

don’t edit the building i (we) live in !

___
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] Hands Off !, respect my (our) space

[Warin]

On 25/8/20 11:37 pm, Matthew Woehlke wrote:

On 25/08/2020 06.04, Paul Allen wrote:

On Tue, 25 Aug 2020 at 06:38, Warin wrote:

Off list.


It looks like you accidentally Bcc'd the list.


It looks like Warin tried to send it to "80hnhtv4agou---" without 
noticing that address is a spoofed¹ tagging@OSM.



Apologies to the list members.

I'll have to be more careful in future of these less than helpful headers!

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

Re: [Tagging] tagging for fairgrounds

[Warin]

On 28/8/20 8:05 am, Graeme Fitzpatrick wrote:




On Fri, 28 Aug 2020 at 05:31, Richard Welty > wrote:



again in the US, state and county fairgrounds are permanent facilities
which function as event space when the fair is not actually going on.
the midway is usually temporary, but the buildings for, say,
agricultural exhibits are permanent, as is the race track (at many
fairs), which might be for horses or cars.


As Phil said for the UK, in Australia they are Showgrounds, with just 
about every country town having their own.


As per your description, the show is usually only on for one weekend a 
year, but there are permanent buildings & facilities on site, & the 
area is  frequently used as a caravan / tourist park for the rest of 
the year.



In Australia:

"The Show" (where ever it is) as Graeme says, is once a year for a week 
or two. However other events are also held at the same venue.


For example via a quick web search, the Mt Isa Show 1 week per year in 
June, Mt Isa Roedo 1 week per year in August, Mt Isa Motor Show and Swap 
Meet 1 day per year in August and there are others.


Presently in OSM as a recreation ground as Way: Buchannan Park 
Racecourse 455194137. I would assume racing takes place here as well as 
the above 'shows'.



The few I've just checked are currently tagged with a mixture of 
either leisure=park or landuse=recreation_ground. Personally, of the 
two options, I'd prefer rec. ground, which I notice a few of your 
samples were also tagged as.


Thanks

Graeme



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

Re: [Tagging] Rail segment in a bike route

[Warin]

On 31/8/20 8:25 am, Volker Schmidt wrote:

Keep it simple, if the simple solution does not limit you.



Agreed. I see no reason why a way as a member of a simple route relation 
could not have the role 'transport'.




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

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

[Warin]

On 27/9/20 5:51 pm, Mateusz Konieczny via Tagging wrote:

I am a bit dubious about value of updating fire=perimeter

It is something that changes extremely quickly, we should
not encourage people to survey perimeter of ACTIVE fire,
OSM is doomed to be strictly worse source of fire perimeter
than alternative sources

> fire has absolutely enormous impact to what we do and might map here,
both present and future. The aftermath of this fire (>85,000 acres 
this fire alone)

will last for decades, and for OSM to not reflect this in the map



The Australian fires have less long term significance as most of the 
flora has mechanisms to cope with fire, some even needs fire to propagate.




Obviously, we should (try to) update map where situation changed.



We don't mapped parked vehicles unless they are 'permanent', same should 
be adopted for fires, floods, earth quakes and volcanic eruptions.


If there is no permanent effect then mapping it is at best a temporary 
thing.





Delete building that will not be rebuild (mark them as 
destroyed:building=*

until aerial imagery will update)
[deleting buildings and remapping them as they get reconstructed may
be viable in cases of heavy mapper presence]

Delete other permanently destroyed objects and so on.

> Do we have landcover tags which could replace landuse=forest
or natural=wood with something like natural=fire_scarred?

AFAIK nothing established, see
https://lists.openstreetmap.org/pipermail/tagging/2018-March/035435.html
for related discussion about wind damage.



Note:

While you state "landuse=forest is used to tag tree covered area, not 
for how land is used" others disagree with this statement and use the 
tag to indicate how the land is used as would be indicated by the key 
'landuse'.


There is already a tag for a tree covered area "natural=wood" and that 
is a better tag to use for tree covered areas.


Continued use of the key 'landuse' for things other than true land use 
will simply result in the continued denigration of the key with things 
like landuse=sand, landuse=scrub, landuse=mud and so on.




Sep 24, 2020, 23:30 by stevea...@softworkers.com:

I didn't get a single reply on this (see below), which I find
surprising, especially as there are currently even larger fires
that are more widespread all across the Western United States.

I now ask if there are additional, appropriate polygons with tags
I'm not familiar with regarding landcover that might be added to
the map (as "landuse=forest" might be strictly true now only in a
'zoning' sense, as many of the actual trees that MAKE these
forests have sadly burned down, or substantially so).

Considering that there are literally millions and millions of
acres of (newly) burned areas (forest, scrub, grassland,
residential, commercial, industrial, public, private...), I'm
surprised that OSM doesn't have some well-pondered and actual tags
that reflect this situation. My initial tagging of this (simply
tagged, but enormous) polygon as "fire=perimeter" was coined on my
part, but as I search wiki, taginfo and Overpass Turbo queries for
similar data in the map, I come up empty.

First, do others think it is important that we map these? I say
yes, as this fire has absolutely enormous impact to what we do and
might map here, both present and future. The aftermath of this
fire (>85,000 acres this fire alone) will last for decades, and
for OSM to not reflect this in the map (somehow, better bolstered
than a simple, though huge, polygon tagged with fire=perimeter,
start_date and end_date) seems OSM "cartographically misses
something." I know that HOT mappers map the "present- and
aftermath-" of humanitarian disasters, I've HOT-participated
myself. So, considering the thousands of structures that burned
(most of them homes), tens of thousands of acres which are
burn-scarred and distinctly different than their landcover,
millions of trees (yes, really) and even landuse is now currently
tagged, I look for guidance — beyond the simple tag of
fire=perimeter on a large polygon.

Second, if we do choose to "better" map these incidents and
results (they are life- and planet-altering on a grand scale) how
might we choose to do that? Do we have landcover tags which could
replace landuse=forest or natural=wood with something like
natural=fire_scarred? (I'm making that up, but it or something
like it could work). How and when might we replace these with
something less severe? On the other hand, if it isn't appropriate
that we map any of this, please say so.

Thank you, especially any guidance offered from HOT contributors
who have worked on post-fire humanitarian disasters,

SteveA
California (who has returned home after evacuation, relatively
safe now that this fire is 100% contained)


On Aug 29, 2020, at 7:20 PM, stevea  wrote:

 

Re: [Tagging] How to tag for dualband GPS ?

[Warin]

On 30/11/20 8:45 am, Andrea Mazzoleni wrote:

Hi,

I bought a tracking device that supports GPS dualband (also called 
dual frequency) for high precision mapping, and I'm wondering if I can 
put this information in the "source" tag.


The intention is to make future mappers consider the device precision 
when doing corrections.


Sigh.

If the intention is to indicate the error/accuracy/uncertainty then 
tag/state that. The better GPS devices give indications of this 
error/accuracy/uncertainty.


As the error/accuracy/uncertainty varies with the topography, satellites 
presently in view and the capabilities of the GPS device a statement of 
the GPS device capabilities revel little about the actual on the ground 
situation at the time of survey. Some of these 
error/accuracy/uncertainty can be reduced by taking many GPS tracks over 
several days/week/months and obtaining an average that excludes 
outliers. If possible take tracks of home to/from work and compare them 
to see how much they vary day to day ... they should give an idea of 
problem.


In some locations the topography gives reflected signals that produce 
false GPS tracks, in these areas imagery may well be better than survey 
by consumer GPS even with dual band and many constellations are used.




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

Re: [Tagging] COVID-19 vaccination centres

[Warin]

On 19/11/20 6:59 am, Tom Pfeifer wrote:
With the first Covid-19 vaccines getting approved, many municipalities 
are planning facilities for administering mass vaccination. In Berlin, 
the two former airports Tegel and Tempelhof are planned,

along with some sports facilities.

This raises the question for appropriate tagging.



In Australia, and I would think a portion of the world, there are yearly 
vaccinations for the flu. We don't tag them as they are available from 
the local GP/doctor and even some pharmacies in Australia, so they are 
'expected'.


The  existing facilities cope with the yearly flue vaccine though I hope 
the participation rates are better for the COVID vaccine.


COVID testing centers have also been setup ... but these are usually in 
place for short periods of time and then move or are disbanded waiting 
for the next problem area to occur. Being short term they don't go into 
OSM.


How  long are these mass vaccination centers going to operate for?

I would assume the location of these mass vaccination centers would be 
widely publicized and the locations identified. Do they need further 
identification within OSM?



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

Re: [Tagging] How to tag for dualband GPS ?

[Warin]

On 1/12/20 7:46 am, Andrea Mazzoleni wrote:


I recently wrote a series of diary entries about my experience
with the accuracy of one-device GPS precision. I concluded with a
comparison of three devices I had personal experience with
including a new Garmin GPSMAP 66sr which I posted here:
https://www.openstreetmap.org/user/bobwz/diary/394711

Very interesting!

Here you can find the mapping of my tests with GPSMAP 65s and eTrex 30x:

https://ibb.co/bKvpxYG

It's a circular trail repeated 5 times with one point every second.

I repeated it again with the recording frequency set to Auto, and the 
GPSMAP lost a bit in accuracy, so better to stick to one point every 
second.



Think your confusing two terms;

resolution


accuracy


With increased points along a way there is increased resolution.

The accuracy does not follow with increased number of points unless they 
are all for the same location so averaging those points reduces noise 
thus increasing accuracy.




On Mon, Nov 30, 2020 at 3:45 PM Lindsay Barnes <mailto:newsspea...@gmail.com>> wrote:


I recently wrote a series of diary entries about my experience
with the accuracy of one-device GPS precision. I concluded with a
comparison of three devices I had personal experience with
including a new Garmin GPSMAP 66sr which I posted here:
https://www.openstreetmap.org/user/bobwz/diary/394711

In short, multi-band and multi-GNSS devices do offer in an
increase in precision and accuracy and we're seeing this become
more common in a standard smartphone. However, that level of
precision is not necessary in most cases. It is most helpful in
areas without good satellite imagery coverage or where imagery
lacks reference points (like in wooded trail areas, as mentioned).
This is compounded by the fact that one GPS device has a floor to
how accurate it can be due to the nature of the system and
interference from the natural landscape, as was mentioned.
Furthermore, mult-band and mult-GNSS chips are becoming more
common in smartphones and I would expect this level of precision
available to most mappers without the need for specialty equipment
over the next 5-ish years.

To answer your question about tags, a comment can be added in the
source field of a changeset, but in my opinion most mappers will
not dig too deep into a change to determine how precise the mapper
may have been . Satellite imagery is generally used as the source
of truth and if a mapped feature varies substantially from the
imagery, mappers are inclined to move the feature to match imagery
without researching how the feature was initially created. The
good news is that if satellite imagery in unclear or lacks
reference marks, mappers will usually leave features alone unless
they have personal knowledge of an area or are working off a
tasking manager.

On Mon, Nov 30, 2020 at 8:36 AM Andrea Mazzoleni
mailto:amadva...@gmail.com>> wrote:

On Mon, Nov 30, 2020 at 12:27 PM Warin <61sundow...@gmail.com
<mailto:61sundow...@gmail.com>> wrote:

If the intention is to indicate the
error/accuracy/uncertainty then tag/state that. The better
GPS devices give indications of this
error/accuracy/uncertainty.

The big advantage of the dualband is not (only) the increase
in accuracy but the ability to work in not optimal conditions,
like under a clif or other obstacles where you have reflected
GPS signals.

To give you an example, my eTrex device reports 3m of
precision, the new GPSMAP 65s reports 1.8m.
But reality is that I saw errors up to 50m with the eTrex.
It's also difficult to know the precision because it changes
while moving, and it's not recorded in the track.

If possible take tracks of home to/from work and compare
them to see how much they vary day to day ... they should
give an idea of problem.

I bought that new device exactly due the frustration of always
seeing a different recording...

My initial tests are really encouraging. Yesterday I repeated
10 times a trail under the woods of a hill, comparing the
results of the eTrex and GPSMAP 65s, and the dualband one has
the recorded tracks a lot more consistent. Something like 10m
vs 2m thickness.

imagery may well be better than survey by consumer GPS

I agree. Where an image is available I always use it as
reference. But most of the trails of my local area are under
the woods (low mountain) and the GPS is the only source of
information.



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

Re: [Tagging] Animal trails

[Warin]

On 1/12/20 10:36 am, Lukas Richert wrote:


I wouldn't tag this as foot=no or access=no. There are many trails in 
my area that are clearly animal tracks and seldom used by people - but 
it is allowed for people to walk on these and they are sometimes 
significant shortcuts so allowing routing over them in some cases 
would be good. However, they should be lower priority than real paths.


- Lukas

On 30.11.20 23:06, Paul Allen wrote:
On Mon, 30 Nov 2020 at 21:45, Brian M. Sperlongano 
mailto:zelonew...@gmail.com>> wrote:


Note that there is already an animal=* tag for describing things
related to animals, so that probably shouldn't be overridden. 
Perhaps a combination of foot=no and animal=yes satisfies what
we're describing?


 Or not:highway=path + note=animal trail.

--



I think these are called 'animal pads'? They are usefull for hiking 
where no other path exists as they avoid further damage to vegetation 
and damage to pants/gaiters/shoes. They do also lead hikers astray by 
leading away from the path that they should use. Possibly highway=pad or 
highway=animal_pad?


The tags 'note' and 'comment' are for mappers and not usually used by 
renders, using the tag 'description' may be more helpful?


The tag 'access' should be used where access is restricted within OSM. I 
don't think it is necessary to have signage on the ground to apply 
access tags that are 'community standard' e.g. most home driveways in 
Australia would be regarded as access=private and should be tagged as 
such within OSM despite there being no sign on every home driveway.


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

Re: [Tagging] COVID-19 vaccination centres

[Warin]

On 1/12/20 12:24 am, Martin Koppenhoefer wrote:


sent from a phone


On 30. Nov 2020, at 12:56, Warin <61sundow...@gmail.com> wrote:

I would assume the location of these mass vaccination centers would be widely 
publicized and the locations identified. Do they need further identification 
within OSM?


the same holds true for post offices and townhalls.



Err no. I would expect mass vaccination centers to be heavily publicized in the 
local press (TV, radio, newspapers, etc) with location, opening hours, and 
other operating details
where as the townhall could be mentioned occasionally in the press as part of a 
news articular but without any location and opening hours information.
Post offices here only appear here in advertising brochures and these are 
general in applying to all, they don't give any location information at all.

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