Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Hello Allan, sorry, I'm a late comer to the discussion, so there might be something I've/am missed/missing, but... From your description I understand that "embassy=*", "consulate=*" and "liaison=*" will be new first level keys: wouldn't it be better to make them secondary level keys under the

Re: [Tagging] Estimated values for height

Hello everybody, I'm the one who, in the Italian mailing list, first brought out the issue about how to tag estimated heights (/in our context it was about trees height/). My first proposal has been to use a new sub-key in which to store estimated values, as in "height:estimated=10". Then I

Re: [Tagging] Estimated values for height

Yes, agreed, but in our user case we are importing official government data about historical/monumental/landmark trees and one of the fields that will be imported is the survey date (survey:date). If, at a second time, someone will update info about the tree height I *hope* he/she will have

Re: [Tagging] Estimated values for height

Please, just forget about trees (/and the fact that they obviously grow.../): trees have only been the "/casus belli/", the case for which we asked ourselves how "Estimated values for height" (/the topic of this thread.../) should be tagged. The real question, I think, is if it is correct to

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Thanks! ... but I don't see a voting section in https://wiki.openstreetmap.org/wiki/Proposed_features/office%3Ddiplomatic Is this because voting is not open yet? Sergio On 2018-11-13 15:26, Paul Allen wrote: > > > On Tue, Nov 13, 2018 at 2:13 PM Sergio Manzi <mailto:s...@sm

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Colin, I subscribe to every single word of your post... bravo! Regards, Sergio On 2018-11-12 22:37, Colin Smale wrote: > At moments like this I like to invoke one of my heroes: Albert Einstein. One > famous saying attributed to him is: As simple as possible, but no simpler. > > If you

Re: [Tagging] Feature Proposal - RFC - (consulate)-->(office=diplomatic)

Me too. I let my "/namespacing/" modification proposal die: this is not the time and the place. BTW, can you quickly explain, to a newbie like me, who has voting rights and what the voting process will be? Can you point me to any documents about that? Regards, Sergio On 2018-11-13 12:54,

Re: [Tagging] Estimated values for height

Sorry, typo: *g*uestimate, not *q*uestimate!! On 2018-11-13 16:07, Sergio Manzi wrote: > > Yeah, agreed. And I think in our context "/estimate/" should be more taken as > "/quesstimate/", i.e. "/a first rough approximation pending a more accurate > est

Re: [Tagging] Estimated values for height

Grunt: *g*uesstimate, not *q*uesstimate On 2018-11-13 16:16, Sergio Manzi wrote: > > Sorry, typo: *g*uestimate, not *q*uestimate!! > > On 2018-11-13 16:07, Sergio Manzi wrote: >> >> Yeah, agreed. And I think in our context "/estimate/" should be more taken >

Re: [Tagging] Estimated values for height

source has stated that the measurement is an estimation. It can happen. It's actually happening... On 2018-11-13 22:31, Sergio Manzi wrote: > > I missed the existence of "/metric/:source". > > At first sight (my /guesstimate/...) it is not much used (/46 times it is

Re: [Tagging] Estimated values for height

I missed the existence of "/metric/:source". At first sight (my /guesstimate/...) it is not much used (/46 times it is associated to "width", 0 times with "length", and 413 times with "heigth"/), but it is actually used with that meaning (/the most used value is "estimated"/), and it could be

Re: [Tagging] Estimated values for height

... because, as you correctly point out, comments are just a human-to-human thing (/let's put AI aside for the moment.../), while a structured information for accuracy could open the way to an automated method to "/update this information only if the accuracy of this new measure is better than

Re: [Tagging] Yay, new howto map for diabilities created in wiki

Perfect! On 2019-01-15 10:00, Philip Barnes wrote: > How to map the needs of people with disabilities smime.p7s Description: S/MIME Cryptographic Signature ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

Well, sorry, obviously I did an editing mistake and the "/Wikipedia defines 6 types of forest/" phrase jumped up in the wrong place: it should be just above the dotted list of forest types... Sorry about the confusion... Sergio On 2019-01-23 01:52, Sergio Manzi wrote: >

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

On 2019-01-23 04:14, Warin wrote: > Temperate and Tropical moist/dry are climates... if those are to be mapped > them go right ahead .. but they are not confined to forests, so should be > mapped separately. Those are simply the names biologists give to that forest types.  E.g. "Tropical

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

Only about the cited point (/tagging natural forests as natural=wood/), I think a natural forest should be tagged as natural=forest (/quite logically, I would say.../), while natural=wood should be reserved for "small forests" (/which is one of the possible meaning of "wood" in English, if I'm

Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

Hi! On 2019-01-23 02:10, Joseph Eisenberg wrote: > The one thing that’s missing is a tag for the density of the main vegetation > type; is it a dense canopy of trees, or dense scrubland, verses more widely > spaced. Not only that (and the "leaf cycle" thing): again, a forest is not a bunch of

Re: [Tagging] emergency=control_centre

Just a short note to let you know that in the Italian mailing list (talk-it) we recently had the contribution of an ambulance driver who reported how in his zone he uses OSM maps as the best solution availabale. Cheers! Sergio On 2018-12-10 13:06, Paul Allen wrote: > On Mon, Dec 10, 2018 at

Re: [Tagging] Feature Proposal - RFC - Ephemeral a water property key.

On 2018-12-13 02:36, Warin wrote: > At the moment developing a system to render seasonal values on requires a  > determination on spring/summer/autumn/winter etc .. this would add some new > terms. Not too hard but does add to things. Also developing a system to render the ephemeral key would

Re: [Tagging] Feature Proposal - RFC - Ephemeral a water property key.

Sorry, read: /we could simply add the following //*values *//for intermittent=*:/ On 2018-12-13 01:52, Sergio Manzi wrote: > /we could simply add the following //*keys *//for intermittent=*:/ smime.p7s Description: S/MIME Cryptographic Signat

Re: [Tagging] Feature Proposal - RFC - Ephemeral a water property key.

Hello Warin, I think that extending the defined values for intermittent=* could yield the same result and convey the very same information *without adding a new tag* (/don't we have enough?/) Assuming (/and this is just an assumption at this time.../) that we are able to define a correct and

Re: [Tagging] Benefits of namespaces

u, 20 Dec 2018 at 12:36, Sergio Manzi mailto:s...@smz.it>> > wrote: > > The definition of primary v.s. secondary is about which is the exciting > part and which is the excited part. "tertiary" is pure nonsense, AFAIK. > > > Power transformers can have tertia

Re: [Tagging] Benefits of namespaces

and which is the excited part. "tertiary" is pure nonsense, AFAIK. Sergio On 2018-12-20 13:27, Xavier wrote: > On Thu, Dec 20, 2018 at 01:00:20PM +0100, Sergio Manzi wrote: >> I *never *heard of a transformer's /tertiary/, thus: try asking an >> electrical engineer... >

Re: [Tagging] Benefits of namespaces

... unless we start putting columns (":") into keys according to a different logic. On 2018-12-20 11:44, Martin Koppenhoefer wrote: > Am Do., 20. Dez. 2018 um 11:36 Uhr schrieb Claudius Henrichs > mailto:claudiu...@gmx.de>>: > > It feels like the two arguments are about stying true to how

Re: [Tagging] Benefits of namespaces

BTW, if that's not clear: * railway:switch describe/is an *object* * fire_hydrant:position describe/is an *attribute *of the fire_hydrant object, for which, you are right, location=* would had been correct. On 2018-12-17 02:36, Sergio Manzi wrote: > > You are mixing correct names

Re: [Tagging] how to map soft story/soft storey buildings properly?

For what is worth, it sounds good to me. If you want to be even more precise and "/taxonomist/-minded", it could be building:structure:soft_storey=yes/no (/no being the default value/). Sergio On 2018-12-17 00:42, Stefano Maffulli wrote: > So far, building:soft_storey:y/n seems to be the

Re: [Tagging] how to map soft story/soft storey buildings properly?

Yeah... you're right... "/Buildings are classified as having a "soft story" if that level is less than 70% as stiff as the floor immediately above it, or less than 80% as stiff as the average stiffness of the three floors above it./" [1] hard to eyeball that... But the key would be right for

Re: [Tagging] Benefits of namespaces

Hello, You are mixing correct namespacing (like railway:switch) with... mistaken namespacing (like hydrant:position). Now, for the reasons for namespacing and just as an example (/it is not the only good reason.../), think about documentation: the documentation for describing a power switch

Re: [Tagging] Benefits of namespaces

Sorry, I meant to say: the documentation describing *railway switches* should not be intermixed with the documentation describing power switches On 2018-12-17 02:36, Sergio Manzi wrote: > the documentation for describing a power switch should not be intermixed with > the documen

Re: [Tagging] Feature Proposal - RFC - Ephemeral a water property key.

And of course my apologies to Warin too! On 2018-12-14 11:26, Sergio Manzi wrote: > > Hello Mateusz, > > On 2018-12-14 10:40, Mateusz Konieczny wrote: >> New keys are much, much better than new values for tags well established as >> having boolean values. > > S

Re: [Tagging] Feature Proposal - RFC - Ephemeral a water property key.

Hello Mateusz, On 2018-12-14 10:40, Mateusz Konieczny wrote: > New keys are much, much better than new values for tags well established as > having boolean values. Sorry, you are absolutely right: in my head I had mixed up the values for intermittent=* with the values for seasonal=*. My bad!

Re: [Tagging] how to map soft story/soft storey buildings properly?

Hello Martin, On 2018-12-17 11:32, Martin Koppenhoefer wrote: > yes, _*it is a structural detail*_ (insufficient stiffening/strutting, if I > interpret it correctly), that's why it is _*not suitable as a value for > building:structure*_, as that key is about the structural system, not about >

Re: [Tagging] Benefits of namespaces

Bonjour François, On 2018-12-17 11:50, François Lacombe wrote: > I own no switches. Sorry, I didn't meant to be rude in any way: I just assumed you were the one who introduced the switch=* key for power lines (/and apparently I was wrong, you just "expanded" the information about those...)/ >

Re: [Tagging] Benefits of namespaces

Thanks, me too! :-) If you are interested in this kind of things, have a look at the following (/not an exaustive list of topics, just a random one.../): * https://en.wikipedia.org/wiki/Namespace * https://en.wikipedia.org/wiki/Uniform_Resource_Name *

Re: [Tagging] how to map soft story/soft storey buildings properly?

wrote: > > > sent from a phone > > On 17. Dec 2018, at 13:34, Sergio Manzi mailto:s...@smz.it>> > wrote: > >> I added emphasys to part of your quote to underline how I fail to understand >> how a "structural detail" cannot be construed as a sub-

Re: [Tagging] Printing company for newspapers

Hello, I would abstain from shop=* as a shop is a place where products can be bought: "/Use shop=* to mark the location of a shop and the products that it *sells*./" [1]. I would also abstain from craft=* as it applies to "/small production of goods *on demand and by order*/"  [2] The places

Re: [Tagging] Neighborhood Gateway Signs?

No, wait, I disagree with the "place=neighbourhood" thing! See: https://wiki.openstreetmap.org/wiki/Places and https://wiki.openstreetmap.org/wiki/Key:place Cheers! On 2018-11-30 18:10, Sergio Manzi wrote: > > Seems very good to me. > > * already used: https://taginfo.

Re: [Tagging] Neighborhood Gateway Signs?

board_type in information=board, but welcome signs are far from being restricted to boards On 2018-11-30 18:18, Sergio Manzi wrote: > > No, wait, I disagree with the "place=neighbourhood" thing! > > See: https://wiki.openstreetmap.org/wiki/Places and > https://wiki.openstre

Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

Fitzpatrick wrote: > > > On Fri, 30 Nov 2018 at 02:19, Sergio Manzi mailto:s...@smz.it>> > wrote: > > Right! Too many payments! :-) To spare some bytes it could be: > payment:sms:ExampleApp:code=.  What do you think? > > I would think that it shouldn't be up to OSM

Re: [Tagging] Feature Proposal - Voting - boundary=aboriginal_lands

+1000! On 2018-11-29 03:52, Paul Johnson wrote: > Treating tribal boundaries as other political boundaries humanizes the > situation. smime.p7s Description: S/MIME Cryptographic Signature ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Neighborhood Gateway Signs?

Seems very good to me. * already used: https://taginfo.openstreetmap.org/tags/man_made=gantry * proposal exist: https://wiki.openstreetmap.org/wiki/Proposed_features/Gantry In the proposal I don't like very much the way to indicate clearence, maxheight:physical=* (/what? opposed to... 

Re: [Tagging] Neighborhood Gateway Signs?

n place=neighbourhood is more likely to be usable by a routing > engine than usage=welcome_sign. > > Cheers! > >> On Nov 30, 2018, at 9:18 AM, Sergio Manzi mailto:s...@smz.it>> >> wrote: >> >> No, wait, I disagree with the "place=neighbourhood"

Re: [Tagging] Neighborhood Gateway Signs?

Oh, and, BTW, by doing that the neighbourood will not suddenly disappear if they ever take down the gantry...  :-) On 2018-11-30 21:21, Sergio Manzi wrote: > > I understand what you mean (/and it reminds me of my first arrival in India, > to the neighbourood of Pahrganj in New Delhi!

Re: [Tagging] Neighborhood Gateway Signs?

This! This! This! :-) On 2018-12-01 00:12, Kevin Kenny wrote: > The 'description' tag, perhaps? Things eventually get to the point where even > the obsessive classifiers on this list might as well admit that even if they > do introduce a taxonomy, it is likely that no data consumer will use it. 

Re: [Tagging] antenna use key to replace some of the antenna type

Hello, Warin, a couple of quick, non-exhaustive, notes on antenna use (or is it /usage/?) even if I'm still doubtful we should map with such detail: * amateur_radio: antenna systems used by *licensed *radio amateurs * transponder: I think they are mostly used on *mobile *systems

Re: [Tagging] Can OSM become a geospacial database?

Once again, reality is complex and multifaced: I don't think one should try to frame what is a local French reality, an "École primaire", into an US or UK based context: let the French decide... I have the same problem for some shop categories which are not part of the US/UK tradition: an

Re: [Tagging] Can OSM become a geospacial database?

... or maybe a better solution, if we would like the kind of shop to be comprhensible to people of different culture, then I would establish a namespace for food shops and then specify the (/locally relevant/) kind of shop, like eg. shop:food=salumeria. On 2018-12-05 22:26, Sergio Manzi wrote

Re: [Tagging] Can OSM become a geospacial database?

Naaahhh... just "complex/" /or/"/complicated"  (/I don't know which one is better in English/)...    :-) On 2018-12-06 00:48, Paul Allen wrote: > The real world is messy. > smime.p7s Description: S/MIME Cryptographic Signature ___ Tagging mailing

Re: [Tagging] Can OSM become a geospacial database?

that may only actually have water in > them very rarely,  > or in some cases, never in human memory! But they are still called lakes, > the same as the "normal" inland bodies of water. > > There is intermitent=yes tag to denote dry lakes as far as I remember

Re: [Tagging] Can OSM become a geospacial database?

anguage, perhaps? > > (That’s “natural=water” and “water=lake” in Bahasa Indonesia. Yes, “air” > means “water”) > > -Joseph > > On Thu, Dec 6, 2018 at 8:19 AM Sergio Manzi <mailto:s...@smz.it>> wrote: > > I understand your concerns and tend to agree, but how would

Re: [Tagging] Can OSM become a geospacial database?

P.S.: ... but if I want my /salumeria /to show up on the map, I *have to* "/lie for the rendering/" and tag it as a shop=deli: but'I'm not happy at all... On 2018-12-05 22:02, Sergio Manzi wrote: > > Once again, reality is complex and multifaced: I don't think one should try

Re: [Tagging] Can OSM become a geospacial database?

There is no way I can think of: for lack of better tagging some very different shop categories (/very different in our culture..//./), like the aforementioned "salumeria", "rosticeria", "polleria", the generic "alimentari", and many others, have all been tagged as "shop=deli", so we have "/lost

Re: [Tagging] Can OSM become a geospacial database?

you're probably right, but it would nonetheless be the "/child of a lesser God/" compared to a "deli" in New York, USA... On 2018-12-05 22:51, Dave F wrote: > Going off topic, but you /can/ tag it as "shop=salumeria", it will still be > searchable & will be displayed on the standard map with

Re: [Tagging] Can OSM become a geospacial database?

ch is often considered part of the name.  > > Eg, alt_name:ru=, loc_name=, official_name= etc, as appropriate based on > local usage. > > -Joseph > > On Thu, Dec 6, 2018 at 9:47 AM Sergio Manzi <mailto:s...@smz.it>> wrote: > > I mean, in a more general way and

Re: [Tagging] Can OSM become a geospacial database?

o find a place where to buy food, and "/an Italian in Rome/" trying to find a proper salumeria... On 2018-12-06 15:51, Kevin Kenny wrote: > On Thu, Dec 6, 2018 at 9:31 AM Sergio Manzi <mailto:s...@smz.it>> wrote: > > That's what I'm often hearing, and not only

Re: [Tagging] Can OSM become a geospacial database?

That's (/quite obviously I would say.../) not a solution: all it does is to move the problem from one place to another: how would you make up the name for one of yoursпруд or копанка in English? On 2018-12-06 12:51, Eugene Podshivalov wrote: > Another solution is to always put category name

Re: [Tagging] Salumeria(it) / charcuterie(fr) / Wurstwaren (de) WAS Re: Can OSM become a geospacial database?

I understand this is not a discussion between you and me, but as you cited me, I felt obliged to explain you why I'm not (/much/) interested in the specific, just as an act of courtesy toward you (/but //apperently you misunderstood.../) take care, Sergio On 2018-12-06 14:02, Martin

Re: [Tagging] Can OSM become a geospacial database?

e mentioned it because it is currently used in every > country for highway=residential ways. > > чт, 6 дек. 2018 г. в 15:08, Sergio Manzi <mailto:s...@smz.it>>: > > That's (/quite obviously I would say.../) not a solution: all it > does is to move the

Re: [Tagging] Salumeria(it) / charcuterie(fr) / Wurstwaren (de) WAS Re: Can OSM become a geospacial database?

willng to dilute their history with the history of different similar places. On 2018-12-06 09:44, Martin Koppenhoefer wrote: > > > sent from a phone > > On 5. Dec 2018, at 22:08, Sergio Manzi mailto:s...@smz.it>> > wrote: > >> P.S.: ... but if I want my /salumeria

Re: [Tagging] Salumeria(it) / charcuterie(fr) / Wurstwaren (de) WAS Re: Can OSM become a geospacial database?

OK, sorry, a lot of typos... it's all salumeria (singular) and salumerie (plural)! On 2018-12-06 13:39, Sergio Manzi wrote: > > Martin, > > I see you have "/spawned/" my comment from another thread into this thread. > > I take for granted your good willingness in do

Re: [Tagging] emergency=control_centre

bulance, I don't hink you could consider that an... amenity. Cheers! On 2018-12-09 17:06, dktue wrote: > You're right! But amenity=ambulance_station could be used. The point I tried > to make was: Why are we using the emergency-key in that case at all. > > Am 09.12.2018 um 17:0

Re: [Tagging] emergency=control_centre

Maybe because not all (/probably few.../) ambulance stations occupy an entire building? On 2018-12-09 16:58, dktue wrote: > But why are we using emergency=ambulance_station and not > building=ambulance_station? smime.p7s Description: S/MIME Cryptographic Signature

Re: [Tagging] leisure=hammock_hook

Mon, Dec 10, 2018 at 2:44 AM Sergio Manzi wrote: >> Wow! Either those things are high enough that a would be suicide could make >> good use of them, or sooner or later a kid will loose an eye on one of those >> hooks... :-/ >> > So we should stop mapping railways

Re: [Tagging] emergency=control_centre

Sorry, but I don't think so: office=control_centre could be the control center for whatever infrastructure (/unless some more specific tag exists in some specific namespace/). *If* (/and it is a big if of which I'd like to say something later/) we want to tag the places where emergency phone

Re: [Tagging] leisure=hammock_hook

Wow! Either those things are high enough that a would be suicide could make good use of them, or sooner or later a kid will loose an eye on one of those hooks...  :-/ My advice? Don't map those: you could be held liable... On 2018-12-10 00:29, Sérgio V. wrote: > Hi, I've found a playground

Re: [Tagging] leisure=hammock_hook

Got it, thanks! Those ropes did look strange, didn't they? :-) Sergio On 2018-12-10 04:25, Michael Patrick wrote: > > ... beside, are you sure those hooks are for hammocks? How can you hang 3 > hammocks radially from the center point? There doesn't seems to be enough > "angle" between

Re: [Tagging] emergency=control_centre

I totally agree on that and, with my limits, I too try doing the same... Cheers! Sergio On 2018-12-10 00:32, Warin wrote: > On 10/12/18 10:17, Sergio Manzi wrote: >> >> I know that there are ones who think that every little detail of the world >> should be tagged, but

Re: [Tagging] antenna use key to replace some of the antenna type

Hello Warin, On 2018-11-29 07:27, Warin wrote: >> >> * amateur_radio: antenna systems used by *licensed *radio amateurs >> > > A mapper will not be able to tell if they are licensed. So I would not > stipulate it. And this is tagging the use, not who uses it (operator=licensed > radio

Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

se pay by phone. But the wiki > only suggests payment=* keys for vending=parking_tickets, not for > amenity=parking. > > > Sergio Manzi schrieb am 21:15 Mittwoch, 28.November 2018: > > > Sorry, but it should be: > > payment:s

Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

Hi Martin! On 2018-11-29 17:11, Martin Koppenhoefer wrote: > payment:sms:WhateverPayApp:contact= > > > Does not look very sustainable, are we going to mass retag all of these if > the number changes? I agree it might be useful to have this information, but > it shouldn’t need to be tagged on

Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

On 2018-11-29 17:17, Martin Koppenhoefer wrote: > maybe just “ref”, unless it is different? We are using ref for example for > bus stops where you can use this code to dynamically query an api for bus > arrival times. As long as it is just one reference number, there’s no need to > declare 5

Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

.. Sergio On 2018-11-29 17:20, Sergio Manzi wrote: > On 2018-11-29 17:17, Martin Koppenhoefer wrote: >> maybe just “ref”, unless it is different? We are using ref for example for >> bus stops where you can use this code to dynamically query an api for bus >> arrival t

Re: [Tagging] Can OSM become a geospacial database?

That's what I'm often hearing, and not only from you, but have a look at wiki page about the /craft /key [1 ], as in there I can read: "/You are *free *to use *values *that match your needs as a mapper and your local or country environment,

Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

Hello Yves, maybe you're missing that according to the proposal we will have a first feature tagged as *both */highway=*/ *and */railway=separately_mapped/, *plus *a second overlapping/parallel feature tagged as/railway=*/ Utterly confusing, IMHO: the embedded rail is an attribute of the

Re: [Tagging] antenna type

Hello Warin, I'm afraid we're opening a can of worms here, but you're right: something needs to be fixed, and here below I'm trying to contribute with some considerations... The Wiki [1 ] gives a very good definition of what an

Re: [Tagging] antenna type

lecom=* and BTS will often get > man_made=street_cabinet > > Recently reviewed Telecom=service_device is suitable for "BTS" cabinets with > telecom:medium=radio and aditional tags for 3GPP technology 2G/3G or LTE. > > Several antennas can be fed by a single radio cabinet  > >

Re: [Tagging] antenna type

I like it! To me it makes much more sense to tag telecom=BTS (Base Transceiver Station, see [1 ]) than man_made:antenna + antenna:type=whatever. But BTS is not indicated as possible value for telecom=* in the wiki... Cheers, Sergio [1]

Re: [Tagging] antenna type

Right, forgot about that!   :-) On 2018-11-24 20:26, Colin Smale wrote: > And possibly microwave backhaul equipment smime.p7s Description: S/MIME Cryptographic Signature ___ Tagging mailing list Tagging@openstreetmap.org

Re: [Tagging] Feature Proposal - RFC - landuse=governmental

Correct: it very much depends and vary from state to state: Italy's central bank, Bank of Italy, is not a goverenmental institution (/it has shareholders.../), and the same is true (/afaik, but haven't checked/) for the US Federal Reserve Bank... On 2018-11-21 00:16, Martin Koppenhoefer

Re: [Tagging] Feature Proposal - Voting - (Tramtrack_on_highway)

I like this very much! Maybe I'd love it even better if it would be: "surface:embedded rails=tram|railway" Cheers, Sergio On 2018-11-20 22:02, Rainer wrote: > ... > As the rails in the highway are a feature that describes the shape of the > highway similar to surface=*, I would rather use a

Re: [Tagging] Add some tag to identify disputed borders

To me "agreed" seems better than "confirmed" (/and other possibilities could be "recognized" or "accepted"/) , but... do we really need to find an adjective qualifying such borders? I guess they represent the vast majority of boundaries, so we could just leave them alone and just qualify

Re: [Tagging] Suggestion: ref:mobile_payment for amenity=parking

t;ref:" could be go, IMHO... Cheers, Sergio Manzi On 2018-11-28 21:07, bkil wrote: > payment:sms=yes > payment:WhateverPayApp=yes > contact:sms= > ref:payment= > > As an alternative, ref:sms=* would also work for me, though I think > it's redundant if the code is t

Re: [Tagging] emergency=control_centre

Me too!  :-) But, as others have already pointed out, I'm really unsure if this kind of information is relevant/appropriate here... On 2018-12-09 17:29, Markus wrote: > On Sun, 9 Dec 2018 at 17:22, dktue wrote: >> I've been convinced that the office-key is a suitable place to put the tag. >

Re: [Tagging] Neighborhood Gateway Signs?

Doh... every day harder... :-) I'd say information=board + board_type=welcome_sign look at it here: https://wiki.openstreetmap.org/wiki/Key:board_type Cheers! On 2018-11-30 23:10, Graeme Fitzpatrick wrote: > OK, so man_made=gantry, or in some cases =archway, works for "things" > crossing

Re: [Tagging] Feature Proposal - Voting - (office=diplomatic)

Great job, Allan! One more small quirk, thus: in https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dembassy the deprecation banner says that the reason for the deprecation is documented in https://wiki.openstreetmap.org/wiki/Deprecated_features but I don't see anything about amenity=embassy in

Re: [Tagging] Walking route on a beach

Why don't you use trail_visibility=no on the sections of path which are invisible as they are just plain beach? Routing will not be affected (/it will work.../). See: https://wiki.openstreetmap.org/wiki/Key:trail_visibility Cheers, Sergio smime.p7s Description: S/MIME Cryptographic

Re: [Tagging] Benefits of namespaces

Visible now! :-) On 2018-12-19 03:30, Sergio Manzi wrote: > > Thank-you Claudius, > > I've posted an answer in the forum, but I'm afraid it is awaiting for > moderation (I'm new to the forum...). > > Cheers, > > Sergio > > > On 2018-12-18 22:20, Claudius Henr

Re: [Tagging] Benefits of namespaces

François, The discussion about this has also been brought to the forum, here: https://forum.openstreetmap.org/viewtopic.php?id=64825 I'm unsure if it is better to continue it here in the ML, there in the forum, or in both places... On 2018-12-20 01:04, François Lacombe wrote: > > Le mer. 19

Re: [Tagging] weight limit in short tons

On 2019-01-27 00:42, Paul Allen wrote: > On Sat, 26 Jan 2019 at 23:28, Warin <61sundow...@gmail.com > > wrote: > > The only problem is the 'ton'. > > I n the USA 2,000 pounds > In the UK 2,240 pounds. > > Resolving this? units 'ton us' and 'ton uk'

Re: [Tagging] weight limit in short tons

On 2019-01-27 01:32, Paul Allen wrote: > I have no idea what a "cental ton" is.  Should I drink more covfefe? > Aahahhahahh! :-) Nice, and I had quite a similar reaction when I first heard about it (by an English gentleman): /"cental" /from the Latin "centum" (one hundred), because the US short

Re: [Tagging] weight limit in short tons

... but now I have a doubt... I don't find any referenece... have I been pranked? :-/ On 2019-01-27 01:45, Sergio Manzi wrote: > On 2019-01-27 01:32, Paul Allen wrote: >> I have no idea what a "cental ton" is.  Should I drink more covfefe? >> > Aahahhahahh! :-) Nic

Re: [Tagging] weight limit in short tons

On 2019-01-27 17:53, OSMDoudou wrote: > Indeed, it's very strange to require mappers do the maths when there is a > notation to indicate the unit and let the renderers do the maths. Hi! Why do you talk about math? Do you expect renderers to automatically convert weights from whatever unit

Re: [Tagging] crossing=cycleway as a node

If I understand it correctly, you have 2 higways (both with cycleway=lane) that connect at a node further away, but cycles should cross at that point, before the point where motor traffic merge into one way. In that point I'd probably draw a cycleway (no motor traffic, no pedestrian) between

Re: [Tagging] crossing=cycleway as a node

Actualy the "left side" highway continues to have cycle traffic throughout, so the "triangle" will be: * 1 side for motor vehicles * 1 side for cycles * 1 side for mixed traffic Sergio On 2019-01-27 23:59, Sergio Manzi wrote: > > If I understand it correctly

Re: [Tagging] transaction parameters for ATMs

I agree. In Italy too there are so many different limits depending on "who you are" (/how fat your account is.../), in which bank you have your account and from which bank's ATM you are whitdrawning, per-account daily/monthly limits, etc. And I really can't imagine _how one could know_ the

Re: [Tagging] Clarification unclassified vs residential

+1 here too, and a little bit of the same concerns expressed by Andy (https://xkcd.com/927/) BTW, in the Italian mailing list there is currently a thread discussing if and how we should tag highways according to what are the official categories in the Italian Traffic Code (/Codice della

Re: [Tagging] Clarification unclassified vs residential

... and not only cycleways: have a look here, where I live: https://www.openstreetmap.org/#map=15/45.4364/12.3334 All are "highway=pedestrian", at the same level, but believe me: they are not! Sergio On 2019-02-26 14:30, Paul Johnson wrote: > Honestly couldn't hurt the cycleways to have a

Re: [Tagging] Clarification unclassified vs residential

On 2019-02-26 14:13, Andy Townsend wrote: > On 26/02/2019 09:58, Dave Swarthout wrote: >> Whoa, >> >> What happened to the original topic of this thread? We were trying to come >> up with a system of determining whether a highway is classified or >> residential. Now we're talking about traffic

Re: [Tagging] amenity=police

On 2019-03-02 00:09, Graeme Fitzpatrick wrote: > However, In Australia (& I know there are other countries the same) the Coast > Guard is a strictly civilian, volunteer marine rescue group only, with no > military, or police, connections at all (apart from working together with > Water Police

Re: [Tagging] Clarification unclassified vs residential

On 2019-03-02 01:35, Paul Allen wrote: > On Sat, 2 Mar 2019 at 00:22, Sergio Manzi mailto:s...@smz.it>> > wrote: > > On 2019-03-02 00:59, Graeme Fitzpatrick wrote: >> Being picky, but (at least out here) they're not exempt, they're just >> allowed to bre

  1   2   >