Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Sergio Manzi]

On 2019-03-14 23:57, Martin Koppenhoefer wrote:
> There are indications that at least 2 other secret groups operating in osm 
> are suspicious about the plans for a new group and are planning to covf

Another tasteless and vile joke. Not that I was expecting anything better from 
you, Martin: tastless jokes are a clear sign of a lower IQ and a troubled 
personality by someone with the delusion of being superior to others.

Anyway, I see this as the last straw and I have decided to unsubscribe from the 
mailing list and leave the community: too much noise and bitching and I have 
more important things to do in my life.

I suppose you can congratulate yourself, Martin: you achieved what quite 
evidently was your goal, since day one.

Goodbye everybody.

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Expand the key:opening_hours

[Sergio Manzi]

On 2019-03-14 01:28, Warin wrote:
> Think best to separate it from the present opening hours.
>
> Perhaps   opening_hours:persian=* (example - where the Persian calendar is in 
> use).???

Good idea!

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Sergio Manzi]

On 2019-03-14 00:26, Graeme Fitzpatrick wrote:
>
> On Thu, 14 Mar 2019 at 08:06, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
>
> I was advicing somebody something completely different as of lately: to 
> form a hidden, underground, group of motivated persons to draft proposals 
> that are already agreed upon by at least "some" before going public with the 
> proposal...
>
> Your opinion?
>
>
> Did see that, & thought Hmmm?
>
> The problem I can see, & yes, of course there'll be ways around it, is how do 
> you pick their conspirators collaborators team?
>
> Do you stick up a post saying I'm thinking about a new way of mapping 
> disputed boundaries, anybody interested please contact me privately, or do 
> you send private messages to me, Joseph, Kevin, Dave etc etc to say the same 
> thing?

Honestly there is no conspiratory intent in what I'm talking about.

How would I pick them? Say that I want to make a proposal about how to tag 
"cauliflower fields": I'll try to get in touch via email with others that have 
already expressed their interest in something similar (/e.g. artichokes 
fields/) and ask if they are interested in working with me on my new fantastic 
idea of tagging "cauliflower fields" and/or if they know anybody else that they 
think could be interested.


> Then how do you work together? I don't think we've got any secret pages that 
> are locked against outsider access?

No need for that. You can use good-old email, WhatsApp, Telegram, Signal, 
Slack, IRC, ... whatever.

There is no need for that interaction to go through channels directly handled 
by OSM


> Also, when do you decide that we're going to need a secret meeting to plot 
> this out - some things that seem complicated will turn out to be "change 
> always to usually & it's good to go" & vice versa.

Ooops... sorry... I'm afraid I don't understand the meaning of the above. Can 
you please repharase?


> Please don't get me wrong - it's an interesting idea & may well prove to be a 
> good way to go!
>
> Thanks
>
> Graeme

Cheers!

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Sergio Manzi]

On 2019-03-14 00:03, Joseph Eisenberg wrote:
> > “form a hidden, underground, group of motivated persons to draft proposals”
>
> 臘‍♂️
>
> I might support this if all men, Europeans, and people of European ancestry 
> were excluded from this cabal of illuminati. 
>
> [guilty as charged ☺️]


All the silly funny faces do not makes any less *_vile_* your attempt to put in 
my words meanings that were not expressed nor implied.

I never talked about /illuminati /or a conspiring elite: I was talking about 
people working in team, in a friendly way, to collectively bring out ideas.

IMHO ideas that comes out from a group debate have far more odds to be accepted 
by the community: that's all.


> Seriously though, it’s much more helpful if authors of proposals get as much 
> advice as possible before going to a vote. 
>
> But y’all could try to be nicer and more constructive in comments on new tags.
>
> Not everyone shares the north-western European value of frank / blunt / 
> direct criticism.

I understand that, as I understand how other cultures have different way to 
express their feelings, but I hope people of different cultures, here, have the 
intelligence to understand where I come from and what my real intents are.

Apparently I'm an optimist.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] Tagging disputed boundaries

[Sergio Manzi]

On 2019-03-13 22:57, Graeme Fitzpatrick wrote:
> It would just be good if there was only  place that these discussions on new 
> proposals took place.

I was advicing somebody something completely different as of lately: to form a 
hidden, underground, group of motivated persons to draft proposals that are 
already agreed upon by at least "some" before going public with the proposal...

Your opinion?

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 21:30, Sergio Manzi wrote:
> I also think that, as you correctly pointed out, both me and *Peter*, (/I 
> guess.../) forgot about "armchair mapping" which is neither "import" nor 
> "locally sourced" and probably represent a huge amount of data in OSM.


My bad! Please read:

I also think that, as you correctly pointed out, both me and *Tom*, (/I 
guess.../) forgot about "armchair mapping" which is neither "import" nor 
"locally sourced" and probably represent a huge amount of data in OSM.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 19:04, Volker Schmidt wrote:
> On Wed, 13 Mar 2019 at 15:45, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
> Have mappers walked along the whole world coastlines? Have they descended 
> all world's rivers by canoe?
>
> No, these are examples where imports make sense as these are feature that 
> change slowly (normally) 
>
> Have all Mumbay, New York, Rome, Shanghai, etc., streets and alleys been 
> walked by volunteers mapping their location and names?
>
> No, but many have been photographed and the photographs are available with 
> open license (Mapillary and OpenStreetCam) and many raods have been recorded 
> with GPX tracks. This allows armchair mapping with high quality results, 
> where the mapper does not need to be the photographer.
> New York on OpenStreetCam 
> <https://openstreetcam.org/map/@40.73919689890453,-73.96898232070473,13z>, 
> Amsterdam on Mapillary 
> <https://www.mapillary.com/app/?focus=map=52.37459220767326=4.89873550043=11.451877849993338>
>
> All the peaks escalated?
>
> Again classical data that change slowly, where imports are justified.
>
> But when you start importing trees or buildings or hotels or petrol stations 
> or shops or crops than you are importing  perishable data which are 
> maintained outside OSM, and hence need frequent updates, with the obvious 
> cost that they need to be updated in the external source database and in the 
> OSM database in synchronism.
>
> Volker


Fair enough, Volker, I agree on all your points. But let's recap, if you don't 
mind.

My objection was to Tom Pfeifer assertion "/I think you misunderstand. OSM is 
*based **on locally sourced, handcrafted data*. That creates the high quality./"

To me "/based on/" means the bulk of data which constitues OSM foundation.

I also have to admit that as far as concern myself, I'm very much more 
interested in what you call "/data that changes slowly/" and I see that as the 
OSM foundation:

  * natural terrain with all its features like hills, mountains, rivers and 
lakes, forests and land cover in general
  * man made features like highways, canals, buildings, bridges, etc.
  * persistent and generally useful information like street numbers

The above, slowly changing information, is what I think represent OSM "base" 
information, and I don't believe the bulk of the above is "locally sourced, 
handcrafted data", but I'm ready to change my mind if proved wrong.

I also think that, as you correctly pointed out, both me and Peter, (/I 
guess.../) forgot about "armchair mapping" which is neither "import" nor 
"locally sourced" and probably represent a huge amount of data in OSM.



As far as regards Giovanni's import, my position is that I'm pretty sure that 
the work he has done is of high quality, probably much better than many 
"locally sourced" information (/you probably have an idea of the quantity of 
"locally sourced" crap I see here in Venice, mainly self-defined hotels and  
B which are... nothing... just the address of people renting their 
rooms/apartment/ and stick a name on it).

Personally I would be much happier if OSM would limit itself to its "base 
layer" and let other data aggregators handle different kind of information: if 
I want an Hotel or a room I can go to Tripadvisor or to Airbnb (/not endorsing 
those //_in any way_//, just an example.../), see if it accepts my pet and my 
credit card and then use OSM to navigate to the address.

Unhappily things are not like this and we are mapping hotels. In this regard I 
strongly tend to trust Giovanni import much more than the "locally sourced" 
data.

Cheers,

Sergio






smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 20:22, Martin Koppenhoefer wrote:
>
> On 13. Mar 2019, at 16:34, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
>> ... an example of massively imported data (/which I agree with, btw.../): 
>> https://blogs.bing.com/maps/2018-06/microsoft-releases-125-million-building-footprints-in-the-us-as-open-data
>
>
> This data wasn’t generally imported AFAIK (I believe a small part of it was 
> imported). Here’s the wiki page: 
> https://wiki.openstreetmap.org/wiki/Microsoft_Building_Footprint_Data
>
> here an import:
> https://wiki.openstreetmap.org/wiki/Microsoft_Building_Import_-_North_Central_Texas
>
>
> Cheers, Martin


Yes, right: it wasn't "/massively imported data/" but "/a massive amount of 
data which is being imported/".

Thanks for pointing out.

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 15:44, Sergio Manzi wrote:
> On 2019-03-13 15:27, Mateusz Konieczny wrote:
>>
>>
>>
>> Mar 13, 2019, 12:53 PM by s...@smz.it:
>>
>> On 2019-03-13 12:15, Tom Pfeifer wrote:
>>> I think you misunderstand. OSM is based on locally sourced, handcrafted 
>>> data. That creates the high quality.
>>
>> That's totally inaccurate.
>>
>> The reality is that OSM is based on imported data, augmented by locally 
>> sourced information (/of ///sometimes /questionable quality/).
>>
>> Sergio
>>
>> [citation needed]
>>
>> It may be true in some rare regions, in many cases real mapping requires 
>> deletion of substandard
>> imports dumped into OSM (see TIGER mess in USA, low quality landcover in 
>> Slovakia making
>> mapping a horrible experience).
>>
>> Describing OSM as "imported data, augmented by" is as far as I known 
>> complete misrepresenting the
>> situation.
>
> I haven't said that OSM *is* imported data, but that it is *based on* 
> imported data: that's different. And I never said that the "augmentation" 
> contributed by mappers is of irrelevant importance (/even if sometime the 
> quality is sub-par/).
>
> Have mappers walked along the whole world coastlines? Have they descended all 
> world's rivers by canoe? Have all Mumbay, New York, Rome, Shanghai, etc., 
> streets and alleys been walked by volunteers mapping their location and 
> names? All the peaks escalated?
>
> Sergio
>
... an example of massively imported data (/which I agree with, btw.../): 
https://blogs.bing.com/maps/2018-06/microsoft-releases-125-million-building-footprints-in-the-us-as-open-data



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 15:27, Mateusz Konieczny wrote:
>
>
>
> Mar 13, 2019, 12:53 PM by s...@smz.it:
>
> On 2019-03-13 12:15, Tom Pfeifer wrote:
>> I think you misunderstand. OSM is based on locally sourced, handcrafted 
>> data. That creates the high quality.
>
> That's totally inaccurate.
>
> The reality is that OSM is based on imported data, augmented by locally 
> sourced information (/of ///sometimes /questionable quality/).
>
> Sergio
>
> [citation needed]
>
> It may be true in some rare regions, in many cases real mapping requires 
> deletion of substandard
> imports dumped into OSM (see TIGER mess in USA, low quality landcover in 
> Slovakia making
> mapping a horrible experience).
>
> Describing OSM as "imported data, augmented by" is as far as I known complete 
> misrepresenting the
> situation.

I haven't said that OSM *is* imported data, but that it is *based on* imported 
data: that's different. And I never said that the "augmentation" contributed by 
mappers is of irrelevant importance (/even if sometime the quality is sub-par/).

Have mappers walked along the whole world coastlines? Have they descended all 
world's rivers by canoe? Have all Mumbay, New York, Rome, Shanghai, etc., 
streets and alleys been walked by volunteers mapping their location and names? 
All the peaks escalated?

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 14:45, Martin Koppenhoefer wrote:
>
> Am Mi., 13. März 2019 um 12:54 Uhr schrieb Sergio Manzi  <mailto:s...@smz.it>>:
>
> On 2019-03-13 12:15, Tom Pfeifer wrote:
>> I think you misunderstand. OSM is based on locally sourced, handcrafted 
>> data. That creates the high quality.
>
> That's totally inaccurate.
>
> The reality is that OSM is based on imported data, augmented by locally 
> sourced information (/of ///sometimes /questionable quality/).
>
>
>
> There are examples for this like the US, Friuli Venezia Giulia (buildings), 
> maybe France (landcover + cadastre) and the Netherlands, but this is still 
> not globally the case, and I would hope it will not get to this point. You 
> are relatively new here Sergio and may not know the history of OSM, also in 
> Italy where you map, most data was mapped by mappers. Notable Italian 
> exceptions may be Friuli Venezia Giulia, administrative boundaries by ISTAT, 
> fuel station import last year, some locally confined imports in some 
> municipalities.
>
> Cheers,
> Martin
>
Was this https://www.openstreetmap.org/node/288179924 mapped by Reinhold 
Messner carrying an high accuracy GPS in is backback? As I think he is one of 
the very few who put foot there...

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Sergio Manzi]

If a "/superroute/" has an official status (/like this one: 
https://www.openstreetmap.org/relation/20773/), I'm all-in for that.

If instead it is something "/invented/" by the mapper, than I'm all-against it.

Can you please provide more information/examples/context?

Sergio


On 2019-03-13 14:18, Paul Allen wrote:
> I've hesitated to ask this question for months now: what's the
> consensus on superroutes?  Going by all I can find on the wiki,
> forums and past discussions, they're highly controversial.  One wiki
> page mentions them and says don't use them.  They were either
> never well documented on the wiki or some documentation has
> been scrubbed.  What I don't know is whether the intense dislike
> some people expressed when they were first proposed has faded
> or if they're still largely considered to be a very bad idea.
>
> One justification for them is that they simplify the mapping of
> trans-national routes or very long routes: individual sections can
> be mapped separately and then assembled into a coherent whole
> as a superroute.
>
> Another justification is that very long ways (the figure I've seen is
> 300 nodes) can be problematic and they should be split into
> a superroute of individual routes.
>
> An argument against them is that some routers may not be able
> to handle them.  Which would obviously have been true when they
> were first proposed and may still be true now.  Which is a problem
> with just about everything proposed here: we propose something
> new, it's argued against because editors/renderers/routers don't
> handle it, but the reason editors/renderers/routers don't handle it
> is because nobody uses it.
>
> The reason I ask is that I can see an application for them that is
> not explicitly mentioned in the documentation but might allow me
> to deal with an otherwise intractable problem.  If there is universal
> disdain here I'll have to abandon that idea.  But if there are enough
> people who are happy with them then I have some questions...
>
> Please don't let this degenerate into a flame war.  That can come when
> (if) I explain what I want to do with a superroute - even the people who
> support superroutes (if there are any) may be unhappy with that idea.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Hotel dataset import? / Re: Baby-sitting

[Sergio Manzi]

On 2019-03-13 12:15, Tom Pfeifer wrote:
> I think you misunderstand. OSM is based on locally sourced, handcrafted data. 
> That creates the high quality.

That's totally inaccurate.

The reality is that OSM is based on imported data, augmented by locally sourced 
information (/of ///sometimes /questionable quality/).

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC - Line attachments

[Sergio Manzi]

Hello François,

So, your updated picture made it clear that it is the "insulator set" what 
should be mapped with your newly proposed tag. I suppose  that for power lines 
the same would be true in case the "line attachment" would be through a "pin 
insulator" or a "shackle insulator" or every other form of insulator.

So, when one is supposed to use the "power=insulator" tag instead?

The wiki for that tag (/which *you* wrote/) is describing insulators as "/Power 
insulator linking a power line to a support/" and also "/It's a power insulator 
linking an overhead line to another (grounded) infrastructure/".

In the examples there is also a picture of a concrete portal with the caption 
stating: "/Support : Insulators are used to *anchor *the power line on a 
concrete portal/".

*So we should tag the same node as both a "power=insulator" and 
"line_attachment=suspension", or should we map a distinct node for the 
"line_attachment"?*

I would barely understand if you only had *two values* for line_attachment *as 
properties of the "insulator" key*: suspension and anchor, distinguishing if 
the vector of forces on an insulator add-up to an essentially vertical vector 
because the "traction" forces of two catenaries compensate each other and you 
just have a vertical component of force at the binding post (/suspension/), or 
you don't have the compensation of the two catenaries (the line is attached to 
a fixed post or the two catenaries are not compensated) and you also have an 
horizontal component of force that the binding post must sustain (/anchor/). 
Not much useful to know, IMHO,  but hey, who am I to judge that?

But that's not the case, unhappily! In your proposal you also describe 
"/shackle insulators/" and "/pin insulators/" as "line attachments". For me 
they should have been documented in the "insulator" key as types of insulators 
(/yes, Warin, I know you dislike "type" and it goes under your skin.../).

*A**s I wrote you in our personal mail exchange I have the feeling that you are 
trying to map "concepts", not "things", through generalization: the Platonic 
idea of a line attachment in this case.*

You're doing the same in your current proposal about "substations" 
(/https://wiki.openstreetmap.org/wiki/Proposed_features/Substation_functions/), 
where you want to generalize the concept of "substation" and apply it to both 
the domain of power distribution (power) and fluid distributions (pipeline).

That's profoundly wrong in my opinion and I strongly feel that this should 
stop: we are not here "to put order in the universe" and categorize a and "name 
things" (/I'm an atheist, so I'm not much informed about this things, but I 
seems to remember that the Bible talks about that.../), we are here to map 
useful information about things.

And the above, of course, is in addition to my basic objection about mapping 
things that I think are more fit to AutoCAD or CATIA than OSM...

Cheers,

Sergio


On 2019-03-11 23:35, François Lacombe wrote:
> Hi Sergio,
>
> The proposal aims to map the way lines are bound to their supports.
> In my mind, attachement = {Insulator set ; clamps ; accessories to secure the 
> insulators on crossarms} for a bare power conductor.
> Further keys can give details about each item in this set (but out of the 
> current proposal).
> For insulated cables you don't have insulators but the attachment methods are 
> the same.
>
> Here are illustrations :
> https://wiki.openstreetmap.org/wiki/File:Elbekreuzung_2_traversen_crop_suspension.jpg
> https://wiki.openstreetmap.org/wiki/File:Power_cable_suspension_attachment.png
>
> Keep in mind that currently, it is possible to give the same information with 
> tower:type=suspension.
> As explained in the rationale, :type suffix is meaningless and gather too 
> much possibilities to be usable.
>
> Hope it's clearer
>
> François
>
> Le dim. 10 mars 2019 à 23:04, Sergio Manzi mailto:s...@smz.it>> 
> a écrit :
>
> François,
>
> Thank-you for addressing the mistakes I outlined (/some still needs some 
> polishing I gues/s), but anyway (/and putting aside my reluctance to map such 
> things/) I'm afraid there is still something profoundly wrong with this 
> proposal, at its very essence.
>
> I still don't understand what are *the objects* that one is expected to 
> map with this tag.
>
> Taking as an example the first tower you depict for 
> "line_attachment=suspension" 
> (https://upload.wikimedia.org/wikipedia/commons/5/50/Elbekreuzung_2_traversen_crop.jpg)
>  what are they? The tower (/BTW, shouldn't it be pylon in Brit. Eng. ?/) The 
>

Re: [Tagging] Mapping deforestation

[Sergio Manzi]

Thanks for the numbers, for explaining and for the link, Christoph. Apreciated!

Sergio


On 2019-03-12 00:19, Christoph Hormann wrote:
> On Monday 11 March 2019, Peter Elderson wrote:
>> Sorry, 2000.
> IIRC the saying is "two wrongs does not make a right".
>
> Original use of tags with the landcover key, that is mappers creating a 
> new geometry with a landcover tag, is as follows (based on data from 
> 2019-02-28):
>
> 72848 ways/relations (more of half of these created in organized mapping 
> with tagging not being the free choice of the mapper)
> 1310 different users
> 494 of which have used the key exactly once (this, i.e. that about 1/3 
> to half of the genuine active users of a tag have only used it once is 
> pretty standard but still this has to be kept in mind when 
> contemplating such numbers)
>
> The reason why taginfo reports only the number of users who have last 
> touched features with this key is not because this is particularly 
> meaningful information but because this can be counted quite easily 
> when processing a planet file (which is what taginfo does on a daily 
> basis) while numbers on active users (i.e. who maps features with a tag 
> or who adds a tag to features) can only be determined from the history.
>
> I can highly recommend Frederik's talk on the matter of OSM statistics 
> which discusses this in detail:
>
> https://www.youtube.com/watch?v=Kx0KuvkbvfQ
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation

[Sergio Manzi]

On 2019-03-12 00:00, Mateusz Konieczny wrote:
> Mar 11, 2019, 11:38 PM by s...@smz.it:
>
> On 2019-03-11 18:47, Mateusz Konieczny wrote:
>> Mar 11, 2019, 6:44 PM by s...@smz.it :
>>
>> On 2019-03-11 18:17, Mateusz Konieczny wrote:
>>> Mar 11, 2019, 4:32 PM by pelder...@gmail.com 
>>> :
>>>
>>> you can use landcover, it has about 160K uses now by 6000 users
>>>
>>> 6000 users? How you know that?
>>
>> https://taginfo.openstreetmap.org/keys/landcover says:
>>
>> "Objects with this key were last edited by 2 025 different users."
>>
>> Cheers,
>>
>> Sergio
>>
>> What answers completely different question (it is possible that
>> tag was added by 200 users and then other people edited objects
>> with it).
>
> ... and that doesn't change things very much: it means that even if only 
> 200 (or 20) users have originally added those tags, 2025 users who have last 
> edited those objects have somehow agreed with the tag being there, which I 
> think is the important thing and probably that's why Taginfo exposes that 
> statistic.
>
> "2000 users" and "2000 people not disliking it enough to remove all noticed 
> instances"
> is a bit different.

Right



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation

[Sergio Manzi]

On 2019-03-11 18:47, Mateusz Konieczny wrote:
> Mar 11, 2019, 6:44 PM by s...@smz.it:
>
> On 2019-03-11 18:17, Mateusz Konieczny wrote:
>> Mar 11, 2019, 4:32 PM by pelder...@gmail.com 
>> :
>>
>> you can use landcover, it has about 160K uses now by 6000 users
>>
>> 6000 users? How you know that?
>
> https://taginfo.openstreetmap.org/keys/landcover says:
>
> "Objects with this key were last edited by 2 025 different users."
>
> Cheers,
>
> Sergio
>
> What answers completely different question (it is possible that
> tag was added by 200 users and then other people edited objects
> with it).

... and that doesn't change things very much: it means that even if only 200 
(or 20) users have originally added those tags, 2025 users who have last edited 
those objects have somehow agreed with the tag being there, which I think is 
the important thing and probably that's why Taginfo exposes that statistic.


> Though given that even this value is so low makes 6000
> people adding this tag even less likely.


As you have probably seen Peter has amended the number (which initially was 
little a bit "optimistic") to something very comparable.

Cheers,

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping deforestation

[Sergio Manzi]

On 2019-03-11 18:17, Mateusz Konieczny wrote:
> Mar 11, 2019, 4:32 PM by pelder...@gmail.com:
>
> you can use landcover, it has about 160K uses now by 6000 users
>
> 6000 users? How you know that?

https://taginfo.openstreetmap.org/keys/landcover says:

"Objects with this key were last edited by 2 025 different users."

Cheers,

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Sergio Manzi]

On 2019-03-11 03:44, Warin wrote:
> On 11/03/19 10:39, Sergio Manzi wrote:
>> On 2019-03-11 00:33, Sergio Manzi wrote:
>>> On 2019-03-11 00:30, Jan S wrote:
>>>> How about police=detention as a more generic term then?
>>> Nice!
>>>
>>> Sergio
>>
>> And this makes me think that maybe we could find something better for our 
>> ~10.000 "amenity=prison" (/go tell them inside that their hopefully 
>> temporary home is an "amenity", and see the reaction.../)
>>
>
> :))
>
> More of a landuse=prison I think. 

... or maybe landuse=detention_facility




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Sergio Manzi]

On 2019-03-11 04:05, Warin wrote:

> On 11/03/19 10:29, Sergio Manzi wrote:
>>
>> In Italy there are five main, state-wide, police corps:
>>
>>   * /Polizia di Stato/: a civil organization with civil jurisdiction (/with 
>> several different branches dealing with specific activities/).
>>   * /Carabinieri/: a military branch with military jurisdiction, but also 
>> civil jurisdiction.
>>   * /Polizia penitenziaria/:  a civil organization handling prisons, but 
>> with also other civil jurisdictions.
>>
> In the UK these are not police officers and their powers are only while 
> 'acting as a prison officer' i.e. in relation to prisoners.
> https://en.wikipedia.org/wiki/Her_Majesty%27s_Prison_Service#Powers_and_structure
> They are not considered 'police' by the general populace.

Not here. Automatic Google translation (/sorry, no time for good 
translation.../) from the Italian Wikipedia article 
(https://it.wikipedia.org/wiki/Corpo_di_polizia_penitenziaria):

/"//Mainly it carries out the task of managing people subjected to 
restrictions or restriction of personal freedom. It also carries out traffic 
police activities pursuant to art. 12 of the Highway Code /[but TBH I never saw 
them acting in this capacity, mainly handled by the Polizia Stradale (part of 
the Polizia di Stato) and by the Carabinieri. smz]/, participates in the 
maintenance of public order, carries out judicial police activities and public 
safety even outside the prison environment, as well as all other police forces, 
carries out escort activities for the protection of institutional personalities 
(Minister of Justice, Undersecretaries of State) and magistrates.//"/

>
>>   * /Guardia di finanza/: a military organization, but depending from the 
>> Ministry of Finance, with civil jurisdiction on financial matters.
>>
>
> What do you mean by "military organization'? (/Guardia di finanza)/
> Are they under the command of the army/navy/air force?
> Or is that the personnel structure is similar to the military (captains, 
> corporals, etc)


No, they are in a very peculiar situation: they are a militarized organzation, 
but not depending from the Ministry of Defence, but the Ministry of Finance. 
English Wikipedia aricle about them is quite good so I refer you to it: 
https://en.wikipedia.org/wiki/Guardia_di_Finanza


>
>>   * /Corpo delle capitanerie di porto - Guardia costiera/: a military 
>> organization, roughly comparable to the US Coast Guard.
>>
>
>  More like the navy?
>
> Or 'water police'?
>
> https://en.wikipedia.org/wiki/Water_police
>
> https://en.wikipedia.org/wiki/Metropolitan_Police_Marine_Policing_Unit
>

They are part of the Italian Navy (Marina Militare) but their responsiblities 
are more akin of those of the "US Coast Guard". Quite good English Wikipedia 
article for them too: 
https://en.wikipedia.org/wiki/Corps_of_the_Port_Captaincies_%E2%80%93_Coast_Guard

Cheers!

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Sergio Manzi]

On 2019-03-11 00:33, Sergio Manzi wrote:
> On 2019-03-11 00:30, Jan S wrote:
>> How about police=detention as a more generic term then?
> Nice!
>
> Sergio

And this makes me think that maybe we could find something better for our 
~10.000 "amenity=prison" (/go tell them inside that their hopefully temporary 
home is an "amenity", and see the reaction.../)

Cheers,

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Sergio Manzi]

On 2019-03-11 00:30, Jan S wrote:
> How about police=detention as a more generic term then?

Nice!

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Sergio Manzi]

On 2019-03-11 00:02, Warin wrote:
> On 11/03/19 09:52, Martin Koppenhoefer wrote:
>
>>
>> sent from a phone
>>
>>> On 10. Mar 2019, at 14:13, Paul Allen  wrote:
>>>
>>> Which of all those get mapped as police and which get mapped as military 
>>> will need to be
>>> figured out at some point.
>>
>> IMHO we should be able to map it as both (as military and as police) where 
>> it is applicable.
>>
> I think it comes down to their jurisdiction: who do they have power over?
>
> If it is the civilian population - then police
>
> If it is the military population and anyone on a military base them 
> military_police
>
> Sorry if that does not fit around the world! Please explain the local 
> situation? And then there will have to be some tagging accommodation?


In Italy there are five main, state-wide, police corps:

  * /Polizia di Stato/: a civil organization with civil jurisdiction (/with 
several different branches dealing with specific activities/).
  * /Carabinieri/: a military branch with military jurisdiction, but also civil 
jurisdiction.
  * /Polizia penitenziaria/:  a civil organization handling prisons, but with 
also other civil jurisdictions.
  * /Guardia di finanza/: a military organization, but depending from the 
Ministry of Finance, with civil jurisdiction on financial matters.
  * /Corpo delle capitanerie di porto - Guardia costiera/: a military 
organization, roughly comparable to the US Coast Guard.

Add to that several different local regional/provincial/metro polices.

Of particular interest (/for those interested in such things.../) is the 
"/Compagnia barracellare/" 
(https://it.wikipedia.org/wiki/Compagnia_barracellare), operating in Sardinia 
and that, having been founded in the 1560, represent the oldest existing 
European police force.

So, essentially all Italian police forces have civil jurisdiction with only the 
Carabinieri having military jurisdiction too. If I'm not mistaken...

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC - Line attachments

[Sergio Manzi]

BTW, what I incorrectly (/I knew it was wrong!/) named a "branch" of the tower 
is correctly named a "crossarm".

See: http://www.electropedia.org/iev/iev.nsf/display?openform=466-08-12

Cheers!

Sergio


On 2019-03-10 23:02, Sergio Manzi wrote:
>
> François,
>
> Thank-you for addressing the mistakes I outlined (/some still needs some 
> polishing I gues/s), but anyway (/and putting aside my reluctance to map such 
> things/) I'm afraid there is still something profoundly wrong with this 
> proposal, at its very essence.
>
> I still don't understand what are *the objects* that one is expected to map 
> with this tag.
>
> Taking as an example the first tower you depict for 
> "line_attachment=suspension" 
> (https://upload.wikimedia.org/wikipedia/commons/5/50/Elbekreuzung_2_traversen_crop.jpg)
>  what are they? The tower (/BTW, shouldn't it be pylon in Brit. Eng. ?/) The 
> "/branch/" (/sorry, I'm missing the correct word.../) of the tower/pylon to 
> which the insulator sets are suspended? The rings/hooks/bolts/nuts suspending 
> the insulator sets under the "branch"? The insulator sets themselves? The 
> clamps suspending the conductors under the insulator sets?
>
> Would it be too much asking you to edit the picture by adding a red arrow 
> pointing to the object of this tag?
>
> TIA,
>
> Sergio
>
>
> On 2019-03-10 17:54, François Lacombe wrote:
>> Thank you for the time took to provide your conclusions here
>>
>> Le sam. 9 mars 2019 à 19:22, Sergio Manzi mailto:s...@smz.it>> 
>> a écrit :
>>
>> *A) **Scope of the proposal.*
>>
>> It is badly defined. The "Definition" is given as "/Consistently 
>> defining how a power, telecom or even washing line is attached to supporting 
>> pole or tower/", a very broad definition, but then reading on I see that you 
>> state that "/This proposal is mainly dedicated for utilities network//s/". 
>> Which one should we take? With the "mainly" adjective are you indicating 
>> that you are willing to extend the scope of the proposal to different 
>> application fields later on?
>>
>> As a matter of fact I'm convinced that a generalization cannot be done 
>> in terms of tagging: "attaching" a power line to a fixed infrastructure is 
>> done with very different techniques from the "attaching" of a washing line, 
>> the suspension line of a cable car, the cables of a suspension bridge, the 
>> overhead line of an electric railway (/and I have the strong feeling tha 
>> "railways taggers" here have their own ideas on how to tag their contact 
>> lines/), etc., and therefore will require different tagging schemes.
>>
>> Since tagging is built by contributors here, yes all is extendable by 
>> further proposals.
>> It's hard to get a whole topic described in one shot so anyone will be able 
>> to propose more precise tagging for insulators for instance.
>>
>> Generalisation is made upon shared concepts. Whatever the line is, an 
>> anchorage is still an anchorage.
>> Additional keys can precise how the anchorage is made, and so on
>>
>> *B) **Inconsistency between the proposal name and the tag name.*
>>
>> Solved, proposed renamed accordingly.
>>  
>>
>> *C) **Are we really talking about "Clamps"?*
>>
>> The images you are attaching to the definition of "suspension_clamp" and 
>> "anchor_clamp" are misleading in the sense that one could easily take what 
>> in reality is a "Suspension insulator set" as a "Suspension clamp" and a 
>> "Tension insulator set" as an "anchor clamp".
>>
>> Right. Clamp term is removed from the proposal and values.
>> As the rationale stands to share concepts between power, telecom or any 
>> supported line, it's out of the scope to define insulators sets, chains and 
>> so on.
>> The point is to provide tags to make the distinguish between suspension, 
>> anchorage and shackles.
>>
>> The confusion is even more augmented by the fact that in your proposal 
>> you refer to "shackle insulators" too (IEC 471-03-09), and they are in a 
>> totally different area of the IEC standards, "Insulators", same as "pin 
>> insulators" (IEC 471-03-06).
>>
>> Shackle insulators are the basis to define shackles and how they differ from 
>> suspension and anchors/tensions.
>>
>> So, are we talking about clamps (fittings) or about insulators (/or 
>> insulator set

Re: [Tagging] Feature proposal - RFC - Line attachments

[Sergio Manzi]

François,

Thank-you for addressing the mistakes I outlined (/some still needs some 
polishing I gues/s), but anyway (/and putting aside my reluctance to map such 
things/) I'm afraid there is still something profoundly wrong with this 
proposal, at its very essence.

I still don't understand what are *the objects* that one is expected to map 
with this tag.

Taking as an example the first tower you depict for 
"line_attachment=suspension" 
(https://upload.wikimedia.org/wikipedia/commons/5/50/Elbekreuzung_2_traversen_crop.jpg)
 what are they? The tower (/BTW, shouldn't it be pylon in Brit. Eng. ?/) The 
"/branch/" (/sorry, I'm missing the correct word.../) of the tower/pylon to 
which the insulator sets are suspended? The rings/hooks/bolts/nuts suspending 
the insulator sets under the "branch"? The insulator sets themselves? The 
clamps suspending the conductors under the insulator sets?

Would it be too much asking you to edit the picture by adding a red arrow 
pointing to the object of this tag?

TIA,

Sergio


On 2019-03-10 17:54, François Lacombe wrote:
> Thank you for the time took to provide your conclusions here
>
> Le sam. 9 mars 2019 à 19:22, Sergio Manzi mailto:s...@smz.it>> 
> a écrit :
>
> *A) **Scope of the proposal.*
>
> It is badly defined. The "Definition" is given as "/Consistently defining 
> how a power, telecom or even washing line is attached to supporting pole or 
> tower/", a very broad definition, but then reading on I see that you state 
> that "/This proposal is mainly dedicated for utilities network//s/". Which 
> one should we take? With the "mainly" adjective are you indicating that you 
> are willing to extend the scope of the proposal to different application 
> fields later on?
>
> As a matter of fact I'm convinced that a generalization cannot be done in 
> terms of tagging: "attaching" a power line to a fixed infrastructure is done 
> with very different techniques from the "attaching" of a washing line, the 
> suspension line of a cable car, the cables of a suspension bridge, the 
> overhead line of an electric railway (/and I have the strong feeling tha 
> "railways taggers" here have their own ideas on how to tag their contact 
> lines/), etc., and therefore will require different tagging schemes.
>
> Since tagging is built by contributors here, yes all is extendable by further 
> proposals.
> It's hard to get a whole topic described in one shot so anyone will be able 
> to propose more precise tagging for insulators for instance.
>
> Generalisation is made upon shared concepts. Whatever the line is, an 
> anchorage is still an anchorage.
> Additional keys can precise how the anchorage is made, and so on
>
> *B) **Inconsistency between the proposal name and the tag name.*
>
> Solved, proposed renamed accordingly.
>  
>
> *C) **Are we really talking about "Clamps"?*
>
> The images you are attaching to the definition of "suspension_clamp" and 
> "anchor_clamp" are misleading in the sense that one could easily take what in 
> reality is a "Suspension insulator set" as a "Suspension clamp" and a 
> "Tension insulator set" as an "anchor clamp".
>
> Right. Clamp term is removed from the proposal and values.
> As the rationale stands to share concepts between power, telecom or any 
> supported line, it's out of the scope to define insulators sets, chains and 
> so on.
> The point is to provide tags to make the distinguish between suspension, 
> anchorage and shackles.
>
> The confusion is even more augmented by the fact that in your proposal 
> you refer to "shackle insulators" too (IEC 471-03-09), and they are in a 
> totally different area of the IEC standards, "Insulators", same as "pin 
> insulators" (IEC 471-03-06).
>
> Shackle insulators are the basis to define shackles and how they differ from 
> suspension and anchors/tensions.
>
> So, are we talking about clamps (fittings) or about insulators (/or 
> insulator sets/) here? Because it really seemsyou are mixing under the same 
> tag two very different kind of objects...
>
> We are dealing with attachments, which only involve insulators with bare 
> power conductors.
>
> And BTW, how could you then tag "the real clamp" with its bolts and nuts 
> when it comes to it?
>
> Keys have to be proposed for that, it's not the point of the current proposal.
>
> *D) Inaccurate wording. *Some examples:
>
>   * You state that "anchor_clamp" is "/built stronger than suspension 
> tower//s/". Really? A clamp stronger than a tower? :-/
&

Re: [Tagging] Feature Proposal - RFC - police=*

[Sergio Manzi]

Hi Andy and Jan,

no problem maintaing the currently defined terminology "prison" and "operator", 
for me: as I said it was a bit of hair splitting and as I hit the send button I 
also asked myself if maybe "jail" was an americanism (/I'm Italian, I spent 
some time in the US but very little time in the UK.../).

I think the car_repair vs. vehicle_maintenance (or is it 
vehicle*_s_*_maintenance??) issue to be a little bit more important, thus...

Cheers,

Sergio


On 2019-03-10 19:07, Andy Townsend wrote:

>
> On 10/03/2019 16:02, Sergio Manzi wrote:
>> 2) More than "prison" I think "jail" would be more adequate: AFAIK police 
>> forces do not "own" prisons (long term incarceration) but only jails (short 
>> term incarceration). It is true that in some countries a dedicated police 
>> force is in charge of prisons operation, but the "ownership" of the prison 
>> is usually "the government".
>>
> That difference might confuse  - that's an American rather than a UK 
> difference, I think.  Where "jail" (or even "gaol") is used in the UK it's 
> essentially a synonym for prison.  Ireland I think has a similar usage to the 
> UK; not sure about other English-speaking jusidictions worldwide.
>
> Best Regards,
>
> Andy
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Sergio Manzi]

One more, sorry: instead of "car_repair", why not "vehicles_maintenance"? Have 
a look here (/out of curiosity.../): 
https://www.popularmechanics.com/cars/g15895645/nypd-fleet-mechanics/

Cheers,

Sergio


On 2019-03-10 17:02, Sergio Manzi wrote:
> Jan, after a quick look at your proposal I have a couple of minor comments:
>
> 1) You're using "operator=*" to identify the particular police force to which 
> a feature is related. That's in line with what we do in several other 
> situations, but as we are talking about police, wouldn't be "corps=*" more 
> correct?
>
> 2) More than "prison" I think "jail" would be more adequate: AFAIK police 
> forces do not "own" prisons (long term incarceration) but only jails (short 
> term incarceration). It is true that in some countries a dedicated police 
> force is in charge of prisons operation, but the "ownership" of the prison is 
> usually "the government".
>
> Both of the above are "splitting an hair in two" things, so do not be too 
> much concerned about my concerns!
>
> Good job!
>
> Sergio
>
>
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - police=*

[Sergio Manzi]

Jan, after a quick look at your proposal I have a couple of minor comments:

1) You're using "operator=*" to identify the particular police force to which a 
feature is related. That's in line with what we do in several other situations, 
but as we are talking about police, wouldn't be "corps=*" more correct?

2) More than "prison" I think "jail" would be more adequate: AFAIK police 
forces do not "own" prisons (long term incarceration) but only jails (short 
term incarceration). It is true that in some countries a dedicated police force 
is in charge of prisons operation, but the "ownership" of the prison is usually 
"the government".

Both of the above are "splitting an hair in two" things, so do not be too much 
concerned about my concerns!

Good job!

Sergio





smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC - Line attachments

[Sergio Manzi]

On 2019-03-08 00:35, François Lacombe wrote:

> Hi all
>
> The line attachments proposal has been updated according to comments received 
> all along past weeks. Thanks to TOGA and Nakaner mainly.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_clamps
>
> It is not restricted to power nor telecom lines. Any line can be anchored or 
> held with suspension clamps over heads.
>
> This sounds to be ok for me and may be voted shortly.
> Feel free to raise objections or comments prior of this to help building a 
> more useful tagging.
>
> All the best
>
> François


I already expressed my dissent about using OSM for mapping/tagging this kind of 
things on the ground of both A) this not being matter for a *Geografica**l* 
Information System, and B) the technical limitation of OSM architecture for 
storing such information, I therefore will not insist on this point any more.



I've read your proposal and IMO it contains so many mistakes to make it unfit 
to be taken into consideration even as a starting point:

*
*

*A) **Scope of the proposal.*

It is badly defined. The "Definition" is given as "/Consistently defining how a 
power, telecom or even washing line is attached to supporting pole or tower/", 
a very broad definition, but then reading on I see that you state that "/This 
proposal is mainly dedicated for utilities network//s/". Which one should we 
take? With the "mainly" adjective are you indicating that you are willing to 
extend the scope of the proposal to different application fields later on?

As a matter of fact I'm convinced that a generalization cannot be done in terms 
of tagging: "attaching" a power line to a fixed infrastructure is done with 
very different techniques from the "attaching" of a washing line, the 
suspension line of a cable car, the cables of a suspension bridge, the overhead 
line of an electric railway (/and I have the strong feeling tha "railways 
taggers" here have their own ideas on how to tag their contact lines/), etc., 
and therefore will require different tagging schemes.



*B) **Inconsistency between the proposal name and the tag name.*

The proposal is named "Line clamps", but then the tagging is defined as 
"line_attachment". This is confusing.


*C) **Are we really talking about "Clamps"?*

A "/clamp/" is a device or a tool used to fix two otherwise relatively moving 
parts to each other by virtue of friction and compression (/which augment 
friction/).

In a power line a clamp is just the device used to fit the conductor to the 
insulator. The definition given by  IEC 466-11-09 and 466-11-10, that you are 
referring to, are clear: "/a fitting which attaches a conductor to a 
_suspension insulator set_/" and "/a clamp which attaches a conductor to a 
_tension insulator set_ or to a support, and designed to withstand the 
conductor tension/". In the IEC documentation both are tagged to be in the 
"Conductor fittings" of the "Overhead lines" area of the IEC.


IEC 383-2 (/Insulators for overhead lines with a nominal voltage above 1000V/) 
gives definitions:

  * *Insulator string*: One or more string connected insulators units and 
intended to give flexible support to overhead line conductors and stressed 
mainly in tension.
  * *Insulator set*: An assembly of one or more insulator strings suitably 
connected together, complete with fixing and protective devices as required in 
service.
  * *Suspension insulator set*: An insulator set complete with fittings to 
carry a line conductor or conductors at its lower end.
  * *Tension insulator set*: An insulator set complete with fittings to secure 
a line conductor or conductors in tension.

The images you are attaching to the definition of "suspension_clamp" and 
"anchor_clamp" are misleading in the sense that one could easily take what in 
reality is a "Suspension insulator set" as a "Suspension clamp" and a "Tension 
insulator set" as an "anchor clamp".

The confusion is even more augmented by the fact that in your proposal you 
refer to "shackle insulators" too (IEC 471-03-09), and they are in a totally 
different area of the IEC standards, "Insulators", same as "pin insulators" 
(IEC 471-03-06).

So, are we talking about clamps (fittings) or about insulators (/or insulator 
sets/) here? Because it really seemsyou are mixing under the same tag two very 
different kind of objects...

Are you taking "a clamp" as "the whole thing suspending conductors from the 
tower/pole" (/of which the insulator is just a component/)? That would be a 
mistake: that's an "insulator set", not a clamp. And BTW, how could you then 
tag "the real clamp" with its bolts and nuts when it comes to it?


*D) Inaccurate wording. *Some examples:

  * You state that "anchor_clamp" is "/built stronger than suspension 
tower//s/". Really? A clamp stronger than a tower? :-/
  * "/A shackle insulator may be used to hold conductors safely from their 
support/" Isn't that the meaning of the life of *every* insulator?
  * ...

*
*

Re: [Tagging] Baby-sitting

[Sergio Manzi]

On 2019-03-08 17:36, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 7. Mar 2019, at 23:31, Cascafico Giovanni  wrote:
>>
>> How can I tag an hotel which features baby-sitting?
>
> what does babysitting mean? Ages 0-3? 
>
> Cheers, Martin 
>

https://en.oxforddictionaries.com/definition/babysitting

Ciao,

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC - Line attachments

[Sergio Manzi]

On 2019-03-08 02:08, Jarek Piórkowski wrote:
> On Thu, 7 Mar 2019 at 19:39, Warin <61sundow...@gmail.com> wrote:
>> Let the mappers vote on if it should be in OSM by using or not using it.
>> Here we should be getting the best tags
> +1, I would rather have a well-specified tag that is rarely used than
> no tag at all.
>
> --Jarek

Then why not bolts and nuts? I suppose there are many nuts of historical 
significance around.

Have a look at this: 
https://en.wikipedia.org/wiki/Nut_(hardware)#/media/File:SydneyHarbourBridgeNutMilsonsPoint.JPG

Do you have something against nuts? I don't...

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC - Line attachments

[Sergio Manzi]

On 2019-03-08 01:39, Warin wrote:
> On 08/03/19 10:40, Sergio Manzi wrote:
>> On 2019-03-08 00:35, François Lacombe wrote:
>>> Hi all
>>>
>>> The line attachments proposal has been updated according to comments 
>>> received all along past weeks. Thanks to TOGA and Nakaner mainly.
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_clamps
>>>
>>> It is not restricted to power nor telecom lines. Any line can be anchored 
>>> or held with suspension clamps over heads.
>>>
>>> This sounds to be ok for me and may be voted shortly.
>>> Feel free to raise objections or comments prior of this to help building a 
>>> more useful tagging.
>>>
>>> All the best
>>>
>>> François
>>
>> ... I suppose a vote for bolts and nuts is imminent too, isn't it?
>
> Nuts on trees?
>
> 
> Providing a way for something to be sensibly tagged is what this is about.
> If enough people map it and then a render shows it then it is justified.
> If few map it and no one renders it the it will wither on the line. (pun).
>
> Let the mappers vote on if it should be in OSM by using or not using it.
> Here we should be getting the best tags, not thinking 'this is not something 
> for OSM' as that is one persons view.


... beside that "/this one person/" happens to have a name, Sergio, and feels 
fully entitled to express his opinion about "/this not being something for 
OSM/", as much as those who are using those tags which I'm convinced will be 
minimally and sparsely used.

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Emergency vehicle country-specific law

[Sergio Manzi]

+1!

On 2019-03-07 19:02, Richard Welty wrote:
> i think OSM should stick to mapping what is legal. first responders
> frequentlhy have permission to ignore the restrictions that apply
> to normal motorists, but they usually have relevant policies that
> probably don't belong in OSM proper and which aren't knowable
> without interviewing the responders in question (and i've
> interviewed a bunch while developing requirements, i have some
> insight into common policies.)
>
> richard



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - RFC - Line attachments

[Sergio Manzi]

On 2019-03-08 00:35, François Lacombe wrote:
> Hi all
>
> The line attachments proposal has been updated according to comments received 
> all along past weeks. Thanks to TOGA and Nakaner mainly.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_clamps
>
> It is not restricted to power nor telecom lines. Any line can be anchored or 
> held with suspension clamps over heads.
>
> This sounds to be ok for me and may be voted shortly.
> Feel free to raise objections or comments prior of this to help building a 
> more useful tagging.
>
> All the best
>
> François


... I suppose a vote for bolts and nuts is imminent too, isn't it?

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Baby-sitting

[Sergio Manzi]

On 2019-03-07 23:31, Cascafico Giovanni wrote:
> How can I tag an hotel which features baby-sitting?

I think it should be something in the lines of "service:babysitting=yes" unless 
we already have something different in use...

Cheers!

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] tagging laboratories

[Sergio Manzi]

I agree with Volker and I also woul like to underline how in Italian we use the 
sister word "laboratorio" (/both com from the Latin "labor, "work"/) for some 
craftmanship activity: we call a "laboratorio" also the places where a 
goldsmith or an orthodontic mechanic performs their craft, and the same for 
many others. I'm unsure if there is a similar usage in English too, but just in 
case...

Sergio


On 2019-03-06 15:27, Volker Schmidt wrote:
> My point was only to be aware that we in front of one of many cases where the 
> same English word has many meanings and that may produce the effect of 
> regrouping under one tag with subtags could produce problems.
> "Laboratory" certainly needs a disambiguation page,
>
> On Wed, 6 Mar 2019 at 15:15, Kevin Kenny  > wrote:
>
> On Tue, Mar 5, 2019 at 2:51 AM Volker Schmidt  > wrote:
> >
> > ... and then there are big research centres that are called 
> "laboratory". Like LLNL or Los Alamos National Laboratory.
>
> The two near me (GE Global Research Center; Knolls Atomic Power
> Laboratory) I've simply tagged 'landuse=industrial'. Both are mostly
> devoted to the development of industrial processes, from early
> experiments at benchtop scale up to pilot plants. Both have
> occasionally even gone into manufacturing specialty components,
> usually when attempts to build out the process elsewhere encountered
> unexpected difficulties. One is my employer.
>
> Most of the buildings on the GE site are tagged 'building=industrial'.
> (The fire house, the fitness centre, the power plant, the sewage
> treatment facility, and the on-site hotel are tagged as such.)  Most
> of the buildings have both labs and offices and I've not attempted to
> do any indoor mapping to separate the two.
>
> Conditions in the laboratories vary from "experimenters work in shirt
> sleeves" to "experimenters work in space suits".
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "satellit"

[Sergio Manzi]

On 2019-03-06 08:46, Jean-Marc Liotier wrote:

> On 3/6/19 3:31 AM, Sergio Manzi wrote:
>> My friend, there are 88 persons who have mapped 520 antennas 
>> (https://taginfo.openstreetmap.org/keys/antenna).
>>
>> Compare it to the billions of antennas out there and I think we are far 
>> below the "/noise level/" and that all energy "invested" in trying to 
>> regulate this is... lost energy.
>>
>> The only antennas I would personally map and tag are those who are enough 
>> conspicuous to represent landmarks
>>
> We are currently at 7252 for man_made=antenna alone 
> (https://taginfo.openstreetmap.org/tags/man_made=antenna) and then there are 
> all the strange things such as (man_made=mast + tower:type=communication) 
> which may or may not record a mast with antennas.
>
> But yes, my goal is landmarks such as conspicuous parabolas, not my 
> neighbour's pet yagi.
>
oops, yes, you're right, I only checked those antenna that do have an 
associated antenna=* key (/about 1 in 15/), but anyway we are not talking about 
huge numbers.

To put things in perspective, and just as  an example, we have about 186000 
amenity=drinking_water, that is an antenna every 26 water taps...

If for those 7252 antennas (/out of billions/) someone is willing to tag 
technical characteristics like operating frequency and polarization, my 
objection about verifiability and observability still hold, but please, go 
ahead if you really want.

I still fail to see _who could benefit_ from that fragmentary, sparse, 
information of unknown quality: I surely would not (/but I'd probably be 
interested into knowing how high the antenna stands and approximately how big 
it is.../).

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "satellit"

[Sergio Manzi]

On 2019-03-06 03:20, Warin wrote:
> On 06/03/19 12:38, Sergio Manzi wrote:
>> Also, if on the other hand you don't expect all TV antennas to be mapped, 
>> what will be the value of such fragmentary and sparse information? "/Cui 
>> prodest/"? Who is going to benefit from such information? Those with a 
>> concrete interest in such information will surely already have their 
>> accurate sources of information and disregard our fragmentary and sparse 
>> information of unknown accuracy.
>
> Unfortunately people are tagging antennas .. in all sorts of ways. And it is 
> a mess.
>
> I seek to provide some constancy so that the information is at least usable 
> for those that want it.
>
> A short look at https://taginfo.openstreetmap.org/keys/antenna%3Atype#values 
> will give you a feeling of what is happening and why there needs to be some 
> guidance on it.
> The numbers are small .. but best to provide some guidance now rather than 
> end up with 'oh but it is in use so we cannot fix it now'. 


My friend, there are 88 persons who have mapped 520 antennas 
(https://taginfo.openstreetmap.org/keys/antenna).

Compare it to the billions of antennas out there and I think we are far below 
the "/noise level/" and that all energy "invested" in trying to regulate this 
is... lost energy.

The only antennas I would personally map and tag are those who are enough 
conspicuous to represent landmarks.

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "satellit"

[Sergio Manzi]

On 2019-03-05 23:48, Warin wrote:
> On 05/03/19 21:30, Sergio Manzi wrote:
>>
>> On 2019-03-05 11:14, Warin wrote:
>>
>>> On 05/03/19 20:08, Jean-Marc Liotier wrote:
>>>> On Mon, March 4, 2019 11:20 pm, Warin wrote:
>>>>> https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use
>>>> This is a way to solve most of the problem, but it fails the "map it as I
>>>> see it" test.
>>>>
>>>> man_made=antenna + antenna:reflector=dish does map the satellite
>>>> communications antenna I just spotted... But what the naïve mapper I am
>>>> really wants is man_made=antenna + antenna=dish (or
>>>> monopole/dipole/yagi/helical/phased_array ...) : "map it as I see it" !
>>>>
>>>> Then one can add antenna:propagation, antenna:application,
>>>> antenna:propagation, antenna:polarisation etc. but they are accessory.
>>>>
>>>> Am I mistaken in believing that the main tags chain should focus on
>>>> offering a straightforward way to map the apparent physical features,
>>>> rather than invisible distinctions ? Not that invisible distinctions are
>>>> not welcome too - but they should stay out of the way.
>>>
>>> Sympathies!
>>>
>>> An alternative is available ...
>>>
>>> man_made=antenna
>>>
>>> dish=yes
>>
>> So far, so good.
>>
>>
>>> cross_gain_feed=yes
>>
>> What does that mean? I'm a licensed radio amateur (/for more than 30 years/) 
>> and I never heard of that term... :-/
>>
>
> Arr  casse grain ... apologies. (added word to spell checker)


Ah, OK, a Cassegrain antenna, one with the Illuminator on (/or close to/) the 
surface of the main concave reflector and a secondary convex reflector. 
Amazing, but it takes the name from the inventor of this design, Laurant 
Cassegrain, 1*_6_*29-1*_6_*93!!!  :-)


> How is the reflecting dish signal connected? There must be a real antenna 
> that does that.
> And then there is the way the antenna gets the reflected signal.
> https://en.wikipedia.org/wiki/Parabolic_antenna
>
>
>
> There is a lot to learn, we should have more life times ...
>
>>> two_way=yes
>>
>> Prove that!
>>
> As an example: This may be a TV studio where TV programs are transmitted to a 
> satellite for distribution.
> As a TV studio it may also receive TV signals from remote broadcasts... or 
> other TV studios connected to the satellite.


I'm sure you understand that the above argument isn't worth a dime: you only 
move the issue of "/knowing/" that an antenna is a two ways antenna to the one 
of "/knowing/" that below the antenna there is a production studio broadcasting 
stuff and therefore there must be a two_ways antenna somewhere on the roof: one 
of the probably many antennas up there.


> OSM accepts 'knowledge' as a suitable source of information.


Really? OSM accepts 'knowledge' as a suitable source of information? Whose 
knowledge? How verifiable? I don't know if this is really an official policy 
(/to me it seems to violate the observability and verifiability principles/), 
but if it really is (/is it?/), I tell you, I'm not interested in that kind of 
information: in a GIS I only trust observable and verifiable truths, even if 
you have all the rights to "map your knowledge".


>>> satellite=yes
>>
>> Prove that! Because it points at the sky? There are many other good reasons 
>> to point an antenna at the sky...
>>
>
> Again? If you don't know .. don't tag it. But don't deny others from adding 
> stuff they do know.
>
> Don't know that a road is closed in winter? then don't tag it.
> Know that a road is closed in winter - tag it.
> Come across an open road in summer that is tagged closed in winter ... and 
> you want to verify the closure? Come back in winter or contact the relevant 
> mapper.


Yes, sorry, again and again. Of course if I don't know something I will not tag 
it, but I'm more concerned about those who thinks or pretend to know and will 
tag "something" which is not generally and easily verifiable.

If on the antenna on the roof there is a board stating "This is a two_ways 
antenna" and on the road there is a board stating its winter closure, I fully 
accept the tagging. If there is no such board I don't trust that information, 
nor for the antenna, nor for the road and I'll seek more reliable sources of 
information (/of course the "boards" could be "virtual boards", such as 
officially published information from the road/building operator/).


> The most common antenna people see a

Re: [Tagging] leisure=common replacement for public areas with some trees

[Sergio Manzi]

On 2019-03-05 12:48, Marián Kyral wrote:
>
> -- Původní e-mail --
> Od: Mateusz Konieczny 
> Komu: Tag discussion, strategy and related tools 
> Datum: 5. 3. 2019 12:35:28
> Předmět: Re: [Tagging] leisure=common replacement for public areas with some 
> trees
>
>
>
>
>
> Mar 5, 2019, 11:48 AM by s...@smz.it:
>
> Hi!
>
> On 2019-03-05 11:13, Mateusz Konieczny wrote:
>
>
> Mar 5, 2019, 9:00 AM by mky...@email.cz :
>
> Typically a small areas in the city between apartment 
> buildings. These areas are not official parks, gardens or grass. It is just a 
> green accessible for everoyne. So we can say it is a *public* or *common* 
> green.
>
> So far I usually tagged such places as follows:
>
> Made sure that it is within landuse=residential (as it is a 
> residential area)
> Mapped physical features (leisure=playground, natural=tree, 
> landuse=grass, highway=footway etc)
>
> Is it land*use*=grass or land*cover*=grass? I tend to agree with 
> Alessandro Sarretta who uses landcover...
>
> landcover=grass also would be fine in this case, but meaning of this tags 
> is the same and
> landuse=grass is more popular
>
>
> landcover=grass - still not rendered: 
> https://www.openstreetmap.org/way/402959582
>

Thanks for hinting about landcover=grass not being rendered (/I guess we should 
open a Github issue for that if one doesn't exist already.../).


> landuse=grass -  means that there will be landuse (grass) on landuse 
> (residental). Is this OK? I'm not sure If I want to create a lots of 
> multipolygons because of this.


As I already mentioned in a different context, I think the correct technique 
would be to be to just draw one multipolygon (/the "main" one, probably tagged 
with landuse=residential in this case/), and then create a new relation, 
containing just the "main" multipolygon, and tag that relation with the 
secondary landuse.


> Marián




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] leisure=common replacement for public areas with some trees

[Sergio Manzi]

Sorry, my answer was meant to regard the "common replacement" (topic of the 
thread) more than the situation described by Marián for which "playground" is 
probably OK...

On 2019-03-05 11:48, Sergio Manzi wrote:
>
> Hi!
>
> On 2019-03-05 11:13, Mateusz Konieczny wrote:
>>
>> Mar 5, 2019, 9:00 AM by mky...@email.cz:
>>
>> Typically a small areas in the city between apartment buildings. These 
>> areas are not official parks, gardens or grass. It is just a green 
>> accessible for everoyne. So we can say it is a *public* or *common* green.
>>
>> So far I usually tagged such places as follows:
>>
>> Made sure that it is within landuse=residential (as it is a residential area)
>> Mapped physical features (leisure=playground, natural=tree, landuse=grass, 
>> highway=footway etc)
>
> Is it land*use*=grass or land*cover*=grass? I tend to agree with Alessandro 
> Sarretta who uses landcover...
>
> I also have doubts about leisure=playground as it is not a physical feature 
> but it describe the usage done of that space, not its characteristics. Also 
> that very same space could be used for different things (/fairs, concerts, 
> rallies, etc./) at different times...
>
> TBH I don't have an answer to the problem, but I tend to agree that we 
> should, A) describe the physical characteristics of the place, and, B) 
> describe the fact that the place is of public interest...
>
>
>> Maybe one may also add access tag to landuse=residential to tag it as a 
>> public?
>> AFAIK this is not commonly done at this moment, but I see nothing wrong with 
>> it.
>
> Sergio
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] leisure=common replacement for public areas with some trees

[Sergio Manzi]

Hi!

On 2019-03-05 11:13, Mateusz Konieczny wrote:
>
> Mar 5, 2019, 9:00 AM by mky...@email.cz:
>
> Typically a small areas in the city between apartment buildings. These 
> areas are not official parks, gardens or grass. It is just a green accessible 
> for everoyne. So we can say it is a *public* or *common* green.
>
> So far I usually tagged such places as follows:
>
> Made sure that it is within landuse=residential (as it is a residential area)
> Mapped physical features (leisure=playground, natural=tree, landuse=grass, 
> highway=footway etc)

Is it land*use*=grass or land*cover*=grass? I tend to agree with Alessandro 
Sarretta who uses landcover...

I also have doubts about leisure=playground as it is not a physical feature but 
it describe the usage done of that space, not its characteristics. Also that 
very same space could be used for different things (/fairs, concerts, rallies, 
etc./) at different times...

TBH I don't have an answer to the problem, but I tend to agree that we should, 
A) describe the physical characteristics of the place, and, B) describe the 
fact that the place is of public interest...


> Maybe one may also add access tag to landuse=residential to tag it as a 
> public?
> AFAIK this is not commonly done at this moment, but I see nothing wrong with 
> it.

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "satellit"

[Sergio Manzi]

On 2019-03-05 11:14, Warin wrote:

> On 05/03/19 20:08, Jean-Marc Liotier wrote:
>> On Mon, March 4, 2019 11:20 pm, Warin wrote:
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use
>> This is a way to solve most of the problem, but it fails the "map it as I
>> see it" test.
>>
>> man_made=antenna + antenna:reflector=dish does map the satellite
>> communications antenna I just spotted... But what the naïve mapper I am
>> really wants is man_made=antenna + antenna=dish (or
>> monopole/dipole/yagi/helical/phased_array ...) : "map it as I see it" !
>>
>> Then one can add antenna:propagation, antenna:application,
>> antenna:propagation, antenna:polarisation etc. but they are accessory.
>>
>> Am I mistaken in believing that the main tags chain should focus on
>> offering a straightforward way to map the apparent physical features,
>> rather than invisible distinctions ? Not that invisible distinctions are
>> not welcome too - but they should stay out of the way.
>
> Sympathies!
>
> An alternative is available ...
>
> man_made=antenna
>
> dish=yes

So far, so good.


> cross_gain_feed=yes

What does that mean? I'm a licensed radio amateur (/for more than 30 years/) 
and I never heard of that term... :-/


> two_way=yes

Prove that!


> satellite=yes

Prove that! Because it points at the sky? There are many other good reasons to 
point an antenna at the sky...


> --
> This does open it up for adding 2 things that are mutually exclusive eg
> yagi=yes
> monopole=yes
>
> but in other respects is easier to use.


Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "satellit"

[Sergio Manzi]

On 2019-03-05 10:08, Jean-Marc Liotier wrote:
> On Mon, March 4, 2019 11:20 pm, Warin wrote:
>> https://wiki.openstreetmap.org/wiki/Proposed_features/antenna:use
> This is a way to solve most of the problem, but it fails the "map it as I
> see it" test.
>
> man_made=antenna + antenna:reflector=dish does map the satellite
> communications antenna I just spotted... But what the naïve mapper I am
> really wants is man_made=antenna + antenna=dish (or
> monopole/dipole/yagi/helical/phased_array ...) : "map it as I see it" !
>
> Then one can add antenna:propagation, antenna:application,
> antenna:propagation, antenna:polarisation etc. but they are accessory.
>
> Am I mistaken in believing that the main tags chain should focus on
> offering a straightforward way to map the apparent physical features,
> rather than invisible distinctions ? Not that invisible distinctions are
> not welcome too - but they should stay out of the way.

+1!

As far as I'm concerned, lack of observability and/or lack of verifiability are 
a no-go for inclusion in OSM!

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] "satellit"

[Sergio Manzi]

On 2019-03-04 11:54, Martin Koppenhoefer wrote:
> Do not counter this with "not sufficiently relevant for mapping", as you'll 
> see people will likely tag it ;-)


Personally I counter this for lack of observability/verifiability.

From https://wiki.openstreetmap.org/wiki/Verifiability

"At the core, "verifiability" is that everything you do can be demonstrated 
to be true or false - the latter hopefully implying that there has been a 
change on the ground that needs mapping. We apply this not only to the mapping 
data itself, but also to the way in which we record it - the tags and values we 
use to describe the attributes of objects on the map. From a given scenario, a 
tag/value combination is verifiable *if and only if* independent users when 
observing the same feature would make the same observation every time. For a 
user's tagging to be verifiable, it is desirable to have objective criteria for 
tagging. This principle applies to any observable characteristic which is a 
matter of fact, be it numerical or descriptive - a concrete road surface, a red 
brick building, etc. "

Isn't the above an OSM tenet any more?

Sergio


P.S.: yeah, I know it is a "lost cause", but anyway...



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

On 2019-03-03 00:49, Mark Wagner wrote:
> On Sat, 2 Mar 2019 02:05:46 +0100
> Sergio Manzi  wrote:
>
>> On 2019-03-02 01:33, Martin Koppenhoefer wrote:
>>> sent from a phone
>>>  
>>>> On 1. Mar 2019, at 13:45, Mateusz Konieczny
>>>>  wrote:
>>>>
>>>> I would tag max weight, I would not tag emergency=no.  
>>> +1, it will not exclude all kinds of emergency services anyway,
>>> only those in vehicles that are too heavy, for example there could
>>> be police on bicycles who could cycle on the bridge like
>>> pedestrians can walk on it.
>>>
>>>
>>> Cheers, Martin  
>>
>> I really-really-really like to know of a place where emergency
>> vehicles are *legally *not allowed to go...
> It's not "legally not allowed to go", but on Fairchild Air Force Base,
> civilian emergency vehicles are subject to the same "with permission
> only" restriction as everyone else.  I suspect the same is true of most
> if not all other military bases in the United States.


I also suspect guards of the US Bullion Depository at Fort Knox will not just 
open the gates to an unexpected ambulance even if it had full light flashing 
and siren wailing. Or will they? Maybe a good idea worth trying...






smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

On 2019-03-02 14:15, Jarek Piórkowski wrote:

> On Sat, 2 Mar 2019 at 05:34, Sergio Manzi  wrote:
>> BTW, do we have a specific tag for "emergency traffic light" that are put 
>> near emergency vehicles exits to stop normal traffic when emergency vehicles 
>> are about to exit?
> Funnily enough, per
> https://wiki.openstreetmap.org/wiki/Key:traffic_signals this should be
> traffic_signals=emergency

Thanks!

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

On 2019-03-02 11:20, Mateusz Konieczny wrote:
>
>> Though in all cases when I used it I should be using emergency=designated
>> (road was signed as firefighter access road or main ambulance access at 
>> the hospital).
>
> ... and that's a different story, because this is valuable information 
> for non-emergency vehicles: "you can't go there!"
>
> Nope. Access may be designated for multiple uses or one use designated and 
> other
> allowed.

Right.

BTW, do we have a specific tag for "emergency traffic light" that are put near 
emergency vehicles exits to stop normal traffic when emergency vehicles are 
about to exit?


Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

On 2019-03-02 09:07, Martin Koppenhoefer wrote:
>> On 2. Mar 2019, at 02:18, Sergio Manzi  wrote:
>>
>> Should I tag every street wide enough for a chair to pass with 
>> "emergency=yes"?
> no because emergency is an access key (legal access), so „wide enough“ is not 
> a criterion 
>
> Cheers, Martin 

Martin,

I was on the impression that the "/latest/" interpretation of emergency=yes was 
"physical accessibility", not "legal right" ...

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

On 2019-03-02 09:49, Mateusz Konieczny wrote:
>
> Mar 2, 2019, 2:05 AM by s...@smz.it:
>
> I really-really-really like to know of a place where emergency vehicles 
> are *legally *not allowed to go...
>
> And if there isn't such a place, why do we need ""?
>
> And if we don't have such a need, why do we need "emergency=yes"?
>
> Because a given road is *accessible *to a emergency vehicles?
>
> Apparently people like to explicitly tag in some situations.


The problem (/as I see it.../) is that it isn't clear at all what they are 
trying to explicitly tag.

Once a again:

  * a legal right? Absurd, as emergency vehicles always have that right.
  * physical accessibility? Absurd, as it doesn't state to which kind of 
vehicles (/small police car or humongous fire truc//k?/).

IMHO emergency=yes and emergency=no should be deprecated, as simple as that.

If there are physical restrictions (/weight, width, height/), tag that.


> Though in all cases when I used it I should be using emergency=designated
> (road was signed as firefighter access road or main ambulance access at the 
> hospital).

... and that's a different story, because this is valuable information for 
non-emergency vehicles: "you can't go there!"


Sergio


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

BTW, here in Venice patients are almost always transported by emergency 
personnel on "a chair with handles" (/a chair-stretcher... I don't know if 
there is an English name for that.../).

The reason is that normal stretchers would not pass through most buildings 
narrow and steep stairs.

Should I tag every street wide enough for a chair to pass with "emergency=yes"?

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

On 2019-03-02 01:33, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 1. Mar 2019, at 13:45, Mateusz Konieczny  wrote:
>>
>> I would tag max weight, I would not tag emergency=no.
>
> +1, it will not exclude all kinds of emergency services anyway, only those in 
> vehicles that are too heavy, for example there could be police on bicycles 
> who could cycle on the bridge like pedestrians can walk on it.
>
>
> Cheers, Martin


I really-really-really like to know of a place where emergency vehicles are 
*legally *not allowed to go...

And if there isn't such a place, why do we need "emergency=no"?

And if we don't have such a need, why do we need "emergency=yes"?

Because a given road is *accessible *to a emergency vehicles?

Accessible to which vehicles? A small police car or an humongous fire truck?


Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

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 break them :-) eg in an emergency, an ambulance can go through a 
>> red light, but if they cause an accident by doing so, the driver will be 
>> charged (& they have been)
>
> Sorry, but I'm inclined to categorize the above as BS, or "fake news", if 
> you prefer, until you provide evidence (in which case I'll apologize and eat 
> my words).
>
> http://www.ukemergency.co.uk/blue-light-use/ scroll down to, or search for, 
> section headed
> "Exemptions from Road Signs."  Applies in UK, may be subject to change by 
> future legislation.
> Essentially if they cause an accident by jumping a red light they're in the 
> shit.  Because they're
> allowed to go through a red light only if it is necessary AND it is safe to 
> do so.  If they end up
> causing an accident, it obviously wasn't safe to do so.
>
> -- 
> Paul
>

Of course. And the operative word here is "*exemption*". The truth is that a 
driver *could  *be in deep troubles for "reckless driving" while having caused 
the accident (/because there was actually no emergnecy, because he was 
intoxicated, because ther was an 18 wheeler in the mdst of the crossing at that 
time and he ignored it, etc./), but not for having jumped the light "/per se/".

What your street code says about the behaviour drivers at a crossing (with 
lights) must have when there is an incoming emergency vehicle?

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

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 break them :-) eg in an emergency, an ambulance can go through a red 
> light, but if they cause an accident by doing so, the driver will be charged 
> (& they have been)

Sorry, but I'm inclined to categorize the above as BS, or "fake news", if you 
prefer, until you provide evidence (in which case I'll apologize and eat my 
words).

In every street code I know of, emergency and law enforcement vehicles with 
alarm and light turned on HAVE PRECEDENCE on the traffic, regardless the status 
of traffic lights, with all the legal implications that derive from that.

Sure, an ambulance driver who has caused an accident will be investigated, but 
NOT for having burned a red traffic light (/they'll asses if he/she was DUI and 
stuff like that.../)

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=police

[Sergio Manzi]

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 on searches / rescues etc).


I think you're talking about something different from the "true", de facto, 
Australian "Coast Guard", which is "Maritime Border Command": 
https://en.wikipedia.org/wiki/Maritime_Border_Command_(Australia)

Maybe you're referring  to community S organizations like "Marine Rescue 
NSW", "Australian Volunteer Coast Guard" or "Royal Volunteer Coastal Patrol".

The typical roles of the Coast Guard (/or whatever is called in different 
countries/) is maritime borders control and maritime law enforcement.

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

P.S. a note to Andy Townsend: We are not at "/the price of fish/" yet, but 
we're rapidly closing in...    :-)

On 2019-02-26 19:19, Sergio Manzi wrote:
>
> Exactly! And in Venice there is an official designation of roads accordingly 
> to their availability in case of exceptional high tides ("/Acqua alta/") of 
> different heights, but AFAIK this essential information is not registered 
> anywhere in OSM...
>
> Are you a Venetian too, Fernando?
>
> Cheers,
>
> Sergio
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

Exactly! And in Venice there is an official designation of roads accordingly to 
their availability in case of exceptional high tides ("/Acqua alta/") of 
different heights, but AFAIK this essential information is not registered 
anywhere in OSM...

Are you a Venetian too, Fernando?

Cheers,

Sergio


On 2019-02-26 17:28, Fernando Trebien wrote:
> I believe you, I've spent a week there one year ago. As a map user I
> would prefer to have the safe passages during acqua alta [1] somehow
> highlighted, or at least the main pedestrian routes between the main
> plazas, and I think many of the narrower alleys (some are narrower
> than the width of a car) could be highway=footway with no damage to
> map readability.
>
> [1] http://farm5.static.flickr.com/4014/4259181423_586509d152.jpg
>
> On Tue, Feb 26, 2019 at 10:40 AM Sergio Manzi  wrote:
>> ... 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


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

Venice situation is unusual but not unique and in other contexts different 
tagging schemes have been used, not limited by the footway/pedestrian 
alternative.

As an example see how this road in Mackinac Island (/no motor vehicles 
there.../) is tagged: https://www.openstreetmap.org/way/17874338

I've seen others too, but OTOMH I can't remember where, probably France 
(/possibly St. Malo.../) and/or Netherland, but by Googling for "pedestrian 
town/city" and then checking on OSM,  several pops up...

Cheers,

Sergio


On 2019-02-26 15:30, Martin Koppenhoefer wrote:
>
>
> Am Di., 26. Feb. 2019 um 14:40 Uhr schrieb Sergio Manzi  <mailto:s...@smz.it>>:
>
> ... 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!
>
>
>
>
> Venice is a globally unique (or maybe almost unique) exception anyway, but 
> what we currently have there is the result of people reclassifying all the 
> footways as pedestrian roads, even if they are 50 cm wide. I have started in 
> the past several attempts to open a discussion on this, but it felt like Don 
> Quixote. See this as an example: 
> https://www.openstreetmap.org/way/488627565/history I have surveyed it 
> myself, like many others, where I began to reclassify the very narrow 
> footpaths from pedestrian to footway, but I am not local and people destroy 
> the finer grained distinction of footway and pedestrian as soon as you add 
> them, I guess they do not want the red dots. It is unfortunate, because it 
> makes the Venice map much harder to read and less useful. If you are local, 
> please try to improve the situation, we do not need new tags, it would be 
> sufficient to apply the existing ones consistently rather than 
> indiscriminately.
>
> Cheers,
> Martin


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

On 2019-02-26 15:19, Martin Koppenhoefer wrote:
>
>
> Am Di., 26. Feb. 2019 um 13:52 Uhr schrieb Fernando Trebien 
> mailto:fernando.treb...@gmail.com>>:
>
> On Mon, Feb 25, 2019 at 9:00 PM Sergio Manzi  <mailto:s...@smz.it>> wrote:
> I think the official categories in Codice della Strada should probably
> be assigned to OSM's classes by closely matching the descriptions in
> the wiki. 
>
>
>

Hi!

The above citation could be mistakenly taken as mine, but that's not the case...

Cheers,

Sergio


> not at all, we already have classified all of our roads according to wiki, 
> surroundings/context, local knowledge etc.
> If we are to add "Codice della Strada" classes, it should not influence the 
> highway class, it should be an additional tag.
>
> We might also decide to tag the Italian network classes explicitly. I'm not 
> an expert in this field, but from a quick internet lookup it appears in Italy 
> there are 4 classes of (kind of) movement: a - primary network (transit), b - 
> principal network (distribution), c - secondary network (penetration), d - 
> local network (access).
> For the specific characteristics you must take into account whether the road 
> is inside or outside of a built-up area (this is generally an interesting 
> information for which we do not explicitly cater in general with our tagging, 
> but which should probably be introduced).
>
> When planning a road you must additionally take into account:
> - entity of movement (median distance that the vehicles travel)
> - territorial connecting function (national, interregional, provincial, local)
> - traffic components (light vehicles, heavy vehicles, motorvehicles, 
> pedestrians, etc.)
>
> You can find more information in this ministrial decrete from 2001 which was 
> issued after the new 1992 CdS law: 
> http://www.mit.gov.it/mit/mop_all.php?p_id=1983
> (this is mainly thought as a reference for the Italian mappers, I do not 
> expect the others to read through 100 pages in Italian).
>
> The CdS classes are only part of the entire picture, e.g. the same CdS class 
> (example "B Strada extraurbana principale") may be used for a "movement a" or 
> "movement b" kind of road.
>
>  
>
> This would help Italians make sense of the map.
>
>
>
> really, the sense does not come from classifications mostly, it is the refs 
> and names that make the information locally relevant. Joe Mapuser really 
> doesn't need all the detail information typically, because we have already 
> conveniently summarized everything into a single highway class ;-)
> Still, we should not deny the addition of detail, but it likely doesn't mean 
> we can set up a lookup-table CdS to highway class and be done.
>
>
> Except for the official categories in Codice della Strada, I think
> such attributes of the road should go into specific tags.
>
>
>
> if there is a clear 1:1 correlation between CdS and OSM, e.g. motorways, we 
> already have that information in the map (well, besides we do not have 
> specific tags yet for motorways in built-up settings).
>  
>
>
> For example,
> in Brazil, the administrative responsibility is represented by the
> road's reference code, so it can be easily identified from ref=* tags
>
>
>
> same in Germany, Italy and likely many other places indeed.
>
> Cheers,
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

... 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 better model than just path 
> and cycleway, since some networks can get quite complex (consider quietways 
> and cycle superhighways; or the multitiered systems in The Netherlands, for 
> example).



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

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 density and traffic speed, and 
>> some sort of numerical classification scheme for motorways, etc.
>>
>> What's going on?
>
> It's the tagging list.  It'll move on to the price of fish next :)
>
> Best Regards,
>
> Andy


Yeah... true... but interesting discussion nonetheless!

Cheers,

Sergio




smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] transaction parameters for ATMs

[Sergio Manzi]

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 ATM's absolute maximum 
whitdrawal limit (/unless you are a bank employee, maybe/)...

I see it hardly usable here...

Sergio


On 2019-02-25 11:44, Marc Gemis wrote:
> Any tagging proposal should make it very clear that it is the limit of
> the ATM. A tag that should not be used in Belgium.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

+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 Strada/) are.

There the concern is most about how to tag an official classification 
(/something that is implicit in the tag value in UK, if I'm not mistaken/) 
instead of a "descriptive classification".

But other concerns are emerging too (/at least in my head!/), like the 
administrative responsibility under which a given road falls (/state, region, 
province, municipality, private/) and ad-hoc values as input for the router 
(/s//peed limits, traffic density, etc. *OR* a comprehensive "preference"value  
/).

Keep on going!

Cheers,

Sergio



On 2019-02-25 22:10, Andy Townsend wrote:
> On 24/02/2019 14:25, djakk djakk wrote:
>>
>> I think we should decorrelate the attributes of a road : its administrative 
>> class, its importance in the road network (at least 5 levels), its physical 
>> characteristics (motorway-like, two large lanes, link=yes ...), possibly its 
>> traffic characteristics.
>>
>> So we can tag a secondary motorway or a primary road through a residential 
>> area or an official motorway with pedestrians actually walking on it.
>>
>> So that we’ll unify osm road classification through the world (remember the 
>> highway=trunk issue ;-))
>>
>
> It's a noble aim, but unfortunately the first thing that springs to mind is 
> https://xkcd.com/927/ :)
>
> However, some of the stuff on 
> https://wiki.openstreetmap.org/wiki/User:Djakk/new_tagging_scheme_for_roads I 
> definitely agree with, and in some cases actually do do myself - like trying 
> to capture the physical characteristics wherever relevant.
>
> Best Regards,
>
> Andy
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

Thanks Greg,  Warin and Marc, I stand corrected on this: "unclassified" is a 
class of roads and an unclassified road is a "road".

Ooops... my tongue just got twisted!  :-)

Sergio


On 2019-02-21 02:01, Greg Troxel wrote:
> But it doesn't mean that in the UK. It means "in the national road
> system, with a number, but not A B or C".  So it really is a higher
> class than a road which is not ABC and is not unclassified, at least as
> I understand it and observed it.
>
> In OSM we use words by their OSM defintions, not what they ought to mean
> in English!


On 2019-02-21 06:31, Warin wrote:
> No. If you don't know any thing about it then highway=road is the thing to use


On 2019-02-21 09:39, marc marc wrote:
> Le 21.02.19 à 02:01, Greg Troxel a écrit :
>> there is a road there, but we don't know how it is
> that's highway=road



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] units and notations for maxstay

[Sergio Manzi]

This is easy to answer:

"We want to make the best map data set of the world"

Sergio


On 2019-02-20 23:11, Graeme Fitzpatrick wrote:
> Is OSM supposed to be for a tight, dedicated group of expert mappers trying 
> to create the best, most accurate, technically-perfect map the World has ever 
> seen; or is it for the use of John Doe & Jane Public using OSMAND & Maps Me 
> on their mobile phones to find their way from Point A to Point B, or round a 
> strange town?


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Clarification unclassified vs residential

[Sergio Manzi]

Hello Mark,

I'm not willing to criticize your contribution, at all, but your preamble, 
"/Here in Washington State .../", was food for thought about the fact that 
sometimes (/often?/) we are affected by cultural bias here: the definition of 
features like highways may differ a lot depending in which part of planet Earth 
you happen to live. My (Italian) concept of a residential road is surely 
different from yours (US, Washington State), and one of an Indian citizen (/I 
travelled a lot in India so maybe I have rough idea about that/), or a Somali 
(/never put foot there.../), just to make a couple of examples.

I think those definitions ar much better left to local communities, and so 
seems to think "the wiki" too in its incommensurable wisdom: see pages like 
https://wiki.openstreetmap.org/wiki/Tagging *or* 
https://wiki.openstreetmap.org/wiki/Highway:International_equivalence *and* 
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions

One thing I'm quite sure, anyway, is that "unclassified" should mean just that: 
"/it doesn't fall in any other classification OR we don't know cr.p about it 
(we know there is a road there, but we don't know how it is)/".

Routing decisions too are culture-dependent. As an example, in India I know of 
some residential roads which are perfectly normal roads by daytime, but are 
closed to traffic by night time (/but maye there is some other kind of more 
specific restriction for tha/t).

Sergio

On 2019-02-20 20:50, Mark Wagner wrote:
>
> Here in Washington State, ...


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] units and notations for maxstay

[Sergio Manzi]

Maybe not a such bad idea, after all, but probably unfeasible.

Ever since technology has given us powerfull but potentially dangerous tools 
(/steam engine, cars, firearms, electricity, the radio, surgery, drugs, 
airplanes, etc, etc.../) society, conscious of the dangers associate to such 
tools, has correctly asked operators of such tools to be "able and conscious" 
and that to be certified through some agreed formal process.

And yes, I think maps too are powerful but potentially dangerous.

I wouldn't come so far to ask for a formal qualification, but the modicum of IQ 
and decency we should expect from mappers is what's enough to understand when 
one can honestly feel entitled to talk about something or perform a particular 
task.

Cheers,

Sergio


On 2019-02-20 12:10, marc marc wrote:
> I wonder if it will soon be necessary to do an IQ test to contribute
> to osm.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] units and notations for maxstay

[Sergio Manzi]

Perfect!

NIH syndrome [1] anybody?

[1] https://en.wikipedia.org/wiki/Not_invented_here


On 2019-02-20 13:42, Colin Smale wrote:
> Lets be clear, the storage format can (and should) be decoupled from the 
> display format. What is stored in the database can easily (assuming it is 
> sufficiently standardised!!!) be translated for human consumption, and the 
> inverse can be done when storing.
...
>  Among the advantages of using the ISO standard include that all that 
> thinking has already been done, and the documentation of the syntax is 
> available freely in millions of languages.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] units and notations for maxstay

[Sergio Manzi]

And so? I'm also quite sure that less than 1% of mappers will spontaneously 
encode opening_hours=* according to what we prescribe in the wiki [1], but 
nonethelss that's what we expect they should do.

What's your point?

Sergio

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

On 2019-02-20 13:06, marc marc wrote:
> ...
> ask other mapper how to tag "2 hours" in the iso form.
> I doubt that 1% 'll reply "T2H" without first reading the doc.
> it not only the IQ, it's also the use of user-not-friendly value.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] units and notations for maxstay

[Sergio Manzi]

+1 this!

On 2019-02-20 01:45, Andrew Errington wrote:
> Already handled by ISO8601:
>
> https://en.m.wikipedia.org/wiki/ISO_8601#Durations
>
> I think any discussion of dates and times should start by asking if we could 
> apply ISO8601 to the problem at hand. For example the other thread about 
> start date variants.
>
>  Andrew



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Sergio Manzi]

On 2019-02-18 15:58, Dave F via Tagging wrote:
>> Different tagging will not remove the non-consensus. 
>
> What consensus will it remove? Misunderstanding the meaning of a tag is not 
> consensual. Different tags allows the specifying of varying objects/attributes


(not removing) (the non consensus) !== (removing) (the consenus)

(not removing) (the non consensus) == (keeping/maintaining) (the non consensus)

logic 101...

Cheers!

Sergio





smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Waterway length

[Sergio Manzi]

I think I know understand what usage you want to do of that "waterway length" 
datum (/or at  least that's what I'm reading in your last message/): use it as 
a "control" for checking if the waterway's segments add up to the "official" 
(/whatever that can mean.../) waterway length.  Or at least in part: that datum 
will be close to useless to check waterways with the complexity of the "/river 
of a hundred waterways/" and many similar ones.

For that I guess  a better solution would be to use the fixme=* tag: "fixme: 
check that this river length is between 5499 and 7088 Km", for the Nile.

TBH I see A LOT of issues with this tag:

  * it is wrongly named (/distance instead of length/)
  * it is unverifiable "on the ground"
  * it can assume multiple different values according to different sources
  * it is IMNSHO useless (/just point to a Wikipedia article to get this 
information/)

Personally I'm leaning to propse to deprecate the usage of this key and subject 
that to a vote. What is the process for that?

Sergio


On 2019-02-17 14:07, Eugene Podshivalov wrote:
> вс, 17 февр. 2019 г. в 15:18, Sergio Manzi  <mailto:s...@smz.it>>: 
>
>   That's as old as data processing: "/garbage in, garbage out/". Let's 
> fix the data. 
>
> Fixing data is a good thing but from utilization in production point of view 
> the choice between unstable and stable data is not questioned.
> Competeness of data is even more important than its stability, and that 
> unfortunately cannot be achieved that quickly. One can create a waterway 
> relation with a length defined and then there may be a long run until all 
> waterway segments are drawn properly to finally be able to compare it to an 
> official length.
>
> You'll probably can find many different estimations about its length. 
> Which one are you going to choose? 
>
>  I would take one from any encyclopedia (subject to its license) and that 
> figure will at least serve other mappers as a guidence when searching for 
> incomplete or broken rivers.
>
> Cheers,
> Eugene
>
>  
> вс, 17 февр. 2019 г. в 15:18, Sergio Manzi mailto:s...@smz.it>>:
>
> On 2019-02-17 12:55, Eugene Podshivalov wrote:
>>
>> It will work but only if the entire river from its spring to mouth is 
>> drawn precisely enough, all relation roles are labeled properly and nobody 
>> breaks the labeling by intent or mistake some day.
>
> That's as old as data processing: "/garbage in, garbage out/". Let's fix 
> the data.
>
> And yes, the river you pointed at is particularly complex and probably 
> geographers are pulling each other's hairs about computing its length. You'll 
> probably can find many different estimations about its length. Which one are 
> you going to choose?
>
> Sergio
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Waterway length

[Sergio Manzi]

On 2019-02-17 12:55, Eugene Podshivalov wrote:
>
> It will work but only if the entire river from its spring to mouth is drawn 
> precisely enough, all relation roles are labeled properly and nobody breaks 
> the labeling by intent or mistake some day.

That's as old as data processing: "/garbage in, garbage out/". Let's fix the 
data.

And yes, the river you pointed at is particularly complex and probably 
geographers are pulling each other's hairs about computing its length. You'll 
probably can find many different estimations about its length. Which one are 
you going to choose?

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] start_date variants

[Sergio Manzi]

Hi Stephan!

Yes, a relation can be made up of a relation: no problem with that, AFAIK.

In your particular case, anyway, I'm afraid there is something wrong:

https://www.openstreetmap.org/relation/1937535 (name=MuseumsQuartier) is tagged 
as "building=yes" and also with "building:architecture=baroque", but in reality 
MusemQuartier is not "_*a*_" building, but an area, a cultural district (on 
https://www.mqw.at/en/ I read "/MuseumsQuartier Wien is one of the largest 
districts for contemporary art and culture in the world/"), made up of several 
different building_*s*_ ranging from the baroque to the contemporary era.

MuseumsQuartier (/the district/) is already mapped with 
https://www.openstreetmap.org/way/335982323 as both a tourism=attraction and 
landuse=commercial (/yeah... I know... it seems we miss a specific tag for 
cultural districts and I think that's something we should address.../), and 
several of the tags applied to relation 1937535 (e.g. wikidata=*, wikipedia=*) 
are already there. Anything globally related to the MuseumsQuartier cultural 
district should be tagged on that way.

If relation 1937535 is meant to map *one* of the several buildings which are 
part of the MuseumQuartier district, then anything related to the district 
should be deleted from it and probably the name should also be changed: a 
building is not a /quartier/ and I suppose the correct name for that particular 
building (/the baroque building encompassing the district/) to be 
/Hofstallungen./

The "building:start_date=1725" tag should be modified into just a 
"start_date=1725" tag, and the "start_date=2001-06..2001-09" tag should be 
instead applied to the /quartier /(/the way.../) if it is a property of the 
district, or, if it is meant to indicate the date of the /Hofstallungen 
/renewal, it should probably go into a note of the 1937535 relation or we could 
use and document a "renewal_date=*" key (/there is already 1 usage for that, 
here: https://www.openstreetmap.org/relation/7255270/).

Cheers!

Sergio


On 2019-02-17 08:07, Stephan Bösch-Plepelits wrote:
> In the particular case which I was describing in the opening mail
> https://www.openstreetmap.org/relation/1937535
> the building is already a multipolygon relation.
>
> Do you think a relation with a multipolygon relation as member would work?
> Or would it be better to duplicate the multipolygon relation?


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] start_date variants

[Sergio Manzi]

Currently, and AFAIK, relations are the *only* solution for modeling situations 
like the one you described...

On 2019-02-17 00:40, Anton Klim wrote:
> not sure if relations are a good fix though


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] start_date variants

[Sergio Manzi]

Yeah. The "/other/" solution could be to "/namespace everything/", so you could 
tag building:whatever_property_key_you_want and 
amenity:whatever_property_key_you_want, applied to the very same object. But 
we're probably too late for that and apparently many seems to hate this latter 
solution.

On 2019-02-16 23:59, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 16. Feb 2019, at 23:49, Anton Klim  wrote:
>>
>> Like in the thread opening email, where there is an amenity that occupies 
>> the whole building, we put amenity tags on the outline. 
>
> I agree with Serge here, when there is a problem where it is not clear to 
> what the tags refer, it is usually a modeling problem of mixing different 
> things up in one object, and a better solution than creating more specific 
> tags by prefixing them, would be to fix the model. It will not end at 
> start_date ;-)
>
> Cheers, Martin 
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] start_date variants

[Sergio Manzi]

Then I guess the correct solution would be to not "stick" the amenity to the 
building but to a new relation whose only member will be the building itself.

One further benefit is that if the amenity goes you can delete the relation 
without disturbing the building...

Sergio


On 2019-02-16 23:49, Anton Klim wrote:
> Like in the thread opening email, where there is an amenity that occupies the 
> whole building, we put amenity tags on the outline. 
> I generally support adding more granularity to start_date, but feel like 
> start_date:* might fit better than *:start_date. 
>
> Anton Klim
>
>> 16 февр. 2019 г., в 21:40, Sergio Manzi  написал(а):
>>
>> Stephan, can you point to any such object in OSM where you find that 
>> ambiguity?
>>
>> I have the feeling that we could possibly discover a violation of the "One 
>> feature, one OSM element" principle [1] in there...
>>
>> Sergio
>>
>> [1] https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
>>
>>
>>> On 2019-02-16 22:01, Stephan Bösch-Plepelits wrote:
>>> My suggestion was to use a prefix "building:" if the start_date of the
>>> building differs from the start_date of the amenity. It is not very common
>>> though right now, with only 163 uses. Only 9 have both start_date and
>>> building:start_date.
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Waterway length

[Sergio Manzi]

Sorry for the typo: of course Wikip_*a*_dia was meant to be Wikip_*e*_dia!

On 2019-02-16 23:15, Sergio Manzi wrote:
> Then why don't you submit a paper to the CNFG (http://www.cnfg.fr/) and 
> correct the Wikipadia articles?
>
> Sergio
>
>
> On 2019-02-16 23:07, marc marc wrote:
>> Le 16.02.19 à 22:32, Sergio Manzi a écrit :
>>> A static value for a river length in OSM, without any information about 
>>> its source
>> every tag you add into osm have a changeset with a source tag, isn't it?
>> so adding the lenght should/must also have a source (extrapolation (sum 
>> of all way of a relation) of osm data is a source)
>>
>> a few month ago, I have checked the length of Rhône [1]
>> the french wikipedia list 2 sources for the lenght... both are very fair 
>> away of the lenght found after some work on osm data.
>> which one to choose? osm without hesitation. maybe it is not fair but at 
>> least it is verifiable (everyone can load the relationship, see the 
>> result and correct errors if necessary) while the other 2 sources 
>> (including the official French source) are totally unverifiable.
>>
>> unfortunately I did not send in osm the result of the cleaning because 
>> it concerned partly errors in osm (mainly roles in the relationship)
>> but I started by purging everything that didn't interest me in the 
>> relationship before fixing. it will have to be done again
>>
>> [1] https://en.wikipedia.org/wiki/Rh%C3%B4ne
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Waterway length

[Sergio Manzi]

Then why don't you submit a paper to the CNFG (http://www.cnfg.fr/) and correct 
the Wikipadia articles?

Sergio


On 2019-02-16 23:07, marc marc wrote:
> Le 16.02.19 à 22:32, Sergio Manzi a écrit :
>> A static value for a river length in OSM, without any information about 
>> its source
> every tag you add into osm have a changeset with a source tag, isn't it?
> so adding the lenght should/must also have a source (extrapolation (sum 
> of all way of a relation) of osm data is a source)
>
> a few month ago, I have checked the length of Rhône [1]
> the french wikipedia list 2 sources for the lenght... both are very fair 
> away of the lenght found after some work on osm data.
> which one to choose? osm without hesitation. maybe it is not fair but at 
> least it is verifiable (everyone can load the relationship, see the 
> result and correct errors if necessary) while the other 2 sources 
> (including the official French source) are totally unverifiable.
>
> unfortunately I did not send in osm the result of the cleaning because 
> it concerned partly errors in osm (mainly roles in the relationship)
> but I started by purging everything that didn't interest me in the 
> relationship before fixing. it will have to be done again
>
> [1] https://en.wikipedia.org/wiki/Rh%C3%B4ne
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] start_date variants

[Sergio Manzi]

Stephan, can you point to any such object in OSM where you find that ambiguity?

I have the feeling that we could possibly discover a violation of the "One 
feature, one OSM element" principle [1] in there...

Sergio

[1] https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element


On 2019-02-16 22:01, Stephan Bösch-Plepelits wrote:
> My suggestion was to use a prefix "building:" if the start_date of the
> building differs from the start_date of the amenity. It is not very common
> though right now, with only 163 uses. Only 9 have both start_date and
> building:start_date.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Waterway length

[Sergio Manzi]

TBH, I'm all with you (/and maybe I'm seen as an eccentric too.../) and I see 
the tagging of waterways length as egregiously useless.

Beside, I smell a lack of verifiability [1] in this waterways property: I'm not 
a geographer, by far, but in the years I made up my mind that this is one of 
those things that experts debate in their congresses and can be object of 
accademic thesis.

On the other hand a tool to compute the total length of waterways from their 
source (/once you have pinpointed it/) to their mouth (/again, once you have 
pinpointed it/), could be really interesting.

A static value for a river length in OSM, without any information about its 
source (/pun not intended, but valid anyway.../), is the kind of information I 
will usually route to /dev/null and for which I'll seek more autortiative 
sources (/again.../)

Sergio


[1] https://wiki.openstreetmap.org/wiki/Verifiability

On 2019-02-16 22:10, André Pirard wrote:
> It's easy to make a script to total up all the segments of a waterway or any 
> way.
> ...
> But I seem like not well understood or maybe seen as eccentric.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Waterway length

[Sergio Manzi]

On 2019-02-16 14:46, Eugene Podshivalov wrote:
> Calculated value may differ from the official one ...

Official according to whom?

From https://en.wikipedia.org/wiki/Nile#cite_note-length-1 :

/"The length of the Nile is usually said to be about 6,650 km (4,130 mi), 
but reported values lie anywhere between 5,499 km (3,417 mi) and 7,088 km 
(4,404 mi). The length measurements of many rivers are only approximations and 
differ from each other because there are many factors that determine the 
calculated river length, such as the position of the geographical source and 
the mouth, the scale of measurement, and the length measuring techniques"/

From https://en.wikipedia.org/wiki/Amazon_River :

"/The Amazon River ... in South America is the largest river by discharge 
volume of water in the world, and //*by some definitions*//it is the longest./" 
(/my emphasis/)

Encyclopedias are the preferred source for this kind of information, not maps 
(or GIS databases).

Sergio



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] start_date variants

[Sergio Manzi]

Actually building:buildyear is of much more widespread use than 
building:start_date:

  * https://taginfo.openstreetmap.org/keys/?key=building%3Abuildyear -> 2051 
objects
  * https://taginfo.openstreetmap.org/keys/?key=building%3Astart_date -> 163 
objects

that's a 12.6:1 proportion...

The key is documented in the IndoorOSM proposal [1] and in a wiki page of which 
I fail to understand the meaning [2].

Sergio


[1] https://wiki.openstreetmap.org/wiki/Proposed_features/IndoorOSM

[2] https://wiki.openstreetmap.org/wiki/Item:Q2952


On 2019-02-16 10:39, Anton Klim wrote:
> I believe there was an (failed? Undocumented?) attempt to make 
> building:buildyear a thing, but haven’t seen it used for a while. 


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 113, Issue 52 Co-ordinate sets vs. background informations = ODbL vs. CC

[Sergio Manzi]

Hello Richard,

That's a totally different approach, and a I completely agree with you (/for 
the very little that that may matter.../).

Before (/hopefully/) closing the incident, please let me clarify that I was 
just dissenting with _the tone_ of the reply in question.

Regards,

Sergio


On 2019-02-15 17:55, Richard Fairhurst wrote:
> Sergio Manzi wrote:
>> I strongly dissent with the tone of your mail.
>> Everybody, not only you and the most vocifeferous ones, have the right to
>> express 
>> their opinion.
> They do, but if the opinion is off-topic and unconstructive for the list and
> likely to divert from the purpose of said list, then the list
> admins/moderators are within their rights to ask the thread to stop, and
> that's what I'm doing here.
>
> Ulrich, your comments are seriously off-topic for the tagging@ list. If you
> would like to continue the argument then I would suggest you use the talk@
> list. It won't get you anywhere, but who am I to tell someone not to bang
> their head repeatedly against a wall.
>
> If you do so, please learn to participate in a threaded discussion, either
> by replying to individual messages (not digests) or by using a web interface
> like Nabble that permits you to do so. Thank you.
>
> Richard
> tagging@ list admin
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] StreetComplete 10 / foot=yes on residential

[Sergio Manzi]

+1!

On 2019-02-15 00:52, Joseph Eisenberg wrote:
> I believe this is the wrong question. It should be “Are pedestrians legally 
> prohibited from walking along this road?”
>
> If so, use foot=no



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 113, Issue 52 Co-ordinate sets vs. background informations = ODbL vs. CC

[Sergio Manzi]

On a mailing list, in a community, I can't imagine anything more rude and 
divisive than *publicly* telling someone that he can go away if he don't like 
things the way you (/and others, even the majority indeed/) like it, and that 
you are considering to block him/her *just for the opinions she/she express* 
(/mind you, not for the way he/she express it.../).


On 2019-02-14 14:02, Paul Allen wrote:
> On Thu, 14 Feb 2019 at 12:34, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
> I strongly dissent with the tone of your mail.
>
> That is your right.  Even if you are strongly dissenting about somebody 
> expressing strong
> dissent, it is your right.
>
> Everybody, not only you and the most vocifeferous ones, have the right to 
> express their opinion.
>
>
> Indeed.  I strongly support everyone's right to express their opinion.  As 
> far as I am concerned,
> you can say whatever you want.  But you cannot force me, or anyone else, to 
> listen.  Interacting
> with others in a way that stops them listening to you is not an effective way 
> of getting your point
> across.  YMMV.
>
> You can dissent, but the tone of your mail is definitely rude and 
> divisive.
>
> Rude???  I refrained from giving my opinion of the guy (which is something 
> most people
> would consider to be extremely negative) and merely told him what options were
> available to him since he is dissatisfied with the current situation.  The 
> OSM community
> has given a great deal of thought to copyright issues to arrive at their 
> position and I don't
> see much chance of them moving to his position, a position they explicitly 
> state is (in
> their opinion) not tenable.
>
> His only feasible options are to live with what we have, stop mapping, set up 
> a competing project,
> or continue to rant incomprehensibly here.  Should he continue to rant here 
> then he's likely to
> end up in killfiles.  Telling him that isn't rude, it's advising him that he 
> is not doing himself any
> favours with his current behaviour.
>
> Think twice.
>
> I thought three times before I posted.  You would certainly have thought the 
> second version of my
> post to be extremely rude.  And you would have had a conniption fit over the 
> first version.  What I
> actually posted refrained from rebuking him and instead offered a stark, 
> unadorned explanation
> of the options open to him.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 113, Issue 52 Co-ordinate sets vs. background informations = ODbL vs. CC

[Sergio Manzi]

I strongly dissent with the tone of your mail.

Everybody, not only you and the most vocifeferous ones, have the right to 
express their opinion.

You can dissent, but the tone of your mail is definitely rude and divisive.

Think twice.

Regards,

Sergio


On 2019-02-14 12:45, Paul Allen wrote:
> On Thu, 14 Feb 2019 at 09:13, Ulrich Lamm  > wrote:
>
> Am 12.02.2019 um 05:59 schrieb tagging-requ...@openstreetmap.org 
> :
>
> Rules according to the interests of commercial exploiters make our 
> mapping an unpaid labour for some landlords. 
> That is the opposite of freedom.
>
>
> You have the freedom not to map.  Nobody is forcing you to participate in a 
> project that you
> fundamentally disagree with.
>
> You have the freedom to set up your own alternative to OSM with your own 
> rules about permissible
> imports.  If you can justify it within your own tortured logic about 
> copyright, you can even use the
> OSM database as a foundation for your efforts.
>
> The rest of us have the freedom to set mail filters so your messages go 
> straight to the bit
> bucket, unread.  I don't know about others, but that option looks 
> increasingly tempting to me.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Micronations

[Sergio Manzi]

There is something really wrong going on around that bogus micronation: more 
than half of Harmony Way (from the crossing with Allens Lane to the one with 
Mont Vernon Avenue) has disappeared, leaving many other ways isolated (e.g. 
Rose Avenue and Walnut Hills Drive).

Beside, the f..ing thing is still visible at some Z values.

Is someone looking at this?

Cheers

Sergio


On 2019-02-10 01:39, Graeme Fitzpatrick wrote:
>
> On Sun, 10 Feb 2019 at 05:42, Simon Poole  > wrote:
>
> The user in question has already been blocked and at least their initial 
> changesets were reverted 2 months ago. Naturally any remaining fictional 
> edits should be reverted too and the user reported again to tho DWG.
>
>
> Thanks Simon
>
> The whole thing is still there as of yesterday, so something either didn't 
> work, or they're very persistent!
>
> Message has been forwarded to DWG for action.
>
> Thanks


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Micronations

[Sergio Manzi]

True, but I'm quite sure it is more difficult to fake Google Maps: some time 
ago I had to register an entry in Google Maps and I went through a quite secure 
mechanism that involved Google sending back to the registered address a 
postcard (yes, a piece of paper) with a confirmation code printed on it that I 
had to use to confirm the entry. I don't know if they still use that mechanism. 
If yes, it is admirable.

The BBC article too talks about a verification process. A SNAFU at the school's 
principal office?

Again, my uttermost concern is how to evitate to fall into a "fake maps" era, 
after the "fake news" one...

Sergio


On 2019-02-09 21:16, Paul Allen wrote:
> On Sat, 9 Feb 2019 at 19:48, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
> But, yes, "there is /something/ out there": Google too report the 
> existence of a "Pitchfork Union" POI [1] [2].
>
>
> Google is not immune from vandalism.  As this recent report by the BBC shows:
> https://www.bbc.co.uk/news/uk-england-humber-47118901  And while the name of 
> the nearby
> chip shop seems suspicious, it is apparently correct.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Micronations

[Sergio Manzi]

The thing is quite obviously fruit of immagination, creativity, and/or 
delusion: there surely isn't out there such a concoction of toll booths (/many 
of them/), bunkers, town halls, dams, towers, campgrounds, etc.

The creator's name too, "landhahaha", is also an hint for a probable vandalism.

But, yes, "there is /something/ out there": Google too report the existence of 
a "Pitchfork Union" POI [1] [2].  I really don't know what that could be. My 
bet is on some kind of elaborate prank, maybe even something funny, but again 
I'm ready to bet that those detailed micronation's features are not to be found 
on the ground.

And that concerns me a lot, because it is really hard not thinking what 
implications events like this can have on the reliable availability of OSM 
data/services.

Sergio


[1] 
https://www.google.com/maps/place/Pitchfork+Union/@38.0057611,-87.6230528,17.47z/data=!4m13!1m7!3m6!1s0x8871d5133156772d:0xb52e4939112ac99d!2sEvansville,+IN,+USA!3b1!8m2!3d37.9715592!4d-87.5710898!3m4!1s0x8871d3a41e3edbcb:0x36d89880f9e4b0c6!8m2!3d38.0055153!4d-87.6223733?hl=en

[2] 
https://www.google.com/maps/@38.0053737,-87.6226287,3a,75y,90t/data=!3m8!1e1!3m6!1sAF1QipNc0Cno_lNKO_O8oyna_8ihGVTkuy_RQoo1oceA!2e10!3e11!6shttps:%2F%2Flh5.googleusercontent.com%2Fp%2FAF1QipNc0Cno_lNKO_O8oyna_8ihGVTkuy_RQoo1oceA%3Dw203-h100-k-no-pi2.3155072-ya316.65625-ro1.7720242-fo100!7i5376!8i2688?hl=en


On 2019-02-09 18:28, ael via Tagging wrote:
> On Sat, Feb 09, 2019 at 06:20:11PM +1100, Warin wrote:
>> On 09/02/19 16:18, Mark Wagner wrote:
>>> On Sat, 9 Feb 2019 10:54:16 +1000
>>> Graeme Fitzpatrick  wrote:
>>>
 https://www.openstreetmap.org/way/653287455#map=15/38.0034/-87.6183
>> In this case they have been mapped as a 'residential area' with that name ...
>> The basic question is ... is that area residential?
> But note the user name: it does suggest vandalism.
>
> ael
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] motorcycle:scale

[Sergio Manzi]

I don't really know where I was at that times, mostly because I don't know when 
that times where, honestly. Should I feel ashamed?

I wasn't criticizing the rationale for having a better wording for the status 
of that kind of "/debatable/" tags, but only the wording you proposed.

Cheers,

Sergio


On 2019-02-07 14:48, Paul Allen wrote:
> On Thu, 7 Feb 2019 at 13:23, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
> "/ad hoc/" (for this)  signifies a solution designed for a specific 
> problem or task, non-generalizable, and not intended to be able to be adapted 
> to other purposes.
>
> "/extempore/" (or more correctly "/ex tempore/", "from the time") means 
> something done without preparation or forethought, as if prompted by the 
> spirit of the moment.
>
> "/impromptu/", improvisation, has more or less the same meaning as "/ex 
> tempore/".
>
> I don't see how how the above could be seen as substitutes for "in use" 
> or any other OSM tags status...
>
> Were you here when we discussed landuse=clearing that somebody found used 
> (presumably
> by a HOT mapper)?  Used only a handful of times.  It had not been proposed 
> and accepted, or
> proposed and rejected.  It was not widely used.  It was something that 
> somebody had made up
> on the spot from lack of knowledge about the correct way to deal with it.  
> The wiki should
> probably document and deprecate it, for the benefit of anyone who finds it on 
> taginfo and
> would otherwise assume it to be acceptable.
>
> But there are other de novo tags which don't have existing alternatives, 
> haven't been through a
> proposal process and are not widely used.  "In use" implies fairly wide 
> usage.  Otherwise
> anyone can invent a tag (however silly) use it once and document it in the 
> wiki as "in use."  I
> doubt that is a good way to go.  Nor is leaving such things undocumented else 
> we're likely
> to end up with dozens of alternative tags for the same thing.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] motorcycle:scale

[Sergio Manzi]

"/ad hoc/" (for this)  signifies a solution designed for a specific problem or 
task, non-generalizable, and not intended to be able to be adapted to other 
purposes.

"/extempore/" (or more correctly "/ex tempore/", "from the time") means 
something done without preparation or forethought, as if prompted by the spirit 
of the moment.

"/impromptu/", improvisation, has more or less the same meaning as "/ex 
tempore/".

I don't see how how the above could be seen as substitutes for "in use" or any 
other OSM tags status...

Sergio


On 2019-02-07 14:02, Paul Allen wrote:
> On Thu, 7 Feb 2019 at 12:12, Dave Swarthout  > wrote:
>
>
> I like the idea of the "informal" category but isn't that more or less 
> the same as "proposed"?
>
>
> The proposal process is formal.  It's documented, people scream at you if you 
> don't do it exactly
> right, etc.  Doesn't matter if the tag gets approved or not, the proposal 
> process is formal.
> "Informal" means "make it up as you need it."  Or, as I said, ad hoc.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] edit war about deletion of proposal

[Sergio Manzi]

done!

On 2019-02-05 22:47, Richard wrote:
> On Tue, Feb 05, 2019 at 01:25:34PM -0800, Tod Fitch wrote:
>> Another +1
>>
>> That wiki page [1] should be reverted back to its prime, no need for it to 
>> be labeled for deletion.
>>
>> [1] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dbikeshed
> just do it.. I do not want further edit warring with the particular user but 
> if anyone contests the deletion request I think it should be just reverted.
> If anyone still wants to delete the page it can go through a deletion 
> proposal 
> procedure.
>
> Richard
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] edit war about deletion of proposal

[Sergio Manzi]

+1!! :-)

On 2019-02-05 21:57, Kevin Kenny wrote:
> Oh, please bring back amenity=bikeshed!  I hadn't seen it before, and
> it's hilarious!
>
> (Unless we have a rule that the Wiki shall be devoid of the least
> indication that mappers have a sense of humour...)



smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Drain vs ditch

[Sergio Manzi]

Thank-you for confirming that, Mark.

Personally I think we, in OSM, should stop with this folly of overloading 
English words with meanings they do not have in *any *dictionary (be it AmE, 
BrE, CaE, or whatever).

Both the "ditch" and "drain" words *can *be used to describe certain features 
in English. The difference is essentially an etymological one, with one related 
to the *process *of excavation (dig -> ditch) and the other to the *function 
*of carrying liquids away (dry -> drain).

If we want to precisely map certain characteristics of a feature we should do 
it explicitly through a *correct data model* that takes into consideration the 
particular aspect we are trying to communicate. We want to communicate the 
information that a (small) waterway is lined with concrete? Just say that with 
an appropriate tag, like e.g. lined=*, or lining=*. We want to communicate the 
information that a (small) waterway is used to carry waste water away? Once 
again, let's say that with an appropriate tag, like e.g. usage=* (/please 
ignore if the specific tags I put in the examples are not of your liking: not 
the point here, let's discuss that later.../).

Arbitrarily overloading words with meanings they do not have in the common 
language is just a perfect way to Babel, that is a reduction in information.

Sergio


On 2019-02-02 09:22, Mark Wagner wrote:
> My copy of the Oxford English Dictionary has about a page of
> definitions for "ditch" and "drain", and not a hint that either of them
> needs to be lined.
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Drain vs ditch

[Sergio Manzi]

I know, that's why I asked for a good one...

On 2019-02-02 01:23, Joseph Eisenberg wrote:
> Dictionary.com usually provides definitions in American English, so it 
> wouldn’t be a good source.
>
> On Sat, Feb 2, 2019 at 8:35 AM Sergio Manzi  <mailto:s...@smz.it>> wrote:
>
> Please point me to a dictionary defining "drain" as a "lined ditch" or in 
> any way stating that a drain must be lined, because I tried and I failed.
>
> Best I found is in dictionary.com <http://dictionary.com>  that (/under 
> /"/Physical Geography/") define it as
>
>  1. an artificial watercourse, as a ditch or trench.
>  2. a natural watercourse modified to increase its flow of water.
>
>
> On 2019-02-01 23:46, Paul Allen wrote:
>> On Fri, 1 Feb 2019 at 22:43, Sergio Manzi > <mailto:s...@smz.it>> wrote:
>>
>> So, how do you tag drains which are not lined?
>>
>>
>> Ditch.   Because, physically, that's what it is.
>>
>> -- 
>> Paul
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/tagging
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Drain vs ditch

[Sergio Manzi]

Please point me to a dictionary defining "drain" as a "lined ditch" or in any 
way stating that a drain must be lined, because I tried and I failed.

Best I found is in dictionary.com  that (/under /"/Physical Geography/") define 
it as

 1. an artificial watercourse, as a ditch or trench.
 2. a natural watercourse modified to increase its flow of water.


On 2019-02-01 23:46, Paul Allen wrote:
> On Fri, 1 Feb 2019 at 22:43, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
> So, how do you tag drains which are not lined?
>
>
> Ditch.   Because, physically, that's what it is.
>
> -- 
> Paul
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Drain vs ditch

[Sergio Manzi]

Right in these days you can read in the Italian newspapers of an industry 
having contaminated with industrial sewage an area inhabited by 300.000...

And let's not get started with what we /"westerns" /normally call "the third 
world"...

So, how do you tag drains which are not lined?


On 2019-02-01 23:34, Paul Allen wrote:
> Then again, I would hope an industrial drain would be lined.


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Drain vs ditch

[Sergio Manzi]

I'm pretty sure that's the case in UK, but are you willing to bet on all drains 
(/e.g. industrial/) of the world being lined?

On 2019-02-01 23:22, Paul Allen wrote:
> On Fri, 1 Feb 2019 at 22:09, Sergio Manzi mailto:s...@smz.it>> 
> wrote:
>
> If you think it is important to differentiate between lined vs. unlined 
> minor waterways (/and I'm not objecting to that/), I guess the best option 
> would be to use a specific tag (lined=* ?)
>
> As I understand it, Ordnance Survey maps in the UK make a distinction between 
> ditches
> and drains.  Of course, printed maps don't have the luxury of sub-tags, so we 
> don't have
> to use ditch and drain just because OS does.  However, ditch and drain are 
> already
> established.
>
> -- 
> Paul


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Drain vs ditch

[Sergio Manzi]

If you think it is important to differentiate between lined vs. unlined minor 
waterways (/and I'm not objecting to that/), I guess the best option would be 
to use a specific tag (lined=* ?)

IMHO relying on the tagger knowledge of the OSM dictionary semantic subtleties 
(/which sometimes happen to collide with other English dictionaries/) is a bit 
too optimistic.

Sergio


On 2019-02-01 22:50, Graeme Fitzpatrick wrote:
> On Fri, 1 Feb 2019 at 11:51, Warin <61sundow...@gmail.com 
> > wrote:
>
> It appears in the descriptions that a 'ditch' can be used as a 'drain'. 
> So why have a tag 'drain'?
>
>
> Really only to differentiate between lined & unlined, which I /think/ may be 
> important / needed?
>
> Thanks
>
> Graeme


smime.p7s
Description: S/MIME Cryptographic Signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging