Re: [Tagging] Picnic_table with barbecue table extension.

[Martin Koppenhoefer]

sent from a phone

> On 22 May 2023, at 20:06, Dave F via Tagging  
> wrote:
> 
> I've a leisure=picnic_table but has an extended table top made of metal to 
> accommodate disposable barbecues.
> 
> Can anybody recommend a sub-tag that's more descriptive than barbecue=yes?


for the avoidance of doubt you could add barbecue_grill=no as you’ll have to 
bring your own if I understood it well, or could you just light a fire on the 
metal plate?
https://taginfo.openstreetmap.org/keys/barbecue_grill#overview

The barbecue tag is not really used a lot and some values indicate a type of 
barbecue grill https://taginfo.openstreetmap.org/keys/barbecue#overview

There is more use for “bbq” but it is defined as “a bbq grill is available” 
(property) https://taginfo.openstreetmap.org/keys/bbq#overview

I’d use a more specific tag for this feature, or maybe a generic property like 
fireproof=yes/partial on the table ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - Extended playground equipment

[Martin Koppenhoefer]

sent from a phone

> On 27 May 2023, at 08:45, Alex  wrote:
> 
> As a group of mappers who regularly map playgrounds, we are proposing more 
> values to the list of documented playground equipment to better map typical 
> devices that had no documented value before.
> 
> https://wiki.openstreetmap.org/wiki/Proposal:Extended_playground_equipment


I welcome more tag definitions for specific features. Generally I don’t think 
using “playground” as key for playground equipment was a good choice (one would 
usually expect in OpenStreetMap that it is a key for types of playgrounds), but 
this is not an objection to this proposal, as it only adds more value 
definitions to an established tag.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Coach parking

[Martin Koppenhoefer]

sent from a phone

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


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

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

Re: [Tagging] Coach parking

[Martin Koppenhoefer]

sent from a phone

> On 9 Jun 2023, at 12:56, Warin <61sundow...@gmail.com> wrote:
> 
> The difference between a coach and a bus?
> 
> A 'coach' is intended for long distance transport - so more comfortable, 
> provision for luggage and possibly an on board toilet.


yes, but this is a distinction like a car vs. a station wagon, a coach is a 
kind of bus and the differences (internally/design/features) are not relevant 
for the traffic rules. 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 10 Jun 2023, at 00:13, Matija Nalis  
> wrote:
> 
> I think in such vandalized case it would be better tagged as
> disused:amenity=bbq or abandoned:amenity=bbq


there is also fireplace as tag
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] road accident memorials

[Martin Koppenhoefer]

sent from a phone

> On 10 Jun 2023, at 17:58, Anne-Karoline Distel  wrote:
> 
> I don't know if
> wayside_cross is used for this in some instances, for example, which
> IMHO it shouldn't be


agreed. One tag I am aware of in this context is memorial=ghost_bike
https://taginfo.openstreetmap.org/tags/memorial=ghost_bike#overview___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What separator do you use for multiple value

[Martin Koppenhoefer]

sent from a phone

> On 14 Jun 2023, at 11:15, _ _  wrote:
> 
> What separator do you use, and what advantage do they have over the others?


the semicolon is standard for most cases, for multilingual names dashes and 
slashes are in use, for housenumbers periods are an alternative to semicolons.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What separator do you use for multiple value

[Martin Koppenhoefer]

sent from a phone

> On 15 Jun 2023, at 09:41, Simon Poole  wrote:
> 
> 
>> Am 14.06.2023 um 11:26 schrieb Martin Koppenhoefer:
>> ...for housenumbers periods are an alternative to semicolons. 
> You probably wanted to write "commas", periods are not in use as separators 
> for house numbers. See 
> https://wiki.openstreetmap.org/wiki/Addresses#Buildings_with_multiple_house_numbers
> 


yes indeed wanted to write commas, thank you for correcting, 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] navigational aid relation

[Martin Koppenhoefer]

Am Sa., 17. Juni 2023 um 21:48 Uhr schrieb Minh Nguyen <
m...@nguyen.cincinnati.oh.us>:

> You're quite fortunate that the meaning of an address is unambiguous in
> Italy. At least you can be sure that a pedestrian route will lead to the
> main entrance, even if other modes aren't as well-served.



actually the real situation in Italy is more complicated than the theory.
For one, because the reality doesn't always follow the legal prescriptions
(every entrance to a building or site should get a housenumber according to
the law, i.e. also small gates leading to the garden, or similar), but
sometimes no housenumber is posted (maybe not assigned, maybe not displayed
by the owner, but either way not compatbile with the law), and sometimes,
"old" housenumbers (where there used to be a door but is now closed) are
still posted. And the law also declares that "potential" entrances should
get their own numbers, this refers mostly to shop windows, i.e. many
housenumbers are not assigned to a place where you can currently enter the
building/site.

As a result, many businesses and homes have more than one housenumber.
Adresses always are assigned to points and never directly to buildings
(although one could say a "buillding has several housenumbers" if you look
at the collection of numbers that lead to the building, and POIs usually
either indicate a of their housenumbers, or use the one that is actually
usable,  or sometimes use one that is now a closed door (e.g. because it is
their official address where they have registered the business).

You cannot assume that where a housenumber is posted this means access for
pedestrians, because "vehicle only" access points also get housenumbers
(AFAIK).


Here in the U.S., the meaning of an address depends on who's using it.
> To the tax authorities, it refers to the whole parcel. To emergency
> responders, it's either the building or the beginning of the driveway.
> To the postal service, it's the mailbox, which can be at the door, at
> the street curb, or even at the neighborhood entrance.
>


This is probably how these are effectively interpretated / used. If the
number refers to the whole parcel (tax), isn't this then a valid point of
view for emergency responders as well? Won't they help you on every spot of
the parcel, or do they require you go either into the building or to the
beginning of the driveway before they will rescue you?



>
> Mappers here generally treat the address as an attribute of a building,
> POI, or something else. [1]



in Italy, we also treat the address as an attribute of a POI -
additionally, because from all the possible (assigned) addresses, there
will often be a principal / official one which the business uses in their
communications (this is somehow disputed in the community, some people do
not want to "duplicate" addresses, so they add the poi information on the
entrance node, which is not fully correct obviously, because the POI is
usually inside and not on the perimeter, and the entrance is not the same
as the POI so it goes against the one object one element rule. We never use
addresses on buildings though.



> So the address point's coordinates don't
> necessarily have any relation to where you would navigate to.



IMHO this is a problem, the addresses we add should indeed have a relation
with where they are assigned to. A postbox with an address that is not on
the site where the address belongs to, should not get "addr:*" tags of the
far away place. There is "contact:street", "contact:housenumber" and others
to add addresses that are elsewhere, as referers.



>
> This is another good reason why I'd advocate for objectively
> micromapping features that data consumers (whether routers or geocoders)
> could recognize as navigable points or not, depending on the situation.
>


+1

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

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

[Martin Koppenhoefer]

sent from a phone

> On 21 Jun 2023, at 13:10, Warin <61sundow...@gmail.com> wrote:
> 
> I note the absence of 'fire' in the above definitions. Explosions can be had 
> from compressed gas


doesn’t seem to cover electromagnetic weapons, or does it?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 21 Jun 2023, at 15:52, Greg Troxel  wrote:
> 
> It is absolutely the wrong thing to say that shop=firearms means "a shop
> that sells whatever the local law means by firearms".   This is a
> general principle in OSM that we define something and then expect
> mappers to use the OSM definition, not local language.


I am not sure I can subscribe to this. Generally our tags are used when the 
thing meets the local expectations of “such thing”, e.g. an amenity=cafe or 
amenity=pub in England is probably different from places with such a tag in 
Germany. Or a shop=bakery in England will not necessarily sell the same kind of 
bread than one in France.

There is a point where the differences are so big that we decide to introduce a 
new tag (or subtag), but in a case like the arms shop I believe the most likely 
answer for OpenStreetMap is actually "a shop that sells whatever the local law 
means by firearms", just like a highway=motorway is “a highway that the local 
law means by motorway”.

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

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

[Martin Koppenhoefer]

sent from a phone

> On 22 Jun 2023, at 00:43, Frederik Ramm  wrote:
> 
> Generally, yes, I'd however not invoke the law at this point - I'd say a 
> shop=firearms is whatever locals would call a firearms shop, if that term is 
> used locally.


agreed


> 
> Generally speaking I object to an one-size-fits-all approach to tagging. 
> Instead of defining that in order to be a shop=bakery something must fulfil 
> the following 5 criteria (which can amount to cultural imperialism) I'd 
> rather say that a shop=bakery is whatever the locals call a bakery.


when they don’t speak English and have different types of „bakeries“, things 
become more complicated though. If you ask locals about a „bakery“ it may 
depend what word(s) your dictionary translates it to, whether they‘d consider 
it such.


> 
> And highway classification is maybe not the best example, because it is 
> generally agreed that the legal status of a road is not the sole deciding 
> factor when it comes to which highway=* we map it as. A road that is 
> secondary by law but primary in practice, will often be tagged primary.


yes, but motorway is an exception because it is usually defined by signs rather 
than characteristics (e.g. if the signs are missing but it looks and feels 
like, we use motorroad=yes in some countries)

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

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

[Martin Koppenhoefer]

Am Do., 22. Juni 2023 um 12:36 Uhr schrieb Brian M. Sperlongano <
zelonew...@gmail.com>:

>
> yes, but motorway is an exception because it is usually defined by signs
>> rather than characteristics (e.g. if the signs are missing but it looks and
>> feels like, we use motorroad=yes in some countries)
>
>
> Iknow you said 'usually' but this sounds like a very European perspective
> to me.  We have no such distinction in the US. I've learned on this project
> to be quite careful about projecting what we think to be a normal structure
> onto other locations in the world.  In the US it's a motorway if it's
> physically constructed like one, and there's many edge cases that we
> scratch our heads on.
>


I believe the US is an exception then, at least the current wiki confirms
what I wrote (and in this case I didn't write it myself ;-) ) , from
highway=motorway:

Typically highway =motorway
should be *used only on roads with control of access
*, or selected
roads with limited access
 depending on the local
context and prevailing convention.

Generally roads with control of access
 are proclaimed in
government documents, and have an official status as a controlled access
road, sometimes this can include the term motorway, freeway or expressway
among others in the road name. These kinds of roads usually have a special
designation by the law, with a set of laws specifically applied on them.
Generally some restrictions are placed on the kind of vehicles or traffic
which can be on roads which should be classed as highway
=motorway, such as no
pedestrians, bicycles, livestock, horses and so on.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

Am Do., 22. Juni 2023 um 14:41 Uhr schrieb Greg Troxel :

>
> Suppose in some other country, bakery is a term that means a shop that
> primarly sells sausages.  We wouldn't say that this should be
> amenity=bakery.



this is why we have agreed to use English words. A "bakery" in English is a
place that primarily sells bread (and other baked stuff, at least
generally), so if some other language used the same letters for a word
"bakery" which had a different meaning, it could not be the one intended in
OSM because we use English.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 23 Jun 2023, at 16:13, Greg Troxel  wrote:
> 
>   My point is that a tag defines a semantic concept and that we should strive 
> to have it mean that concept everywhere.   That is the point, so that data 
> consumers can use it.


agreed. The problems for example arise because sometimes essential things are 
not explicitly defined as people take them for granted (the definitions are 
just more English words), and then it turns out, different properties have been 
taken for granted or not be considered.


Let’s have a look at basic concepts that occur around the world, e.g. food 
provision. If you don’t produce your own food, or go foraging, hunting or 
fishing, you’ll have to buy it. Generic food buying places in osm are markets 
and street vendors (let’s ignore the latter for this time as they don’t occur 
everywhere), convenience stores and supermarkets. The market term is a huge 
umbrella and can accommodate lots of different kinds of places (if you look 
into more detail than just “market”) so we won’t have a problem at this level 
of specificity, but defining a semantic difference of convenience store and 
supermarket regardless of local customs seems impossible.


The wiki says for convenience store:
“ A convenience shop is a small local shop carrying a variety of everyday 
products, such as packaged food and hygiene products”

While this might seem a good description of a convenience store, it still isn’t 
a real definition that would exclude all other shops that aren’t. it doesn’t 
say there must be food, e.g. a shop selling clothing, hygiene products and 
newspapers would also fit.

There is also a longer text, full definition says: “ A convenience shop, also 
known as a convenience store or mini-mart: A small local shop carrying a 
variety of everyday products, mostly including single-serving food items such 
as milk, bread, snacks, groceries to over-the-counter medications, household 
items, stationery, and small auto supplies such as fuses. 
They may be part of a chain - 7-Eleven (US, Japan, Europe, Australia) and 
AM/PM, Wawa (US) - or locally owned. In the USA, they're also sometimes 
referred to as a bodega or a corner store.”


This is not a definition (and not an exception, I bet the tag definition for 
“building” says it is about a building but does not exactly define what a 
building is). You can not decide whether a shop is a convenience shop with 
these descriptions, rather you have to know what a convenience shop is in order 
to use it correctly.
For example the first paragraph says: mostly including …small auto supplies 
such as fuses. - I am willing to believe this is the case somewhere, but I have 
never seen a convenience store selling auto supplies, should I never have used 
the tag then? Or is it just an example and it is fine when auto supplies are 
missing, or single serving milk? What is required as a minimum, what is 
indispensable? Could this be defined with semantics for a global application? 
Yes, we should strive to clearly define semantic concepts, but we are often 
very far, we do things by local accustoms and agreements and common (hopefully, 
mostly/often) understanding of single words we use as tag names, in English ;-)___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 24 Jun 2023, at 00:29, Minh Nguyen  wrote:
> 
> But if we focus too pedantically on legal status at the expense of common 
> sense, then we've reinvented designation=*, and mappers and data consumers 
> have to find yet another key to express what could've been in highway=*.


oh yes, absolutely, if legal status and common sense/reality are not congruent 
we should record both.

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

Re: [Tagging] Tag which restaurant or cafe allows bringing your own food or drink?

[Martin Koppenhoefer]

sent from a phone

> On 25 Jun 2023, at 18:11, Timeo Gut  wrote:
> 
> Other than the obvious yes/no we should also have a value to indicate that a 
> place generally allows outside food but charges a fee for bringing particular 
> items.



this is something typical also in Italy: people bring the dessert (cake), and 
restaurants have policies if and how it is ok / whether you have to pay a fee 
(on the other hand I agree with Frederik that this may not be constant but 
depend on lots of soft factors).

There are also places like the German Biergarten, where you can/could bring 
your food but will buy the local wine there (fraschetta). Actually today, all 
of these places will also sell food, and only some are ok if you bring your 
own, there’s a wikipedia article about it in Italian: 
https://it.wikipedia.org/wiki/Fraschetta
no particular tagging so far (afaik)___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 26 Jun 2023, at 20:50, Minh Nguyen  wrote:
> 
> For what it's worth, the Sporting Goods Retailers subindustry in NAICS 
> includes "gun shops".


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


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

Re: [Tagging] [RFC] Feature Proposal - Wave Lounger

[Martin Koppenhoefer]

sent from a phone

> On 2 Jul 2023, at 20:19, Asa Hundert  wrote:
> 
> I'd have to propose to deprecate the uses on areas
> that allows for such atrocities as "amenity=lounger; surface=grass".


I don’t think this would be suitable tagging for a Liegewiese (habe recently 
seen such a sign in the swimming pool, a nicer way to say no ball playing I 
guess). If it were for a lounger with growing grass on it, it would be ok.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - Wave Lounger

[Martin Koppenhoefer]

https://i.etsystatic.com/26861520/r/il/09aa34/3144992841/il_1140xN.3144992841_ps9i.jpg___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - Wave Lounger

[Martin Koppenhoefer]

sent from a phone

> On 3 Jul 2023, at 01:27, Graeme Fitzpatrick  wrote:
> 
> Ah, but is that frame, material or surface? :-)


frankly I believe this level of detail would be overdoing it. Feel free to 
develop any scheme you feel suits well. If I wanted to tag more detail, 
priority would be „material“ and it would refer to the material where you 
sit/lie on. Another approach would be tagging specific or generic models/types 
(similar to how we do it for drinking fountains).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] [RFC] Historic main tag for defensive works

[Martin Koppenhoefer]

forwarding by request.

Begin forwarded message:

> From: Casper Kersten via OpenStreetMap Community Forum 
> 
> Date: 20 July 2023 at 13:41:38 CEST
> 
> Reply-To: OpenStreetMap Community Forum 
> 
> 
> 
>   Friendly_Ghost Casper Kersten 
> July 20
> Hello friends,
> 
> I wrote a short proposal to add historic=defensive_works as main (top-level) 
> tag to defensive_works=*. Details can be found at Proposal:Historic main tag 
> for defensive works - OpenStreetMap Wiki. All feedback is appreciated. I am 
> not active on the tagging mailing list, so I would appreciate it if someone 
> could share my proposal there.
> 
> Visit Topic or reply to this email to respond.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] cancelling proposal

[Martin Koppenhoefer]

Am Mi., 6. Sept. 2023 um 19:46 Uhr schrieb Anne-Karoline Distel <
annekadis...@web.de>:

> I've decided to cancel the proposal I started on August 22 in favour of
> using the vending machine option in combination with fee=no instead.



I am thinking about using natural=bay with water=no for some named
geografic areas in the mountains ;-)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 11 Sep 2023, at 08:39, Graeme Fitzpatrick  wrote:
> 
> foot:oneway=yes / oneway:foot=yes?


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.

https://wiki.openstreetmap.org/wiki/Key:oneway#Pedestrians

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

Re: [Tagging] [RFC] Feature Proposal - lifecycle prefix vandalised:

[Martin Koppenhoefer]

sent from a phone

> On 17 Sep 2023, at 14:12, Marc_marc  wrote:
> 
> If you're not there at the precise moment of the change of state,
> the only thing you can see is that the bench is no longer there
> or isn't in a working state anymore


maybe, but there might be other ways to learn how it was damaged, someone could 
tell you, or the type of damage indicates it was vandalized.


> 2 "past" lifecycles seems sufficient to me (was: for when there's nothing 
> left, damaged or equivalent for when there's something non-functional)


was: can also be used for non-physical features (indeed most usage is with 
was:amenity) it doesn’t imply there is nothing left at all. There are already a 
lot of prefixes for similar lifecycle states, e.g. demolished, razed, 
destroyed, abandoned, ruins, from this point of view, “vandalized” would be one 
more, adding another nuance. 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - lifecycle prefix vandalised:

[Martin Koppenhoefer]

sent from a phone

> On 17 Sep 2023, at 20:25, Mark Wagner  wrote:
> 
> was it deliberately pulled over by a snowmobiler
> (thus, "vandalized:")


if you don’t know it you can remain on the save side and put “destroyed“ 
because this is what you see. It doesn’t mean there aren’t lots of other 
situations where you can be very clear something was deliberately 
destroyed/vandalized
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - Millstone

[Martin Koppenhoefer]

Am Mi., 27. Sept. 2023 um 10:32 Uhr schrieb Mitchel van Duuren <
mitchelvanduu...@hotmail.com>:

> This proposal suggests the addition of a new tag to represent historic or
> decommissioned millstones found worldwide within the OpenStreetMap
> database: historic=millstone.
>



I think it is generally a good proposal, but what is the difference between
a historic millstone and another millstone? So historic millstones can be
tagged like this even when they are still used, while other millstones get
the tag only if they are decommissioned?
I appreciate you mention man_made=millstone, it has slightly less usage,
but could be an alternative:
https://taginfo.openstreetmap.org/tags/man_made=millstone

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

[Tagging] RFC Ladders

[Martin Koppenhoefer]

Please comment on the proposal for highway=ladder
https://wiki.openstreetmap.org/wiki/Proposal:Ladders
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

sent from a phone

> On 20 Oct 2023, at 10:23, Mateusz Konieczny via Tagging 
>  wrote:
> 
> maybe just removing this bad advise without proposal would be a good idea

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

[Tagging] Voting highway=ladder

[Martin Koppenhoefer]

Voting is now open for highway=ladder

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

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

[Tagging] voting for highway=ladder has ended

[Martin Koppenhoefer]

Hi,

just a short headsup that voting is ended now, the proposal was
approved with 95% of votes:
https://wiki.openstreetmap.org/wiki/Proposal:Ladders

I have created a page for the approved feature:
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dladder

Cheers,
Martin

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

Re: [Tagging] shops for display

[Martin Koppenhoefer]

sent from a phone

> On 20 Nov 2023, at 20:59, Anne-Karoline Distel  wrote:
> 
> Hi,
> 
> is there a way to tag shops that are not used for selling goods
> directly, but are just used for display for the actual shop or even to
> advertise something different? Here in Ireland, I think they are often
> used to hide the fact that it's actually a vacant premises, and rates
> are also different, I believe, if you're not actually conducting
> business there. Would "shop=display_only" be a way to do it? I would
> still like to have an option to mark them as vacant,  in a way.
> 
> They could be using the space inside to display their goods or even just
> have the windows covered in decals to advertise that they have moved or
> to advertise local sights or whatever.


according to the wiki a shop is selling goods or services, if they don’t do 
either it’s not a shop for OpenStreetMap.

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

Re: [Tagging] shops for display

[Martin Koppenhoefer]

sent from a phone

> On 21 Nov 2023, at 12:47, Niels Elgaard Larsen  wrote:
> The wiki for Tesla says that Tesla showrooms are tagged shop=car
> A lot of shop=kitchen are really showrooms where you can order a
> kitchen which will be installed in you kitchen. The shop do not actually
> have kitchens for sale in the store.


„ordering“ a kitchen or car in a shop is a sale, IMHO. The word sale does not 
imply you take the goods away with you immediately, nor that they are 
necessarily present at the point of sale.

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

Re: [Tagging] shops for display

[Martin Koppenhoefer]

sent from a phone

> On 21 Nov 2023, at 21:42, Niels Elgaard Larsen  wrote:
> 
> With more stuff being sold online, we will probably see more showrooms,
> and I think we should have a way to tell users if they can buy anything
> at a shop, or it is just a showroom


yes, this is a good idea. The original question was different though, as from 
what I understood the shop was closed, you could only look from the outside, 
this is a different situation from a showroom where you can enter (and possibly 
try the product, talk to staff etc.)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] shops for display

[Martin Koppenhoefer]

Am Mi., 22. Nov. 2023 um 17:12 Uhr schrieb Anne- Karoline Distel
:
>
> My case was where you can't enter the premises, it's really just displaying 
> goods or even (slightly different) displaying contact details for the 
> business which has moved to the outskirts of town.


yes, your thread was somehow "hi-jacked" because we discovered we
might also need tagging for showrooms. I think the best solution for
your situation is no shop and maybe some advertising=* tag
Actually "advertising" says it is for advertising devices, and your
situation isn't a device I guess, so maybe it is a showroom without
admittance?

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

Re: [Tagging] shops for display

[Martin Koppenhoefer]

sent from a phone

> On 22 Nov 2023, at 18:33, Mateusz Konieczny via Tagging 
>  wrote:
> 
> I would consider it more as device than showroom


can you provide a dictionary definition for “device” that could refer to a 
room? Because the ones I looked at wouldn’t fit.

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

Re: [Tagging] The reason to not use loc_name is far too subjective.

[Martin Koppenhoefer]

sent from a phone

> On 27 Mar 2024, at 20:36, Dave F via Tagging  
> wrote:
> 
> what determines the cut off point for a name being too "slangy"?


the “what” is harder to generalize, but the “who” is pretty clear: the local 
mapper decides this
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] traffic_signs: human readable values vs. ISO and law codes

[Martin Koppenhoefer]

sent from a phone

> On 15 Apr 2024, at 07:37, yo paseopor  wrote:
> 
> It is not a big problem...except they are using the same key.


it is not a problem, as long as the values describe a traffic sign. It means 
parsing doesn’t become even slightly more laborious, as a datauser you have to 
parse the values all in one key and not in 2, as you propose, but ultimately 
it’s about the same work, and the same information is given.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] traffic_signs: human readable values vs. ISO and law codes

[Martin Koppenhoefer]

Am Mo., 15. Apr. 2024 um 12:33 Uhr schrieb Greg Troxel :

>
> It seems really obvious that normalized osm words and CC:codepoint are
> different things and belong in different keys.
>


they are both ways to refer to a traffic sign, you do not have to know they
are "CC:codepoint" values, you can just treat them as opaque strings (and
synonyms for normalized osm words where it is the case). If a country
specific maxspeed sign has a specific meaning in this country, the
"normalized osm words" would have to deal with the same issue (there would
have to be a specific normalized osm word for this case).



>
> Part of the point is that renderers (including routing engines) and
> humans want to see a value that can be interpreted regardless of country
> and without having to know that country's laws.
>


traffic signs do not make sense if you do not know the law, they are all
about law. This said, all you need is equivalence lists, this may be
onerous, but it is no different if the CC:codepoint value is tagged with a
specific key like traffic_sign:id or if it is tagged with "traffic_sign".
Either you know what the code stands for, or you cannot use the
information.
Maybe the desire is that people would add both tags, a specific "encoded"
and a generic "human readable" one, but it doesn't seem likely this will
happen, also because we already tag the meaning of the sign with different
tags (not as a sign, but as properties on the road), so the whole point of
tagging signs is not changing the way the data is interpreted, it is a
source why something was mapped as it was mapped, and it is an inventory
where which traffic sign is located.

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

Re: [Tagging] Highway classification in Antarctica

[Martin Koppenhoefer]

Am Mi., 24. Apr. 2024 um 16:33 Uhr schrieb Fernando Trebien <
fernando.treb...@gmail.com>:

> As Antarctica is international space,[1] I understand that, in
> principle, the highway classification scheme of no particular country
> applies there.



Generally, highway classification is not done based on a particular
country's classification scheme.



> For a while, I tried to come up with a balanced generic
> scheme based on the regional importance of these roads,[2] which has
> been questioned,[3] so I would like to hear opinions on the matter.
>
> Should the classification of highways in Antarctica:
>
> 1. Follow country-specific conventions near stations? This can lead to
> different classifications for long polar traverses maintained by
> different countries and can create disconnected road networks (in
> terms of classification) between nearby stations operated by different
> countries.
>
> 2. Follow generic OSM definitions based on absolute population
> thresholds of the places they connect? (10k+ people for town, 1k for
> village, 100 for hamlet, etc.) This will assign very low road classes
> across the continent.
>
> 3. Follow generic OSM definitions based on lower place population
> thresholds that are more compatible with the reality of the continent,
> based on regional importance? [4] The result may be perceived by some
> as assigning higher than normal highway classes to the connections
> between these small settlements.
>
> Additionally, should the permanent population be considered (zero in
> most cases, which is the case even for larger stations, further
> lowering highway classification), or the average occupancy of the
> stations?



generally, we are not interested in citizenship or official population
count but rather in actual population. The highway class should reflect the
"importance" of the road for the (regional) grid. With a peak population
(presence) of about 5000 people, I would not expect a lot of traffic
anywhere. On the other hand, given the few roads and harsh conditions, I
could imagine that the existing roads could be considered quite
"important", regardless of the few traffic.

After all, it doesn't really matter as the conditions and context are
pretty unique and not comparable with the rest of the world anyway,
especially the part for which the existing applications are built.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Highway classification in Antarctica

[Martin Koppenhoefer]

to be more concrete, I think for an important link like
https://en.wikipedia.org/wiki/South_Pole_Traverse
highway=primary would be appropriate.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Highway classification in Antarctica

[Martin Koppenhoefer]

sent from a phone

> On 25 Apr 2024, at 09:51, Christoph Hormann  wrote:
> 
> By established conventions of functional road tagging in OSM these would 
> almost all be service roads (no through-traffic to other destinations than 
> the ones the route ends at).


this is also the case with some motorways leading to airports for example, the 
“no through-traffic to other destinations than the ones the route ends 
at”-property does not automatically equate to highway=service.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Direct reduced iron plants

[Martin Koppenhoefer]

sent from a phone

> On 26 Apr 2024, at 09:30, Daniel Evans  wrote:
> 
> Differentiating with different `product=` values doesn't seem sensible - both 
> types of works "produce steel", and getting into specific types of steel 
> doesn't help. The two `landuse=industrial + industrial=x` tags do allow that 
> differentiation. Is there any existing or proposed tagging scheme under 
> `man_made=works` to encode that level of detail?


the landuse tagging isn’t suitable to describe features, it is about landuse. 
An area with different steel producing works could be tagged all on the same 
polygon, while man_made=works is about an individual factory. If details are 
missing for meaningful distinctions of man_made=works tagging it can be 
introduced.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Direct reduced iron plants

[Martin Koppenhoefer]

sent from a phone

> On 26 Apr 2024, at 13:11, Daniel Evans  wrote:
> 
> It sounds like your feeling is that the tagging of industrial sites should be 
> closer to power=plant and the associated plant:x tags.



I say it already is like this. The meaning of landuse=industrial is land used 
for industrial purposes. If you add something like industrial=steelmaking or 
steel_mill or steel etc. to it, it means steel industry. It doesn’t say this is 
a steel plant, rather grounds used for the steel industry (there are steel 
mills but it doesn’t say if there’s one, two or even more).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Direct reduced iron plants

[Martin Koppenhoefer]

sent from a phone

> On 26 Apr 2024, at 14:34, Daniel Evans  wrote:
> 
> Thanks. I have been partly lost between some competing (but perhaps poorly 
> supported) proposals which suggested more focus on making the `industrial=` 
> tag more detailed. I'll give some thought to what a sequence of `works:x` 
> tags might look like.


yes, I am aware of these proposals, and frankly I can also not tell which ideas 
have more support, but I think we should generally aim to keep the meaning of 
keys consistent, because it makes life for everyone easier when there is some 
kind of logical structure behind and not just individual meaning for key-value 
pairs, e.g. the distinction of features and properties. We can have 
man_made=bridge (feature) as an object and highway=* with bridge=yes 
additionally, without violating the one feature one element rule, because the 
bridge=yes on the highway isn’t a bridge, it is a property of the highway that 
it is on a bridge. Several bridge=yes highways can be on the same one bridge, 
because you cannot count bridges by counting bridge attributes. Similarly 
counting landuse polygons does not make sense, because landuse is a property of 
the land (speaking about built up landuse and military which can be both, here 
are competing ideas around, e.g. by adding names to landuse polygons, with 
different meaning e.g. development, or settlement part like quarter, or 
individual properties and installations, thereby reading the landuse tag as 
feature tag, personally I don’t think it is a good idea because it limits the 
detail level of landuse mapping to the scale at which the feature is located, 
so the bigger it is (like a whole village or residential area, etc.) the 
likelier it is a problem).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Highway classification in Antarctica

[Martin Koppenhoefer]

apart from the usefulness in routing  (as there aren’t alternatives it doesn’t 
matter for routing if a road on antarctica is unclassified or primary, and 
usual time estimates would generally not be useful in this particular context 
and also likely more depend on the vehicle than the “road”), the scarcity of 
the grid which doesn’t allow for relative comparisons, I would tend to upgrade 
rather than downgrade, because the very few routes which connect something 
across significant parts of the continent, cannot be seen as insignificant as a 
tertiary function. Tertiary requires that there is also a primary somewhere, in 
the region (while this argument by itself could maybe also lead to many other 
“main” roads on small islands being considered primary, I think length also has 
to weigh in), in the case of the South Pole Traverse it is 1600km not 
comparable to any tertiary road.

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

Re: [Tagging] [RFC] Feature Proposal - works:type and works:process

[Martin Koppenhoefer]

sent from a phone

> On 27 Apr 2024, at 10:55, Daniel Evans  wrote:
> 
> works:industry= is an option which is much clearer about exactly what the tag 
> means. Does that sound good to you?


it is fine, maybe also just “industry”? There are a few hundred of them but not 
so much with works: https://taginfo.openstreetmap.org/keys/industry#values

No page in the wiki so far, I think this would be suitable to accomodate in a 
works proposal, or maybe I can see the advantage of works:industry not having 
any usage so far, but it is a bit unwieldy and ultimately it is the same kind 
of industry “property” that would be useful for other contexts/feature tags as 
well, e.g. offices.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - works:type and works:process

[Martin Koppenhoefer]

sent from a phone

> On 28 Apr 2024, at 19:58, Daniel Evans  wrote:
> I've seen "industry=" proposed/discussed before, with the big problem that 
> it's very close to the existing "industrial" tag, and it would likely be too 
> confusing if they had different meanings (one for land use, one for 
> individual facilities). I'd wonder how many existing "industry=" tags are 
> mis-tags of "industrial=".


works could describe the type of plant, e.g. works=sawmill, oil_refinery, 
manufacturing (and you add product), brewery, printing, brickyard,  
slaughterhouse, …

industry would be about the industry, but it could also get another name, there 
isn’t actually too much confusion in the values: 
https://taginfo.openstreetmap.org/keys/industry#values
especially for an undocumented tag (admittedly only few usage), compared to 
industrial:
https://taginfo.openstreetmap.org/keys/industrial#values___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

Am So., 28. Apr. 2024 um 16:40 Uhr schrieb Andy Townsend :

> Assuming we're talking about something that's signed as a "Public
> Bridleway" in England and Wales*, then at the most basic level there are
> two tags to consider:
>
>- highway=steps
>- designation=public_bridleway
>
> The first of those says that there are some steps.  There's no other way
> of doing that; there are steps, so highway=steps it is.
>


actually there would be an alternative, although it is not used so often:
https://wiki.openstreetmap.org/wiki/Tag%3Abarrier%3Dstep
I agree highway=steps is probably the most supported way to tag it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

Am Mo., 29. Apr. 2024 um 09:47 Uhr schrieb Jo :

> I was wondering about that myself. They seem to be 'long' steps. So a
> horse wouldn't have too much trouble with them.
>



there is this property which might be applying:
https://wiki.openstreetmap.org/wiki/Key:flat_steps
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Highway classification in Antarctica

[Martin Koppenhoefer]

Am Mo., 29. Apr. 2024 um 16:06 Uhr schrieb Fernando Trebien <
fernando.treb...@gmail.com>:

> > why you think that place=hamlet are automatically entitled to
> > highway=tertiary?
>
> The wiki emphasizes the highway classification should consider the
> relative importance of roads within regional contexts even for the
> lowest highway classes:
>
> "Outside urban areas, tertiary roads are those with low to moderate
> traffic which link smaller settlements such as villages or hamlets."
>


Yes, but villages and hamlets are just examples, as are settlements. IMHO
there are no settlements required for a road to be tagged highway. If you
strictly read this paragraph from the wiki, if a road doesn't link a
settlement, it could not be tagged even tertiary. A main road can just as
well lead to a train station or an airport / airfield, or to a mining area,
or to a seaport or military base, no settlement required. The settlements
are mentioned in the wiki, because this is what we usually expect, but
there absence could be justified in some exceptional cases (like the
aforementioned).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Highway classification in Antarctica

[Martin Koppenhoefer]

Am Mo., 29. Apr. 2024 um 16:25 Uhr schrieb Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

> (second note also may benefit from fix as the most important in
> Vatican is not highway=trunk - though again, maybe it can be avoided
> via "Vatican has no road network system").
>


the Vatican has a road network system, but it is not publicly accessible.
The idea that we should start from the most important roads (trunk) should
not refer to a "country" but to a "region", i.e. the question is not which
are the most important roads in the Vatican but which are these in Central
Italy (and FWIW, in Italy we adopted the German idea, to use "trunk" for
roads that are built to motorway like standards without being motorways, so
that the major roads are tagged as primary if they present level crossings).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Difference between "yes" and "designated" in access tags

[Martin Koppenhoefer]

sent from a phone

> On 30 Apr 2024, at 08:51, Graeme Fitzpatrick  wrote:
> 
>> In fact, some bicycle trails are signed where
>> cycling is illegal 
> 
> So does that then make it legal?


no, in Germany it also happens from time to time that we discover signposted 
bicycle routes where cycling is legally forbidden, often presumably because the 
signs are not “correct” (not what is intended), and the legal conclusion from 
such a situation is you have to push the bike on such sections. Route markers 
do not change legal accessibility as defined by traffic signs.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Difference between "yes" and "designated" in access tags

[Martin Koppenhoefer]

Am Di., 30. Apr. 2024 um 10:54 Uhr schrieb Szem :

> There was a similar conversation in the Hungarian community as well. I
> would like to ask what you think about such (and similar) official bicycle
> route signs:
>
> https://www.google.hu/maps/@47.4675022,18.8055463,3a,35.3y,85.25h,81.51t/data=!3m6!1e1!3m4!1s_4lLYsjnTzP_R_swduneHg!2e0!7i16384!8i8192?entry=ttu
>
> https://www.google.hu/maps/@47.4653939,18.8056303,3a,16.7y,337.24h,87.52t/data=!3m6!1e1!3m4!1s5KRYaFzRIWPFrMwQBrYf9g!2e0!7i16384!8i8192?entry=ttu
> do they imply a bicycle=designated value for the road if it is not a
> cycleway (because it is unnecessary for that), or is it enough to just put
> the lcn/rcn etc. value on the road.
>


IMHO, these markers have no legal meaning for accessibility (e.g. in
Germany and Italy), but I am not familiar with Hungarian law. Generally, a
route is mapped as a route (relation and/or lcn/rcn/ncn tags), while access
(bicycle=designated) is mapped according to traffic signs (these route
markers in jurisdictions I am aware of, are not "traffic signs" in this
sense). Legally, there is nothing wrong with a bicycle route where cycling
is not allowed (e.g. on short stretches), it just means you have to push.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Highway classification in Antarctica

[Martin Koppenhoefer]

Am Di., 30. Apr. 2024 um 01:47 Uhr schrieb Juan Pablo Tolosa Sanzana <
jptolosanz...@outlook.cl>:

> It has no sense to inflating classifications of every island in the word
> for being the most important road in respective island.
>
> If a neighbor garage is more quieter than the mine is not a justification
> to elevate road classification of one of them to compensate this difference.
>
> The highway=* tag is no made to use all classifications in a region
> delimited by you.
>
>


yes, agree to all of this, this is why I mentioned the length. A continent
is also not a region arbitrarily delimited by someone, especially if it is
completely surrounded by water, like antarctica.




> You need take account the function supplied by the road, the differences
> in the highway value are related to the function of the road.
>


The main criterion that we decided was "relative importance in the road
network". Function somehow has to do with it.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] breads of bakeries

[Martin Koppenhoefer]

what about
sells:bread=X;Y;Z (xyz being bread types)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] breads of bakeries

[Martin Koppenhoefer]

I agree for specific types of bread, but maybe we can have "classes" of
breads, if that makes sense. Personally, when going into a bakery I am
interested in the quality of the bread more than the exact type. Typically
I would ask "do you have bread made of natural sourdough" and the answers
will vary from "no" to "yes" to "all our breads are made from natural
sourdough", and I find this information worthy to record (although I am not
doing it yet). Similarly it can be interesting if they sell only bread or
also bread rolls, or also pizza.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] breads of bakeries

[Martin Koppenhoefer]

Am Fr., 3. Mai 2024 um 14:09 Uhr schrieb Zoon van Michiel <
spaanse@gmail.com>:

> What is the benefit of putting the breads a bakery sells into OSM? 
> Otherwise, bread is just bread. I will choose the variety I like best when
> I get there.

That even bakers might not advertise which sorts of bread they are selling
> could be another clue that it is not important.
> If the bakery is too small to have a website, it is not special and you
> can expect the regular selection of bread for the region you are in.



I have been looking at websites of local bakeries (didn't even expect they
had one, but actually they do), and there wasn't information about specific
types of bread (other than pictures of it, and text describing the
production by artisanal means). I agree that mostly bakeries in my area
will have a similar selection of bread and rolls, by type, but IMHO there
are significant differences in quality and taste (especially the latter may
be hard to describe in neutral, verifiable terms, although from discussion
with others my impressions about quality seem to be shared, so it is not
just "personal").

What I think could be interesting and apply universally, among others:
- natural or chemical leavening,
- availability of whole grain bread,
- kind of oven (wood fired or other (typically electrical), this is already
tagged with "oven")



> To further that point: because bakeries have similar offerings in similar
> regions, you don't need to tag all the bread they offer, only maybe what
> they don't offer.
>


no. Really not. If the list of what they offer is too long, the list of
what they don't offer will still be much longer.




>
> Why tag baguette=yes  in France, it is much easier to tag baguette=no  on
> the few shops that don't sell it. The same holds for basically all types of
> bread.
>


there are certainly different types of baguettes in France, while outside
of France, you will typically find just 1 or maybe 2 types.

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

Re: [Tagging] [RFC] Feature Proposal - Industrial tagging scheme complementing man made=works (was:works:type and works:process)

[Martin Koppenhoefer]

sent from a phone

> On 3 May 2024, at 15:39, Daniel Evans  wrote:
> 
> This proposal has now been updated on feedback, both here and on the talk page


thank you for working on this, the current improvements are promising, I think 
you could work a little bit on the page structure, now there are definitions in 
the proposal section and also at the end “specific tags”, maybe you could list 
the tags that you are planning to introduce in one place, and then describe 
tags and values each under a subheading of the (sub)key (if this sounds 
complicated, what I mean is rename “specific tags” to “works:stage” and move it 
into the proposal, etc. some cut+paste), or make a wikitable for the tags (IMHO 
these are a pain to work with though), because it is becoming long 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] voting shop=tortilla

[Martin Koppenhoefer]

forwarding this from the forum:

https://community.openstreetmap.org/t/voting-feature-proposal-shop-tortilla/113059

Voting will start tomorrow for shop=tortilla at the proposal page. I am not 
familiar with mailing lists, so, please, cross post this announcement on the 
tagging mailing list on my behalf by sending an email to: 
tagging@openstreetmap.org. If you do, I will appreciate it if you comment in 
this thread that you did crosspost my call for votes on the proposal.

I went ahead with the voting process since there were no more new comments in 
the RFC for a couple of days now.

Please vote YES! Am I allowed to vote, by the way? Proposal:Shop=tortilla - 
OpenStreetMap Wiki___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] voting shop=tortilla

[Martin Koppenhoefer]

sent from a phone

> On 11 May 2024, at 23:21, Martin Koppenhoefer  wrote:
> 
> If you do, I will appreciate it if you comment in this thread that you did 
> crosspost my call for votes on the proposal.


I sent it to the tagging ml
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Two way street, but entry of motor vehicles blocked at one end. Relation correct? Tagging correct?

[Martin Koppenhoefer]

there is also
restriction=no_entry
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Two way street, but entry of motor vehicles blocked at one end. Relation correct? Tagging correct?

[Martin Koppenhoefer]

sent from a phone

> On 20 May 2024, at 21:57, Bryce Nesbitt  wrote:
> 
> I tried that, but could not get the from, via and to nodes to work out. 


create a node at the actual start of the crossing street (some meters away from 
the crossing of the center ways) and split it there, that’s your via node.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Two way street, but entry of motor vehicles blocked at one end. Relation correct? Tagging correct?

[Martin Koppenhoefer]

Am Di., 21. Mai 2024 um 15:01 Uhr schrieb Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

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


the restriction is not applied to a section, it is applied to a point, you
may not cross the sign in this direction.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Two way street, but entry of motor vehicles blocked at one end. Relation correct? Tagging correct?

[Martin Koppenhoefer]

sent from a phone

> On 1 Jun 2024, at 19:55, Mateusz Konieczny via Tagging 
>  wrote:
> 
> yes, but tagging very short stretch of road (say 3m where it is not connected 
> to anything) 
> conveys the same info without using relations



it is tagging for the router, you add a oneway restriction where there isn’t 
because you assume it will work just as fine. Turn restrictions and similar 
restrictions require the use of relations, it is not a problem it’s the default
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Two way street, but entry of motor vehicles blocked at one end. Relation correct? Tagging correct?

[Martin Koppenhoefer]

sent from a phone

> On 23 Jun 2024, at 12:35, Greg Troxel  wrote:
> 
> So I think you should absolutely have the oneway section, even if you
> also add another tag.  Unless of course there is evidence that the large
> majority of routers would do the right thing.


there is no oneway section because there is no oneway sign, there is only a 
no-entry sign at a certain point, and the no-entry restriction relation is 
perfect for representing it, many routers will understand it or could easily 
support it because turning restrictions are expected to be implemented in 
routers
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - Deprecate crossing=zebra in favor of crossing:markings

[Martin Koppenhoefer]

sent from a phone

> On 28 Jun 2024, at 17:52, bauer3--- via Tagging 
>  wrote:
> 
> I would like to introduce my proposal to deprecate crossing=zebra and replace 
> the instances with the nowadays more popular alternative of 
> crossing:markings=zebra and crossing=uncontrolled.


it is almost equally popular, 453k of crossing=zebra vs. 461k of the 
combination you favor.

Frankly, I prefer a simple single tag instead of 2 for the usual crossing case 
I encounter all the time, the crossing:markings subtag could still be useful 
for particular situations, but I think having it implied by a simple 
crossing=zebra is easier. Also, I dislike the „uncontrolled“ term because I 
think it is counter intuitive for a crossing that is controlled by crossing 
markings and often traffic signs 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [RFC] Feature Proposal - Deprecate crossing=zebra in favor of crossing:markings

[Martin Koppenhoefer]

sent from a phone

> On 28 Jun 2024, at 21:15, Mark Wagner  wrote:
> 
> at the current pace, the specific combination of
> "crossing=uncontrolled, crossing:markings=zebra" is probably going to
> have double the usage of "crossing=zebra" by the end of the year.


that’s possible, just currently both are the same, you cannot see it in 
taghistory because it doesn’t allow for tag combinations 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] [Voting] (Post-comment changes) Add ability to specify ordering-only phone number, sms-only phone numbers and related tags

[Martin Koppenhoefer]

forwarding on behalf of Jason, Begin forwarded message:

> From: Jason Olshefsky via OpenStreetMap Community Forum 
> 
> Date: 16 July 2024 at 04:26:10 CEST
> To: dieterdre...@gmail.com
> Subject: [General talk/Tagging general discussion] [Voting] (Post-comment 
> changes) Add ability to specify ordering-only phone number, sms-only phone 
> numbers and related tags
> Reply-To: OpenStreetMap Community Forum 
> 
> 
> 
>   Jason_Olshefsky 
> July 16
> After a second round of comments, voting is now open on the proposal, “Add 
> ability to specify ordering-only phone number, sms-only phone numbers and 
> related tags ”, announced in the community topic, “[RFC] Add ordering:* keys; 
> add contact:sms ”.
> 
> Please, cross post this announcement on the tagging mailing list on my behalf 
> by sending an email to: tagging@openstreetmap.org. Thanks!
> 
> Visit Topic or reply to this email to respond.
> 
> You are receiving this because you enabled mailing list mode.
> 
> To unsubscribe from these emails, click here.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] RFC: deprecate cycleway=shared (forwarded)

[Martin Koppenhoefer]

crossposting on behalf of tordans:



https://community.openstreetmap.org/t/rfc-feature-proposal-deprecate-cycleway-shared/116579



Hello! I am looking into deprecating cycleway=shared (notshared_lane). Please 
find the proposal at Proposal:Deprecate cycleway=shared - OpenStreetMap Wiki

I suggest we use this thread for comments (instead of the Wiki Discussion page).___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] VOTING, Fwd: [General talk/Tagging general discussion] Proposal to replace `denomination=mormon` with `denomination=latter-day_saint`

[Martin Koppenhoefer]

sent from a phone

Begin forwarded message:

> From: dknelson9876 via OpenStreetMap Community Forum 
> 
> Date: 14 August 2024 at 04:44:16 CEST
> To:
> Subject: [General talk/Tagging general discussion] Proposal to replace 
> `denomination=mormon` with `denomination=latter-day_saint`
> Reply-To: OpenStreetMap Community Forum 
> 
> 
> 
>   dknelson9876 
> August 14
> I have created the formal proposal matching this discussion on the forum: 
> link and started the RFC period
> 

FYI, the voting period has begun on this proposal’s wiki page.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

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

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



it may depend on the area, but around here restrictions relating to actual
weight are rather rare, because they are impractical to verify, while
weight ratings can be seen in the vehicle documents and are easy to check.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Adding man_made=spoil_heap to the Map Features page?

[Martin Koppenhoefer]

sent from a phone

> On 4. Jun 2020, at 02:29, Joseph Eisenberg  wrote:
> 
> The Map Features page is already quite long and unwieldy, so it is reasonable 
> to limit how many more tags are added.


yes, it is already so long, it really doesn’t matter so much whether you add 
another item or not, it’s too long to read entirely. My suggestion would be to 
make it either very short so it’s obvious it is incomplete and only major tags 
(examples), or add everything with something like 50+ or 100+ uses.

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

Re: [Tagging] Adding man_made=spoil_heap to the Map Features page?

[Martin Koppenhoefer]

sent from a phone

> On 4. Jun 2020, at 02:41, Mateusz Konieczny via Tagging 
>  wrote:
> 
> All features with 50+ uses? It would probably not load within minute in a 
> typical browser.


you’re right, make it 500

> 
> In its current state it is still barely usable.


+1

Cheers Martin 


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

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

[Martin Koppenhoefer]

sent from a phone

> On 6. Jun 2020, at 03:58, Jack Armstrong  wrote:
> 
> 
> The wiki permits the mapping of reality, on-the-ground, as it is in the world 
> today. OSM should reflect what exists today, not decades ago. If there is 
> something that remains of a previous railroad, then it can be mapped in some 
> way. If there is nothing remaining of what used to be a railroad, it should 
> be out-of-scope.



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

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

Re: [Tagging] Adding mapillary tags to every building

[Martin Koppenhoefer]

sent from a phone

> On 5. Jun 2020, at 10:14, European Water Project 
>  wrote:
> 
> They also expressed interest in having more Mapillary images linked to OSM 
> objects.


from the OpenStreetMap point of view it seems preferable to have the images we 
link to available openly. If mapillary doesn’t allow for downloading the images 
(only thumbnails/previews) we should not link to it.

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

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

[Martin Koppenhoefer]

sent from a phone

> On 4. Jun 2020, at 16:56, Cornelis via Tagging  
> wrote:
> 
> Maybe this one even serves as example for an old railway that in fact
> should be mapped to explain these clearly visible features that
> otherwise would lack an explanation?


this is about a different topic: projects that have been started but have never 
been completed and the fragments are now either:
repurposed 
or 
left to decay
or
waiting to be completed

Cheers Martin 



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

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

[Martin Koppenhoefer]

sent from a phone

> On 6. Jun 2020, at 00:04, Volker Schmidt  wrote:
> 
> I do object strongly to the invitation to remove the razed/dismantled-railway 
> tag in the case of railway tracks have been replaced by roads with the same 
> geometry.


+1

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

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

[Martin Koppenhoefer]

sent from a phone

> On 7. Jun 2020, at 23:54, Jarek Piórkowski  wrote:
> 
> Do you also object when the geometry of the railway and the road is a
> straight line?


yes

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

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

[Martin Koppenhoefer]

sent from a phone

> On 7. Jun 2020, at 03:32, Warin <61sundow...@gmail.com> wrote:
> 
> How hard you look for them? I would hope that does not extend to ground 
> penetrating radar that is used to find old buildings that used to exist
> 

ultimately things under the surface would be included, the distinction is not 
how difficult to find or hard to access something is, but whether “it exists”


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


If nothing at all has remained, usually no, eventually for some time yes (e.g. 
to avoid someone reputting it from aerial imagery). 
> 
> And yes I am thinking of old railway routes that have gone and been replaced 
> with roads/rail trails etc. 
> 
> 
> 
> To me - the old thing is no longer there, the new thing has overlay-ed it and 
> replaces it. If people want to map old things .. well their place should be 
> in OHM not OSM.


we were discussing things which have been removed or have decayed but of which 
something has remained. These can be very sparse, small and hard to find 
traces, but something must be observable. It does not mean everybody must be 
able to identify and correctly interpret it, even without additional knowledge.

Cheers Martin 


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

Re: [Tagging] Features underwater (inside reservoirs)

[Martin Koppenhoefer]

sent from a phone

On 6. Jun 2020, at 11:22, Lanxana .  wrote:

But how to indicate that it’s underwater partially or totally and its
access is occasionally possible, when the water drops?



an area with natural=water around it?


I find these tags, but none convinces me:...

Location=underwater [3] -> it seems that it’s appropriate but the
description tells “installed between a water surface and the floor
beneath”, it isn’t the case…


the definition doesn't seem suitable. Why shouldn't an underwater thing
extend into the ground? The relevant part is "inside a water body / under
water surface", but there shouldn't be requirements to not extend
below/inside the floor


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

Re: [Tagging] Adding mapillary tags to every building

[Martin Koppenhoefer]

Am Mo., 8. Juni 2020 um 10:48 Uhr schrieb European Water Project <
europeanwaterproj...@gmail.com>:

> Dear Martin,
>
> For-profit companies have different levels of openness, I think it would
> be a mistake to put them all in the same bucket.
>
> While all their data and images are not open, Mapillary shares many
> geolocalized images through creative commons licensing - in a more open
> manner than many non-profit companies and local municipalities.
>


I might have not been clear with "If mapillary doesn’t allow for
downloading the images (only thumbnails/previews) we should not link to
it.", what I meant was that I would not encourage people to build on
systems that aren't open (it didn't mean: go and remove them). I would also
not object to people doing it nonetheless (if the links are still useful
because you can get "something" from them), but we should be aware that we
are building on sand here. The owner of the external db (here mapillary)
can choose at any time to deny access to its data, or the company may go
bancrupt or close its business for other reasons and we might have put a
lot of effort into this in vain. Open projects allow for forking, while
proprietary systems usually don't, so that the usefulness of related tags
is deeply linked to the goodwill and operational situation of the company.



> Hopefully a significant level of data openness will continue to be part of
> Mapillary's business model.
>
>

yes, we can just hope for it. Not more.

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

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

[Martin Koppenhoefer]

Am Mo., 8. Juni 2020 um 11:20 Uhr schrieb Mateusz Konieczny via Tagging <
tagging@openstreetmap.org>:

> On 6. Jun 2020, at 00:04, Volker Schmidt  wrote:
>
> I do object strongly to the invitation to remove the
> razed/dismantled-railway tag in the case of railway tracks have been
> replaced by roads with the same geometry.
>
> +1
>
> Add I have no problem with removal of them.
>


this is fine, we do not have to share opinions on everything. But we should
be cautious to not misrepresent community consensus in the wiki. It doesn't
appear to be an universally shared conviction that you can remove these
objects of which the traces are less evident than of other things.



>
> I see the point in cases of ones where there are no traces
> but road geometry makes 100% clear that railway was there
> and probably would not delete them.
>
> I see point in cases where track of former railway is marked/
> memorialized/etc and that info is mentioned on OSM object.
>
> But for cases where new road is matching geometry but shape
> is not recognizable at all as track of former railroad, and
> historic maps are needed to recognize it?
>


there aren't only written/drawn sources by the way. Oral tradition can also
be relevant. Your grandpa told your dad and your dad told you, why not?



>
> Deletion should happen, OSM is not for objects that are gone.
>


we were discussing objects which left traces. "are gone" is not very
precise, do you intend to include things which aren't operational but
traces are there? Or does is mean "left not traces whatsoever"?



>
> https://en.wikipedia.org/wiki/Western_Interior_Seaway
> https://en.wikipedia.org/wiki/Ural_Ocean
> https://en.wikipedia.org/wiki/Sundance_Sea
> and other https://en.wikipedia.org/wiki/Category:Historical_oceans
> also left traces and are not mappable in OSM
>


I agree that these are not very compatible with OSM, similar to current
geological features, and even current oceans aren't very well represented
in OSM. They aren't good examples for discussing dismantled railways
though. They are former natural features, of millions and billions years
ago (i.e. all the coastlines were completely different), while railways are
man made features.

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

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

[Martin Koppenhoefer]

Am Mo., 8. Juni 2020 um 12:28 Uhr schrieb Mateusz Konieczny <
matkoni...@tutanota.com>:

>
> Jun 8, 2020, 11:39 by dieterdre...@gmail.com:
>
> Am Mo., 8. Juni 2020 um 11:20 Uhr schrieb Mateusz Konieczny via Tagging <
> tagging@openstreetmap.org>:
>
> On 6. Jun 2020, at 00:04, Volker Schmidt  wrote:
>
>
> I do object strongly to the invitation to remove the
> razed/dismantled-railway tag in the case of railway tracks have been
> replaced by roads with the same geometry.
>
>
> +1
>
> Add I have no problem with removal of them.
>
>
>
> this is fine, we do not have to share opinions on everything. But we
> should be cautious to not misrepresent community consensus in the wiki. It
> doesn't appear to be an universally shared conviction that you can remove
> these objects of which the traces are less evident than of other things.
>
> Can you edit wiki or link problematic page and quote text that should be
> changed?
>


the reference is Volker 6/6/2020, 0:04:

> Nevertheless the wiki page Demolished_Railway
>  was completely
> rewritten on 07:17, 27 May 2020 by Mateusz Konieczny
> 
> In particular the wording
> " Here railway is gone without any trace in terrain except possibly road
> alignment. Its course is well documented, but such historic feature is out
> of scope of OpenStreetMap, should not be mapped and should be deleted if
> mapped"
> in the caption of the first picture is certainly something we were talking
> about, but had not agreed upon.
>



Lets say that there was a castle and was replaced by a sport pitch, and
place looks like

> this nowadays (a theoretical example):
>
> https://upload.wikimedia.org/wikipedia/commons/c/cd/Tehelne_pole-pitch_and_stand.JPG
>
> Castle is remembered. Is such castle mappable? In my opinion would not be
> as there are
> no identifiable traces (possibility of archeological excavations are not
> really changing this).
>



I do not know if this is a real example (you say it is theoretical), but
according to what I experience every day, you can find many traces of
former things, which do not exist as such any more, but are still
detectable. Objects like castles hardly ever vanish completely without
leaving any traces.

Take the Berlin castle for example, here a sequence of different states:

around 1900, at its "top"
https://upload.wikimedia.org/wikipedia/commons/thumb/4/4f/Berlin_Nationaldenkmal_Kaiser_Wilhelm_mit_Schloss_1900.jpg/1280px-Berlin_Nationaldenkmal_Kaiser_Wilhelm_mit_Schloss_1900.jpg

tearing it down 1950:
https://upload.wikimedia.org/wikipedia/commons/7/7e/Bundesarchiv_Bild_183-08687-0010%2C_Berlin%2C_Stadtschloss%2C_Abriss.jpg

new building atop in 1981 (from the seventies):
https://upload.wikimedia.org/wikipedia/commons/3/36/Bundesarchiv_Bild_183-Z0602-323%2C_Berlin%2C_Palast_der_Republik%2C_Fernsehturm.jpg

>From the last picture you would not expect that anything remained, but when
they tore down the seventies building around the year 2000, some parts of
the old castle surfaced:
https://commons.wikimedia.org/wiki/File:Berlin_Berliner_Stadtschloss_Keller_001.JPG

So even if this would be the only reason, there would have clearly been
traces of the castle, although not visible on the ground (but below). But
there are other, less direct, traces. For example the castle left traces in
the urban structure, the main arterial road bends in front of the castle,
and it did so also during the time when the castle wasn't there. And some
buildings around it have always been referring to the castle, e.g. the
building for the imperial guards and horses. Also the name of the bridge
(castle bridge / Schloßbrücke) was always referring to the castle.

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

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

[Martin Koppenhoefer]

sent from a phone

> On 9. Jun 2020, at 03:40, Warin <61sundow...@gmail.com> wrote:
> 
> Similar for Roamn and Saxon sites, if there is something present today, map 
> it... nothing there then nothing on OSM, put it in OHM


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


Cheers Martin 



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

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

[Martin Koppenhoefer]

sent from a phone

> On 8. Jun 2020, at 18:14, Alan Mackie  wrote:
> 
> Last I heard it was "mostly harmless".


the less dangerous an area is, the more the remaining dangers will be 
emphasized. Let’s tag normalized dangerousness ;-)

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

Re: [Tagging] Adding mapillary tags to every building

[Martin Koppenhoefer]

sent from a phone

> On 8. Jun 2020, at 11:53, European Water Project 
>  wrote:
> 
> Which is why we seek to store user contributed images on Wikimedia Commons 
> (if they will accept them) rather than on our server. 


+1, I completely agree, of all available options wikimedia commons seems a good 
choice wrt openness and supposed stability/permanence.
Are you planning to change the image tags in OpenStreetMap after uploading the 
pictures to commons? (I have noticed that currently they are pointing to your 
server).

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

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

[Martin Koppenhoefer]

sent from a phone

> On 10. Jun 2020, at 01:07, Mike Thompson  wrote:
> 
> I asked this same question about a trail in a nearby park (Natural Area) a 
> couple of weeks ago on this list and received a largely different answer from 
> the one I am receiving today.   Perhaps it is just that different people are 
> reading this list today. 


frankly I guess most people are not interested in changing the definitions for 
track or path or service, nor are they believing that it is possible to do it, 
hence they might be avoiding reading long threads about these topics. These 
discussions have been held so many times that it is not very likely that new 
arguments will evolve which change everything. It’s my opinion and I might be 
wrong, please don’t feel discouraged to continue the discussion if you think 
differently.

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

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

[Martin Koppenhoefer]

sent from a phone

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


+1 for service, while tracks may actually “go somewhere”, they might be usable 
as through ways, but they are not considered “roads“ in some jurisdictions at 
least.

service roads are for accessing something (are not part of the connection 
grid), while tracks may (according to the regional situation) form a kind of 
„second grid“ (for agricultural purposes, but eventually open to cyclists, 
hikers, etc. as well).

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

Re: [Tagging] Do we map pedestrian crossings twice?

[Martin Koppenhoefer]

Am Mi., 10. Juni 2020 um 14:09 Uhr schrieb Kevin Kenny <
kevin.b.ke...@gmail.com>:

> As far as I know, all routers need the node if they're going to, for
> instance, present a warning to an approaching motorist or cyclist that
> the crossing is impending. But some attributes of the crossing (most
> notably, its full geometry!) can belong only to a way.



+1, I am doing it usually like this:
highway=footway (or cycleway) and footway=crossing on the way (from kerb to
kerb).
highway=crossing and crossing=traffic_signals / zebra / uncontrolled etc.
on each intersection node of the street(s) with the crossing way.

i.e. there is no "highway=crossing" or "crossing=*" on the way, instead the
crossing information there is conveyed as a kind of footway.

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

Re: [Tagging] Do we map pedestrian crossings twice?

[Martin Koppenhoefer]

sent from a phone

> On 10. Jun 2020, at 20:28, Clifford Snow  wrote:
> 
> 1. Tagging both the crossing and a node on the highway. 
> https://mycloud.snowandsnow.us/index.php/s/YEFoYcTgR2gtW3j
> 2. With no crossing ways, just a node on the highway to mark the type of 
> crossing https://mycloud.snowandsnow.us/index.php/s/4ad5wLzMNcE3sNo
> 3. With just crossing ways and no node at the intersection of the crossing 
> and highway. https://mycloud.snowandsnow.us/index.php/s/tHF62pH5txPEX55


1 is the scheme when it is a dual carriageway or there is at least one explicit 
sidewalk (or cycleway in case of bike crossing) mapped


2 if you do not have to connect other things


3 is incomplete and you may expect that routing software for cars might not 
become aware of the crossing, and the type of crossing (markings, lights, etc)


Of course you could find out with solution 3 that there is a crossing node, but 
as the docs always said that there’s the tags on the node, they are set up to 
not do it (i.e. they can build their graph without footways). In preprocessing 
these tags could be automatically set on the node (provided the kind of 
crossing would be given on the crossing way, otherwise that there is a 
crossing).

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

Re: [Tagging] Do we map pedestrian crossings twice?

[Martin Koppenhoefer]

sent from a phone

> On 10. Jun 2020, at 18:19, Clifford Snow  wrote:
> 
> Before changing the wiki, I'd like a clearer understanding of your proposed 
> change.


this sentence was only introduced recently, it is not backed by history, 
current usage or the people in this thread here. Just remove it...

https://wiki.openstreetmap.org/w/index.php?title=Tag%3Ahighway%3Dcrossing&type=revision&diff=1950634&oldid=1941458


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

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

[Martin Koppenhoefer]

sent from a phone

> On 10. Jun 2020, at 18:56, Mike Thompson  wrote:
> 
> Also, the land manager (e.g. parks and recreation department) has access to 
> almost all of their properties via motor vehicle.
> 
> Does this only apply to unpaved ways?  


General motorized traffic is typically excluded, while traffic for agricultural 
or forestry scope has access. It has nothing to do with surface quality, in 
some areas most tracks are paved.


Cheers Martin 



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

Re: [Tagging] Do we map pedestrian crossings twice?

[Martin Koppenhoefer]

sent from a phone

> On 10. Jun 2020, at 23:28, Clifford Snow  wrote:
> 
> I would suggest that the one feature per element page needs to include a 
> couple of exceptions to the rule. 


the rule is mostly pointless, because it depends what you define as a feature. 
In the crossing example there is no infraction of the rule:
there is one feature which is a pedestrian crossing (footway of type crossing) 
and there is a crossing node where a crossing footway crosses the highway way 
(different feature).

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

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

[Martin Koppenhoefer]

sent from a phone

> On 14. Jun 2020, at 20:02, Niels Elgaard Larsen  wrote:
>> What do you mean by 'just unused?'
> 
> 
> Waiting to be demolished


or repaired, turned on, reused etc.
just unused means not currently used/operating, but might again in the future, 
or not.

For example a disused drinking fountain is useless at the moment, and it might 
be removed, or maybe turned back into operation without repair. 

On the other hand, an abandoned fountain would require repair, e.g. 
https://www.openstreetmap.org/node/270304103

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

[Tagging] site relation definition

[Martin Koppenhoefer]

I just noticed that a year ago someone well meaning has significantly
changed the site relation definition, by introducing the requirement for
the site to be "man_made":

https://wiki.openstreetmap.org/w/index.php?title=Relation%3Asite&type=revision&diff=1850677&oldid=1850254

According to the comment, this is based on the original proposal (dating
probably 10 years back).
IMHO it does not make sense to change the definition after so many years,
and with already so many objects tagged.

Can we remove the "man_made" requirement?

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

Re: [Tagging] Adding mapillary tags to every building

[Martin Koppenhoefer]

sent from a phone

> On 19. Jun 2020, at 11:20, European Water Project 
>  wrote:
> For how long ?


for as long as Facebook wants. There is also the practical aspect: even if the 
license is permissive, it doesn’t imply you can actually get the data for 
downloading.

Facebook has changed conditions of their services in the past, let’s recall 
their whatsapp acquisition where they promised it would remain “independent” 
from the rest of Facebook and where they then combined/unified their messenger 
services under the same hood some years later. If history has told us one 
thing, it’s not to trust facebook (IMHO not even as far as you’re able to throw 
them)...

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

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

[Martin Koppenhoefer]

sent from a phone

> On 19. Jun 2020, at 20:32, Joseph Eisenberg  
> wrote:
> 
> A qanat is a specialized kind of underground aqueduct which is the 
> traditional way of supplying water in hot and arid climates within limited 
> distance of a mountain range.


while the description reads quite neutral and inclusive, as if these features 
could occur everywhere on the globe, the term suggests it is very specific to a 
cultural region. Can you explain in what way these are “specialized”, what the 
criteria for the tag are (is this for all kinds of underground aqueducts “in 
hot and arid” climate or are there specific requirements for the term?). Is 
this only about historic features, or are there also modern qanats that get the 
tag? IMHO, if we want to include all kinds of underground aqueducts, something 
more generic would suit better, while I would be fine with tagging actual 
qanats as qanats.

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

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

[Martin Koppenhoefer]

What about historic=aqueduct
should it be applied as well, in case of historic qanats?


Cheers Martin 

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

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

[Martin Koppenhoefer]

Am Fr., 19. Juni 2020 um 23:15 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> As mentioned on the proposal page, there are 4 criteria, which all qanat
> features share:
>
>
>- The immediate source of water is groundwater (aquifer or well), not
>a spring, stream or river
>
>

a spring is groundwater as well.



>
>- Water flows by gravity in free flow (not pressurized or pipe flow)
>- The channel is underground, minimising evaporation
>- Construction and maintenance is through vertical shafts, which are
>then visible on the surface
>
>

if there are parts that are in pipes, will the qanat be interrupted? If
vertical shafts are not present, it is not a qanat (e.g. short enough to
not require these shafts)?


>
> The short definition of the tag will be "A gently-sloping man-made
> underground channel for transporting groundwater via gravity, with shafts
> visible from the surface."
>


my suggestion would be to add a "typically" before "with shafts visible
from the surface", because it would seem strange to need a different main
tag just because the shafts aren't visible for one reason or the other
(e.g. hidden on purpose)

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