Re: [Tagging] breads of bakeries

[OSM]

Hi,

Am 03.05.2024 um 09:27 schrieb Frederik Ramm:

In general, I would advise against trying to record which products are
offered in any kind of shop, as this is likely to change often and
lead to bitrot.

Only map such detail if you are very likely to spot any change in the
future, and will be able to record it. (E.g. it is the bakery you go
to every week.)


+1

As a mapper I would like to add more information too - as I am
interesting in these as user too.
But as a travelling user I still have do too much work on updating the
basics:
- a POI that does not exist in OSM
- and more often a POI - and bakeries are searched very often by me -
that does not exist in reality anymore ... or changed its purpose.

Bye
Georg

--
Diese E-Mail wurde von AVG-Antivirussoftware auf Viren geprüft.
www.avg.com

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

[Tagging] [RFC] Feature Proposal - Deprecating demolished railway tags

[Ewrt1 OSM]

This proposal aims to deprecate all Demolished Railway tags.
https://wiki.openstreetmap.org/wiki/Proposal:Deprecating_demolished_railway_tags
Please discuss this proposal on its Wiki Talk page.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] [RFC] Feature Proposal - Details of construction

[Ewrt1 OSM]

This proposal aims to detail construction projects in OpenStreetMap.
Link: https://wiki.openstreetmap.org/wiki/Proposal:Details_of_construction
Please discuss this proposal on its Wiki Talk page.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] [RFC] Feature Proposal - Types of highway construction (2)

[Ewrt1 OSM]

This proposal will detail the types of highway construction.
Please view the proposal on the 
wiki.

Please discuss this proposal on its Wiki Talk page.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[OSM]

Am 11.09.2023 um 23:39 schrieb Graeme Fitzpatrick:

Not arguing, but

oneway:foot = 5024
foot:backward = 394
foot:forward = 300

Personally, I would interpret that as time that the wiki had a 
rewrite! :-)


Voted by their "foot" ... ;-) - and I used it too ...
But it is already rewritten:

On Mon, 11 Sept 2023 at 19:19, Martin Koppenhoefer 
 wrote:


as „oneway“ is defined for vehicles only, „oneway:foot“ doesn’t
make a lot of sense. The wiki suggests „foot:backward“ or
„foot:forward“ as alternatives that follow the generic way of
tagging restrictions.



That is the official way - but it will be a long way until the "foot" 
will arrive there ...


--
Diese E-Mail wurde von AVG-Antivirussoftware auf Viren geprüft.
www.avg.com___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Imgur links in OSM data has been backed up

[osm]

Hi, I already mentioned it on the forums but might be good to mention it here 
as well.

For contenxt: the image hosting website Imgur announced last month they 
announced a policy change so that they can delete imges uploaded without a user 
account. 
https://help.imgur.com/hc/en-us/articles/14415587638029-Imgur-Terms-of-Service-Update-April-19-2023-
The Openstreetmap database actually contains about 19712 imgur links.

So I've made a script that extracts all Imgur links from the OSM database, 
using taginfo. And I downloaded all of them tip a zip file.

All is available on my Github repo here: 
https://github.com/thibaultmol/OSM-image-archiver



There's already people looking into alternatives (for example, the Mapcomplete 
application uses the Imgur api to upload the images (without a user account)) 
but it's still WIP


Cheers,
Thibault

publickey - osm@mail.thibaultmol.link - 0xE9A7DEC8.asc
Description: application/pgp-keys


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

Re: [Tagging] Deprecate water=pond?

[OSM]

Am 11.11.2020 um 18:25 schrieb Peter Elderson:
I am getting a foot vs hiking feeling. Everybody knows a difference, 
nobody has the same difference. In the end, it does not matter.


Hmm - does it matter, if it is a river or a stream or a lake or a pond?
Especially a lake with a river flowing through?
Or is it not all and everything only water - and a name somewhere ...
Why does the water=* tag exist anyway? To distinguish between flowing 
and standing waters? Don't say so - see above.


--
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com


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

Re: [Tagging] Deprecate water=pond?

[OSM]

Maybe there is no clear-cut between a lake and a pond - but for me there 
is at least a clear impression by size of a pond or a lake beyond the 
transition zone.
I never would call a natural small water or a 'Gartenteich' (garden 
pond) a lake.


--
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com


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

Re: [Tagging] What does bicycle=no on a node means?

[OSM]

Am 15.10.2020 um 22:18 schrieb Emvee via Tagging:

This recent wiki change by Emvee
 is in my view not
helpful, or even misleading, as it does discourage a wide-spread
tagging practice (if we like this or not is a different question, but
it's established tagging, and the wiki is supposed to describe the
establsihed methods of tagging)


The change describes what a router does with bicycle=no on a node, see 
https://github.com/abrensch/brouter/issues/265


Already discussed elsewhere but having routers ignore bicycle=no in
combination with highway=crossing means that it is more or less
useless as routers are they main data consumers while at the same time
crossing data is far from being complete.

My take is that it is not a wide-spread tagging practice and it does
not add new information as weather it is a pedestrian issue can be
deduced from the connecting ways.



We still have the valid mapping practice, that sideways are mapped with
tags at the highway= with no seperately mapped ways.
Therefor we still have highway=crossing nodes _without_ a crossing way.
Some of these still have no bicycle crossing allowed.

How can/should a mapper map this 'new' information now?


--
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] railway=station areas

[OSM]

Am 10.10.2020 um 00:35 schrieb Dave F via Tagging:


I edited a copy of the diagram (A-simple-station.svg) of a station 
layout, primarily to remove any references to PTv2 tags, a completely 
independent, duplicating tagging schema, irrelevant to anything to do 
with the railway=station tag.


That is the main problem I think:
You think, that railway=* and PTv2 tags are duplicating tagging schemas.

But:
railway=* are _railway_ related tags - they are for infrastructure.
PTv2 tags are _public_transport_ tags - they are for the public 
transport use cases.


And yes - these both are truly different.

--
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com


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

Re: [Tagging] What does bicycle=no on a node means?

[OSM]

Am 10.10.2020 um 20:16 schrieb Emvee:



Basic question I think, for a bicycle router bicycle=no on a node
means it should "avoid" crossing the node likely by adding a moderate
penalty as the cyclist could make the choice to dismount passing the
node. I know at least on bicycle router implementing it this way, see
https://github.com/abrensch/brouter/issues/265

Really just by bicycle=no on a node?
It does not check for barrier=* first?
I think that would be a bad idea.


The check is just on bicycle=, see the end of
https://github.com/abrensch/brouter/blob/master/misc/profiles2/trekking.brf 



In the bouter github issue everybody (incl. the developer, but excluding
Mateusz) do expect bicycle=no on a node to mean bicyle=no in node 
context.



Question now is if this rule should be applied differently if it is
used in combination with highway=crossing.

At least I think so.

The recent "meaning of highway=crossing + bicycle=no" thread makes
the case that it means "you cannot use this crossing to cross road
while cycling, it does not affect legality of cycling on the road"

I think so. The main tag ist highway=crossing.


I see nothing like this mentioned on
https://wiki.openstreetmap.org/wiki/Key:access.

Do you know any other combination a tag with an access tag on a node
that means something else depending on from which way you enter it and
leave it?

I think you suggest ("It does not check for barrier=* first?") to have a
bicycle router ignore bicycle=* on nodes except in combination with
barrier=*. That would mean one could just remove bicycle=* as it is
largely useless, see my response on "other data consumers" elsewhere in
this thread.


I see this as common practice (for whom this crossing is meant).


An educated guess is that there are 3000 crossings mapped incorrectly
with bicycle=no of the 4.5 million crossings mapped, that is 0.07%. Much
less of a problem than other problems.


by giving the right access rights on the ways connecting to the node
all possible access scenarios can be covered.

That can be a solution for crossings.


It is a "solution" that makes bicycle=no on highway is crossing 
unnecessary.




How to solve the issue with a single crossing node at highway= 
without a crossing highway= because of "sideway 
tagging by tags on highway" mapping?


Sorry:
Why does my email program send the saving draft while I am still writing 
... does matter only to osm lists ... without asking for the outgoing 
password - heaven!


--
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com


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

Re: [Tagging] What does bicycle=no on a node means?

[OSM]

Am 07.10.2020 um 23:01 schrieb Emvee via Tagging:
Basic question I think, for a bicycle router bicycle=no on a node 
means it should "avoid" crossing the node likely by adding a moderate 
penalty as the cyclist could make the choice to dismount passing the 
node. I know at least on bicycle router implementing it this way, see 
https://github.com/abrensch/brouter/issues/265


Really just by bicycle=no on a node?
It does not check for barrier=* first?
I think that would be a bad idea.

Question now is if this rule should be applied differently if it is 
used in combination with highway=crossing.


At least I think so.

The recent "meaning of highway=crossing + bicycle=no" thread makes the 
case that it means "you cannot use this crossing to cross road while 
cycling, it does not affect legality of cycling on the road"


I think so. The main tag ist highway=crossing.
I see this as common practice (for whom this crossing is meant).

I think this is a bad idea as that way the access can not be evaluated 
in node context (a router would have to look at the incoming and 
outgoing way) while adding bicycle=yes/no to a crossing node does not 
give "additional possibilities";


You can check the simple node context - as a bicycle=no (should) never 
stand alone on a node.


by giving the right access rights on the ways connecting to the node 
all possible access scenarios can be covered.


That can be a solution for crossings.

Georg



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

Re: [Tagging] Linking Sidewalks to Highways

[OSM]

Sorry sorry for the noise - I dont know, who pushed the send button that 
often ...

Georg

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

Re: [Tagging] Linking Sidewalks to Highways

[OSM]

Am 21.09.2020 um 14:54 schrieb Paul Allen:
On Mon, 21 Sep 2020 at 11:06, Supaplex > wrote:


The problem remains that physically non-existent road crossings
("wildly crossing the street"), which in reality represent a
crossing possibility for many users, are still not available for
routing. In my opinion, this problem is not very relevant if
separate ways are well mapped (which they often are unfortunately
not!) and all essential routable connections are in the database.
At the beginning and at the end of the route, people can use their
brains ("destination across the street") if their routers do not
solve this task for them.


This isn't as simple as you make out.  Assume that I am at point A and 
wish to
go to point B, which involves a "wild crossing" at some point between 
the two.
However, there is a real crossing at point C, a mile beyond point B,  
A router
will direct me to travel to point C (a mile further than my 
destination) in order

to cross the road there, so I can then walk a mile back to B.


You really walk a mile beyond and back again, knowing your destination 
is - say 10-20 m - across the street?

Or do you not know that your destination is at the street you walk along?

I call those assumes a 'theoretical island problem'.
a) Your point A is as near at point B, that you know or can estimate 
where you have to cross.
b) Your point A is so far away from point B , that there is - or at 
least should be mapped - another possible crossing before ('virtual' 
connection at a T-crossing or similar) .
c) Most routers have a display - and the view should show your 
destination (or route path to) across the street.


Maybe my view of a) and b) is a bit european centric - but I assume 
foreign cities would match and for foreign countrysides the seperate way 
problem would not apply.


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

Re: [Tagging] OHV greater than 50 inches (wide)

[Robert Whittaker (OSM lists)]

On Tue, 1 Sep 2020 at 21:33, Mike Thompson  wrote:
> In specifying access constraints for the roads it manages, the US Forest 
> service makes a distinction between ATVs, highway vehicles, and "OHVs > 50"."
> The first two categories correspond to the tags motorcar=* and atv=* I think, 
> but I have not been able to find an existing tag that corresponds to "OHVs > 
> 50"."  There is an ohv=* tag, but it seems to apply to all OHVs regardless of 
> width as well as motorcycles.

Have you looked at conditional access restrictions:
https://wiki.openstreetmap.org/wiki/Conditional_restrictions ?

If ohv=* is understood as an access tag (though it doesn't appear at
https://wiki.openstreetmap.org/wiki/Key:access ), then you could e.g.
do something like ohv = no + ohv:conditional = yes @ (width > 50") to
allow OHVs only if they are wider than 50".

-- 
Robert Whittaker

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

Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

[Robert Whittaker (OSM lists)]

On Thu, 19 Mar 2020 at 14:43, Tobias Wrede  wrote:
> Isn't the addr:* scheme used to describe the physical address of a 
> location/building/amentiy/etc.?
>
> PO Boxes, privat bags etc. are addresses where mail for someone residing at 
> said location is delivered to.
>
> As addr:* I would always put in what is needed to find the place as a visitor 
> and that is a housenumber and street, a house name or any other place name. 
> And sometimes there might be nothing besides city or postcode.
>
> Mail delivery address I would expect to find under the contact:* scheme if at 
> all.

Those would be my thoughts too.

Robert

-- 
Robert Whittaker

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

Re: [Tagging] Feature Proposal - RFC - survey_point:benchmark

[ITineris OSM]

Hi,

 

I need help in tagging a special kind of survey points: geodesic towers.

A new tag may help some.

 

These are tubular concrete structures, with usual steel triangulation tripods on their top.


They have the precise benchmark on the ground level, the tower is erected so that it's visible from far, being higher than the trees around.
They form the base of the national reference grid.
 

http://ballon.hu/wp-content/uploads/2017/12/2017-12-23-12.39.37.jpg

http://karpat-medence.hu/keptar/galleries/Magyarorszag/Fejer/Perkata/Geotorony/perkata-geotorony_02.jpg

 

They could be tagging as man_made=survey_point because their main purpose is being a geodesic reference point.

However, they could be a man_made=tower, for being a tower emerging from the surface - and to distinguish it from brackets, benchmarks or pavement rivets.

Furthermore, additional functions can be connected to the latter only:

Some of them are tourist attractions, like this viewpoint. It is a tower:type=observation.

If it's rigged with GSM and microwave antennae, it's tower:type=communication.


 

(And of course you may add the triangulation_point=yes tagging.)

 

So how would you tag them?

 

Greets,
Ákos


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

Re: [Tagging] Public refrigerators

[Robert Whittaker (OSM lists)]

On Tue, 25 Feb 2020 at 15:47, Markus  wrote:
> I've noticed that recycling:food= has been added [1] to
> amenity=recycling wiki page with the meaning "community fridge [2] to
> help reduce food waste".
>
> [1]: 
> https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Drecycling&diff=1908674&oldid=1906084
> [2]: https://en.wikipedia.org/wiki/Community_fridge
>
> In my opinion, it's not a good idea to tag community fridges (public
> refrigerators) amenity=recycling, because containers for recycling or
> reuse are only for depositing and not for picking up. What if there
> are also containers where food can only be deposited, but not picked
> up (similar to containers for clothing donations)? We couldn't tell
> them apart any more.
>
> As we already use amenity=public_bookcase and amenity=give_box for two
> very similar facilities, it seems better to use something like
> amenity=public_refrigerator or amenity=community_fridge.

I agree with your thoughts re not using amenity=recycling. I've tagged
a couple of Community Fridges near me as

amenity=social_facility + social_facility=community_fridge

as this tagging (although not documented anywhere) mirrors that for
Clothing Banks, Food Banks and Soup Kitchens, which are listed at
https://wiki.openstreetmap.org/wiki/Key:social facility , and seem to
be related sorts of things. (Though I'm not sure how much these
community fridges are designed to provide useful items for those in
need, versus just help reduce waste versus. The balance is probably
slightly different for each implementation.)

Robert.

-- 
Robert Whittaker

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

Re: [Tagging] eelgrass

[Jerry Clough - OSM via Tagging]

Apologies for top-posting, but the interface in the browser does not enable me 
to make any sense of multiple comments. Anyway here goes:
Zostera (eel-grass) grows below the tide line, so really is not an emergent 
plant. Other things in your list of aquatic bed vegetation are also not usually 
apparent on the surface (e.g., Chara). Some such as Kelp will be visible at the 
lowest tides. I don't think any of these sensibly qualify for the current 
natural=wetland tag, which implicitly connotes emergent vegetation typically on 
a land surface which can dry out. Some emergent vegetation will have it's foot 
in the water, but water depth will be shallow (typical Phragmites beds). I'd 
suggest considering a new tag for submerged vegetation in marine environments.
At this point I'm not sure about freshwater vegetation which is totally 
submerged (but see below).
For the detailed US classification of wetlands, this is what the 
plant_community tag is there for: more detailed, more scientifically precise 
categories. Obviously many of these are not easy for the average mapper to 
identify, but when information is available it is often a good way of enhancing 
the base tagging. I think there is also a US National Vegetation 
Classification. I've documented some parts of the UK equivalent, including one 
of the types of Alder Carr (equivalent to your Alder meadow).
Phragmites does grow in estuarine environments, with brackish water.
I learnt some years ago that German usage of reedbed (Rohr) includes other tall 
emergent plants: notably sedges (Carex), Cladium, reed-mace/cat's-tails 
(Typha), cane (Arundo) and club-rushes. PresumabThus the meaning of 
wetland=reedbed may well be wider than expected in some countries. One way to 
be sure is to add a dominant_taxon tag (e.g., Phragmites australis, Carex, 
Typha etc).
As for floating water plants (which I would not particularly class as emergent, 
including water-lilies) they can have odd life cycles. Some living on the bed 
of the water body when dormant and later floating during the growth season 
(Water Soldier & Frogbit). There are certainly places in France where a carpet 
of Duckweed coats the waterways during the summer. Unlike Kelp & Eelgrass beds 
(one a significant carbon sink, the other increasingly threatened) I've never 
felt the need to map such things (they are seasonal, and usually quite small 
features). Even something like Water Hyacinth which does form large patches is 
likely to change because of control measures.
Jerry

In Wednesday, 18 December 2019, 22:25:50 GMT, Kevin Kenny 
 wrote:  
 
 On Wed, Dec 18, 2019 at 2:08 PM Clifford Snow  wrote:
>
> How should eelgrass[1] be tagged? I see that wetland=reedbed [2]  has been 
> used in tidal areas mainly in Europe but also in the US but they are two 
> different plants.

Perhaps wetland_class=emergent or wetland_class=aquatic_bed? (How does
the eelgrass grow in the area you're considering?)

Thus saith 'Classification of Wetlands and Deepwater Habitats of the
United States' (https://www.fws.gov/wetlands/documents/classwet/index.html):

https://www.fws.gov/wetlands/documents/classwet/emergent.htm :
Definition. The Emergent Wetland Class is characterized by erect,
rooted, herbaceous hydrophytes, excluding mosses and lichens. This
vegetation is present for most of the growing season in most years.
These wetlands are usually dominated by perennial plants. All water
regimes are included except subtidal and irregularly exposed.


https://www.fws.gov/wetlands/documents/classwet/aquatic.htm
Definition. The Class Aquatic Bed includes wetlands and deepwater
habitats dominated by plants that grow principally on or below the
surface of the water for most of the growing season in most years.
Water regimes include subtidal, irregularly exposed, regularly
flooded, permanently flooded, intermittently exposed, semipermanently
flooded, and seasonally flooded.

Aquatic beds further divide into algal (e.g., kelp, rockweed,
stoneword), moss (e.g. Fisseidens, Fontinalis), rooted vascular
(Zostera would fall in this category), and floating vascular
(duckweed, water lettuce, water hyacinth, water-nut (Trapa), water
fern (Salvinia), bladderwort, and so on).

Rooted vascular aquatic beds occur in marine, estuarine, riverine,
lacustrine and palustrine systems

Some species, such as the water lily Nuphar luteum, are hard to
classify between 'aquatic bed' and 'emergent', since it usually grows
as lily pads, but occasionally stands erect above the water surface.
Some of the eelgrasses have the same difficulty in classifying.

The categories are always going to be fuzzy around the edges.

USFWS would therefore label your eelgrass bed - if I understand
correctly what you're trying to label - as "Marine, subtidal, aquatic
bed, rooted vascular"  while a typical reedbed might be "palustrine,
emergent wetland, persistent, dominant vegetation Phragmites spp." and
a typical alder meadow near me could be "palustrine, scrub-shrub
wetland, b

Re: [Tagging] Barrier=berm

[Tony OSM]

How do we know that 61 precious uses of the word berm all meant the 
same? without verifying each one .


The english wikipedia https://en.wikipedia.org/wiki/Berm allows

 * the level step element of raised barrier
 * raised element without a level element

An earthwork raised element with a way on top seems to be an embankment.

A earthwork raised element which has an armoured side seems to be a 
revetment - I can see no use of this in OSM., but it is in many books 
about castles and fortifications.


In my view earthworks in general could do with analysis to agree terms 
and usage, they do occur in many places and are large mappable features.


Tony

TonyS999

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

Re: [Tagging] Deprecating mini_roundabout

[Tony OSM]

I think deprecating mini_roundabout is incorrect.

Near where I live in Chorley England a 3 way junction was converted to a 
mini-roundabout to equalise the flow of traffic. The space available 
made a build roundabout impractical, and traffic lights would have been 
overkill. It works. It is different on the ground that a built 
roundabout (tin of poured paint versus brick and kerbing). The map is 
appropriately different - mini-roundabout has its own symbol whereas a 
roundabout is sized to reflect its actual size.


Understanding of mini_roundabouts (how to build complex junctions) and 
their distinctiveness may be helped by viewing


https://en.wikipedia.org/wiki/Magic_Roundabout_(Swindon)

and its OSM representation

https://www.openstreetmap.org/#map=18/51.56273/-1.76929&layers=N

The nearby Drakes roundabout is a large roundabout identified only by 
its shape


Regards

TonyS999


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

Re: [Tagging] Status of oneway=cw oneway=ccw

[osm]

I prefer that those complete newbies get to mess with only 1 or 2
members of route relations, at the relatively small price of ordering. 

Peter Elderson skrev den 03.05.2019 16:12:

> You prefer routes to stay unordered? Or that edits damage routes?
> 
> Vr gr Peter Elderson 
> 
> Op vr 3 mei 2019 om 16:08 schreef : 
> 
>>>>> For a non-roundtrip route consiting of two consecutive ways the route
>>>>> direction can be deduced from the order of the ways in the relation.
>>>> 
>>>> That's assuming the ways are ordered at all. I've cleaned up hundreds 
>>>> of routes (most created by Potlatch users though) and my advice is: do 
>>>> not rely on routes being ordered.
>>> 
>>> In OSM a relation is by definition an ordered list, see
>>> https://wiki.openstreetmap.org/wiki/Relation :
>>> "A relation is a group of elements. To be more exact it is one of the
>>> core data elements that consists of one or more tags and also an
>>> ordered list of one or more nodes, ways and/or relations as members
>>> ..."
>>> 
>>> Also the elevation profiles for the routes (e.g. in
>>> waymarkedtrails.org [1]) only work if the routes are ordered and they
>>> usually look ok, see also
>>> https://wiki.openstreetmap.org/wiki/Relation:route#Order_matters .
>>> 
>>> If some editors damage the order in the relations this is a bug that
>>> should be fixed anyway.
>> 
>> In order to sort the members of a relation in JOSM, you need to download 
>> all of them. The majority of edits to relations involve downloading only 
>> 2-3 members. If only 1 member is added or removed, that's how they 
>> become unordered.
>> Personally I'd prefer it stays like that, because I've seen complete 
>> newbies make some really weird edits to cycleroutes, because they 
>> obviously didn't understand what it was.
>>> 
>>> ___
>>> 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
 

Links:
--
[1] http://waymarkedtrails.org___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[osm]

For a non-roundtrip route consiting of two consecutive ways the route
direction can be deduced from the order of the ways in the relation.


That's assuming the ways are ordered at all. I've cleaned up hundreds 
of routes (most created by Potlatch users though) and my advice is: do 
not rely on routes being ordered.


In OSM a relation is by definition an ordered list, see
https://wiki.openstreetmap.org/wiki/Relation :
"A relation is a group of elements. To be more exact it is one of the
core data elements that consists of one or more tags and also an
ordered list of one or more nodes, ways and/or relations as members
..."

Also the elevation profiles for the routes (e.g. in
waymarkedtrails.org) only work if the routes are ordered and they
usually look ok, see also
https://wiki.openstreetmap.org/wiki/Relation:route#Order_matters .

If some editors damage the order in the relations this is a bug that
should be fixed anyway.


In order to sort the members of a relation in JOSM, you need to download 
all of them. The majority of edits to relations involve downloading only 
2-3 members. If only 1 member is added or removed, that's how they 
become unordered.
Personally I'd prefer it stays like that, because I've seen complete 
newbies make some really weird edits to cycleroutes, because they 
obviously didn't understand what it was.


___
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] Status of oneway=cw oneway=ccw

[osm]

cycle.travel appears to try to follow cycle routes as much as possible.
It respects road attributes 

Peter Elderson skrev den 03.05.2019 15:13:

> This one seems to map routes to ways, and it knows the attributes of the ways.
> Are you saying it ignores oneway tags on the individual ways? I wonder, if I 
> feed it a route that goes over a oneway street and then reverse the 
> direction, would it allow that in the navigation? Could be dangerous if it 
> did...
> 
> Vr gr Peter Elderson 
> 
> Op vr 3 mei 2019 om 14:55 schreef Andy Townsend : 
> 
>> On 03/05/2019 13:36, Peter Elderson wrote:
>>> Routers look at the ways, not the routes.
>> 
>> Immediately I can think of at least one major exception for that 
>> (cycle.travel [1]).  I suspect that there are others too.
>> 
>> Best Regards,
>> 
>> Andy
>> 
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 

Links:
--
[1] http://cycle.travel___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[osm]

Hufkratzer skrev den 02.05.2019 12:11:

On 30.04.2019 21:05, Kevin Kenny wrote:

On Tue, Apr 30, 2019 at 2:19 PM s8evq  wrote:
Personally, I like signed_direction=yes. It's simple and avoids using 
the word oneway.
Also, using the value forward|backward might not be necessary, as 
it's possible to deduce this from the order of ways in the relation.

The forward/backward direction cannot be deduced from the order of the
ways if the relation contains fewer than three ways.


For a non-roundtrip route consiting of two consecutive ways the route
direction can be deduced from the order of the ways in the relation.


That's assuming the ways are ordered at all. I've cleaned up hundreds of 
routes (most created by Potlatch users though) and my advice is: do not 
rely on routes being ordered.



___
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] Status of oneway=cw oneway=ccw

[osm]

s8evq skrev den 30.04.2019 20:18:

Helo everyone. I would like to pick up this month old discussion again
and try to come to a conclussion.

The situation so far:

Problem: There are signposted hiking and biking routes, where the
route itself goes only one way, because it's not way-marked in the
opposite direction. How do we add that information in OSM?

Current solution: oneway=yes. Not preferred by many on this list, as
oneway should indicate a legal restriction.

New solution: Some of you suggested alternative new tags, but we
didn't come to a conclusion on this yet. What I have gathered from the
various answers:

- bidirectional=no
- signed_oneway=yes
- signed_direction=yes
- designated_direction=forward|both|backward
- signed=forward|backward|both|none

Personally, I like signed_direction=yes. It's simple and avoids using
the word oneway.
Also, using the value forward|backward might not be necessary, as it's
possible to deduce this from the order of ways in the relation.


This is a false assumption. You should never rely on ways in route 
relations to even be ordered at all. OSM route relations are often 
edited by less experienced or non-technical contributors with no idea 
about ordering at all and there are also lots of cases where you can't 
even order a route in a meaningfull way.


Any other views? Anybody against replacing oneway=yes with
signed_direction=yes in the wiki pages of route=foot and route=hiking?


I happen to know the guy who came up with the oneway=cw/ccw tagging 
(https://wiki.openstreetmap.org/w/index.php?title=Tag:route%3Dhiking&oldid=1453921) 
and remember briefly discussing it with him (he mapped a ton of 
walking/hiking routes in the areas around the danish/german border).


I don't really have much of a problem with oneway=* on route relations 
(since the meaning is fairly obvious to me), but I'm not against 
replacing it (note that the inventors primary language isn't english) , 
but have to state that the cw/ccw values (I suggested 
clockwise/anticlockwise) are necessary, since there's really no other 
way to indicate which direction a circular route is better followed.


Do also note that clockwise/anticlockwise values can be usefull for 
human consumers, even though they may not be for data consumers.



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

[Tagging] A fool with a tool ... Vehicle service tags

[Thilo Haug OSM]

8X-

Sérgio V. svolk2 at hotmail.com
Fri Jan 4 15:59:48 UTC 2019

As talking on tools, standards and principles, I think what is vital is
to follow "OSM principles":

https://wiki.openstreetmap.org/wiki/Good_practice

*Don't remove tags that you don't understand*

https://wiki.openstreetmap.org/wiki/How_We_Map

*Do not engage in large-scale "cleanups" without securing the agreement
of the relevant community or talking to the people whose work you aim to
"clean".*
8X-

Possibly you didn't notice I (first) tried to do so in May 2018 ?

8X-
Fri Jan 4 14:35:57 UTC 2019
...but last time this wasn't very successful :
https://lists.openstreetmap.org/pipermail/tagging/2018-May/036095.html

8X-

And did they ?
https://lists.openstreetmap.org/pipermail/tagging/2018-May/036119.html

Nothing happened, last mail :
https://lists.openstreetmap.org/pipermail/tagging/2018-May/036275.html

So please be try to be constructive,
look forward and tell us which scheme you prefer and why

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

[Tagging] A fool with a tool ... Vehicle service tags

[Thilo Haug OSM]

8X-
Frederik Ramm frederik at remote.org
Fri Jan 4 12:29:34 UTC 2019

Hi,

I agree there seems to be a problem here that needs careful discussion &
consideration, but:

On 03.01.19 16:47, Thilo Haug OSM wrote:
> So which ACTION should we take now ?
> At least those who introduced it should be in charge.

The ACTION should definitely not be you mass-editing things back to how
you think they should be tagged. This can be discussed here and we can
make a change AFTER that, not while.

Bye
Frederik
8X-

I agree, but last time this wasn't very successful :
https://lists.openstreetmap.org/pipermail/tagging/2018-May/036095.html

8X-

Sérgio V. svolk2 at hotmail.com
Fri Jan 4 11:54:17 UTC 2019

Even if the tag keys were not propper, you've just removed many specific
information about services that were in the values, such as batteries;
brakes; electrical; inspection; muffler; oil_change.
Without preserving them in any other usefull, or more propper tag if needed.
https://www.openstreetmap.org/changeset/66006238
Simply removing true info is not a good deal.
Where and how would someone find those specific infos about car services
again?
Are you considering the validity of those previously tagged specific
infos, and the efforts of who did it to put valuable info in to OSM, in
your large-scale re-tagging?

Sérgio

8X-

Yeah, this should be discussed beforehand,
whether we then also tag all items in a supermarket,
or instead use more generic tags like food/non-food.

I'd suggest :

batteries; brakes:
car:parts=yes         OR         car:parts=batteries;brakes (if only)

electrical :
unclear what is meant, electrical repair or electric cars ?
either :
car:repair=yes        OR         car:repair=electrical (if only)
OR
car:type=electric

inspection
car:repair=inspection (if only, such as pitstop and similar)

muffler; oil_change
car:repair=muffler;oil_change (if only)

I think it's vital to follow those principles:
https://en.wikipedia.org/wiki/Standardization#Effect_on_consumers
https://en.wikipedia.org/wiki/KISS_principle

Cheers,
Thilo

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

[Tagging] A fool with a tool ... Vehicle service tags

[Thilo Haug OSM]

Forgot to mention :
" it follows what `service:bicycle:*` does."
is not true.

And if you introduce a new system,
you should also explain the namespace structure.
And not just create a hard to find "notice"
which isn't linked to from the affected existing tags
https://wiki.openstreetmap.org/wiki/Key:service:vehicle

8X---

Bryan Housel bryan at 7thposition.com
Sun May 6 12:27:15 UTC 2018

    Previous message: [Tagging] service:vehicle: prefix
    Next message: [Tagging] service:vehicle: prefix
    Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Hey all, this is something I added to iD because we can’t support
reusing the `service=*` tag to also store values for vehicle services. 
The tag is already overwhelmingly used to hold values for
`highway=service` and `railway=service`.

So we added `service:vehicle` for users to tag these, and it follows
what `service:bicycle:*` does.

https://lists.openstreetmap.org/pipermail/tagging/2018-May/036107.html

8X---


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

[Tagging] A fool with a tool ... Vehicle service tags

[Thilo Haug OSM]

8X--
Bryan Housel bhousel at gmail.com
Thu Jan 3 04:39:03 UTC 2019We discussed it here on this list last year.
You started the thread even, so you can’t pretend like you "just
realized” it.

I even asked people to update the wiki.
https://lists.openstreetmap.org/pipermail/tagging/2018-May/036095.html

 
Anyway, be nice & happy new year.
8X--

Thanks for mentioning that, I really forgot about it.
At the time I obviously didn't realize the dimension of this
(implementing it in ID, and in which opulence).
Meanwhile it's destroying established tagging schemes and it's still not
documented
nor did someone take care to avoid further entries in the format which
triggered this decision (shop=car service=*).
And I'm afraid if I do there will be a lot of whiners crying "where has
this been discussed" ?

There was an appropriate comment at the time,
but it seems it's been ignored:

8X--
Martin Koppenhoefer
    dieterdreist at gmail.com
  
    Sun May  6 20:07:50 UTC 2018

introducing undocumented and formerly unused tags via preset without any
discussion or proposal process
is something I didn’t expect from the main osmf endorsed editor.
Are there more tags that have been introduced this way,
and if yes, have they been documented in the meantime?
8X--

So which ACTION should we take now ?
At least those who introduced it should be in charge.


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

[Tagging] A fool with a tool ... Vehicle service tags

[Thilo Haug OSM]

Hi all,

just realized there's a "great" new feature in ID editor,
lots of senseless service tags in this format :
https://taginfo.openstreetmap.org/search?q=service%3Avehicle%3A

Seems to be over a year ago that someone decided to avoid conflicts
between the "street" and the "car" services :
https://wiki.openstreetmap.org/wiki/Key:service:vehicle

They just forgot to check whether it had some influences on existing
tagging schemes
and didn't even adjust the "shop=car" wiki page (whose tagging scheme
apparently lead to this decision).

This leads to entries like this one :
https://www.openstreetmap.org/way/44809

Thoughts ?
Ideas how to fix that ?
At least this opulent tagging scheme should be deactivated ASAP in ID.

Cheers,
Thilo


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

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

[Jerry Clough - OSM]

  
It looks as though the key in use is diplomatic in conjunction with 
amenity=embassy.
 
There are several mapped in the Brazilian city of Curitiba. The reason I'm 
aware of these was that a friend was the Polish consul during the early 1990s.
 
Jerry
On 21/10/2018 18:01, Allan Mustard wrote:
  
 

https://wiki.openstreetmap.org/wiki/Proposed_features/Consulate
 
Consular representation of a foreign country in a host country as defined by 
the Vienna Convention on Consular Relations
 

 
 

 
 

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

Re: [Tagging] Topographic Prominence for Peaks

[Jerry Clough - OSM]

 

On 24/09/2018 07:03, Joseph Eisenberg wrote:
  
 
 Right! Especially on my island, New Guinea.  
  That’s why we need to check the height of saddles and peaks “by hand”, or 
better yet by survey with GPS.  
  OSM is the right place for this data, and some map styles and database users 
will find it useful to analyze data about mountain areas and peaks. 
  For example, even those lists of “tallest peaks” actually use topographic 
prominence as a cutoff. Otherwise the highest peaks on Earth would all be rocks 
and bumps on the slopes of Everest.  
  Most of us just estimate the prominence of a peak intuitively, before 
choosing to add one to the map. Clearly, a 5 meter tall bump isn’t a peak. 
Perhaps a 10 meter rise may have a name in England or Denmark, where mountains 
are scare. In other contexts a peak won’t be named unless it is 100m or 200m 
above the nearest saddle on a ridge.  
  Joseph 
On Mon, Sep 24, 2018 at 12:59 PM Yves  wrote:
  
I don't see no issue in mapping prominence for those interested in.
 Just to mention for the sake of the discussion that 'sufficiently accurate 
DEM' doesn't exists globally.
 Yves ___
 Tagging mailing list
 Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging
 
   
  
 ___Tagging mailing 
listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging A 
few points on this thread: * Prominence has been added for every significant 
peak in Scotland (along with which hill-bagging group they are members of). The 
peaks called Marilyns (a play on the more famous Munros - peaks over 3000 ft) 
are entirely based on prominence, and are sufficiently well known in the UK to 
have a guidebook. Overpass query: http://overpass-turbo.eu/s/Cbi * What Michael 
describes sounds very much like something close to topographic isolation 
(https://en.wikipedia.org/wiki/Topographic_isolation). Co-incidentally I looked 
at calculating something like this after a recent conversation with Stefan 
Keller (prompted by a wikipage on Dominance: 
https://wiki.openstreetmap.org/wiki/User:Maxbe/Dominanz_von_Gipfeln). I simply 
calculated the closest, higher peaks for all Swiss peaks and then filtered by 
that distance (e.g. over 5 or 10 km). This produces a reasonably good 
distribution of peaks (see 
https://www.dropbox.com/s/qoe2y9d6n6pjh0c/ch_peak_iso.jpg?dl=0), and can 
obviously be adjusted by other parameters. * One problem with prominence is 
that it is probably most easily obtained from non-open sources (such as those 
used to populate wikipedia), and equally there is temptation to use copyright 
maps for information on saddle points. For the peaks with a very significant 
prominence (say 1000 m or more) this is less of a problem as most can be 
deduced very quickly. * Peak names can be an issue when the high point is part 
of a group of peaks with an encompassing name (Dufourspitze Monte Rosa, 
Breithorn Occidentale/Westgipfel comes to mind). The Matterhorn traditionally 
has 2 summits (the Swiss & Italian ones), but only one is mapped, avoiding this 
issue for that peak.
  * Many peaks which sit on national boundaries are not on located as part of 
the border way on OSM, and may therefore not be included in peaks with a 
country filter. There are several examples near Zermatt. Thanks to Kevin Kenny 
& others who have pointed out the theoretical value of prominence. Jerry
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Thilo Haug OSM]

You just forgot to mention the table would solve this :-)
https://wiki.openstreetmap.org/wiki/Default_speed_limits#The_table

And there should be a link to it on these pages :
https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table
https://wiki.openstreetmap.org/wiki/Key:maxspeed

Perhaps there should also be a new value maxspeed=default,
to express the road's speed limit refers to this table
(where "default" links to the wiki page) ?

Am 22.09.18 um 14:32 schrieb Colin Smale:
>
> Well said, I agree wholeheartedly. A local, anecdotal view is in
> itself not enough to produce a data model that works for everyone.
>
>  
>
>
> On 2018-09-22 14:22, Tobias Zwick wrote:
>
>> Tagging an implicit speed limit explicitly for example in town with
>> maxspeed=50 is straightforward enough for Germany. It seems natural that
>> no specialist knowledge is required for that kind of thing. For a German.
>>
>> But let's look at some other countries for the default urban speed limit.
>>
>> Spain (ES):
>> maxspeed=50
>> maxspeed:hazmat=40
>>
>> Chile (CL):
>> maxspeed=60
>> maxspeed:bus=50
>> maxspeed:hgv=50
>>
>> Hungary (HR):
>> maxspeed=50
>> maxspeed:tricycle=40
>>
>> Kerala in India (IN-KL):
>> maxspeed=50
>> maxspeed:conditional=40 @ (weight > 7.5)
>> maxspeed:trailer=40
>> maxspeed:bus_articulated=40
>> maxspeed:hgv_articulated=40
>> maxspeed:bus:conditional=40 @ (weight > 7.5)
>> maxspeed:hgv:conditional=40 @ (weight > 7.5)
>> maxspeed:tricycle=30
>>
>> Punjab in India (IN-PB):
>> maxspeed=50
>> maxspeed:trailer=35
>> maxspeed:bus_articulated=30
>> maxspeed:hgv_articulated=30
>> maxspeed:hgv=45
>> maxspeed:hgv:conditional=40 @ (weight > 6)
>> maxspeed:conditional=40 @ (weight > 6)
>> maxspeed:trailer:conditional=30 @ (weight > 6)
>> maxspeed:motorcycle=35
>> maxspeed:goods=45
>> maxspeed:goods:conditional=40 @ (weight > 6)
>>
>> Malta (MT):
>> maxspeed=50
>> maxspeed:bus=40
>> maxspeed:hgv=30
>> maxspeed:goods=40
>> maxspeed:goods:conditional=30 @ (weight > 3)
>>
>> Poland (PL):
>> maxspeed=50
>> maxspeed:conditional=60 @ (23:00-05:00)
>>
>> Zambia (ZM):
>> maxspeed=50
>> maxspeed:conditional=40 @ (weight > 2.275)
>> maxspeed:trailer=40
>> maxspeed:hgv=40
>>
>> Because the maxspeed tag applies to all vehicles except overridden for a
>> specific vehicle type or a conditional, specifying only maxspeed=50 in
>> any of the above cases has to be considered wrong or at least
>> incomplete. In other words, the tags you see above would need to be
>> added in the case the speed limit is given explicitly. It is not so
>> straightforward then anymore.
>>
>> So, maybe not for Germany, but as you see, in other places, this *is*
>> specialist knowledge. No regular car driver in Punjab will be able to
>> enumerate all these maxspeed rules. And, taking a less extreme example,
>> I think the Polish OSM contributors wouldn't want to add this
>> maxspeed:conditional=60 @ (23:00-05:00) to every single unsigned street
>> in urban areas.
>>
>> Also, note this is only the urban speed limit, trust me, the default
>> speed limit "for all other roads" (=rural) can be much more complex.
>>
>> Actually, don't trust me, see for yourself in the document I link all
>> the time in the hope people would read it:
>> https://wiki.openstreetmap.org/wiki/Default_speed_limits
>>
>> We can not get to any results or any progress on the matter of default
>> speed limits (or for any topic, for that matter) if everyone just keeps
>> arguing out of his best knowledge about his home region or country only.
>>
>> "It works for me" is simply not good enough for a global project.
>>
>> Cheers
>> Tobias
>>
>> On 22/09/2018 01:03, Martin Koppenhoefer wrote:
>>>
>>>
>>> sent from a phone
>>>
>>>> On 19. Sep 2018, at 21:16, Tobias Zwick >>> <mailto:o...@westnordost.de>> wrote:
>>>>
>>>> This is a good argument against tagging an explicit maxspeed=X when
>>>> there is actually no speed limit sign around (X is what the OSM mapper
>>>> by his knowledge about the law thinks should be the default limit
>>>> here).
>>>
>>>
>>> everything that you map will be according to your understanding of
>>> it, I cannot see a good argument for

Re: [Tagging] Area of Firestations / Area of Ambulancestations

[Thilo Haug OSM]

Hi all,

I think this should be discussed here (centrally) :
https://wiki.openstreetmap.org/wiki/Talk:WikiProject_Emergency_Cleanup#amenity.3D.2A_vs._emergency.3D.2A

Generally I don't understand why the parameters can't be "mixed"
(a police station is a police station, whether for emergency or not,
same for ambulance).
Then you could add the offered "services" ("below" the "main" tag).

So the discussion shouldn't be in which case to use amenity or emergency
(how to differentiate them),
but how to establish a namespace which allows to express all of the
possible "mixtures".
In any language the meaning of a sentence is based on the context in
which words are used,
so why not a structured mixture of possible expressions instead of too
generic ones ?

I think we should broaden the usage of namespaces
and define the way how they should be used (in general),
also expand the examples of already used namespaces :
https://wiki.openstreetmap.org/wiki/Namespace#Example_namespace_uses

This might IMHO avoid a lot of discussions about "generic" tags
as it would provide a kind of "grammar" to express details.

Cheers,
Thilo

Am 22.09.18 um 10:11 schrieb dktue:
>
>
> Am 22.09.2018 um 00:29 schrieb Warin:
>> On 21/09/18 23:52, Martin Koppenhoefer wrote:
>>>
>>> sent from a phone
>>>
 On 21. Sep 2018, at 11:28, dktue  wrote:

 but: it's not amenity=ambulance_station we're using at the moment.
 We're using emergency=ambulance_station -- so: How do we solve this?
>>>
>>> I’m not sure what an ambulance station is, but not all of the
>>> features I have in mind (a place where ambulances and their staff
>>> are parked and waiting for orders, usually with a coordinating
>>> office and radio unit) are emergency related. Some organizations
>>> only provide ambulance transports for people with special requirements.
>>>
>>
>> Here 'patent transport' is provided by the same organisation that
>> provides ambulances.
>>
>> They are co-located and have very similar vehicles, different colours
>> and lettering. The staff that man them have less training.
>>
>>
>> If they were completely separate then I'd use different tags. But
>> what tags to use?
>> Not emergency as they are scheduled and not urgent. Amenity?
>> amenity=patient_transport?
>>
> Same here -- some organisation provide emergency medical services
> _and_ patient transport, some do only emergency medical services and
> some do only patient transport. I think there really is a need to
> differentiate 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] horse rental

[Thilo Haug OSM]

Such as in the bicycle shop example ?
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle#Additional_keys

This one has been discussed :
https://wiki.openstreetmap.org/wiki/Proposed_features/service:bicycle

And it's totally different to the car version :
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar#Tags_used_in_combination

That's why I think the (namespace) principle / "grammar" should be discussed
instead of inventing the wheel from scratch for every shop
(and having endless discussions about differences between slightly
different shops
instead of letting people express the details with an easy "grammar" /
"subkeys").

Am 03.09.2018 um 15:49 schrieb Martin Koppenhoefer:
>
>
> 2018-09-03 15:18 GMT+02:00 Thilo Haug OSM  <mailto:th...@gmx.de>>:
>
> The principle should be described in general (not only for rental and
> not only for one shop),
> as there's currently a mess with different formats (compare car /
> bicycle / motorcycle shops).
>
>
>
>
> speaking about "mess"; it is the result of people creating new
> webpages for unexisting features without discussion or notice, so that
> the result is often similar to what you created on the skateboarding
> page: board:type for skateboards where all existing values are
> actually typos for board_type of information boards.
>
> Discussing with other mappers prior to writing new stuff into the
> wiki, using the established procedures (proposal process), searching
> the wiki and taginfo before inventing tags, all this can help to avoid
> the mess.
>
> Cheers,
> Martin
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] horse rental

[Thilo Haug OSM]

Hi,

"Doesn't need a semicolon, only the main activity gets amenity=*, see
examples"
is fine.

The principle should be described in general (not only for rental and
not only for one shop),
as there's currently a mess with different formats (compare car /
bicycle / motorcycle shops).

I think namespaces with : are more usual,
but technically it makes no difference.

And the question is whether the "main amenity" makes sense in this case.
Let's say I search a service which is usually already part of something
else (main key shop=* or similar)
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcar_rental
--> then you'd need to search for several values, amenity=car_rental and
car_rental=*
shop=car
or
shop=rental
with
car:rental=yes
would IMHO be more stuctured.

I also don't understand what the prefix "service" in bicycle is good for
(to distinguish it from which other key "without service" ?)
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dbicycle#Additional_keys

Cheers,
Thilo

Am 03.09.2018 um 12:19 schrieb Hufkratzer:
> On 2.9.2018 22:06 Thilo Haug OSM wrote:
>> {...]
>> The current namespace article doesn't mention underscores :
>> https://wiki.openstreetmap.org/wiki/Namespace#Example_namespace_uses
>
> I think it doesn't have to, the underscore can just be a part of a key
> or a value like any letter [a-z] can.
>
>> The amenity=* version is IMHO the worst possibility (in case of several
>> "amenities")
>> as you could just work with semicolon separator,
>> which isn't recommended : [...]
>
> Doesn't need a semicolon, only the main activity gets amenity=*, see
> examples:
>
> https://www.openstreetmap.org/node/3880444689 :
> amenity=restaurant
> horse_rental=yes
>
> https://www.openstreetmap.org/node/1563976033 :
> amenity=fuel
> car_rental=yes
>
> https://www.openstreetmap.org/node/2356973972 :
> amenity=boat_rental
> bicycle_rental=yes
> dinghi_rental=yes
> motorboat_rental=yes
> pedalboat_rental=yes
>
> If you want to search for all car_rental's you have to search for
> amenity=car_rental (main activity) and for car_rental=yes (secondary
> activity). This is uncomfortable, but the  rendering
> depends on the main activity, therefore the distinction is necessary.
> Isn't it?
>
>
> ___
> 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] horse rental

[Thilo Haug OSM]

Hi,

I don't have a general preference about the format,
but I think it should be possible to express several things to rent
(buy/repair etc.)
and it should be easily be possible to filter for all these items
(regardless whether it's a shop/hotel/farm).

So the format should be flexible enough to allow this.
I think it's easier to read (for humans) when the "subject" is in front,
so all the related characteristics are "listed".

There are several existing namespaces using this format :
https://wiki.openstreetmap.org/wiki/Key:addr#Commonly_used_subkeys
https://wiki.openstreetmap.org/wiki/Key:social_facility:for
https://wiki.openstreetmap.org/wiki/Key:generator:output
https://wiki.openstreetmap.org/wiki/Key:parking:lane#Examples

An example for the underscore format :
https://wiki.openstreetmap.org/wiki/Seamarks/Seamark_Objects

The current namespace article doesn't mention underscores :
https://wiki.openstreetmap.org/wiki/Namespace#Example_namespace_uses

The amenity=* version is IMHO the worst possibility (in case of several
"amenities")
as you could just work with semicolon separator,
which isn't recommended :
https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator#When_NOT_to_use
I think this is an overcome way to express simple things from a time
when POIs weren't in focus
(which meanwhile changes with OsmAnd, maps.me, komoot
and other popular apps which allow to use the data not only for pure
navigation).

Cheers,
Thilo


Am 02.09.2018 um 15:37 schrieb Hufkratzer:
> It looks like you didn't understand me. I am sorry that my English is
> so bad. I am trying to express my question in a different way:
>
> We have some differnet ways to tag a bicycle rental:
> a) amenity=bicycle_rental (30k uses), bicycle_rental=yes (< 20 uses)
> b) rental=bicycle (< 300 uses) (rental:bicycle=yes not used)
> c) bicycle:rental=yes (< 40 uses) (links to shop=rental)
>
> ... and a boat rental;
> a) amenity=boat_rental (2k uses), boat_rental=yes (< 10 uses)
> b) rental=boat (< 50 uses) (rental:boat=yes not used)
> c) boat:rental=yes (< 20 uses) (links to shop=rental)
>
> Now we are looking for the best way to tag a place where horses are
> for rent.
>
> The corresponding current numbers for horse rentals are:
> a) amenity=horse_rental : 5 uses, horse_rental=yes : 1 use
> b) rental=horse : 5 uses (rental:horse=yes not used)
> c) horse:rental=yes : 1 use (links to shop=rental)
>
> I wrote that I think the best way would be
> a) amenity=horse_rental or horse_rental=yes (if secondary activity)
> and wrote I don't like
> c) horse:rental=yes
> for the following reasons:
> - horses are usually not sold nor rented in shops
> - horses are no vehicles and no equipment and shop=rental is for these
> - amenity=horse_rental is like how car, bicycle. and boat rentals are
> usually tagged
>
> Why doyou nevertheless prefer to tag a horse rental with b)
> rental=horse rather than with a) amenoty=horse_rental or with
> horse_rental=yes? Why should we propose to tag them in a differnt way
> than bicycle or boat rentals? I think this would be unnecessarily
> confusing. Thanks.
>
>
> ___
> 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] horse rental

[Thilo Haug OSM]

And what if a touristic item (farm, hotel, shop...)
offers several things to rent ?
Let's say horses, bicycles, jetski ?

Am 01.09.2018 um 16:25 schrieb Hufkratzer:
> On 1.9.2018 02:55, Graeme Fitzpatrick wrote:
>>
>> On Sat, 1 Sep 2018 at 09:03, Hufkratzer > > wrote:
>>
>> I think a better alternative would be to use
>> amenity=horse_rental, this
>> is currently used 5 times, this would be analogous to
>> amenity=car_rental, amenity=bicycle_rental and amenity=boat_rental. 
>>
>>
>> I'm not sure if horse rental would really be an appropriate term?
>>
>> If you rent a car, bike or boat, then you decide where to go, but if
>> you're "renting" a horse, you're paying to join an organised trail
>> ride of some form, you're not renting a horse to ride off into the
>> sunset & return it tomorrow!
>>
>> Thanks
>>
>> Graeme
>>  
> One can rent a horse for trail riding, guided or unguided, or for
> riding inside of an enclosed area, with or without a teacher. One can
> do this for just an hour or for several days and also with 
> horse.drawn caravans, see these example webpages:
> -  http://www.sombrerohorses.com
>  - http://www.irishhorsedrawncaravans.com/Horses.htm
>
> What else than "horse rental" is there to call it?
>
>
> ___
> 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] transport=* -key

[Thilo Haug OSM]

Hi all,

what is the meaning of the transport=* -key ? 

I couldn't figure it out because it's often on buildings (possibly
"reachability" ?)
There's a total of 4 013 usages, but no wiki description :
https://taginfo.openstreetmap.org/keys/transport


There are 833 entries of transport=subway,
this would fit into the "public transport" tagging ?
https://wiki.openstreetmap.org/wiki/WikiProject_Cleanup/Public_transport

Are there any other similar wiki entries ?

Cheers,
Thilo

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

Re: [Tagging] building = house vs detached.

[Jerry Clough - OSM]

 On 23/07/2018 14:00, Martin Koppenhoefer wrote


  
 it does not seem to be a very promising concept though. Terraced houses are 
usually seen as a compromise for people who want an independent house, but 
cannot afford a detached one. Terraced houses are cheaper because they need 
less ground (i.e. you can usually find them where the ground is expensive to 
buy), expensive ground means you’ll try to use it intensively, which is 
contradicting the bungalow concept.Terraced houses are almost always narrow, 
deep and relatively high.Maybe in the UK with its tradition of terraced houses 
there could be a cultural interest in something like terraced bungalows and 
there is also an energetic advantage from reducing external walls, but overall 
there’s little danger this will become a widespread concept for housing. 
Cheers,Martin ___Tagging mailing 
listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging 
 An unwise generalisation. Some of the most expensive houses in the UK are 
terraced houses (see Stefan Muthesius "The English Terraced House"). Notable 
examples can be found in Belgravia, Regent's Park, Edinburgh New Town, Regency 
Bath, and many other cities. I can also think of examples in Paris, e.g., Place 
des Vosges. The UK is probably unusual in that terraced houses were built for 
all classes over around a couple of hundred years (roughly 1700 to 1900). 
  At the opposite end of the spectrum, back-to-back terraced houses still exist 
in several places, notably Beeston, a suburb of Leeds (see for instance this 
blog). Thus a plain building=terrace may be inadequate for many purposes (from 
identifying less-well of housing areas, to locating specific types of houses).
  On the actual tagging: it's certainly useful in the UK to distinguish between 
detached, semi-detached and terraced houses. As has been pointed out 
building:levels=1 may be an adequate synonym for bungalow, but there also exist 
"chalet bungalows" which have bedrooms in the roof (usually with dormer 
windows), and certainly I see many detached and semi-detached bungalows. Other 
housing types which may be highly UK specific are : mews houses (found behind 
the grander types of terrace in London and Edinburgh and a few other places, 
and often very expensive); maisonettes, purpose built flats in a structure 
which looks like a house (no good description on wikipedia); (modern british 
usage of) town house, a terraced house with integral garage on the ground floor 
and most living accommodation on the upper floors; link-detached houses, the 
garages of adjacent houses completely fill the space between them.
 I dont have any generic solution to all this, other than to continue 
collecting data. Where I have been trying to precisely delineate very specific 
types of housing I'm using 'private' tags (in part because I need to do archive 
work to find the actual codes used by the architects). 
A commercial mapping provider gave a talk at Geomob about 3 years ago: they 
have something like 70 building classes to cover the spectrum of building types 
in British cities. I have their brochure, but have deliberately avoided 
examining it too closely in case of inadvertently copying their ideas.
 Jerry
      
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 105, Issue 26

[Thilo Haug OSM]

I think what Mark wanted to express
is more about some general guidelines which could be established.

The  tagging systems are very inconsistent, just have a look at the
different "service" syntax (namespaces)
of a car vs. bicycle vs. motorcycle shop (and none for others).
There could be a system of different levels of discussions, for example.
I'm personally not keen on reading every single mail of every topic,
but there's no possibility to choose some topics.

To stay with the "shop" example :
There should be a consensus first what all shops have in common,
THEN the single shops may be discussed, not bottom-up.
Same for the namespace syntax.

It would be good to have some simple voting system
without having to edit the page code.
So when people are able to choose their topics
and an easy way to vote, more will participate
and the "consensus" of currently some dozens
which are willing to withstand the current mess
would be on a broader base (really democratic).

So let's discuss the possible structural enhancements
instead of presuming political opinions
(he didn't really mention "strong leadership, did he ?)

Ideas ?

Am 09.06.2018 um 02:22 schrieb EthnicFood IsGreat:
>     Date: Fri, 8 Jun 2018 08:29:25 +0200
>> From: Frederik Ramm 
>> To: "Tag discussion, strategy and related tools"
>> 
>> Subject: Re: [Tagging] The endless debate about "landcover" as a
>> top-level    tag
>>
>> Hi,
>>
>> it is a gut reaction by people when forced with difficult issues to call
>> for strong leadership to solve them once and for all. OSM is no
>> exception.
>>
>> On 08.06.2018 01:29, EthnicFood IsGreat wrote:
>>> I wouldn't mind if all the existing tags were replaced tomorrow with a
>>> brand new set of "intelligently-designed" keys.
>> Designed by... a visionary leader? A board of experts? A random draw?
>> And if something turns out to be designed wrongly, how will it be
>> challenged?
>
> Of course any system would have to have a means of making revisions,
> as better ways of tagging things become apparent over time.  There
> could still be innovation.
>
>>
>>> And I wouldn't mind if
>>> these keys were enforced from now on.
>> Not having an enforced set of keys and values was definitely a big part
>> of OSM's success (there *were* competing projects which got stuck trying
>> to define the one true set of keys and values that would work for
>> everything).
>>
>> Some people say that while this may be true, the time has now come to
>> get rid of the old ways that got us where we are, and change tack to
>> something more conservative. This is a valid argument but I am not
>> convinced; a lot of innovation is still going on with tags, and strict
>> enforcement would run the risk of killing that.
>>
>>> Someone some time ago on one
>>> of the OSM mailing lists summed up the current situation by stating,
>>> "It
>>> seems OSM is incapable of moving forward."
>> OpenStreetMap is becoming a larger group of more diverse people with
>> more diverse interests, and since we don't - and don't aim to - have a
>> dictator at the top, things need to be done by consensus. These people
>> who take to the internet complaining about how OSM is incapable of
>> moving forward usually are people who are unwilling, or unable, to
>> convince the "great unwashed" their idea of "forward" is a good thing.
>> So they lament the lack of leadership and complain about "gatekeeping",
>> but it's really just them being unable to do the work required to
>> establish consensus in a large project.
>>
>> Because that takes much more than a couple of blog posts (cf. the
>> license change).
>>
>> Bye
>> Frederik
>>
>
>
> I have been editing in OSM for almost four years, and I've been a
> member of this mailing list almost since then.  I read every single
> post.  During that time I have never seen what I would consider a
> consensus reached on anything.  I'm not sure it's even possible.
> Whenever someone proposes a way to tag something, you can be
> guaranteed that people will bring up every possible angle and nuance
> concerning the meaning of the tag, and nobody wants to compromise.
> Consequently there is never a consensus.  Eventually people get tired
> of the debate, when they see it's a no-win situation, and the debate
> just dies away, until somebody brings it up again next year. Case in
> point:  the current issue of landuse versus landcover. There was no
> consensus the last

Re: [Tagging] Removing helpful information in wiki pages

[Thilo Haug OSM]

Hi,

IMHO the picture helps understand the process of starting and landing,
as not everyone heard about the recent development.
I thought this would be helpful to get an overview at a glance.
(talking about the spacex schematic picture, not the " long exposure" one,
which should only show the "real world"- version of the above).

What I dont't understand is how these pictures may be disturbing or
irritating ?

Illustrations in general are usual to help understand a topic,
especially if one isn't already a specialist in it.
Those were just a bit bigger, but this could be solved by using
"thumbnails",
means smaller versions you have to click on to see the full size.

An alternative would be to link to an wikipedia article which explains it,
but if I can get this general understanding with just some pictures,
I think this is more effective ("a picture is worth a thousand words").

Cheers,
Thilo

Am 12.05.2018 um 13:15 schrieb Martin Koppenhoefer:
> Why would you think it is not, and what is the content you believe is
> contained that could help understanding the tags in question?


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

Re: [Tagging] service:vehicle: prefix

[Thilo Haug OSM]

Hello all,

instead of discussing everything from scratch,
let's create a general guideline for shop suffixes.
There has already been a former short dicussion
with some nice examples, but no productive outcome :

General namespace (syntax) for shops :
https://lists.openstreetmap.org/pipermail/tagging/2017-September/033385.html

Proposal :
https://wiki.openstreetmap.org/wiki/Proposed_features/shop_subtags

Please write your input to the proposal's discussion page,
otherwise everyone has to search all the old emails in the tagging
mailing list's archive.

Cheers,
Thilo

Am 06.05.2018 um 22:07 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> On 6. May 2018, at 14:27, Bryan Housel  wrote:
>>
>> Hey all, this is something I added to iD because we can’t support reusing 
>> the `service=*` tag to also store values for vehicle services.  
>
> introducing undocumented and formerly unused tags via preset without any 
> discussion or proposal process is something I didn’t expect from the main 
> osmf endorsed editor. Are there more tags that have been introduced this way, 
> and if yes, have they been documented in the meantime?
>
>
> Cheers,
> Martin 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] service:vehicle: prefix

[Thilo Haug OSM]

How about leaving away both,
the prefix service:vehicle is IMHO needless

car:repair
car:parts
car:rental

etc., same for bicycle,
would express the same ?

Am 06.05.2018 um 14:27 schrieb Bryan Housel:
> Hey all, this is something I added to iD because we can’t support
> reusing the `service=*` tag to also store values for vehicle services.
>  The tag is already overwhelmingly used to hold values for
> `highway=service` and `railway=service`.
>
> So we added `service:vehicle` for users to tag these, and it follows
> what `service:bicycle:*` does.
>
> For more details see:
> https://github.com/openstreetmap/iD/issues/5008
> https://github.com/openstreetmap/iD/issues/4497
> https://github.com/openstreetmap/iD/issues/3535
>
> Please update the wiki, thanks!
> Bryan
>
>
>
>> On May 6, 2018, at 12:35 AM, Warin <61sundow...@gmail.com
>> <mailto:61sundow...@gmail.com>> wrote:
>>
>> So ... no documentation. Nor discussion visible on the wiki.
>>
>> But follows the practice of service:bicycle:repair=yes which is
>> poorly documented on
>> https://wiki.openstreetmap.org/wiki/Key:service:bicycle:repair
>>
>>
>>
>> On 06/05/18 13:42, Graeme Fitzpatrick wrote:
>>> As part of shop=car_repair
>>>
>>> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcar_repair
>>>
>>> Thanks
>>>
>>> Graeme
>>>
>>> On 6 May 2018 at 09:51, Thilo Haug OSM >> <mailto:th...@gmx.de>> wrote:
>>>
>>> Hi all,
>>>
>>> what is the service:vehicle: prefix good for,
>>> and where is it documented ? (1 223 occurrences)
>>>
>>> 
>>> https://taginfo.openstreetmap.org/keys/service%3Avehicle%3Acar_repair#overview
>>> 
>>> <https://taginfo.openstreetmap.org/keys/service%3Avehicle%3Acar_repair#overview>
>>>
>>> Cheers.
>>> Thilo
>>>
>>>
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/tagging
>>> <https://lists.openstreetmap.org/listinfo/tagging>
>>>
>>>
>>>
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org <mailto: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] tagging LPG only station

[Thilo Haug OSM]

fuel:diesel=no
fuel:octane_91=no
fuel:octane_95=no
fuel:octane_98=no
fuel:e10=no

Am 06.05.2018 um 18:52 schrieb Mateusz Konieczny:
> How to tag fuel station with only LPG fuel?
>
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dfuel and
> https://wiki.openstreetmap.org/w/index.php?title=Key:fuel:lpg
> failed to help with that.
>
> amenity=fuel
> fuel:lpg=yes
>
> is a good start but how one may explicitly add that
> no other fuel type is sold there?
>
> I encountered https://www.openstreetmap.org/note/1282285 and now
> I have no idea how to improve tagging there (and I prefer to know that
> before I
> check that anonymous reporter was right)
>
>
> ___
> 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] service:vehicle: prefix

[Thilo Haug OSM]

Hi all,

what is the service:vehicle: prefix good for,
and where is it documented ? (1 223 occurrences)

https://taginfo.openstreetmap.org/keys/service%3Avehicle%3Acar_repair#overview

Cheers.
Thilo



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

Re: [Tagging] musical_instrument tag for publicly available musical instruments

[Thilo Haug OSM]

perhaps

musical_instrument:usage=

?

Am 30.04.2018 um 11:22 schrieb Marc Gemis:
> Besides the arguments from Martin,
>
> how do you differentiate the "rental" in a bar, where you can only
> play on the instrument, and not take it away from the room/building
> from a real rental company that deliver instruments to play somewhere
> else ?
>
>> musical_instrument:sales=*
>> musical_instrument:rental=*
>> musical_instrument:repair=*
>> musical_instrument:parts=*
>> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dmusical_instrument
>>
>> I case of the bars,
>> it could be
>> amenity=bar
>> musical_instrument:rental=piano
>> fee:piao=no @ customers
>> https://wiki.openstreetmap.org/wiki/Key:fee
> ___
> 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] musical_instrument tag for publicly available musical instruments

[Thilo Haug OSM]

Hello all,

i think that subtags are necessary for all types of shops
but may be the same for every (non-food) type of shop,
as all of them usually offer the same (besides sales),
so the following may apply :

musical_instrument:sales=*
musical_instrument:rental=*
musical_instrument:repair=*
musical_instrument:parts=*
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dmusical_instrument

I case of the bars,
it could be
amenity=bar
musical_instrument:rental=piano
fee:piao=no @ customers
https://wiki.openstreetmap.org/wiki/Key:fee

So the keys for the shop
could also be used for other "main" tags such as amenities.
Any standardisation would IMHO ease the tagging of more complex cases.

Cheers,
Thilo

Am 29.04.2018 um 10:36 schrieb José G Moya Y.:
> I think this is a good idea, but, in the suggestion of Thorsten, I
> find problematic the use of "access=" tag when instruments are in a
> bar. Imagine a bar with a private piano is tagged as a point:
>
> amenity=bar
> amenity=musical_instrument
> musical_instrument=piano
> access=private
>
> It does not make clear if either access to bar or access to piano is
> private. 
>
> Also, since bars are amenities, a duplicate "amenity" tag arises. You
> have to either put two points or tag the bar as an area.
>
> Yours,
>
> José
>
>
> El dom., 29 de abril de 2018 7:51,  > escribió:
>
> The musical_instrument *key* is generally used to name the
> specific type of musical instrument:
> https://taginfo.openstreetmap.org/keys/musical_instrument
>
> You are correct that it's mostly used in combination with
> shop=musical_instrument (a place selling them) or
> craft=musical_instrument (a place making them).
>
> But there are also a (very) few cases tagged as
> amenity=musical_instrument (a place where a musical instrument is
> available for use) and playground=musical_instrument (similar, but
> generally a more robust "toy" instrument aimed at a younger
> audience). Neither one of which is currently specifically
> documented on the wiki, but that shouldn't stop you from using them.
>
> So a piano in a bar that is available for people to play on should
> probably be tagged:
>
> amenity=musical_instrument
> musical_instrument=piano
> access=permissive (or access=customer in some cases)
>
> Either way, the piano is privately owned and the owner is
> currently making it available to other people, but may revoke that
> permission at will in the future.
>
> Cheers,
> Thorsten
>
> P.S. is there a preference on this mailing list for top or bottom
> posting?
>
> > -Original Message-
> > From: e1k mailto:emilea...@protonmail.ch>>
> > Sent: Sunday, 29 April 2018 15:12
> > To: tagging@openstreetmap.org 
> > Subject: [Tagging] musical_instrument tag for publicly available
> > musical instruments
> >
> > Hi,
> >
> > (first post, plz be gentle!)
> > i'd love to see if there can be consensus on the use of the
> > 'musical_instrument' tag for publicly available musical instruments.
> > a growing number of bars, train stations and or other public places
> > have musical instruments around where i live (Amsterdam area), and
> > i've started noticing and collecting these places, and would love
> > to tag them in openstreetmap.
> > use case: as a musician that travels around a bit, i'd love to know
> > where i can find a piano or guitar to play on.
> > i see the musical_instrument tag is mostly (only?) used for place
> > that create and/or sell musical instruments, but i'm wondering what
> > the appropriate form of tag would be for a publicly available
> > musical instrument.
> > (if this has been discussed before, plz point me at it, i coudln't
> > find it)
> >
> > best regards,
> > emile
> >
> >
> > ​---
> >
> > All revolutions are impossible until they happen. Then they become
> > inevitable -- Albie Sachs​
> >
> >
> >
> > ___
> > 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] Identifying language regions

[Thilo Haug OSM]

An example, good luck :
56 TSKM, 39 Languages
https://en.wikipedia.org/wiki/Languages_of_Togo
41 TSKM, 4 languages :
https://en.wikipedia.org/wiki/Switzerland

(Germany : 357 TSKM)

Am 18.04.2018 um 21:49 schrieb Vao Matua:
> I would suggest that OSM is probably not the best place for this. 
> There are many countries that have many or even hundreds of
> languages.  The lines between the places where languages are commonly
> spoken can be quite fuzzy and often do not follow any other features.
> A year ago I was living in a place where people living there spoke 3
> different languages in addition to the "official" language.
>
> On Wed, Apr 18, 2018 at 12:41 PM, Yuri Astrakhan
> mailto:yuriastrak...@gmail.com>> wrote:
>
> What would be the best tags to use for mapping language regions? 
> I would like to create a map of primary languages spoken in an
> area. This will greatly help with multilingual maps, allowing data
> consumers to calculate which language name tags to use for which
> locale. This will also give OSM community a much greater control
> over such maps.
>
> Proposal (relations only, must have closed polygons):
> type=language
> primary=xx   (required)
> secondary=yy;zz;...  (optional)
>
> A relation may span multiple countries (e.g. US and most of Canada
> for English), or split countries (e.g. EN and FR regions in
> Canada). In some cases, the relation will reuse country border ways.
>
> What do you think?
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging
> <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] Tag:shop=shotball

[Thilo Haug OSM]

Hi,

there's already
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dweapons

How about a subtag
weapon:type=*

The corresponding sport is here :
https://wiki.openstreetmap.org/wiki/Tag:sport%3Dshooting

Cheers,
Thilo


Am 08.03.2018 um 13:00 schrieb Александр Львов:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:shop%3Dshotball 
>
>
>
> ___
> 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] discrepancy in shop definition and "wholesale" value

[Thilo Haug OSM]

I agree with those statements :

What they sell (e.g. clothes, groceries, only in bulk packaging) or if
access is restricted (specific times, only certain group of people) are
separate concerns
*and should be tagged separately*.

Am 06.03.2018 um 18:55 schrieb Paul Allen:
We already make a distinction between shops (selling goods) and offices
(selling services, though other types of office exist).  I'd go with
wholesaler=*.  *And maybe expand* access to access=trade (wholesaler
deals only with registered traders) and access=public (anyone can shop
there).  Something along those lines.

Of course, there will always be grey areas.

-- 
Paul

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

[Tagging] "service" tags in general (for shops)

[Thilo Haug OSM]

Hello all,

instead of debating every single shop (details),
I'm in favor of using a name scheme which applies to all (kind "grammar"
for it).

In the context of the printer_ink shop discussion I stumbled on the
"service" tags of
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcopyshop

IMHO service:computer=yes/no or service:phone=yes/no
doesn't make sense at all, as nobody knows WHICH "service" is meant.
It would be better to take the "main" tag (of shop=*) as the leading item,
such as
computer:sales=yes/no
computer:parts=yes/no
computer:repair=yes/no
computer:rental=yes/no
computer:[whateverrismeantby"service"]=yes/no

...and to use this scheme for all shop services.

Cheers,
Thilo



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

Re: [Tagging] Shops that sell printer ink cartridges

[Thilo Haug OSM]

I didn't get the point of this comment,
do you got an example ?

Am 24.02.2018 um 00:51 schrieb marc marc:
> Listing all possible values in shop=* means that each tool
> must provide a sorting by category if it wants to organize
> the data and make life harder for the majority of shop that
> have more than one product..
> a schema like shop=first_level + first_level=second_level etc.,
> avoiding the need for each application to do so.
Regarding
"I am against turning OSM into a shop inventory or an ontology of all
products on the planet. I agree with Frederik below and his
shop=printer_ink favourite." :

I didn't want to propose to list all products (or even variants of them)
of a shop=supermarket, shop=doityourself or shop=electronics,
just to give a possibility to mention another "main shop" is also
providing this "service" (or product) of a "specialised" one
(In OSM usually done by a namespace, example : social_facility).
I think the number of shops that are specialised in only one
product/service is much lower than that of shops providing several.
Example : shop=seafood (may be sold by a variety of other shops).

So IMHO the goal of this discussion is to find those attributes (or
services) which apply to several shops and are of general interest.

In the "seafood" example it's the question whether this needs to be
split up in types of seafood or not, but time will show if people feel
the need.
But this might be solved by simply offering seafood:type=* (not to make
a subtag for every type).
In non-food cases, there will mainly be the offer of selling, renting,
repairing and (spare) parts,
so this could be used for a "general" scheme.

In the printer example, it is obvious that there might be more than ink
which could be interesting,
there's even the tag amenity=printer (doesn't make sense to me).




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

Re: [Tagging] Cycling "service area"

[Thilo Haug OSM]

Hi Volker,

the way I understand the current syntax,
underscore is more for spaces (in terms)
and colon for namespaces (to separate the "subcategory").

So I'd use vehicle:type=* rather than vehicle_type=*
(leaves room for vehicle:anythingelse=*)
https://wiki.openstreetmap.org/wiki/Namespace

Cheers,
Thilo


Am 17.02.2018 um 14:44 schrieb Volker Schmidt:
> I would prefer a tag structure of the type
> highway=service _area (or highway=services ?)
> vehicle_type=bicycle; motorcycle; car; agricultural; hgv;
> motor_vehicle (with default vehicle_type=motor_vehicle?)
> attendant=yes|no
>
> I have come across a number of (manned) service places where different
> vehicles are attended to, including bicycles.
>
> On 17 February 2018 at 11:52, nwastra  <mailto:nwas...@gmail.com>> wrote:
>
> I also find the highway=cycle_service_area tag is both useful and
>     specific enough to be a widely used tag if documented on the osm
> cycling pages.
> nev
>  
>> On 17 Feb 2018, at 8:40 PM, John Willis > <mailto:jo...@mac.com>> wrote:
>>
>>
>>
>> Javbw
>>
>> On Feb 15, 2018, at 11:54 AM, Dave Swarthout
>> mailto:daveswarth...@gmail.com>> wrote:
>>
>>> think the highway=cycle_service_area tag is both useful and
>>> specific enough.
>>
>> I will make a draft page for it and start using it for the very
>> rare places here. I assume the rest area in the OSM question
>> thread is a sun protection or picnic shelter with name=Cycle Rest
>> Area. 
>>
>> Javbw 
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/tagging
>> <https://lists.openstreetmap.org/listinfo/tagging>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging
> <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] Not mapping personal preferences and details

[Thilo Haug OSM]

Hi all,

did I miss the
"consensus with the community, after long and detailed discussions"
here ?
https://lists.openstreetmap.org/pipermail/tagging/2017-October/033760.html

There are two guys which appear to me like religios bigot on an Inquisition,
but maybe the definitions in the wiki are just unclear / too interpretable :
https://wiki.openstreetmap.org/w/index.php?title=User_talk:Rtfm

Please let me know what you think of this definition
https://wiki.openstreetmap.org/wiki/Any_tags_you_like#When_to_create_a_proposal
and whether it applies to the "motorcycle_friendly" tag.

Cheers,
Thilo

Am 05.10.2017 um 23:19 schrieb Warin:
> On 05-Oct-17 10:41 PM, Tom Pfeifer wrote:
>>
>>
>> In my understanding, we would not map the personal preferences and
>> hobbies of individuals. 
>
> ? We all map our personal preference and hobbies!
> Walkers map public rights of way and bicycle riders map bicycle paths,
> bicycle parking, bicycle repair stands, drinking water sources and so on.
>
> Why should motorcycle riders not do the same?
> Or pet owners?
>
> The motivation of a business owner to provide specific services is for
> profit, if they have specific knowledge of a particular market, such
> as motorcycling, then they may use it to advantage.
> I don't see any harm in that - after all OSM is mapping crafts and
> shops where the people concerned have skills in those areas.
>
>
>
> ___
> 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] lunch_specials or lunch:specials ?

[Thilo Haug OSM]

Hello all,

I stumbled on a bakery which serves warm meals for lunch
which is quite unusual (whereas it's common for butchers in Germany)
http://www.schmidbeck.de/aktuelles.html

There are currently 5 occurrences of lunch_specials on taginfo :
https://taginfo.openstreetmap.org/search?q=lunch_specials

I think it would be better to use the namespace of Key:lunch instead :
https://wiki.openstreetmap.org/wiki/Key:lunch

Now for the description of the tag :
To me, the "lunch special" is a warm meal
for a reduced price that might be offered by a
butcher
restaurant
cafe
pub
bar
biergarten
and others

Usually, there's just a reduced choice
compared to "a la carte" (1-3 meals),
but it's available immediately (similar to fast food).
Not necessarily for takeaway, but there are already tags to indicate if
this applies.

Any additional comments ?

Cheers,
Thilo


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

Re: [Tagging] shop - clothing_repair

[Thilo Haug OSM]

Maybe a namespace ?
http://wiki.openstreetmap.org/wiki/Namespace

I think this statement isn't true :
" It's impossible to cover all types of shops."'
further, it's mentioned :
"If you discover new shop types, you may invent your own values"
I think this should be standardized,
similar namespaces may apply to most of the shops.


Am 16.12.2017 um 22:36 schrieb Philip Barnes:
> Maybe craft=tailor?
>
> http://wiki.openstreetmap.org/wiki/Tag:craft%3Dtailor
>
> Phil (trigpoint)
>
> On 16 December 2017 20:44:30 GMT+00:00, Warin <61sundow...@gmail.com>
> wrote:
>
> Hi,
>
> Yet another type of shop?
>
> There are 'car_repair' shops but no clothing repair shops ...
>
> For example www.venusrepairs.com.au  
> provides specialised repairs for 
> leather and goretex clothing.
>
> So I have tagged them as shop=clothing_repair.
>
>
> Someone has shop:repair=yes .. does not work for me, could be a repair 
> of a wheelbarrow.
>
>
> 
>
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> -- 
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Vandalism ?

[Thilo Haug OSM]

Was there any consensus about this topic ?

8X---
Gîtes les terres noires. (525407874)
OSM data: remove 12 occurrences of 'proprietor:motorcyclist' after
discussion on the Tagging list
that OSM should not map personal preferences, and is not a vehicle registry
https://www.openstreetmap.org/way/525407874
8X---

I can't see how this tag may do any harm to OSM,
based on this description :
http://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_tags


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

Re: [Tagging] building=maisonette(s)

[Thilo Haug OSM]

Hello all,

here it's defined as :

"A set of rooms for living in, typically on two storeys of a larger
building and having a separate entrance."
https://en.oxforddictionaries.com/definition/maisonette

HTH


Am 02.12.2017 um 23:21 schrieb Warin:
> On 03-Dec-17 09:09 AM, Graeme Fitzpatrick wrote:
>>
>> On 3 December 2017 at 04:58, marc marc > > wrote:
>>
>>
>> In french, a "maisonette" is a small detached house or a tiny
>> house or a
>> shed.
>> Did this word also exist in english
>>
>
> English has stolen many words from other languages. This may well be
> one of them.
> My dictionary says "maisonette"; 1) small house 2) semi-detached house
> 3) self contained flat over 2 floors
>>
>>  Have heard the term in Australia but not for many years.
>>
>> These days, it's apparently been replaced by "Granny Flat", which is
>> a similar concept of a self-contained flat attached to a house, but
>> with it's own entrance.
>>
>
> Granny flats can be attached (or semi-detached) or completely separate
> from the main residence.
>
>
> ___
> 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] Deprecating of leisure=common and leisure=village_green

[Robert Whittaker (OSM lists)]

On 30 November 2017 at 22:45, Daniel Koć  wrote:
> While making some cleaning in osm-carto we have found that leisure=common
> and leisure=village_green are probably not clear enough to show them any
> more. They both have deep roots in British law and history and are
> frequently misused, as far as I can tell.

I agree that those two leisure keys are somewhat odd, as they appear
to be based on a legal designation rather than physical
characteristics. However, that's probably not the full story in the
UK, as they're likely to be used for patches of land that have the
appearance of a typical common or village green, and thus would be
recognised as such by most residents, even if legally they're not. The
"village green" and "common" terms can be thought of as comparable to
other names for open spaces such as "recreation ground" and "park",
but distinct from a UK point of view. Some legal village greens and
commons could well be "recreation grounds" and some may be "parks" but
many will not be either in the British English usage sense.

To capture the legal designation of patches of land, I would recommend
using the designation=* key, with something like
designation=common_land and designation=village_green. (However, we
probably wouldn't want to automagically add these tags to all UK
leisure=common and leisure=village_green objects, as some of the uses
may be based on appearance and not legal status.) Access tags can also
be added to describe access rights. But in addition to this, we'd need
something to capture the physical state / utility of the area. Often
neither leisure=recreation ground nor leisure=park will fit the bill.
If not, then natural=heath, natural=grassland, or natural=meadow may
fit the bill for commons, but it would be a shame if we didn't have
something specific for village green type areas of maintained grass.

In conclusion, I think there are reasonable arguments in favour or
replacing leisure=common with more appropriate tags to describe the
legal status, physical condition and access rights. But I'm not sure
about village_green, as there's a physical/utility aspect captured
there that I think should be maintained, and I'm not sure that there's
an alternative tagging available at the moment.

Robert.

-- 
Robert Whittaker

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

Re: [Tagging] passage only on low tide

[Jerry Clough - OSM]

This seems a good place to use the hazard key. There are a limited number of 
instances of hazard=tide.
There's no reason why post-processing cannot append information about critical 
hazards to names for rendering purposes, and thus we could avoid the spurious 
information in the name tag.
J

  From: Graeme Fitzpatrick 
 To: "Tag discussion, strategy and related tools"  
 Sent: Sunday, 5 November 2017, 6:58
 Subject: Re: [Tagging] passage only on low tide
   



On 5 November 2017 at 13:46, Max  wrote:


I went with

causeway=yes
ford=tidal
tidal=yes

not sure how to say that the passable time frame is about 3 hours (with climate 
change it's getting shorter)..


How about Description: "Only passable 1.5 hours each side of low tide - check 
daily tide times", possibly with a link to online tide info?  
Thanks
Graeme___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] war_memorial

[Jerry Clough - OSM]

Can I contribute to this debate?
AFAIK I invented memorial=war_memorial for the Project of the Week which 
coincided with 11th November 2010. I agonised a certain amount about the best 
tag (both because of issues mentioned here, and because it would apply to both 
historic=monument and historic=memorial). However, at the time there were next 
to no uses of the tag memorial. I did try and discuss this on IRC channels (eg 
with the Italian community) 
As it stands this represents around a third of instances of the key, and I 
believe pre-dates other classes of meanings for memorial (see 
http://taghistory.raifer.tech/ and type some typical values in). 
The original description page for the PotW makes it clear that the tag was 
intended for many different types of memorial (See 
https://wiki.openstreetmap.org/wiki/Project_of_the_week/2010/Nov_10):
   
   - Walls
   - Gates (the Menin Gate)
   - Ossuaries (common in Italy)
   - Monuments (Vimy Ridge)
   - Simple village memorials
   - Public facilities (community halls, bridges etc)
   - Places dedicated as a war memorial: 2 large areas in the centre of the 
English Lake District including the highest peak in England
   - Arboreta

I am personally not very keen on deprecating tags which represent such a 
significant fraction of the total usage of a key, as it is in effect changing 
the meaning of the key in the database (as opposed to its description in the 
wiki). However I share the sense of awkwardness with the dual meanings implicit 
in the use of the key. In general such tags have been disambiguated by adding 
colons. I'm not at all sure about memorial:theme (a proper tabulation of likely 
values is needed), but memorial:form (or something similar for plaque, wall 
etc) is easier. Note that in many cases the object will not need the form to be 
described if it is a building, man made structure etc). 
My personal suggestions are:
   
   - memorial:commemorates with values of person; event; war (or conflict); 
building ...
   - just a simple war_memorial=yes (which perhaps fits better with the wide 
range of object which could be tagged).

As for arboreta, I have been wondering for some time about a garden tag for 
describing all the different features of large gardens, and arboreta are common 
features. The idea needs work, but would include arboretum, alpine, herbaceous, 
systematic & perennial beds, various kinds of glass houses, wild flower 
gardens, species collections etc.
Jerry

  From: Warin <61sundow...@gmail.com>
 To: tagging@openstreetmap.org 
 Sent: Thursday, 5 October 2017, 5:27
 Subject: Re: [Tagging] war_memorial
   
 On 05-Oct-17 01:58 PM, Graeme Fitzpatrick wrote:
  
 Thanks everyone for your thoughts re arboretums 
  Why I brought this up - had a look at the historic=monument tag yesterday 
morning, which lead me to http://wiki.openstreetmap.org/wiki/CheckTheMonuments 
& http://www.historic.place/themes/monuments/map.html. 
  That showed 4 monuments in my general area, 2 of which should apparently be 
memorials, 1 I'm not sure about & this one: 
http://www.openstreetmap.org/#map=18/-28.00759/153.38376. 
  The "Regional Arboretum" is shown as a monument &, by the conversations here, 
almost certainly shouldn't be (maybe it should be a Memorial? - will have to 
get up there & check it out on the ground); while the "ADF Grove" is, almost 
certainly correctly, a Memorial. 
  Now, if the Regional Arboretum isn't actually marked as being a memorial to 
anybody / thing, & therefore not a memorial, how should it then appear in OSM? 
The Botanic Gardens as a whole are shown as landuse=recreation_ground; 
leisure=park. From a Google satellite shot 
https://www.google.com.au/maps/@-28.0070891,153.3834806,174m/data=!3m1!1e3?hl=en,
 the Regional Arboretum is only an open group of trees, so how should it be 
mapped? 
  It's definitely not intended for forestry / logging purposes, so it's not 
landuse=forest 
  It's hardly a forest, so not natural=wood 
  Doesn't produce anything so not landuse=orchard 
  Leisure=garden? Garden brings to mind flowers & bushes, not trees, but I 
guess it may still apply? 
   
 
 Sydney Royal Botanic Garden is  tagged as
 leisure=garden
 garden:type=botanical
 
 Possibly 
 leisure=garden
 garden:type=arboretum?? 
 I think this is the best solution I have - not documented and no actual 
existence in the data base. 
 
 Way 21370319 (Nottingham Arboretum) is tagged as
 name=Arboretum
 leisure=park
 this looks wrong to me .. the name may just be a description. 
 
 The Australian Canberra arboretum is tagged as
 tourist=attraction 
 
 
 A quick look has arboretums tagged as 
 forest (!), conservation, grass (!), leisure=nature_reserve and probably other 
things. 
 
 Will be interesting to see where this goes.
 
 
 I have mapped some 'local' memorials

Re: [Tagging] Proposed deletion of wiki pages about motorcycle_friendly=*

[Thilo Haug OSM]

You're talking about things like this ?
http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dinsect_hotel

Have those all been discussed ?
http://wiki.openstreetmap.org/wiki/Seamarks/Seamark_Object_Usage

When is it "low usage" ?
And how should usage appear (in a structured way),
if it's not documented ?
There's also low usage on those
(as there aren't many yet)
http://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dspaceport
There was a bunch of different values before,
as everybody mapped it the way he/her thought it might be right.

I didn't understand how those (motorcycle) tags might cause others to be
"not identifiable any more".

There weren't "various comments of other mappers",
there were mainly various comments by Warin61 :
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/motorcycle_friendly


Am 03.10.2017 um 11:52 schrieb Martin Koppenhoefer:
>
>
> 2017-10-03 11:34 GMT+02:00 Thilo Haug  >:
>
> Please describe which 'problems' you fear to appear if it's not
> deleted.
>
>
>
> If everybody creates feature pages for his personal, low usage
> features, the wiki looses it's function of documenting the generally
> used and established features, as they are not identifiable any more.
> You already have the proposal page, which states that this is a
> proposal, and documents the tags, no need to create confusion and
> clutter with a feature page that is not justified at this point.
>
> In the discussions about this tag, there have also been various
> comments of other mappers, that explained why they think that these
> tags are not suitable, so it should probably considered disputed.
>
> Cheers,
> Martin
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: logo tag. Opinions?

[Jerry Clough - OSM]

Aren't the legal arguments insuperable?
Even if logos are held in Wikimedia commons I very much doubt that the licence 
on Wikimedia commons is accurate. Most large companies will defend the use of 
their brand image fiercely. 
In practice to use logos and other trademarks on a map one should get explicit 
permission from the owner of the logo. Yes it is done, for instance in shopping 
mall maps, but this will usually be covered by associated legal agreements.
An excellent example is the Transport for London roundel. This image says it is 
""It does not meet the threshold of originality needed ",  but below it notes 
that it may be a trademark in some jurisdictions. TfL on the other hand have 
very clear guidelines: Logo requestsand are known to be litigious.
I would therefore suggest adding explicit links to potentially 
copyright/trade-mark infringing material is not a good idea for OSM. Wikipedia 
may be large enough and have a good enough mind share for large companies to 
tolerate the presence of logos in the commons. It is not clear that this is the 
case for OSM: particularly as the most obvious use-case for logos is in maps of 
public transport networks.
So, although I sympathise with the idea, I'm very dubious about promoting it 
within OSM.
Jerry


  
|  
|   
|   
|   ||

   |

  |
|  
|   |  
Occupy London crowdsources new logo
   |   |

  |

  |

 

  
|  
|   
|   
|   ||

   |

  |
|  
|   |  
Logo requests
 By Transport for London | Every Journey Matters Restrictions on using the TfL 
roundels.  |   |

  |

  |

 
  From: Philip Barnes 
 To: tagging@openstreetmap.org 
 Sent: Tuesday, 19 September 2017, 13:18
 Subject: Re: [Tagging] Proposal: logo tag. Opinions?
   
Ignoring the legal arguments for a moment, but what would OSM gain or do with 
this information. How would it help us build a better map?

Phil (trigpoint) 

On 19 September 2017 08:10:15 BST, SwiftFast  wrote:
The logo tag would link to a Logo of a company/organization/shop.

To avoid unreliable links, questionable licenses, and the rest of the
drawbacks of the "image"[1] tag, the value must link to a Wikimedia
Commons image. The value format is identical to the
wikimedia_commons[2] format.

[1] https://wiki.openstreetmap.org/wiki/Key:image
[2] https://wiki.openstreetmap.org/wiki/Key:wikimedia_commons


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


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


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

Re: [Tagging] Feature Proposal - RFC - shop=* subtags

[Thilo Haug OSM]

Thanks for the really exotic examples,
I'd say this is :

optician also selling delicatessen

shop=optician
deli:sales=yes
deli:type=?

---

bookshop in Paris, whose best known feature is the bánh mì sandwiches

shop=books
fast_food:sales=yes
cuisine=sandwich

---

sexshop for women, but also selling books and operating a cafe/bar

shop=books
amenity=cafe
erotic:sales=yes

not so sure which one of those (or both ?) :
erotic:clothes=yes
clothes:type=erotic ?

erotic:books=yes
books:type=erotic; ?

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


Tuba is a sexshop for women, but also selling books and operating a
cafe/bar:
http://www.openstreetmap.org/node/258081023
As the sexshop property is not very prominent in the shop I decided to
classify it as a bookshop and cafe.
Am 06.09.2017 um 13:50 schrieb Jean-Marc Liotier:
> On Wed, 6 Sep 2017 13:40:16 +0200
> Martin Koppenhoefer  wrote:
>> my favorite one is this:
>> http://www.23hq.com/dieterdreist/photo/7089481?album_id=4237494
>> An optician also selling delicatessen (or maybe a delicatessen store
>> also selling glasses).
> http://www.openstreetmap.org/node/2217707756 - Khai Tri is a Vietnamese
> bookshop in Paris, whose best known feature is the bánh mì sandwiches
> stand at the back of the shop... For now in Openstreetmap it is only a
> bookshop.
>
> ___
> 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] farm schools?

[Jerry Clough - OSM]

  From: Tom Pfeifer 
 To: tagging@openstreetmap.org 
 Sent: Monday, 4 September 2017, 22:56
 Subject: Re: [Tagging] farm schools?
   
On 04.09.2017 22:01, Martin Koppenhoefer wrote:
>> On 4. Sep 2017, at 21:45, José G Moya Y.  wrote:
>> In Spanish it is farm_school.
> in italian it's "fattoria didattica" (didactic farm), in German there are 
> different terms in use, e.g. Jugendfarm, Kinderbauernhof.

Hm, in Berlin we have some tagged as

landuse=farmyard + tourism=zoo + zoo=petting_zoo and some description.
This tagging style would have a focus on farm animals (vs. growing plants)

zoo=petting_zoo is currently defined as "Small zoo or garden for kids to touch 
and play with animals"

tom

Some are certainly small petting zoo type places (there used to be a tiny one 
at Bidmi, Oberhasli, CH used to entertain kids after skiiing lessons).
I'm not sure to what extent there are any working farms taking school visits as 
there were in my childhood. The places which seem closest in Nottinghamshire 
are the following:
   
   - White Post Farm. Originated as a petting zoo type place, but has been a 
fully fledged themed attraction for small kids for at least 20 years.   
 
  | 
  |  
  |  
  |  ||

   |

  |
  | 
  |  | 
OpenStreetMap | Way: ‪White Post Farm‬ (‪333264517‬)
 OpenStreetMap is a map of the world, created by people like you and free to 
use under an open license. |   |

  |

  |



   - Floralands Farm Park. Adjunct to a large garden centre.   
 
  | 
  |  
  |  
  |  ||

   |

  |
  | 
  |  | 
OpenStreetMap | Way: ‪Floralands Farm Park‬ (‪53513306‬)
 OpenStreetMap is a map of the world, created by people like you and free to 
use under an open license. |   |

  |

  |



   - Ferry Farm Park. I've just added more detail to this one.
   - Manor Farm, East Leake. (I have a feeling that was the one I went to back 
in 196x).   
 
  | 
  |  
  |  
  |  ||

   |

  |
  | 
  |  | 
OpenStreetMap | Way: ‪Manor Farm & Woodlands‬ (‪383289850‬)
 OpenStreetMap is a map of the world, created by people like you and free to 
use under an open license. |   |

  |

  |


   
 
  | 
  |  
  |  
  |  ||

   |

  |
  | 
  |  | 
OpenStreetMap | Way: ‪Ferry Farm Country Park‬ (‪488431410‬)
 OpenStreetMap is a map of the world, created by people like you and free to 
use under an open license. |   |

  |

  |



   - Stonebridge City Farm. This is located within an inner-city area, and is 
owned and run by the local council. It is meant to be both an education and 
leisure facility. Just mapped as attraction with farmland. I think there are 
other "city farms" in the UK, which could perhaps be tagged explicitly.   
   
 
  | 
  |  
  |  
  |  ||

   |

  |
  | 
  |  | 
OpenStreetMap | Way: ‪Stonebridge City Farm‬ (‪30802891‬)
 OpenStreetMap is a map of the world, created by people like you and free to 
use under an open license. |   |

  |

  |



Many are tagged either tourism=attraction and attraction=farm_park or 
tourism=farm_park. Most are also tagged with farmland and/or farmyard landuse. 
Farm Park does seem to be the current favoured term for these, at least in this 
part of England. However, note that none of these is a working farm anymore: 
they are attractions with farm animals in a semi-zoo format along with various 
play facilities (pedal go-karts, soft-play and adventure playgrounds). If 'farm 
schools' elsewhere are an ancillary feature of working farms then I think the 
farm_park tag doesn't fit. City farms and the small petting 'zoo' farm features 
are different again.
Hope these additional data points are useful (and also that this email gets 
formatted properly: will repost if not),
Jerry


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

Re: [Tagging] Feature Proposal - RFC - building:architecture:preromanesque

[Jerry Clough - OSM]

First a comment on British usage. The main Romanesque period in Britain does 
start in the middle of C11 more-or-less coincident with the Norman Conquest. 
Although some large Romanesque churches were built earlier most were re-built 
in the decades following the conquest (e.g., Winchester), and thus there are 
few remains from earlier. Churches (pretty much the only surviving buildings) 
from earlier than around 1000 will be described as Anglo-Saxon (examples: 
Brixworth, Deerhurst (both a church & Odda's Chapel), Escomb). Most are small, 
Brixworth being the notable exception. In practical terms there is no Celtic 
architecture in Britain, unless one counts Brochs. In Ireland there are 
monastic buildings which perhaps could be assigned a Celtic designation: most 
have roofs made of corbelled stone and are therefore rather small (e.g., 
Skellig Michael).
Second: I was unfamiliar with the term pre-Romanesque, and would have expected 
buildings such as the abbeys at Mustair, Reichenau; the Carolingian chapel at 
Germingy-des-Pres to be included in the category. However the term does seem to 
be in widespread use (e.g., in my copy of Auvergene Romane). It's therefore 
certainly a good idea to document it (which you have already done).
Thirdly, I suspect using the locally well-known terms -  Anglo-Saxon, 
Carolingian, Mozarabic, Visigothic - may be more informative, and sometimes 
less complicated. For instance I'm not sure if the C7 Saxon churches truly 
belong to an early form of Romanesque or not; similarly for the baptistery at 
Poitiers. 
Notwithstanding these comments I would do as Andy says. By all means use a tag 
if it works for you. My only suggestion is that locally-named subsets should 
preferably be sub-tagged. Comparing English Anglo-Saxon Architecture with 
products of the Carolingian Renaissance may not be that useful.
Regards,
Jerry

  From: José G Moya Y. 
 To: tagging@openstreetmap.org 
 Sent: Friday, 18 August 2017, 10:58
 Subject: [Tagging] Feature Proposal - RFC - building:architecture:preromanesque
   
I propose this tag to describe middle age buildings created before the 
"romanesque revolution" of the 11th century. I guess english people would like 
something like "celtic", but I am using "preromanesque" instead of "celtic" 
because in Spain there is no "celtic" middle age architecture.
In my country, this tag could be used to describe "mozarabic" buildings along 
with "visigothic" buildings. I hope this be useful to other european countries, 
too.
Help from art historians would be useful to refine the proposal.
See the link here:
https://wiki.openstreetmap. org/wiki/Proposed_features/ building:architecture% 
3Dpreromanesque


Yours,
José Moya (Jose M)
El 18/8/2017 10:17, "José G Moya Y."  escribió:

I am proposed this tag to describe middle age buildings created before the 
"romanesque revolution" of the 11th century. I guess english people would like 
something like "celtic", but I am using "preromanesque" instead of "celtic" 
because in Spain there is no "celtic" middle age architecture.
In my country, this tag could be used to describe "mozarabic" buildings along 
with "visigothic" buildings. I hope this be useful to other european countries, 
too.
Help from art historians would be useful to refine the proposal.
See the link here:
https://wiki.openstreetmap. org/wiki/Proposed_features/ building:architecture% 
3Dpreromanesque


Yours,
José Moya (Jose M)
___
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] dispersed settlements / scattered settlements

[Jerry Clough - OSM]

We have plenty of examples of dispersed/scattered settlement patterns which 
have been mapped without having to worry about lack of tags: more or less the 
entire Celtic fringe of NW Europe (Brittany, Cornwall, Wales, Ireland, Scottish 
Highlands) shows this settlement pattern. The nucleated towns of Ireland & 
Wales being introduced by settlers (invaders?) such as Vikings or Anglo-Saxons. 
In addition many mining areas in Wales show a later dispersed settlement 
pattern. The medieval administrative units (parishes) which have often ended up 
as contemporary admin units often have little correspondence with the actual 
settlement pattern and thus defining boundaries for toponyms may be difficult.
The exception, of course, are townlands in Ireland.. These are ancient bounded 
land units which are the primary descriptive toponyms in much or rural Ireland. 
These are all mapped as place=locality, but with an additional attributive tag 
locality=townland. I would see this as a precedent, and one could envisage 
locality=dispersed_settlement.
However, looking at Wales and Brittany, I think the nature of dispersed 
settlement is to create a finer grain of toponymy. Many villages in Wales which 
these days appear nucleated have origins as rather dispersed places, a good 
example which I know well is Llanfair PG on Anglesey. Within living memory 
(mine) the parts of the settlement were known as Pentre Uchaf & Pentre Isaf 
(Upper & Lower), and I think it's likely that many local toponyms of this sort 
were not recorded by map makers. Elsewhere in Wales places where members of the 
family lived tend to be referred to either by the name of the village/parish or 
by the name of the farm/house. For the most part the latter are not true 
toponyms in Britain.
In Brittany there are even signposts showing how to find all the localities of 
a commune in the chef-lieu (I have photos of some with perhaps 60 or so place 
names). These days many can be suitably tagged with place=hamlet, 
place=locality or possibly place=isolated_dwelling. Once again changes in the 
past 40 years or so obscure some of the more obvious features of these places 
(i.e., places which had a few farmsteads and no mains water or sanitation in 
the 1970s are now lived in by commuters).
In summary: we have an excellent source of mapped dispersed settlements in 
Europe; absence of any specific tags for such places has only slightly impeded 
mapping (although perhaps a rigorous insistence on locality having no 
population may make it harder); there are reasonable precedents (townlands.ie) 
for using a locality tag to add further information; and, lastly, the 
relationship between zoonyms, admin boundaries and settlements is likely to be 
complex in such places requiring good local & historical knowledge.
Jerry
  
|  
|   
|   
|   ||

   |

  |
|  
|   |  
OpenStreetMap
 OpenStreetMap is a map of the world, created by people like you and free to 
use under an open license.  |   |

  |

  |

 


.

  From: Martin Koppenhoefer 
 To: "Tag discussion, strategy and related tools"  
 Sent: Friday, 16 June 2017, 11:25
 Subject: Re: [Tagging] dispersed settlements / scattered settlements
   


sent from a phone

> On 16. Jun 2017, at 11:45, Warin <61sundow...@gmail.com> wrote:
> 
> A minimum of 10 residential dwellings


I'd set the minimum as 2-3 (above isolated dwelling)


> each separated from the others by at least 500 meters, with a maximum overall 
> area of 5 square kilometres



for me they don't have to be _each_ separated and there mustn't be a minimum 
distance, it's sufficient that they don't form a nucleus. I'd also not limit 
this by any maximum area, the criterion is that there is a name for the 
ensemble.


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


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

Re: [Tagging] Voting: expand the aeroway key with aeroway=spaceport, aeroway=landingpad, aeroway=launchpad

[Thilo Haug OSM]

Another reminder :
Vote end: 2017-05-30 (in 4 days)

Cheers,
Thilo

Am 16.05.2017 um 10:28 schrieb Martin Koppenhoefer:
> Just a reminder: today voting for the aeroway key redefinition is
> starting, please vote:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/include_spacecraft_in_aeroway
>
> Cheers,
> Martin
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk-be] Missing oneway:bicycle=no / Wiki editing

[Thilo Haug OSM]

Hi André,

according to this documentation,
the tagging mailing list is the wrong platform to address this  :
"*If you have ideas for the wiki, you can generally just do them, by
editing the wiki! *
If you need any assistance the *wikiteam* are here to help."
https://wiki.openstreetmap.org/wiki/Wiki#Wikiteam

Unless some always ask for a proposal to edit /amend anything in the wiki.
IMHO this leads to the result you mentioned :
"Unfortunately, I'm very sorry to say, OSM is often much of a chaos."
There seem to be very few people which first like to request a request form
to be able to help the community to improve *.

A "code of conduct"** would be helpful in which cases
you may just add a minor specification, unfortunately I couldn't find
such up to now.

Cheers,
Thilo

* For those who don't know the concept of sarcasm :
https://en.wikipedia.org/wiki/Sarcasm

** Certainly this will also leave some (border) cases which are disputable,
but at least there would be SOME agreed guideline.
https://en.wikipedia.org/wiki/Code_of_conduct

Am 10.05.2017 um 15:10 schrieb André Pirard:
> Hi,
>
> In this thread, I said, in agreement with others,
> that oneway:bicycle
> <https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle>=no (click to
> open that page) is the tag to be used *to tell routing
> software**(GPS)* that *oneway*=yes
> <https://wiki.openstreetmap.org/wiki/Key:oneway>does not apply to bicycles
> that cycleway
> <https://wiki.openstreetmap.org/wiki/Key:cycleway>=opposite* has
> noting to do with routing and contraflow but indicates that *there is
> a cycleway* that *happens* to be "opposite".
>
> Could you please make the wiki documentation more clear about that?
> Because mappers often believe that cycleway=opposite means to indicate
> bicycle contraflow oneway:bicycle=no.
> Unfortunately, sometimes contradictory sentences about the same
> concept are often spread all over the wiki.
> Find them all!
>
> I have written this script
> <http://overpass-turbo.eu/?Q=%0A%5Bout%3Ajson%5D%5Btimeout%3A60%5D%3B%0A%2F%2F%20gather%20results%0A%28%0A%20%20%2F%2F%20query%20%0A%20way%5B%21%22oneway%3Abicycle%22%5D%5Bcycleway%7E%22opposite%22%5D%28%7B%7Bbbox%7D%7D%29%3B%0A%20%20%0A%29%3B%0A%2F%2F%20print%20results%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%20qt%3B%0A%0A>
> to find where many cycleway=opposite* exist without oneway:bicycle=no
> and even without oneway=yes.
>
> Look at this street <https://www.openstreetmap.org/way/55150670> to
> which GRi added cycleway=opposite without oneway:bicycle=no, to which
> JanFi added oneway:bicycle=no  probably after reading this thread
> (thank you!) and from which I removed cycleway=opposite because there
> is no cycleway at all.
>
> The worst of all is that the map
> http://mijndev.openstreetmap.nl/%7Eligfietser/fiets/ shows
> "cycleway=opposite or oneway:bicycle=no" ways, hence neither
> identifying the cycleways  nor the contraflow correctly and not
> testing in its bugs tag that cycleway=opposite must contain
> oneway:bicycle=no.
> That is pitiful complete misinformation and the author did not even
> reply to my message.
>
> Unfortunately, I'm very sorry to say, OSM is often much of a chaos.
>
> Hoping this will help,
> Cheers
>
> André.
>
>
>
>
>
> ___
> 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] aeroway=spaceport, aeroway=launchpad, aeroway=landingpad

[Thilo Haug OSM]

Hi Martin,

I have no clue what you mean with "downloaded the other day all objects",
I just adjusted a couple of objects (~5) whose tagging was very erratic.

In a lot of wiki descriptions is mentioned to "just act" if necessary.
I've taken the most common parameters and combined them with the most
obvious (existing) key.
That's not rocket science... ;-)
If someone feels that this should be documented more specific he/her is
free to do so.

I think we will discourage a bunch of potentially interested
contributors to add anything
if some request a discussion / proposal ("doctorate") for every slight
adjustment/documentation update.
There are some (older) opinions here, I think this should be followed up:
http://wiki.openstreetmap.org/wiki/Talk:Proposal_process#Cleanup_Request
One example :
Yeah. The mailing list is kind of daunting. It seems to get a zillion
messages a day, but if I want to cut to the chase and discuss a new
feature I feel it will be lost in the noise. Meanwhile the wiki has
perfectly adequate features around watchlists and discussion pages that
don't require me to parse all that noise just to hear the one
conversation that I am interested in. Karora 10:39, 4 January 2008 (UTC)

Cheers,
Thilo

Am 02.05.2017 um 13:04 schrieb Martin Koppenhoefer:
>
> 2017-05-01 23:14 GMT+02:00 Thilo Haug OSM  <mailto:th...@gmx.de>>:
>
> [...]  changing without reviewing cases individually
>
>
>
> this one?
>
> It leaves a bit of a bad taste if you declare on the mailing list 'I'm
> getting tired of this "discussion and proposal" stuff' and then it
> gets discovered you downloaded and modified the other day all objects
> of a certain kind to unify their tagging with a previously
> undocumented and hardly used tag, and then modify the wiki to document
> this style of tagging. And then write an announcement here without
> telling anybody that you modified these objects to fit your documentation.
>
> On the other hand, I don't think it is completely harmful what you
> have done, because there are so few of these objects and we would all
> benefit from uniform tagging. The main issue is with the key you
> chose, of which the general definition is in contradiction with the
> specific tag you added, but I am trying to fix tis by extending the
> key definition with a proposal.
>
> Cheers,
> Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] aeroway=spaceport, aeroway=launchpad, aeroway=landingpad

[Thilo Haug OSM]

Am 01.05.2017 um 22:34 schrieb Martin Koppenhoefer:
> surely their performer didn't follow the automated edits code of conduct.
O really, which case applies ?

  * changes made by Bots ,
which by definition act autonomously from human intervention.
  * data imports , including
both fully automated imports and ones where a standard editor is used;
  * other scripted changes made to the database;
  * [...]  changing without reviewing cases individually

https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct


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

[Tagging] aeroway=spaceport, aeroway=launchpad, aeroway=landingpad

[Thilo Haug OSM]

Hello all,

as aeroway=spaceport was already in use,
I created a wiki description for it :
https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dspaceport

Launchpad is also in use :
http://overpass-turbo.eu/s/oL2

I case you feel this should be further discussed,
please leave your comment here :
https://wiki.openstreetmap.org/wiki/Talk:Tag:aeroway%3Dspaceport

Cheers,
Thilo


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

Re: [Tagging] wikipedia links and copy + paste in tag definitions

[Thilo Haug OSM]

Hello all,

so what is the principle of the "organisation of information" in OSM ?

Up to now, I couldn't find a documentation that explains
the general philosophy how to tag items.

Cheers,
Thilo

> different organisation of information.
> will very likely not be what we want.



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

Re: [Tagging] wikipedia links and copy + paste in tag definitions

[Thilo Haug OSM]

> Do not falsely conflate "complex" with "worse". You original complaint
> was, in effect, that there was a lack of complexity, now you complain
> that there is.
In the OSM Wiki there's enough complexity
(and not everything is "orthogonal").

If you'd like to tag tourism POIs,
you should check several wiki pages :

https://wiki.openstreetmap.org/wiki/Key:tourism
https://wiki.openstreetmap.org/wiki/Key:amenity#Sustenance
https://wiki.openstreetmap.org/wiki/Key:sport#Core_values
https://wiki.openstreetmap.org/wiki/Key:leisure

All of those are interesting when on holidays
but there's no overview about that and the pages aren't linked.
Quite complex for a beginner
(what will an OSM navigation app user be interested in first ?)

Sometimes it's not clear why an item is in a certain category,
for example : why is this an "amenity" and not a "shop=vending_machine" ?
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dvending_machine
(or an own key vending_machine=).

You will always have differences in definitions, especially in different
countries.
There's a nice example in the German Duden dictionary / Duden
Fremdwörterbuch (foreign word dictionary) :
"intellectual" is in one defined as someone with higher education,
in the other one as someone who questions things critically "in a mental
creative way".
Doesn't exclude each other, but quite different.

I agree that in some cases it might be difficult (just) to link to
wikipedia,
but I'm pretty sure that it helps to get some background information
about the "big picture"
in case you personally just know certain aspects of this item.

Cheers,
Thilo

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

Re: [Tagging] aeroway=spaceport , aeroway=launchpad

[Thilo Haug OSM]

Hi Frederik,

I think the main difference is
that spaceports already exist (and are "on the ground") :
https://en.wikipedia.org/wiki/Spaceport
https://en.wikipedia.org/wiki/List_of_rocket_launch_sites

In case of the skyhook I'm not so surprised of the denial,
given the culture of denial without constructive criticism
which isn't controlled a.t.m. by an appropriate social rule.
Will IMHO get worse the more people participate,
imagine all facebook-users commenting proposals...

What do you think about aeroway=spaceport ?
I'm not a specialist in spaceport infrastructure,
but I'd generally like to be able to filter for them in OSM,
which isn't possible if they are tagged as
"amenity=space_centre/spaceport/cosmodrome/..."
See the examples mentioned here :
https://wiki.openstreetmap.org/wiki/Talk:Aeroways#aeroway.3Dspaceport

For further details I could imagine using
aeroway=launchpad
(similar to https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dhelipad)

The rest of the buildings should IMHO be similar to an airport,
or standard tags may be used :
https://wiki.openstreetmap.org/wiki/Aeroways
https://wiki.openstreetmap.org/wiki/Tag:building%3Dbunker

Cheers,
Thilo

Am 28.04.2017 um 20:45 schrieb Thilo Haug OSM:
> Hi all,
>
> I'm astonished there isn't a description for spaceports yet,
> therefore the tagging differs widely :
> https://wiki.openstreetmap.org/wiki/Talk:Aeroways#aeroway.3Dspaceport
>
> - Proposals / Opinions ?
>
> IMHO amenity doesn't fit well,
> as it's just another kind of airport.
>
> Cheers,
> Thilo
>
>
>
> ___
> 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] aeroway=spaceport

[Thilo Haug OSM]

Hi all,

I'm astonished there isn't a description for spaceports yet,
therefore the tagging differs widely :
https://wiki.openstreetmap.org/wiki/Talk:Aeroways#aeroway.3Dspaceport

- Proposals / Opinions ?

IMHO amenity doesn't fit well,
as it's just another kind of airport.

Cheers,
Thilo



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

Re: [Tagging] "Feature Proposal - RFC - (office=courier)"

[Thilo Haug OSM]

In Germany this is the same :
https://en.wikipedia.org/wiki/Deutsche_Post


Am 15.04.2017 um 17:04 schrieb Marc Gemis:
> On Sat, Apr 15, 2017 at 2:14 PM, Paul Johnson  wrote:
>> How is it not a post office that just happens to have an operator other than
>> the state?
> So if I ask you "where is the nearest post office?" , it is possible
> that you send me to a DHL office ?
>
> m
>
> ___
> 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] office=therapist??

[Thilo Haug OSM]

I think it's similar to :
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dmassage

"office" is really strange


Am 13.04.2017 um 23:23 schrieb John Willis:
>
>
> Javbw
>
> On Apr 14, 2017, at 4:42 AM, Martin Koppenhoefer
> mailto:dieterdre...@gmail.com>> wrote:
>
>> Looking through the current list of documented office values I came
>> across so that really sound odd to me, e.g.
>> https://wiki.openstreetmap.org/wiki/Tag%3Aoffice%3Dtherapist
>>
>> wouldn't this be much better suited for the amenity tag?
>>
>> cheers,
>> Martin 
>>
>> sent from a phone
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/tagging
>
> I'm guessing it is a catch-all for offices (businesses) of therapists,
> psychologists, and other guidance/counselor people. 
>
> Therapists have offices, so perhaps similar to shop=* , people are
> using office=* to define various companies that you would find in
> building=office, similar building=retail, because the idea of
> "amenity" can be really confusing and is full of all kinds of things
> now...  
>
> Javbw. 
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Restaurant that doesn't sell alcohol...

[Jerry Clough - OSM]

Hi,
There are two examples of byob=yes, one of bring_your_own_wine=yes, and one 
alcohol=bring_your_own_bottle.
No doubt there are other tags of which I'm not aware. I would have thought that 
London must have a goodly number of BYOB establishments, and surely more than 4.
Regards,
Jerry

  From: Dave F 
 To: "Tag discussion, strategy and related tools"  
 Sent: Monday, 10 April 2017, 13:54
 Subject: [Tagging] Restaurant that doesn't sell alcohol...
   
Hi

I've a restaurant that doesn't sell alcohol but allows customers to 
bring their own & the restaurant will open & serve it.

I can't find anything relevant in taginfo. Any ideas?

DaveF

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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


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

[Tagging] Feature Proposal - RFC - drying:*=*

[Thilo Haug OSM]

Hello all,

please check this proposal and comment on the discussion page :
https://wiki.openstreetmap.org/wiki/Proposed_features/drying

This is thought for all kinds of sport accommodations
which offer a possibility to dry your equipment.

Thanks in advance,
Cheers,
Thilo


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

Re: [Tagging] Vertical farming vs. other vertical plants

[Thilo Haug OSM]

Hello all,

regarding vertical plants,
some examples against air pollution came to my mind.
it's not really "farming", but at least an "artificial" way to grow plants,
so it doesn't really fit with "natural"
http://wiki.openstreetmap.org/wiki/Key:natural

Do you think this should be considered ?

I could imagine to extend this tag for it :
http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dvillage_green
Something like this ? :
landuse=village_green
landuse:type=vertical
landuse:horticulture=lichen,moss

Existing keys :
http://wiki.openstreetmap.org/wiki/Key:plant_community
http://wiki.openstreetmap.org/wiki/Key:trees

In the press :
http://www.nytimes.com/2012/04/10/world/americas/vertical-gardens-in-mexico-a-symbol-of-progress.html
http://www.huffingtonpost.com/toby-nwazor/new-yorks-biggest-ever-gr_1_b_12450500.html
http://www.dw.com/en/stuttgart-builds-moss-covered-wall-to-fight-air-pollution/a-37866760

Some more links :
https://www.witpress.com/Secure/elibrary/papers/AIR15/AIR15025FU1.pdf
http://www.iasp.asp-berlin.de/bilder/poster1302.pdf
http://ccap.org/green-walls-living-walls-green-roofs-courtesy-of-epa-pnc

Selling plant walls :
http://www.plantsonwalls.com/Default.asp
http://plantwalldesign.com/eng/home.html

Cheers,
Thilo

Am 15.03.2017 um 07:32 schrieb Warin:
> On 15-Mar-17 05:14 PM, Martin Koppenhoefer wrote:
>>
>>
>> sent from a phone
>>
>> On 15 Mar 2017, at 04:39, Dave Swarthout > > wrote:
>>
>>> I've seen this list run on and on with discussions about how to tag
>>> wastebins and such but for this one, an arguably important future
>>> tagging construct, hardly a ripple. And members who are usually so
>>> vocal about tagging issues are strangely quiet.  Martin? Warin?
>>> John? Marc? What's up?
>>
> Simple.
> What are you tagging?
>
> The farm?
> landuse=farmland
> produce=?
>
> The factory where the produce is turned into product
> Landuse=industrial
> building=factory
> product=?
>
> The shop where the product is sold
> landuse=commercial
> shop=?
> sells=?
>
>>
>> I don't see a big difference between growing grass and growing
>> marijuana, similarly corn. At least if it's grown outdoors without
>> the help of artificial lighting.
>> Have a look at the key crop: https://wiki.openstreetmap.org/wiki/Key:crop
>> Well, besides that it is quite rare, mostly illegal with the
>> exception of some fields operated for the pharmaceutical industry
>> (the high THC concentration one). Then there's also kind of a
>> comeback of hemp for fibre production (low THC concentration, legal
>> in the EU).
>>
>> Vertical farming sounds interesting, but isn't something I've yet
>> seen in the real. There have been some projects in Europe as well,
>> but AFAIK have not been realized, see e.g. this one by dutch
>> architects MVRDV:
>> https://www.mvrdv.nl/projects/181-pig-city#/archive
>> http://www.alternet.org/story/135410/high_rise_farms_the_new_model_for_sustainable_cities
>>
>>
>>
>> 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] charging station power output

[lucas-osm]

> Most sockets have a stated maximum for any installation no matter where they 
> are installed (house, factory, charging station).
> I think this will be the same for your charging stations? In other words - 
> this does not change in a given distribution area (country).
> From this you can determine the minimum recharge time - assuming the maximum 
> socket power is available, an optimistic value.
For some sockets this is true, like the Schuko and the CEEs, they always 
operate on their maximum: Schuko 3,5kW, cee_red_16a 11kW, cee_red_32a 22kW. But 
others don't. E.g. the Type2 is specified for 3-70kW.
https://en.wikipedia.org/wiki/Type_2_connector (first paragraph). And most of 
the stations I’ve seen only provided 3,5kW or 22kW or 43kW on these Type2s. 
This strongly depends on accessibility to the power grid.
The Type2_combo currently seems to be standardized for 150kW and according to 
Wikipedia car manufactures are trying to build stations providing 350kW at this 
socket https://en.wikipedia.org/wiki/Combined_Charging_System. Most stations 
currently provide 50kW at these, so there will be stations from 50-350kW.
Currently there are already many different implementations out there and the 
variety on power one socket can provide will increase in the future. That's why 
I think the max. power per socket is so interesting. Primarily on those sockets 
particularly designed for charging cars. Because locally there isn't always 
enough power available and DC charging requires rectifiers build into the 
station itself. This increases the cost drastically, that's why not all 
providers go with the maximum these sockets can handle.

> Where a charging station limits the total output power due to the number of 
> sockets in use ...
> You cannot determine from OSM how many are in use at the moment, nor how many 
> might be in use in an hours time nor their respective loads (and these may 
> well change over time)
>  ... so you cannot determine the charge time ... because of the variable 
> number of sockets and their power requirements that are in use now and into 
> the future.
> So the information maybe of little very real value?
That’s right. We do not know how many currently are in use, or maybe will in 
the future. That’s why we can not determine the exact time necessary to charge. 
But if we know the station got 3 sockets each of them say 50kW and the whole 
station only got an input of 60kW. This means each socket could in the worst 
case only provide about 20kW. But if we knew the whole station got an input of 
120kW, each socket could provide 40kW. That’s a huge difference. This way the 
driver can make himself an idea about the worst and best case scenarios.
I do not own an electrical car, but someone I know does. He told me the input 
of the station + number of sockets available + single socket’s power really 
matters to him in planning his trips. That’s the reason I started thinking 
about mapping this in OSM.

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

[Tagging] charging station power output

[lucas-osm]

Hey guys,
 
two of the criteria on charging stations that matter the most to the drivers 
are the max. power output of the whole station and the max. power output of the 
socket compatible with my car. The power output of a specific socket gives some 
orientation on how fast you can charge in the best case. Regardless of other 
cars charging simultaneously or the battery’s charging level.
It’s useful to know the max power available for the whole station, because this 
power will be shared among all sockets. So for example if one station only got 
one socket, these values would be equal. But if you have one with three 
sockets, your current charging power does not only depend on the sockets max, 
but also on the total power available.
That’s why these readings should be directly or indirectly available through 
calculation.
Calculating the max. power is really easy. You just need to know the max. 
amperage (I), the max. voltage (U) and the number of phases (#np) the current 
is delivered in (do you say that?).
p = square_root(#np) * I * U
So a normal Schuko socket would give us roughly square_root(1) * 16A * 230V = 
3,7kW at best. A Schuko always operates on one phase. So you could say that’s 
great, we can determine the phases just by looking at the socket type. But 
sadly there are sockets which can operate at one or three phases. For example 
the Type2. Just by looking at this one you are not able the tell how many 
phases are in use. That’s a problem.
Theoretically say there would be a tag specifying the phase count, at least for 
those with unclear count (assumed we could find this on the station somewhere), 
there would be another issue: The Type2 socket can not only operate on direct 
current (DC) or alternating current (AC), but also on both simultaneously. I 
guess DC and AC will not operate on the same amperage / voltage.
This is getting really messy. As a driver you do not have to worry about the 
max. voltage or max. amperage one station is able to provide at a socket to 
determine if you are able to use and charge at a specific station. Because 
Type2, Type2 Combo etc. all ask your car via pulse-width modulation about it’s 
limits. If you’ve got the right socket or an adapter, only the maximum charging 
speed (depends on power output) matters.
I hope the above was not too confusing. If something in this explanation is 
somehow unclear to you please tell me.

That’s why I’d propose to add a tag describing the power output of the whole 
station and every single socket.
Obviously the power=* tag is no potential candidate, because it’s already in 
use “to identify facilities and features that relate to the generation and 
distribution of electrical power including power lines, power generation ...”.
So what else could we use? Generators already use generator:output=* to 
classify their output in Watts.
What about adopting this scheme like charging_station:output=* to specify the 
max. power output of the whole station, distributed over all available sockets. 
And socket:[socket_type]:output=* to specify the max. power output of one 
specific socket.

An example:
https://upload.wikimedia.org/wikipedia/commons/f/f6/Charging_station_socks.jpg
https://upload.wikimedia.org/wikipedia/commons/4/4a/Charging_station_specs.jpg

charging_station:output=98kW
socket:type2:output=43kW
socket:type2_combo:output=50kW
socket:chademo:output=50kW

As far as I know, these values are always provided on the station itself. On 
the front to inform the user of it’s max. power per socket and on the back 
there’s a specification of the input of the whole station / max. output of all 
sockets. I do not know about other countries, but I think here in Germany this 
sort of specification is mandatory. So through local research you are always 
able to get these values.
IMHO the currently advised tagging scheme of amperage and voltage (for charging 
stations) is meaningless without proper additional information.

What do you think about this?

Thanks a lot!

Lucas

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

Re: [Tagging] A place where letters & parcels are sent to be sorted so they can be delivered?

[Robert Whittaker (OSM lists)]

On 22 February 2017 at 19:56, Dave F  wrote:
> A place where letters & parcels are sent to be sorted so they can then be
> delivered?
>
> In the Britain I think they'd normally be called a sorting office. but
> there's only 21 & 2 for postal_sorting_office from tag info
>
> Is post_depot the same thing? (313 wordwide/212 GB)
>
> Either tag doesn't seem a great number. Is there a more popular one in use?

I've used amenity=post_depot quite a few times in the UK to mean
precisely that. (In particular, I needed something to re-tag Royal
Mail buildings to show that they weren't an amenity=post_office.)
I chose post_depot as a more general term, that would be applicable to
things that might be called a "Delivery Office", a "Sorting Office" or
maybe even something like "Parcel Hub" or "Distribution Centre". The
initial "post_" part mirrored existing "post_office" tag.

Robert.

-- 
Robert Whittaker

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

Re: [Tagging] Dead hedge

[Jerry Clough - OSM]

Just re-read the section in the BCTV handbook and the form they describe under 
"dead hedging" is rather different from the straightforward brash pile. Both 
exist, although in my experience the latter is commoner, but I don't do 
conservation work in woodland suffering from too much grazing by deer.
Note also the use of cut thorny shrubs to create protective barriers in African 
villages.
Either way I would still strongly advise avoiding "dead hedge" as it is not a 
term which is likely to be widely understood, and will clearly be 
mis-understood  In construction these are closest to wattle fences, although 
the construction material which is interwoven  is wood brash rather than nice 
coppice poles.
Jerry



      From: Jerry Clough - OSM 
 To: "Tag discussion, strategy and related tools"  
 Sent: Monday, 20 February 2017, 14:18
 Subject: Re: [Tagging] Dead hedge
   
I've many such things: the material is called brash (sometimes brush) in the 
UK. It is often just collected in piles or in longer rows (typically at the 
edge of the area being worked on) and these are usually referred to as brash 
piles.
Brash is also used to deliberately fill gaps to discourage people (& their 
dogs) from accessing places.
Dead hedge is just not a term that I recognise: it certainly isn't standard 
British English in the conservation sector. Some hedgelaying techniques of 
interweaving can be used, but these are in the main to reduce the size & 
profile of the pile. When used as a barrier brash is usually used to plug small 
gaps rather than to create a continuous barrier. Note that sometimes brash is 
simply not cleared after chainsaw or brush-cutting and this may appear to a 
deliberate rather than a transient & accidental barrier.
I would therefore suggest barrier=brash_pile or brush_pile, and despite 
Wikipedia not dead hedge. Like every other native English speaker on this list 
dead hedge means a hedge where the plants have died.
Jerry

  From: Andy Townsend 
 To: tagging@openstreetmap.org 
 Sent: Monday, 13 February 2017, 21:02
 Subject: Re: [Tagging] Dead hedge
  
On 13/02/2017 20:46, Chris Hill wrote:
>
> It's a fence.
>

+1 to that.

Despite both of the refs on https://en.m.wikipedia.org/wiki/Dead_hedge 
being English ones, it's not an English term I recognise at all, and it 
could have been designed to confuse.

Cheers,

Andy


___
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] Dead hedge

[Jerry Clough - OSM]

I've many such things: the material is called brash (sometimes brush) in the 
UK. It is often just collected in piles or in longer rows (typically at the 
edge of the area being worked on) and these are usually referred to as brash 
piles.
Brash is also used to deliberately fill gaps to discourage people (& their 
dogs) from accessing places.
Dead hedge is just not a term that I recognise: it certainly isn't standard 
British English in the conservation sector. Some hedgelaying techniques of 
interweaving can be used, but these are in the main to reduce the size & 
profile of the pile. When used as a barrier brash is usually used to plug small 
gaps rather than to create a continuous barrier. Note that sometimes brash is 
simply not cleared after chainsaw or brush-cutting and this may appear to a 
deliberate rather than a transient & accidental barrier.
I would therefore suggest barrier=brash_pile or brush_pile, and despite 
Wikipedia not dead hedge. Like every other native English speaker on this list 
dead hedge means a hedge where the plants have died.
Jerry

  From: Andy Townsend 
 To: tagging@openstreetmap.org 
 Sent: Monday, 13 February 2017, 21:02
 Subject: Re: [Tagging] Dead hedge
   
On 13/02/2017 20:46, Chris Hill wrote:
>
> It's a fence.
>

+1 to that.

Despite both of the refs on https://en.m.wikipedia.org/wiki/Dead_hedge 
being English ones, it's not an English term I recognise at all, and it 
could have been designed to confuse.

Cheers,

Andy


___
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] knotted willows

[Jerry Clough - OSM]

There are problems with this approach.
Many trees are pollarded once in their lifetimes: I'm currently looking out at 
some Beech trees which were probably pollarded 70 years ago, and there's a 
Birch which was pollarded rather crudely 50 years ago in the neighbours garden. 
Ancient pollards can be 500 years old. Re-pollarding a tree which has not been 
managed in this way for a long time is a rather hazardous operation for the 
tree. 
  
|  
|   
|   
|   ||

   |

  |
|  
|   |  
Pollarding - Wikipedia
   |   |

  |

  |

 

If a macrophanerophyte is regularly pollarded then it's probably wrong to call 
it a tree. Most coppiced plants will only be allowed to grow to 5-8 m high and 
the individual stems will rarely be more than 10cm diameter. In Britain Hazel, 
Sallows, and Ash are certainly still coppiced. Oak has been coppiced in the 
past as a source of charcoal. However, like pollarded trees neglected coppice 
stools can grow into large multi-stemmed trees. A typical scenario is a wetland 
site where seedlings of any trees are cut close to ground-level ('coppiced') to 
maintain the wetland habitat: this is a relatively easy intervention and can be 
repeated. However, once tree cover can no longer be halted, or when the ground 
dries out, then the coppice stools will be left to grow of their own accord. In 
most former gravel pits in Britain there are numerous examples of 15m high 
mutli-stemmed Crack Willows which originated in this way.
In general I don't think coppicing is a useful thing to apply to an individual 
tree. Coppicing is more usually a woodland management technique and therefore 
belongs to natural=wood and landuse=forest. A typical woodland form in Britain 
is a wood which is coppice with standards. The understorey (most usually Hazel, 
but in Bradfield Woods it's Ash) is coppiced on a cycle which may be from 5-20 
years. Some trees are always retained and form the canopy. Historically the 
understorey produced firewood, and poles, the standard trees were felled for 
timber. 
For individual trees we might recognise the following properties:
   
   - The tree is a pollard (i.e., has been pollarded at least once fairly early 
in its life)
   - The tree is currently managed by repetitive pollarding
   - The tree is multi-stemmed as a result of growing from a coppice stool
   - The tree is multi-stemmed as a result of growing from the planting of 2 or 
more saplings in a bundle (bundle planting)

Tall Common Limes (Tilia x europea) are often managed by a pollarding-like 
process: side branches are removed, the crown is severely reduced, and the 
trunk is cut short at the top. I'm not sure if this qualifies as a pollard.
Additionally there are other styles of regular pruning. For instance fruit 
trees in the Swiss Mittelland are pruned in a way which is very recognisable, 
so that it is quite easy to identify former orchards where the pruning ceased 
decades ago. The tree is usually pruned to have a leader and four principle 
branches. I suspect this Wikipedia article describes the technique in depth. 
Oaks growing in Dehesa (Cork, Holm and Pyrenean) are pruned in a not dissimilar 
manner, perhaps with 3 main branches, but the centre of the crown is kept 
fairly open. You can see examples here. However I would not choose to add this 
information to OSM: it is safe to assume that trees in Spanish Dehesa and Swiss 
Orchards will generally be manage this way. Quite beside which there are 
something like 37 million oaks in the dehesas of Extremadura.
Jerry


  
|  
|   
|   
|   ||

   |

  |
|  
||  
Dehesa
   |   |

  |

  |

 

  
|  
|   
|   
|   ||

   |

  |
|  
|   |  
Oeschbergschnitt – Wikipedia
   |   |

  |

  |

 
  From: joost schouppe 
 To: "Tag discussion, strategy and related tools"  
 Sent: Friday, 17 February 2017, 16:26
 Subject: Re: [Tagging] knotted willows
   
Considering that there are several management styles for individual trees, we 
could have something like
tree:managament=pollard
Other values might be none (allowed to grow free), copicce (pruned almost to 
the ground), espalier (pruned into a flat vertical surface), etc.
tree:management:operator=* could then be used to indicate who is keeping the 
tree pruned. 

Maybe tree:pruning_style would be more logical?
2017-02-11 13:34 GMT+01:00 Wolfgang Zenker :

Hi,

* joost schouppe  [170211 09:43]:
> One of the defining small landscape elements in Flanders (and probably many
> rural areas in Europe) is the "knotted willow". I'm not sure if this is the
> right term in English, in Dutch "knotwilg" really is a thing.

> How would you tag such a thing? (I could not find any previous discussions
> anywhere)

> natural=tree
> genus=Salix
> +
> management_style=knotted

> Or something like that?

> Apparently there's two words in Dutch:
> - knotwilg: knotted at about 2 meters high
> - grien

[Tagging] charging stations: CCS socket wiki conflict

[lucas-osm]

Howdy,

on charging stations we distinguish between socket types like Type1, Type2, 
Chademo etc.
But currently the english wiki version differs from the german one on tagging 
the CCS (combined charging system) socks.
The english version uses socket:type2 and socket:type2_combo (CCS) to 
characterize the models. The german however uses socket:type2 and socket:combo2.

These tow different special tags describing the same socket have led to some 
confusion among some german mappers. I’ve already seen some stations containing 
both tags.

Looking at the history it seems like the user Mentor changed the tag 
socket:combo2 to socket:type2_combo in June 2015. According to his comment that 
time the tag was unused, so I assume he adapted the type1_combo style to the 
type2 socket to use an uniform style. But sadly he forgot to edit the other 
languages as well.

Usage according to taginfo:
   socket:type2_combo 135
   socket:combo2 72

So my question is how should we proceed? Should we stay with those tow 
different tags? Or only use one? But which one? I’d suggest staying with the 
english socket:type2_combo, to be consistent between Type1 and Type2 sockets.


Lucas

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

Re: [Tagging] test track tagging (vs highway=raceway)

[Jerry Clough - OSM]

Hi Richard,
Not just test tracks. Your post instantly brought to mind the training track at 
the Police school outside Merida. I'm sure other Police training establishments 
must also have tracks designed for training of advanced driving skills.
  
|  
|   
|   
|   ||

   |

  |
|  
|   |  
OpenStreetMap | Way: ‪Academia Guardia civil Trafico‬ (‪38288436‬)
 OpenStreetMap is a map of the world, created by people like you and free to 
use under an open license.  |   |

  |

  |

 

My reaction is that this is a rare case where  I think the original tag still 
does the bulk of the work. Rather than split into multiple values (raceway, 
test_track, training_track), I suggest the way to go is to subtag with 
raceway=*. Raceway is already used a) for some of these other types of track; 
and b) also applies to motocross and other disciplines. I presume the 
preponderance of these specialised motor tracks are used for racing of one form 
or another; and that test tracks are only a small proportion. (I also suspect 
that driving at speed is often a part of testing and training).
Cheers,
Jerry

  From: Richard Welty 
 To: "Tag discussion, strategy and related tools"  
 Sent: Thursday, 20 October 2016, 16:46
 Subject: [Tagging] test track tagging (vs highway=raceway)
   
i don't have a particular proposal in mind for this, just looking for input.

there are various tracks in the world that are not used for racing, but
for testing only. major auto manufacturers have their own tracks, and
independent organizations do too (for example, the US publication
Consumer Reports has converted an old drag racing complex in CT into
their own private test facility. likewise i believe there is a small private
test facility on the grounds of the old Brooklands oval in the UK.)

what kind of tagging do folks think is appropriate for these?

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


___
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] Subject: Feature Proposal - RFC - highway=social_path

[Robert Whittaker (OSM lists)]

On 15 June 2016 at 13:10, John Willis  wrote:
> Why isn't having a footway=trail subtag (or something) seen as a much more
> reliable solution?

Perhaps more of an aside, but it may explain some people's reluctance
/ confusion with highway=trail:

As a native British English speaker, the word I would use for what I
think you're describing as a "trail" (i.e. a rough path through the
countryside that's used as a route by walkers / hikers) is "path" or
"footpath" (or maybe "track" if it was wider) -- which are the same
words that I'd use for paths through a park. I would normally use the
word "trail" to describe a route rather than the path itself,
particularly if there was some other purpose/interest in the route
(cultural, historic, fitness, wildlife) above than just walking the
paths.

But back on topic, if two paths have identical surface and width
characteristics (which we can already tag), what difference does it
make whether it's through a park or across more open countryside? Why
would it matter to data consumers or renderers?

Robert.

-- 
Robert Whittaker

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

Re: [Tagging] Orchards and their crops

[Jerry Clough - OSM]

Hi John,
No there is nothing I'm aware of which discriminates anywhere between 
cultivated pears in general (Pyrus communis) & specific cultivars 
('Conference'). Cultivar just is shorthand for "cultivated variety" so of 
course there is no hierarchy variety=>cultivar.
That's just the way gardeners & horticulturalists have evolved their naming 
over hundreds of years. (and for Japanese cherries it's worse as they have such 
a complicated heritage it is not possible to accurately assign them to a 
species, so they are formally known just with the genus & cultivar (Prunus 
'Kanzan' for example).
I suspect the kind of thing you want is related to some other, non-biological, 
property of the said orchard trees: such as colour, use (cooking apple, cider 
apple, perry pear, ornament). Or you are looking for properties which are 
biological, but not directly related to the biological classification (e.g., 
flowering time). If not then I can't help, and I'd be pretty sceptical that you 
can achieve a tagging mechanism that is genuinely useful given that the 
biological/horticultural one has 250+ years of refinement.
Jerry
  
|   |
|   |  |   |   |   |   |   |
| Conference pear - Wikipedia, the free encyclopediaA Conference pear is a 
variety of pear. |
|  |
| View on en.wikipedia.org | Preview by Yahoo |
|  |
|   |



|   |
|   |  |   |   |   |   |   |
| Prunus 'Kanzan' - Wikipedia, the free encyclopediaPrunus 'Kanzan' (syn. 
'Kwanzan' or 'Sekiyama') is a flowering cherry cultivar. It is a deciduous tree 
that grows to between 8 and 12 metres high with an 8 metre spr... |
|  |
| View on en.wikipedia.org | Preview by Yahoo |
|  |
|   |


 From: John Willis 
 To: Jerry Clough - OSM ; "Tag discussion, strategy and 
related tools"  
 Sent: Tuesday, 15 September 2015, 9:54
 Subject: Re: [Tagging] Orchards and their crops
   


Javbw

> On Sep 15, 2015, at 5:27 PM, Jerry Clough - OSM  wrote:
> 
> our next problem is to identify the cultivars: not easy with cherries in 
> Japan.

So there is nothing between

"This is a pear"

And

"This is the very specific cultivar of this variety of this pear.

?

It looks like ill be requesting some more tree types then. 



Javbw. 

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

Re: [Tagging] Orchards and their crops

[Jerry Clough - OSM]

Hi John,
This is pretty much the type of situation which the taxon tag is meant to cope 
with: current tagging says it's an apple orchard, with taxon we can show that 
it's one for Bramley's or the cider apples loved by RichardF.
"taxon=Malus domestica 'Bramley's Seedling'"
This can be used with species & genus too; but most useful is the usage widely 
used by the Vienna tree import:
 "taxon:cultivar=Bramley's Seedling" 
(in this case the single quotes obligatory in the formal name are not needed 
because all cultivar names require them. This can be used standalone, on the 
basis that trees=apple_trees is a synonym of species|taxon=Malus domestica.
Your next problem is to identify the cultivars: not easy with cherries in Japan.
Jerry
   From: johnw 
 To: strategy and related tools Tag discussion  
 Sent: Tuesday, 15 September 2015, 0:52
 Subject: [Tagging] Orchards and their crops
   
I came across some mis-tagged orchards in Japan, and in the process of 
researching how to tag them correctly, I noticed some discrepancies in the EN 
and JA wiki pages for orchards, trees, and related things. the JA page for 
orchard includes the trees= definitions, for example. 
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dorchard   
Englishhttps://wiki.openstreetmap.org/wiki/JA:Tag:landuse%3Dorchard Japanese

My question to the group is how to deal with trees=* when it seems to be very 
generic (apple tree, pear tree, etc) and more specific kinds of crops (fuji 
apples, asian pears). 
crop=* for orchard was changed to trees=* - but how do we get more specific on 
what kind of fruit is grown? do we make a ton of different tree=* tags, or do 
we make generics and then specify the exact fruit produced through produce=* or 
some other tag? 
Also, someone has added a ton of trees to the JA list (and a few to the EN 
list), including cranberries - which are grown in a swampy bog - hardly an 
orchard. Should be at least in farmland+crop, possibly some form of wetlands. I 
cleaned up the entries on the ja page by added “trees” to the items, and 
striking out sugarcane and cranberry, but I didn’t delete any other entries. I 
didn’t touch the EN page. 
I can clean up the JA page to match the EN page, but I need to know how do deal 
with the trees and what they produce:  are the trees=* a very specific type of 
tree, or are they general - and how do we specify the exact type of fruit 
produced?  apples, oranges, pears, peaches, have regional varieties - and 
custard apples and asian pears (sand pears) may be considered so different from 
their normal varieties as to warrant their own tree and rendering. 
If I’m reading the english wiki pages for orchard=, trees= and produce= 
correctly, keeping the trees generic and the specific fruit in produce= seems 
to be right way. I added one example to the JA wiki page for asian pears: 
landuse=orchardtrees=pear_treesproduce=sand_pear  
so fuji apples would be 
landuse=orchardtrees=apple_treesproduce=fuji_apples 
Is this the right way to handle it, and should it be documented this way?
Javbw
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] diplomatic institutions (with tl;dr)

[serpens-osm]

What is the best way to bring this on a formal way to an official tag?
Is wiki:Proposed_features the right place (it is partly about changing existing 
tags not only about new tags)? Where takes a vote place about this?

Best
Serpens

> Gesendet: Dienstag, 25. August 2015 um 14:21 Uhr
> Von: serpens-...@gmx.de
> An: tagging@openstreetmap.org
> Betreff: [Tagging] diplomatic institutions (with tl;dr)
>
> Short introduction: Let’s take the tagging scheme „fuel“ for example:
> 
>   amenity=fuel
>   fuel:diesel=
>   fuel:discount=
>   …
> 
> This is logical and consistent: amenity=xy and then a namespace 
> xy:=
> ---
> 
> Now to my topic: diplomatic institution – like an embassy, a consulate, 
> ambassador’s residence, honorary consulate, consulate general, delegation, 
> high commission, permanent mission, (permanent) representation etc.
> We have amenity=embassy since long time. Some of these are tagged on top with 
> the (relatively new) key „diplomatic“ too – a very useful key.
> ---
> 
> 
> 
> So I have two suggestions: *FIRST*
> 
> Change amenity=embassy to amenity=diplomatic (this is more consistent and 
> logical, analog to amenity=fuel etc.) or =diplomatic. But please 
> not the too specific „amenity=embassy“ – how could I explain a new mapper to 
> tag a non-embassy (like a consulate) as „amenity=embassy“.
> 
> for this, see also proposed features:
> - http://wiki.openstreetmap.org/wiki/Proposed_features/Embassy (and „talk“ 
> page there)
> ---
> 
> 
> 
> Besides the tagging of the type of diplomatic institution it is super useful 
> to tag a machine-readable country code (at least for the sending country). 
> This is done so far via country=. This is not the best solution 
> because there are very often misunderstandings – which country? The sending 
> country or the destination (hosting) country? Sometimes target= 
> is used for the destination (hosting / „targeted“) country.
> 
> My *SECOND* suggestion:
> 
>   diplomatic:sending=ES   <--- machine-readable ISO 3166-1 alpha-2 
> country code
>   diplomatic:destination=FR   <---  -- " --
> 
> It could be also diplomatic:destination_country or diplomatic:target or 
> something like this.
> 
> The destination country is not always identical with addr:country – see for 
> example the embassy of Ethiopia in Berlin (destination countries: Germany, 
> Poland, Slovak Republic and Czech Republic), see 
> http://aethiopien-botschaft.de/
> 
> for this, see also my osm blog (about tagging country codes on embassies 
> etc.):
> - state 2009: http://www.openstreetmap.org/user/Serpens/diary/5734 and 
> http://www.openstreetmap.org/user/Serpens/diary/9082
> - state 2015: http://www.openstreetmap.org/user/Serpens/diary/28350
> ---
> 
> 
> 
> Because English is not my first language: Dear native speakers, please check 
> if this is correct (sending country / destination country?).
> 
> Taginfo:
> http://taginfo.openstreetmap.org/tags/amenity=embassy
> http://taginfo.openstreetmap.org/keys/diplomatic
> http://taginfo.openstreetmap.org/keys/country
> http://taginfo.openstreetmap.org/keys/target
> 
> Best
> serpens
> ---
> 
> 
> tl;dr (sorry for the long post!):
> 
> Example (Spanish consulate in France – CURRENT STATE):
> 
>   amenity=embassy<--- „oh, look, it’s an embassy!“
>   diplomatic=consulate   <--- contradiction: „uhm, wait, no. it’s a 
> consulate.“
>   country=ES <--- often misunderstood as „addr:country“
> 
>   name=Spanish consulate
>   addr:country=FR
>   …
> 
> 
> Example (Spanish consulate in France – MY PROPOSAL):
> 
>   amenity=diplomatic <--- it’s a diplomatic institution
>   diplomatic:type=consulate  <--- more specififc: it’s a consulate
>   diplomatic:sending=ES  <--- machine-readable ISO 3166-1 alpha-2 country 
> code
>   diplomatic:destination=FR  <---  -- " --
> 
>   name=Spanish consulate
>   addr:country=FR
>   …
> 
> ___
> 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] diplomatic institutions (with tl;dr)

[serpens-osm]

> I'm a bit lost in this thread and hope that I'm not repeating what was 
> already said, but there is extensive documentation on this topic in the wiki:
> http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dembassy
> and linked pages. It might be disputable whether tagging consulate generals 
> as embassies in the first level tag though.
> 
> The above mentioned, more verbose  suggestions (sending_country and 
> destination_country rather than the documented "country") make perfect sense 
> also to me
> 

The current state is documented there, yes.

But I think here and not there is the right place to discuss my new suggestions 
(diplomatic:sending_country= etc.). And amenity=embassy just way to 
specific, nobody wants amenity=consulate_general, ameninty=consulate etc.

On http://wiki.openstreetmap.org/wiki/Key:diplomatic is written: „Do not use 
diplomatic=* without amenity=embassy since it is not independently recognised 
by renderers.“ – that is true for now and I want to get rid of this.

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

Re: [Tagging] diplomatic institutions (with tl;dr)

[serpens-osm]

> >> having an English name for a Spanish consulate to France seems kind of odd 
> >> for the tag "name" ;-)
> >
> > That’s a joke, right? ;-)
> 
> I would not see that a joke. name= should be the locally used name, name:en= 
> the English one.

It was just an hypothetical example and the whole discussion is not about the 
"name" tag, so I couldn’t really see the point.
But for the record: Yes, of course, you both are right :-)

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

Re: [Tagging] diplomatic institutions (with tl;dr)

[serpens-osm]

> having an English name for a Spanish consulate to France seems kind of odd 
> for the tag "name" ;-)

That’s a joke, right? ;-)

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

Re: [Tagging] diplomatic institutions (with tl;dr)

[serpens-osm]

Hi,

thank you for your thoughts!

> diplomatic:country=ES

I don’t think that is the best solution. Why not? As I wrote:

>> The destination country is not always identical with addr:country – see for 
>> example the embassy of Ethiopia in Berlin (destination countries: Germany, 
>> Poland, Slovak Republic and Czech Republic), see 
>> http://aethiopien-botschaft.de/

So there is an embassy
- located in Berlin (addr:country=DE),
- the sending country is Ethiopia (diplomatic:sending_country=ET)
- and the destination countries are Germany, Poland, Slovak Republic and Czech 
Republic (diplomatic:destination_country=DE;PL;SK;CZ).

So every tag key makes sense (in my eyes).

Best
Julian

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

[Tagging] diplomatic institutions (with tl;dr)

[serpens-osm]

Short introduction: Let’s take the tagging scheme „fuel“ for example:

  amenity=fuel
  fuel:diesel=
  fuel:discount=
  …

This is logical and consistent: amenity=xy and then a namespace 
xy:=
---

Now to my topic: diplomatic institution – like an embassy, a consulate, 
ambassador’s residence, honorary consulate, consulate general, delegation, high 
commission, permanent mission, (permanent) representation etc.
We have amenity=embassy since long time. Some of these are tagged on top with 
the (relatively new) key „diplomatic“ too – a very useful key.
---



So I have two suggestions: *FIRST*

Change amenity=embassy to amenity=diplomatic (this is more consistent and 
logical, analog to amenity=fuel etc.) or =diplomatic. But please not 
the too specific „amenity=embassy“ – how could I explain a new mapper to tag a 
non-embassy (like a consulate) as „amenity=embassy“.

for this, see also proposed features:
- http://wiki.openstreetmap.org/wiki/Proposed_features/Embassy (and „talk“ page 
there)
---



Besides the tagging of the type of diplomatic institution it is super useful to 
tag a machine-readable country code (at least for the sending country). This is 
done so far via country=. This is not the best solution because 
there are very often misunderstandings – which country? The sending country or 
the destination (hosting) country? Sometimes target= is used for 
the destination (hosting / „targeted“) country.

My *SECOND* suggestion:

  diplomatic:sending=ES   <--- machine-readable ISO 3166-1 alpha-2 country 
code
  diplomatic:destination=FR   <---  -- " --

It could be also diplomatic:destination_country or diplomatic:target or 
something like this.

The destination country is not always identical with addr:country – see for 
example the embassy of Ethiopia in Berlin (destination countries: Germany, 
Poland, Slovak Republic and Czech Republic), see http://aethiopien-botschaft.de/

for this, see also my osm blog (about tagging country codes on embassies etc.):
- state 2009: http://www.openstreetmap.org/user/Serpens/diary/5734 and 
http://www.openstreetmap.org/user/Serpens/diary/9082
- state 2015: http://www.openstreetmap.org/user/Serpens/diary/28350
---



Because English is not my first language: Dear native speakers, please check if 
this is correct (sending country / destination country?).

Taginfo:
http://taginfo.openstreetmap.org/tags/amenity=embassy
http://taginfo.openstreetmap.org/keys/diplomatic
http://taginfo.openstreetmap.org/keys/country
http://taginfo.openstreetmap.org/keys/target

Best
serpens
---


tl;dr (sorry for the long post!):

Example (Spanish consulate in France – CURRENT STATE):

  amenity=embassy<--- „oh, look, it’s an embassy!“
  diplomatic=consulate   <--- contradiction: „uhm, wait, no. it’s a consulate.“
  country=ES <--- often misunderstood as „addr:country“

  name=Spanish consulate
  addr:country=FR
  …


Example (Spanish consulate in France – MY PROPOSAL):

  amenity=diplomatic <--- it’s a diplomatic institution
  diplomatic:type=consulate  <--- more specififc: it’s a consulate
  diplomatic:sending=ES  <--- machine-readable ISO 3166-1 alpha-2 country 
code
  diplomatic:destination=FR  <---  -- " --

  name=Spanish consulate
  addr:country=FR
  …

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