date:20200928

On Mon, Sep 28, 2020 at 8:02 PM Brian May  wrote:
>
> I'm Florida based, have seen Floridaeditor's changes and noticed an eagerness 
> to change a lot of road classifications. I didn't pay a lot of attention 
> until now. Of course, trunk can be a tricky one, but if you got one lone guy 
> on a mission who is arguing with everyone along the path, reverting any 
> differences of opinion, etc - that is getting abusive and needs to stop. It 
> is certainly NE2ish behavior. Other than NE2s behavior towards people who 
> didn't agree and subsequent banning, he taught me a good bit, did a lot of 
> good for FL and was actually inspirational in the beginning of my OSM journey 
> showing what was possible and the impact a prolific editor could have. Sucks 
> that he couldn't play well with others. Pretty sure he was based out of 
> Orlando. Floridaeditor started editing in the Melbourne area not far from 
> Orlando. His editing behavior is somewhat similar to NE2 in that they are / 
> was editing a fairly wide variety of feature types. Also a focus on highway 
> types in many other states and forcefully arguing with others in other states 
> / local stomping grounds.
>
> Anywho, seems like collective wisdom should rule the day with most things 
> OSM, right? Especially long-time editors who have been through the wilderness 
> and put a lot of thought into how features be mapped and tagged. And 
> importantly are engaging with others in a respectful way.
>
> An example unhelpful comment:
>
> "YES GEORGIA IS BADLY-TAGGED TRUNK FREE! Control is provided by 
> floridaeditor; i.e., if anybody tries to change one back I will review the 
> edit and keep/revert as needed."
>
> WTF
>
> Brian aka grouper

That is one of several of his comments that convinces me he doesn't
really want to work with the community.


> On 9/28/2020 7:29 PM, Evin Fairchild wrote:
>
> I totally support reverting Floridaeditor's changes in order to restore all 
> these divided highways to trunk status. I believe that floridaeditor has been 
> given the opportunity to participate in this discussion, right?

He has been invited here, to Slack, and the OSM web forum by no less
than 3 different people (and maybe more--I haven't examined all of his
changesets).

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Brian May

I'm Florida based, have seen Floridaeditor's changes and noticed an 
eagerness to change a lot of road classifications. I didn't pay a lot of 
attention until now. Of course, trunk can be a tricky one, but if you 
got one lone guy on a mission who is arguing with everyone along the 
path, reverting any differences of opinion, etc - that is getting 
abusive and needs to stop. It is certainly NE2ish behavior. Other than 
NE2s behavior towards people who didn't agree and subsequent banning, he 
taught me a good bit, did a lot of good for FL and was actually 
inspirational in the beginning of my OSM journey showing what was 
possible and the impact a prolific editor could have. Sucks that he 
couldn't play well with others. Pretty sure he was based out of Orlando. 
Floridaeditor started editing in the Melbourne area not far from 
Orlando. His editing behavior is somewhat similar to NE2 in that they 
are / was editing a fairly wide variety of feature types. Also a focus 
on highway types in many other states and forcefully arguing with others 
in other states / local stomping grounds.

Anywho, seems like collective wisdom should rule the day with most 
things OSM, right? Especially long-time editors who have been through 
the wilderness and put a lot of thought into how features be mapped and 
tagged. And importantly are engaging with others in a respectful way.

An example unhelpful comment:

    "YES GEORGIA IS BADLY-TAGGED TRUNK FREE! Control is provided by 
floridaeditor; i.e., if anybody tries to change one back I will review 
the edit and keep/revert as needed."

WTF

Brian aka grouper

On 9/28/2020 7:29 PM, Evin Fairchild wrote:
I totally support reverting Floridaeditor's changes in order to 
restore all these divided highways to trunk status. I believe that 
floridaeditor has been given the opportunity to participate in this 
discussion, right?

On Mon, Sep 28, 2020, 3:54 PM Jack Burke > wrote:

On Mon, Sep 28, 2020 at 3:15 PM Evin Fairchild
mailto:evindf...@gmail.com>> wrote:
>
> We've always tagged non interstate freeways as motorways. They
are often designed to interstate standards and there is literally
no distinction between them and interstate freeways except that
there's no interstate shield.
>
> As for Floridaeditor's edits, I noticed him doing this awhile
ago, but didn't really feel like doing anything. Glad someone is
sending him and trying to get this resolved. Many of his
downgrading from Trump to primary were completely unjustified.

Throughout this entire discussion, it sounds like there's pretty good
agreement that trunk is perfectly acceptable to use as a road
classification in OSM for the eastern US, and at least some general
agreement that the examples I cited are reasonable examples of trunk
roads?  Am I mis-interpreting anyone?

And also, that I'm not the only one who's very much disturbed by
floridaeditor's changes?

Does anyone have a strong problem if I continue going through Georgia
and reversing most of his trunk-to-primary changes?

--jack

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Evin Fairchild

I totally support reverting Floridaeditor's changes in order to restore all
these divided highways to trunk status. I believe that floridaeditor has
been given the opportunity to participate in this discussion, right?

On Mon, Sep 28, 2020, 3:54 PM Jack Burke  wrote:

> On Mon, Sep 28, 2020 at 3:15 PM Evin Fairchild 
> wrote:
> >
> > We've always tagged non interstate freeways as motorways. They are often
> designed to interstate standards and there is literally no distinction
> between them and interstate freeways except that there's no interstate
> shield.
> >
> > As for Floridaeditor's edits, I noticed him doing this awhile ago, but
> didn't really feel like doing anything. Glad someone is sending him and
> trying to get this resolved. Many of his downgrading from Trump to primary
> were completely unjustified.
>
>
> Throughout this entire discussion, it sounds like there's pretty good
> agreement that trunk is perfectly acceptable to use as a road
> classification in OSM for the eastern US, and at least some general
> agreement that the examples I cited are reasonable examples of trunk
> roads?  Am I mis-interpreting anyone?
>
> And also, that I'm not the only one who's very much disturbed by
> floridaeditor's changes?
>
> Does anyone have a strong problem if I continue going through Georgia
> and reversing most of his trunk-to-primary changes?
>
> --jack
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

On Mon, Sep 28, 2020 at 3:15 PM Evin Fairchild  wrote:
>
> We've always tagged non interstate freeways as motorways. They are often 
> designed to interstate standards and there is literally no distinction 
> between them and interstate freeways except that there's no interstate shield.
>
> As for Floridaeditor's edits, I noticed him doing this awhile ago, but didn't 
> really feel like doing anything. Glad someone is sending him and trying to 
> get this resolved. Many of his downgrading from Trump to primary were 
> completely unjustified.

Throughout this entire discussion, it sounds like there's pretty good
agreement that trunk is perfectly acceptable to use as a road
classification in OSM for the eastern US, and at least some general
agreement that the examples I cited are reasonable examples of trunk
roads?  Am I mis-interpreting anyone?

And also, that I'm not the only one who's very much disturbed by
floridaeditor's changes?

Does anyone have a strong problem if I continue going through Georgia
and reversing most of his trunk-to-primary changes?

--jack

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-cr] Añadir alertas según CNE al mapa de OSM

2020-09-28 Thread Jaime Gutiérrez Alfaro

Hola compas,

Como parte de la propuesta le añadimos la etiqueta `alert:cne` a los
cantones y algunos distritos. A más tardar el domingo 04 de octubre
eliminaré la etiqueta de estos objetos.

Pura vida,
Jaime.

On Mon, Aug 24, 2020 at 6:35 PM Rodolfo Quesada Zumbado 
wrote:

> La herramienta fue un script muy feo y hecho a la carrera en Python,
> tomando los CSV con los datos de Overpass y generando Wiki markup.  Para la
> tabla total nada más hay que tener cuidado de usar bien el atributo rowspan
> en las Provincias y Cantones con contadores de Distritos.  Para las tablas
> separadas es una generación sencilla, a punta de print() para cada row del
> CSV. :)
>
> Dejemos la columna de notas por ahora, cierto que hay una hoy, pero ya
> Jaime me mencionaba que algunos distritos tienen varios atributos mal
> (duplicidad de admin_centre, etc).  Se puede usar para esas eventualidades,
> si no pasa nada yo la quito en unos dos o cinco años. :P
>
> Ahora que lo menciona, si sería bueno tener un TODO list en el Wiki. :D
>
> On Mon, Aug 24, 2020, at 16:22, Wolter H. V. wrote:
> > [2020-08-24 15:32 -0600] Rodolfo Quesada Zumbado:
> > > Sobre la tabla de unidades administrativas, el Domingo 23 de Agosto
> re-acomodé la información de las unidades administrativas, quité la tabla
> incompleta en el wiki principal, y agregué tablas individuales para
> Provincias, Cantones y Distritos con sus respectivos códigos
> administrativos/postales (para no recargar la tabla grande jerárquica), y
> columna de notas, con la notita de que nos falta sólo un distrito
> (Cabeceras, segregado este 2020 de Quebrada Grande en Tilarán).
> > >
> > > [✓] Tarea terminada.
> >
> > Heróico, eso de separar las tablas me parece genial. Solo por
> > curiosidad, qué herramienta usó para crear la tabla? No creo que lo
> > haya hecho a mano jajaj.
> >
> > De hecho, en vista de que la columna de notas sólo se utiliza una vez
> > tomando en cuenta las tres tablas, propongo eliminarla. La nota sobre
> > Cabeceras podría ir en el mismo campo de la relación, o podría no
> > existir y la tarea podría ser puesta en alguna cola de cosas por hacer.
> >
> > Saludos,
> > Wolter H. V.
> >
> >
> > ___
> > Talk-cr mailing list
> > Talk-cr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cr
> >
>
> --
> Rodolfo Quesada Zumbado
>
> ___
> Talk-cr mailing list
> Talk-cr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cr
>
___
Talk-cr mailing list
Talk-cr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cr

Re: [OSM-talk-fr] Serveur Discord créé

2020-09-28 Thread Jacques Lavignotte


+1.


Le 28/09/2020 à 22:11, Romain MEHUT a écrit :

Bonsoir,

J'ai été contacté par la messagerie interne d'osm.org pour y participer 
mais j'ai décliné la proposition en raison notamment des éléments 
décrits sur Wikipedia https://fr.wikipedia.org/wiki/Discord_(logiciel)


Romain

Le 27/09/2020 à 16:10, Emilie Laffray a écrit :

Bonjour tout le monde,

juste un petit passage pour signaler que quelqu'un a créé un serveur 
discord pour la communauté OpenStreetMap Fr.

L'utilisateur s'appelle Khryashch#1881.
Voila le lien https://discord.gg/wxNGfdT

Pour ceux qui ne connaissent pas Discord, c'est une sorte de IRC 
moderne avec persistance des discussions et la possibilité de faire du 
vocal/vidéo facilement.
C'est surtout utilisé à la base pour faciliter les communaute de 
gamers et ca touche a des gens un peu plus jeune généralement pour qui 
IRC est un truc un peu abscon :)


Voila voila,
Emilie Laffray

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Evin Fairchild

Oh lol, I didn't even realize my phone autocorrected trunk to Trump. Oops!
xD

On Mon, Sep 28, 2020, 12:21 PM Kevin Kenny  wrote:

> On Mon, Sep 28, 2020 at 3:15 PM Evin Fairchild 
> wrote:
> > Many of his downgrading from Trump to primary were completely
> unjustified.
>
> Oh, $LC_DEITY, autocorrupt in 2020!  (I'd have loved to have
> downgraded Trump in the primary, but this year he was unopposed.)
>
> Yeah, I know, you meant 'trunk'.
> --
> 73 de ke9tv/2, Kevin
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Web-SIG du Pays Terres de Lorraine

2020-09-28 Thread Romain MEHUT


Bonsoir à tous les deux,

Suite à mon message sur talk-fr 
https://lists.openstreetmap.org/pipermail/talk-fr/2020-September/101373.html 
je vous contacte pour vous demander s'il y a un espace de discussion du 
groupe AITF SIG-TOPO ?


Merci.

Romain

Le 28/09/2020 à 22:19, Romain MEHUT a écrit :


Bonsoir,

Une information complémentaire, je devrais avoir prochainement un 
nouveau rendez-vous avec la personne qui gère le SIG en question.


Donc je suis toujours preneur de retour d'expérience côté collectivité.

Merci d'avance.

Romain

Le 27/09/2020 à 23:05, pepilepi...@ovh.fr a écrit :

Le 27/09/2020 à 21:17, osm.sanspourr...@spamgourmet.com a écrit :

Le 27/09/2020 à 14:21, Romain MEHUT - romain.me...@mailo.com a écrit :

J'en viens donc à vous, auriez-vous connaissance de web-SIG grand
public où les données OSM seraient exploitées pour justement éviter
cet écueil ? Tony peut être avec la CCPRO ?


GéoBretagne avec ÇaResteOuvert par exemple :

https://cms.geobretagne.fr/content/commerces-de-premiere-necessite-ouverts 

 
  --



Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé 
la bonne question.



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Web-SIG du Pays Terres de Lorraine

2020-09-28 Thread Romain MEHUT


Bonsoir,

Une information complémentaire, je devrais avoir prochainement un 
nouveau rendez-vous avec la personne qui gère le SIG en question.


Donc je suis toujours preneur de retour d'expérience côté collectivité.

Merci d'avance.

Romain

Le 27/09/2020 à 23:05, pepilepi...@ovh.fr a écrit :

Le 27/09/2020 à 21:17, osm.sanspourr...@spamgourmet.com a écrit :

Le 27/09/2020 à 14:21, Romain MEHUT - romain.me...@mailo.com a écrit :

J'en viens donc à vous, auriez-vous connaissance de web-SIG grand
public où les données OSM seraient exploitées pour justement éviter
cet écueil ? Tony peut être avec la CCPRO ?


GéoBretagne avec ÇaResteOuvert par exemple :

https://cms.geobretagne.fr/content/commerces-de-premiere-necessite-ouverts 

 



Avec les débits de boisson sur Marseille, CRO ferme.

En fait non, ne va-t-il pas falloir réactiver CRO ? :-(

CRO ou Kro ?


Mais avant il faut sans doute nettoyer ce qui est encore présent.

Jean-Yvon



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



--


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé 
la bonne question.



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Serveur Discord créé

2020-09-28 Thread Romain MEHUT


Bonsoir,

J'ai été contacté par la messagerie interne d'osm.org pour y participer 
mais j'ai décliné la proposition en raison notamment des éléments 
décrits sur Wikipedia https://fr.wikipedia.org/wiki/Discord_(logiciel)


Romain

Le 27/09/2020 à 16:10, Emilie Laffray a écrit :

Bonjour tout le monde,

juste un petit passage pour signaler que quelqu'un a créé un serveur 
discord pour la communauté OpenStreetMap Fr.

L'utilisateur s'appelle Khryashch#1881.
Voila le lien https://discord.gg/wxNGfdT

Pour ceux qui ne connaissent pas Discord, c'est une sorte de IRC 
moderne avec persistance des discussions et la possibilité de faire du 
vocal/vidéo facilement.
C'est surtout utilisé à la base pour faciliter les communaute de 
gamers et ca touche a des gens un peu plus jeune généralement pour qui 
IRC est un truc un peu abscon :)


Voila voila,
Emilie Laffray

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

Op ma 28 sep. 2020 om 20:55 schreef Dave F via Talk-GB
:
>
> On 28/09/2020 17:53, Dan S wrote:
> > Hi Rodrigo
> >
> > I think Loomio is designed
> > for the purpose of making good decisions together:
>
> Come again? Why do you think "good decisions" can't be made here? What
> do those who don't wish to join yet another off-shoot do?

Please, Dave, try not to be so shocked by everything. Email is a tool.
Loomio is a tool. Mediawiki is a tool. The designers of Loomio tried
to create a tool specifically for group decision-making. That's all!

Best
Dan

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites


On 28/09/2020 17:53, Dan S wrote:

Hi Rodrigo

I think Loomio is designed
for the purpose of making good decisions together:


Come again? Why do you think "good decisions" can't be made here? What 
do those who don't wish to join yet another off-shoot do?


DaveF


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Kevin Kenny

On Mon, Sep 28, 2020 at 3:15 PM Evin Fairchild  wrote:
> Many of his downgrading from Trump to primary were completely unjustified.

Oh, $LC_DEITY, autocorrupt in 2020!  (I'd have loved to have
downgraded Trump in the primary, but this year he was unopposed.)

Yeah, I know, you meant 'trunk'.
-- 
73 de ke9tv/2, Kevin

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Evin Fairchild

We've always tagged non interstate freeways as motorways. They are often
designed to interstate standards and there is literally no distinction
between them and interstate freeways except that there's no interstate
shield.

As for Floridaeditor's edits, I noticed him doing this awhile ago, but
didn't really feel like doing anything. Glad someone is sending him and
trying to get this resolved. Many of his downgrading from Trump to primary
were completely unjustified.

On Mon, Sep 28, 2020, 11:57 AM Matthew Woehlke 
wrote:

> On 28/09/2020 12.27, Paul Johnson wrote:
> > On Mon, Sep 28, 2020 at 11:07 AM Matthew Woehlke wrote:
> >> On 28/09/2020 11.42, Jack Burke wrote:
> >>> I'm willing to bet that most OSM editors who drive on either of those
> two
> >>> will think "this is a great freeway, just with occasional traffic
> >> signals."
> >>
> >> That's an oxymoron. Freeways are, by definition, limited access (no
> >> crossing intersections, period) and do not have (permanent¹) signs or
> >> signals to halt traffic. IMNSHO, if it has traffic lights, stop signs,
> >> or the possibility of vehicles suddenly driving *across* the way, it
> >> isn't a freeway.
> >
> > True, but highway=trunk can mean either expressways (think like freeways
> > that have some or all at-grade intersections; note that having
> > freeway-style ramps in between junctions doesn't make it a
> > highway=motorway), or single-carriageway freeways.  In both cases, they
> > tend to get built as an incremental case to building a full motorway, but
> > are not yet motorways.
>
> We're getting dangerously into the territory of words with ambiguous
> meanings. Note https://en.wiktionary.org/wiki/freeway, especially the
> first definition. Note also my point was about "freeways", not
> highway=trunk. Many in the US would consider "freeway" and
> highway=motorway to be nearly synonymous. (The "nearly" is when we start
> talking about non-interstate limited access.)
>
> I did later state that limited access is *not* a requirement for
> highway=trunk.
>
> Also, Jack has clarified his usage as "artistic"...
>
> > That's not to say there aren't non-interstate highways that meet these
> >> definitions.
> >>
> >> But... is it a highway=trunk? *I* don't see where the wiki excludes the
> >> possibility. (It does, however, seem to me that only *actual* interstate
> >> freeways should be highway=motorway in the US.)
> >
> > That's not true at all...
>
> Citation needed. I don't think that's been established (although we're
> getting pretty off-topic...). The *converse*, sure (interstate =/>
> motorway), I'll concede that.
>
> > [...] the transitions to where an interstate ends and it continues as
> > another kind of highway past the last exit before a junction,
> I would question whether those should be highway=motorway. (Yes, I'm
> looking at https://www.openstreetmap.org/way/98245488 and surrounding,
> possibly as far north as https://www.openstreetmap.org/node/41485037.)
>
> --
> Matthew
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Richard Welty

On 9/28/20 12:39 PM, Jack Burke wrote:

> Related: if it's I-## or I-###, shouldn't it be a highway=motorway,
> period? (Unless those, for some reason, are ever *not* freeways?)

in the lower 48, most of the time an Interstate designation is a
motorway. but there can be exceptions. and in Alaska and Hawaii, the
roads have to be examined on a case by case basis. congress choose to
give those two states latitude so they could get funds from the program
even though they were unlikely to actually build real "motorways".

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

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Kevin Kenny

1. I agree with Paul that the US definitely does have trunk roads.
High-speed dual carriageways with some grade crossings, or 'super
twos,' both qualify. (See (3) for the counterargument about
'importance to the highway network.')

2. The network and route number do not reliably identify the highway
class. New York has unnumbered roads, state highways, and US highways,
that are definitely freeways, There is at least one section of
Interstate that is not a freeway, but rather a 'super two'. US
Highways can be anything from unclassified or tertiary (there are some
US highways that the world has bypassed, but retain the designation
for historical reasons) to freeway. New York's numbered state highways
all appear to be at least secondary, but some are primaries, trunks or
motorways.

3. While the 'highway=*' designation is supposed to denote 'importance
to the highway system', the road characteristics (surface, lanes,
speed limit, ...) are useful surrogates. Highway administrators who
commission multi-lane divided highways that don't provide a major
connection in the network, or elevate crossings on low-traffic roads,
tend to get tarred and feathered by the taxpayers, so the road
characteristics tend to provide a lower bound on the highway class.
It's not a hard upper bound; in some rural areas, a tertiary or even
secondary road may well be narrow and lack a hard surface, simply
because that's what the traffic demands and the community will
support. It's also not an infallible guide, particularly in urban
areas; a city street may be six or eight lanes wide in a congested
area without necessarily having a key role in the network.

4. The official designation of the road's importance is tremendously
influenced by politics. Nevertheless, that designation determines
highway funding, which in turn determines the quality of the road,
which in turn ought to determine routing precedence, so in the end,
even if the official designation doesn't make sense, a designated
'trunk' road will likely be built to support more traffic and a higher
speed than a 'tertiary' one.

5. This isn't the first edit war on the subject.

Some more details follow.

On Mon, Sep 28, 2020 at 12:08 PM Matthew Woehlke
 wrote:
>
> On 28/09/2020 11.42, Jack Burke wrote:
> > I'm willing to bet that most OSM editors who drive on either of those two
> > will think "this is a great freeway, just with occasional traffic signals."
>
> That's an oxymoron. Freeways are, by definition, limited access (no
> crossing intersections, period) and do not have (permanent¹) signs or
> signals to halt traffic. IMNSHO, if it has traffic lights, stop signs,
> or the possibility of vehicles suddenly driving *across* the way, it
> isn't a freeway.
>
> That's not to say there aren't non-interstate highways that meet these
> definitions.
>
> But... is it a highway=trunk? *I* don't see where the wiki excludes the
> possibility. (It does, however, seem to me that only *actual* interstate
> freeways should be highway=motorway in the US.)

I beg to differ.  NY-17 is indeed a motorway for most of its length
(east and south of Harriman, it ought to be primary) It's more-or-less
permanently unfinished between Deposit and Hancock, because the
terrain offers extremely difficult challenges to freeway-building.
Portions are, in fact, posted intermittently as 'Future I-86', but my
understanding is that it can't get that designation until and unless
the missing bit in the middle is finished.

Several of New York's state parkways, such as Southern State Parkway
https://www.openstreetmap.org/relation/1676429, are multi-lane, dual
carriageway, access fully controlled, all crossings elevated, for
their entire length. Southern State Parkway would differ from
'Interstate' only in that: (a) the speed limit is 55 mile/hr (but all
urban freeways in Nassau and Suffolk Counties, including I-495, have
the reduced speed limit), (b) they are hgv=no, (c) they don't have
Federal interstate highway funding. It's not clear to me that any of
these attributes would make them 'not a freeway'.

Taconic Parkway is controversial.  To me, it's clearly a trunk road
from the southern terminus through I-287 (mile 2.85), with all but one
intersection at grade.  Between I-287 and Peekskill Hollow Road (mile
41.28) it drives like a freeway. All the crossings are elevated. North
of that, the crossings with major roads are mostly elevated, but local
streets typically have intersections at grade.  North of Rigor Hill
Road (mile 152.73) there are no at-grade crossings to the northern
terminus (I-90, mile 104.12). I've mostly refrained from editing this
one.  My preference would be to call it a motorway between I-287 and
Peekskill Hollow Road, and again between NY-203 and I-90, and a trunk
road in between. At one point, the locals (or the TIGER import?) had
mapped it as 'motorway' throughout, downgrading it to 'trunk' only for
a few hundred yards surrounding each at-grade intersection; I consider
the latter practice

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Richard Welty

On 9/28/20 12:39 PM, Jack Burke wrote:
>   I *am* trying to say that they should be highway=trunk.  My
> use of the term "freeway" to describe them was artistic in nature, to
> describe how it feels actually driving on them.   That's all.

sometimes, such as in NYS, the formal road classification uses the term
Freeway to describe things that most of us would consider trunk.

for example, Washington Avenue Extension in Albany, NY has an extended
section with frontage roads and a limited number of grade level,
traffic light controlled intersections. in NYS DOT parlance, it is an
Urban Freeway.

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

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-it] (senza oggetto)

2020-09-28 Thread Lorenzo Rolla

Gentilissimi, mi ha “colpito” questo decreto appena pubblicato sulla G.U.
di oggi:


DECRETO 30 giugno 2020

Salvaguardia dei vigneti eroici o storici. (20A05149) (GU Serie Generale
n.240 del 28-09-2020)



https://www.gazzettaufficiale.it/atto/serie_generale/caricaDettaglioAtto/originario?atto.dataPubblicazioneGazzetta=2020-09-28=20A05149=false

Può essere interessante o utile sottolineare queste specificità sulle
mappe? Ovviamente la mia è solo una curiosità personale... buona serata.
Lorenzo
-- 
Lorenzo Rolla
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Fontaine...

2020-09-28 Thread ades

moi, rien ne me choque ;-)  (enfin presque)

c’est juste qu’au départ du fil il est dit que fountain ne correspond pas à 
l’objet à tagger, après examen, c’est sans doute parce que la fontaine est dite 
ornementale et seulement ornementale, dans le wiki, ce qui correspond à une 
traduction (bête) du features anglo saxon.
Bon, je n’ai pas cherché à savoir comment on appelle en anglais ce que l’on 
appelle fontaine en Fçais. Faudrait ausssi voir avec les autres langues latines…


> Le 28 sept. 2020 à 20:45, osm.sanspourr...@spamgourmet.com a écrit :
> 
> C'est assez simple, c'est fountain!
> 
> Je ne vois pas ce qui te choque.
> 
> https://www.linguee.fr/francais-anglais/search?query=fontaine
> 
> https://www.linguee.fr/francais-anglais/search?source=auto=fountain
> 
> Jean-Yvon
> 
> 
> 
> Le 28/09/2020 à 20:11, ades - ades.s...@orange.fr a écrit :
>> le pb semble être que fontaine et fountain ce n’est pas du tout la
>> même chose.
>> 
>> Pour ça, comparer :
>> https://www.collinsdictionary.com/dictionary/english/fountain
>> 
>> 
>> et
>> 
>> https://www.littre.org/definition/fontaine
>> 
>> 
>> ou encore :
>> 
>> http://stella.atilf.fr/Dendien/scripts/tlfiv5/visusel.exe?13;s=4211401755;r=1;nat=;sol=2
>> ;
>> 
>> ou encore :
>> 
>> https://www.dictionnaire-academie.fr/article/A9F1208
>> 
>> 
>> va falloir tropuver en anglais ce qui correspond à la fontaine française…
>> 
>> 
>> 
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Matthew Woehlke


On 28/09/2020 12.27, Paul Johnson wrote:

On Mon, Sep 28, 2020 at 11:07 AM Matthew Woehlke wrote:

On 28/09/2020 11.42, Jack Burke wrote:

I'm willing to bet that most OSM editors who drive on either of those two
will think "this is a great freeway, just with occasional traffic

signals."

That's an oxymoron. Freeways are, by definition, limited access (no
crossing intersections, period) and do not have (permanent¹) signs or
signals to halt traffic. IMNSHO, if it has traffic lights, stop signs,
or the possibility of vehicles suddenly driving *across* the way, it
isn't a freeway.


True, but highway=trunk can mean either expressways (think like freeways
that have some or all at-grade intersections; note that having
freeway-style ramps in between junctions doesn't make it a
highway=motorway), or single-carriageway freeways.  In both cases, they
tend to get built as an incremental case to building a full motorway, but
are not yet motorways.


We're getting dangerously into the territory of words with ambiguous 
meanings. Note https://en.wiktionary.org/wiki/freeway, especially the 
first definition. Note also my point was about "freeways", not 
highway=trunk. Many in the US would consider "freeway" and 
highway=motorway to be nearly synonymous. (The "nearly" is when we start 
talking about non-interstate limited access.)


I did later state that limited access is *not* a requirement for 
highway=trunk.


Also, Jack has clarified his usage as "artistic"...


That's not to say there aren't non-interstate highways that meet these

definitions.

But... is it a highway=trunk? *I* don't see where the wiki excludes the
possibility. (It does, however, seem to me that only *actual* interstate
freeways should be highway=motorway in the US.)


That's not true at all...


Citation needed. I don't think that's been established (although we're 
getting pretty off-topic...). The *converse*, sure (interstate =/> 
motorway), I'll concede that.



[...] the transitions to where an interstate ends and it continues as
another kind of highway past the last exit before a junction,
I would question whether those should be highway=motorway. (Yes, I'm 
looking at https://www.openstreetmap.org/way/98245488 and surrounding, 
possibly as far north as https://www.openstreetmap.org/node/41485037.)


--
Matthew

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Fontaine...

2020-09-28 Thread osm . sanspourriel


C'est assez simple, c'est fountain!

Je ne vois pas ce qui te choque.

https://www.linguee.fr/francais-anglais/search?query=fontaine

https://www.linguee.fr/francais-anglais/search?source=auto=fountain

Jean-Yvon



Le 28/09/2020 à 20:11, ades - ades.s...@orange.fr a écrit :

le pb semble être que fontaine et fountain ce n’est pas du tout la
même chose.

Pour ça, comparer :
https://www.collinsdictionary.com/dictionary/english/fountain


et

https://www.littre.org/definition/fontaine


ou encore :

http://stella.atilf.fr/Dendien/scripts/tlfiv5/visusel.exe?13;s=4211401755;r=1;nat=;sol=2
;

ou encore :

https://www.dictionnaire-academie.fr/article/A9F1208


va falloir tropuver en anglais ce qui correspond à la fontaine française…



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-at] (Halb-)mechanischer Edit von Ärztenamen in Tirol

2020-09-28 Thread Robert Kaiser


Stefan Tauner schrieb:

Da dieses Schema für den deutschen Sprachraum unüblich ist, würde ich
das gerne auf "Dr.  " ändern (bzw. wäre ich natürlich
auch nicht böse, wenn das jemand anderer hackt ;)
Ich würde das ggf. per Overpass laden, exportieren in einem Texteditor,
mit sed oder vl. auch etwas OSM-spezifischen (Vorschläge?) ändern und
wieder hochladen. Allerdings wird es auf Grund von Doppelnamen und
anderen Uneindeutigkeiten ohne eine manuelle Überprüfung ohnehin kaum
gehen. Da fs_LT nichts dagegen hat, seh ich aber keine grundsätzlichen
Probleme. Trotzdem stelle ich das hier mal zur Diskussion, bevor ich
mich um die Details zu automated edits kümmere.


Sehe ich als eine gute Idee, besonders, wenn die manuelle Überprüfung 
auch gemacht wird.


Grüße,
KaiRo


___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-us] Recent Trunk road edits

On Mon, Sep 28, 2020 at 12:02 PM Paul Johnson  wrote:
>
> On Mon, Sep 28, 2020 at 10:42 AM Jack Burke  wrote:
>>
>> On Monday, September 28, 2020, Paul Johnson  wrote:
>>
>> Georgia 400 is a grade-separated, divided, high-speed freeway from its 
>> southern endpoint at I 85, all the way to where it meets GA 369 near Coal 
>> Mountain, 37 miles later. From there, it's an at-grade, divided, high-speed 
>> (mostly 65mph, with short sections of 55mph in denser areas) highway with 
>> extremely long straight sections and other sections with high-speed curves, 
>> until it ends at GA 60 just outside Dahlonega, 16 miles past Coal Mountain.
>
>
> Yeah, not looking very hard at this so don't know if I missed any at-grade 
> intersections looking at Maxar/Mapbox. I'd call that a motorway pretty 
> solidly from I 85 to GA 306 and a trunk north of that to GA 60.  Looks like 
> it turns into GA 115 at GA 60, didn't trace that further but I'd call GA 60 a 
> secondary.

I would call your assessment spot-on, except with a disagreement that
the motorway should end at GA 306 (I think it's fine classified that
way all the way to GA 369).  But that really comes down to individual
preference.  I'm certainly not going to try to argue with someone over
it.  (For reference, my rational for choosing 396 is because that's
where the overhead sign is declaring "signal ahead, prepare to stop.")


>> GA 515 begins life where I 575 ends, at Ball Ground. From there, it is a 
>> grade-separated, divided, high-speed (mostly 65mph, with a few sections of 
>> 55mph, and a couple of 45mph when it passes through Ellijay and Blue Ridge) 
>> freeway that travels north to Blue Ridge, almost at the Tennessee border, 
>> where it arcs eastward and continues to Blairsville.  That's 63 miles of 
>> divided high-speed goodness. There it finally becomes an undivided highway 
>> that continues on to Young Harris, "ending" a few miles past there. GA 515 
>> was upgraded to its dual-carriageway status about 30 years ago as part of 
>> the Appalachian development highway program.
>
>
> Looking at the same imagery as above, yeah, I'd call I 575 a trunk north of 
> Howell Bridge Road and GA 515 a trunk from I 575 until the south end of Blue 
> Ridge, where the single carriageway through town is primary (it stops being 
> an expressway and becomes a boulevard for a bit), and then picks back up as 
> trunk on the north end of town before going primary again at Blairsville.

Again, spot-on, except I'd leave the undivided section through Blue
Ridge as trunk.  (Why?  Because it's so short, and is there really a
need to classify it lower there?)


>> All of these, and others, were highway=trunk until floridaeditor decided to 
>> downgrade them (and challenge anyone to change them back)
>
>
> So far it seems like floridaeditor is the exact opposite of NE2 (who smashed 
> everything in network=US:US to highway=trunk even if it's not an expressway 
> or super-two freeway, something we're still cleaning up particularly in the 
> midwest and Texas).  Given NE2 was also in Flordia, I wouldn't rule out it's 
> the same person.

I never dealt with NE2 directly, since I started after his banishment,
but I have come across a lot of his work.  Some of it I do have to
tilt my head sideways at, but there have been quite a few things he
did that I thought were pretty good.  But that notwithstanding, this
person is going the exact opposite direction with his edits.  Can they
really be the same person?

--jack

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Fontaine...

2020-09-28 Thread ades

le pb semble être que fontaine et fountain ce n’est pas du tout la même chose.

Pour ça, comparer : 
https://www.collinsdictionary.com/dictionary/english/fountain 


et

https://www.littre.org/definition/fontaine 


ou encore :

http://stella.atilf.fr/Dendien/scripts/tlfiv5/visusel.exe?13;s=4211401755;r=1;nat=;sol=2;

ou encore : 

https://www.dictionnaire-academie.fr/article/A9F1208 


va falloir tropuver en anglais ce qui correspond à la fontaine française…


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Choisir le bon name pour les trajets de bus

2020-09-28 Thread osm . sanspourriel



Le 28/09/2020 à 19:22, blef - bernard.lefranc...@free.fr a écrit


Bonjour,

Le problème survient quand il y a des variantes sur une ligne.
Le nom officiel de la ligne est toujours le même, mais les trajets et
arrêts desservis varient.


En général le nom reste le même c'est un tableau horaire.

Par contre en général il y a des notes (a, b, c...) précisant le trajet.

J'aurais tendance à les appeler xxx, variante a etc.

Sinon il y a une liste transports pour les questions de spécialistes.

Jean-Yvon, non spécialiste transports




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Choisir le bon name pour les trajets de bus

2020-09-28 Thread Gad Jo

C'est exactement ça. Sur la même ligne j'ai des variante qui font tous les 
villages et d'autres seulement quelques villages. En bonus certains arrêt en 
milieu de ligne peuvent être ignoré en milieu de journée ou pendant le 
ramassage scolaire

J'avais tenté name=: commune -  → 
commune - 

Au final je vais faire sauter le nom des communes. Le from et to sont justement 
changeant suivant les horaires et périodes de l'année. La clé via permet de 
préciser un peu plus le  otrajet

En tout merci pour votre réactivité

Ps : Prochain mail : comment gérer les horaires sur les lignes de bus (c'est 
coton). Je fait le point et au besoin je poserai ma question



Le September 28, 2020 5:22:08 PM UTC, blef  a écrit 
:
>Le 28/09/2020 à 09:55, Éric Gillet a écrit :
>> Le 27/09/2020 à 16:46, Gad Jo a écrit :
>>> Bonjour a tous,
>>>
>>> Exemple extrême (y aura pas pire que ça) : Bus 12 bis : 
>>> Montredon-des-Corbières - Montredon Pôle d’échanges → 
>>> Montredon-des-Corbières - Clos des Ormeaux
>>> (Désolé le copier-coller sur l'application ajoute le format)
>>> Relation concernée : https://www.openstreetmap.org/relation/11674315
>>>
>>> Auriez vous des propositions à me faire ? À moins que des règles 
>>> existent et j'applique... Je serait tenté de placer que le nom de
>l'arrêt
>>
>> Bonjour,
>>
>> Je pense qu'il faut mettre le nom tel que diffusé au public par le 
>> réseau (en données ouvertes, sur les documents ou sur le terrain).
>>
>> "name=:  → /" 
>> /[1][2]//ou autre variante n'est pas un nom mais une 
>> description//redondante avec les autres tags présents dans la 
>> relation/. /Pas toutes les applications affichent ces détails-là donc
>
>> une telle description en nom me paraît acceptable, mais uniquement en
>
>> "solution de repli" quand la ligne n'a pas de nom.
>>
>>
>[1]https://wiki.openstreetmap.org/wiki/Public_transport#Service_routes
>>
>[2]https://lists.openstreetmap.org/pipermail/tagging/2019-May/045180.html
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>
>Bonjour,
>
>Le problème survient quand il y a des variantes sur une ligne.
>Le nom officiel de la ligne est toujours le même, mais les trajets et 
>arrêts desservis varient.
>Comme il faut établir une relation par variante, il faut bien 
>différencier les noms.
>Dans une petite ville comme la mienne, il y a un nombre restreint de 
>lignes, mais suivant les moments de la journée, la ligne x passe ou pas
>
>par le collège, la zone industrielle ou le cimetière.
>J'ai donc dû différentier arbitrairement les noms de variantes de celui
>
>"fourni" par le gestionnaire du réseau, en général en faisant figurer
>le 
>"via" qui caractérise la variante.

-- 
Envoyé de mon appareil Android avec K-9 Mail. Veuillez excuser ma brièveté.___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Recent Trunk road edits

On Mon, Sep 28, 2020 at 1:21 PM Shawn K. Quinn  wrote:
>
> On 9/28/20 11:00, Paul Johnson wrote:
> > Given NE2 was also in Flordia, I wouldn't rule out it's the same person.
>
> I was considering the same possibility. Given he's been indefinitely
> banned from editing, if we find out it is him doing this, should the
> project consider legal action? This is rather wide-scale vandalism from
> the looks of it.

I started editing post-NE2, so I never had the pleasure of
encountering him.  If it *is* him, then he's doing the exact opposite
of what I've heard about him in terms of road classifications.  For
that reason, it just doesn't sound like him to me, but like I said, I
never worked with him, so I can't really speak to his "touch" when it
comes to how his edits look.

I was hoping someone else would come out and use the "V" word before I
did--thank you, Shawn.  It helps reassure me that I'm not way off base
with my assessment of what is going on.

--jack

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

Hi Chris,

Both the wiki, and the Loomio, require a separate log in account which
is not the same as the main OSM account. So the barriers are the same.

I don't think the Loomio is restricted to just OSM UK "official
business" - though I might be wrong! Someone please correct me.

I do agree with you that a vote isn't necessarily all that helpful. It
was one of the original ways that the OSM community started
self-organising its tagging, but because of various limitations it's
very much fallen into disrepair as a way of doing things. I hope that
"good decision-making tools" like Loomio might be a way forward - but
I don't imagine it's a silver bullet.

Best
Dan

Op ma 28 sep. 2020 om 18:31 schreef Chris Hill :
>
> {this time to the list]
>
> And the people who care about OSM and the way imports and automated
> edits affects OSM, but don't use Loomio and are not connected to OSM UK?
> What should they do?
>
> Everyone in OSM has access to the Wiki.
>
> Having said that, I'm not sure what a vote will do. OSM is very clearly
> not a democracy in any sense. Voting tends to give any outcome the
> veneer of consultation and listening to feedback, but in practice so few
> people vote that the process is meaningless.
>
> Chris (chillly)
>
> On 28/09/2020 17:53, Dan S wrote:
> > Hi Rodrigo
> >
> > Before you create a vote on the wiki, can I suggest a different
> > method? "OSM UK" has started using Loomio for discussions and votes,
> > and it generally seems to work out well. I think Loomio is designed
> > for the purpose of making good decisions together:
> > https://www.loomio.org/openstreetmap-uk/
> >
> > I'm sorry, I don't wish to confuse you with tools and differing opinions...
> >
> > Cheers
> > Dan
> >
> > Op ma 28 sep. 2020 om 15:31 schreef Rodrigo Díez Villamuera
> > :
> >> Thanks all of you for your messages.
> >>
> >> As a new joiner, I could not ask for more than other members engaging in 
> >> such a passionate way :)
> >>
> >> It's fair to say that there is no clear consensus of whether the proposal, 
> >> in its current form, is acceptable or not. So, I am going to create a 
> >> voting section on the wiki page to help us visualise what people think
> >>
> >> However, before I do that I would like to reply to a point that was made 
> >> by Andy
> >>
> >> Andy,
> >>
> >> I'm not actually convinced that's a problem - as others have said, web 
> >> browsers are perfectly capable of converting "www.mypub.com" into either 
> >> "https://www.mypub.com"or ""http://www.mypub.com"as appropriate, so this 
> >> doesn't really add any value.  "Letting the browser sort it out" is a 
> >> great approach as it can deal with now/near future things such as removal 
> >> TLS 1.0 and 1.1 support as well.
> >>
> >> This is not true based on my experience. I just tested on the latest 
> >> version of Chrome and Firefox and, if the URL scheme is not specified, 
> >> they both open the the URL using http even if https is also available for 
> >> it.
> >>
> >> You may have experienced a behaviour by which the user gets redirected 
> >> from the http url to the https one but that depends on the configuration 
> >> of the site server which is not always set-up.
> >>
> >> This is also well documented for Firefox here: 
> >> https://wiki.mozilla.org/Firefox/URL_Bar_Algorithm
> >>
> >> I see value in updating schemaless :website tags with the https version if 
> >> available.
> >> --
> >> Rodrigo Díez Villamuera
> >>
> >> w: http://rodrigodiez.io
> >> t: @rodrigodiez_pro
> >> p: 00 44 7513 638225
> >>
> >>
> >>
> >> On Mon, 28 Sep 2020 at 13:50, Andy Mabbett  
> >> wrote:
> >>> On Mon, 28 Sep 2020 at 10:00, Frederik Ramm  wrote:
> >>>
>  The change you plan to execute is of limited use. Yes, it ensures more
>  conformity in the data, but it will be a temporary fix (since new
>  "wrong" URLs can be added at any time).
> >>> This seems like an argument for never fixing any error.
> >>>
>  So what your edit does is, it "touches" lots of objects and adds no
>  meaningful information whatsoever.
> >>> This statement is false, not least because in some cases "http://; is
> >>> added, in others "https://;; each of those - and the difference
> >>> between them - conveys meaningful information.
> >>>
>  It creates load on the database
> >>> The level of load is trivial. Have our database maintainers ever said
> >>> that a load of such small magnitude is problematic?
> >>>
>  There are many, many better ways to contribute to OSM than runnning a
>  useless automated conformity edit. Take a notebook or mobile editor, go
>  outside, check if the phone booths on OSM are still there on the ground,
>  add a few opening times, or even trees for that matter - a single hour
>  of such original work is more useful to OSM that what you are proposing
>  here.
> >>> Denigrating another's contribution - a valid and valuable contribution
> >>> - in this manner is antithetical to the spirit in which OSM

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread Chris Hill

{this time to the list]

And the people who care about OSM and the way imports and automated
edits affects OSM, but don't use Loomio and are not connected to OSM UK?
What should they do?

Everyone in OSM has access to the Wiki.

Having said that, I'm not sure what a vote will do. OSM is very clearly
not a democracy in any sense. Voting tends to give any outcome the
veneer of consultation and listening to feedback, but in practice so few
people vote that the process is meaningless.

Chris (chillly)

On 28/09/2020 17:53, Dan S wrote:

Hi Rodrigo

Before you create a vote on the wiki, can I suggest a different
method? "OSM UK" has started using Loomio for discussions and votes,
and it generally seems to work out well. I think Loomio is designed
for the purpose of making good decisions together:
https://www.loomio.org/openstreetmap-uk/

I'm sorry, I don't wish to confuse you with tools and differing opinions...

Cheers
Dan

Op ma 28 sep. 2020 om 15:31 schreef Rodrigo Díez Villamuera
:

Thanks all of you for your messages.

As a new joiner, I could not ask for more than other members engaging in such a
passionate way :)

It's fair to say that there is no clear consensus of whether the proposal, in
its current form, is acceptable or not. So, I am going to create a voting
section on the wiki page to help us visualise what people think

However, before I do that I would like to reply to a point that was made by Andy

Andy,

I'm not actually convinced that's a problem - as others have said, web browsers are perfectly capable of converting
"www.mypub.com" into either "https://www.mypub.com"or ""http://www.mypub.com"as
appropriate, so this doesn't really add any value. "Letting the browser sort it out" is a great approach as it
can deal with now/near future things such as removal TLS 1.0 and 1.1 support as well.

This is not true based on my experience. I just tested on the latest version of
Chrome and Firefox and, if the URL scheme is not specified, they both open the
the URL using http even if https is also available for it.

You may have experienced a behaviour by which the user gets redirected from the
http url to the https one but that depends on the configuration of the site
server which is not always set-up.

This is also well documented for Firefox here:
https://wiki.mozilla.org/Firefox/URL_Bar_Algorithm

I see value in updating schemaless :website tags with the https version if
available.
--
Rodrigo Díez Villamuera

w: http://rodrigodiez.io
t: @rodrigodiez_pro
p: 00 44 7513 638225

On Mon, 28 Sep 2020 at 13:50, Andy Mabbett wrote:

On Mon, 28 Sep 2020 at 10:00, Frederik Ramm wrote:

The change you plan to execute is of limited use. Yes, it ensures more
conformity in the data, but it will be a temporary fix (since new
"wrong" URLs can be added at any time).

This seems like an argument for never fixing any error.

So what your edit does is, it "touches" lots of objects and adds no
meaningful information whatsoever.

This statement is false, not least because in some cases "http://; is
added, in others "https://;; each of those - and the difference
between them - conveys meaningful information.

It creates load on the database

The level of load is trivial. Have our database maintainers ever said
that a load of such small magnitude is problematic?

There are many, many better ways to contribute to OSM than runnning a
useless automated conformity edit. Take a notebook or mobile editor, go
outside, check if the phone booths on OSM are still there on the ground,
add a few opening times, or even trees for that matter - a single hour
of such original work is more useful to OSM that what you are proposing
here.

Denigrating another's contribution - a valid and valuable contribution
- in this manner is antithetical to the spirit in which OSM activity
is supposed to be conducted.

Remember: OSM is not an IT project.

Of course it is. "Information technology (IT) is the use of computers
to store, retrieve, transmit, and manipulate data or information." [1]

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

--
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

--
cheers
Chris Hill (chillly)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread Mateusz Konieczny via Talk-GB




28 wrz 2020, 13:53 od talk-gb@openstreetmap.org:

>
>
> On 28/09/2020 10:00, Frederik Ramm wrote:
>> The change you plan to execute is of limited use. Yes, it ensures more
>> conformity in the data, but it will be a temporary fix (since new
>> "wrong" URLs can be added at any time).
>>
>
> Moot. Your claim applies to all tags, all the time. By your logic we might as 
> well not amend anything.
>
Yes, this argument would work as argument
against any type of fix.

fixing case of
 highway=mtorway to highway=motorway
would be useful, despite that it may appear
again and it is possible to add automatic fix
for that

(I am not enthusiastic about this pub edit,
as benefit are minimal but if someone
wants to spend time on that I see nothing
wrong with that)

(I am also thinking whatever wiki should 
claim that http / https is needed -
in practice it is not really needed or useful)___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Choisir le bon name pour les trajets de bus

2020-09-28 Thread blef


Le 28/09/2020 à 09:55, Éric Gillet a écrit :

Le 27/09/2020 à 16:46, Gad Jo a écrit :

Bonjour a tous,

Exemple extrême (y aura pas pire que ça) : Bus 12 bis : 
Montredon-des-Corbières - Montredon Pôle d’échanges → 
Montredon-des-Corbières - Clos des Ormeaux

(Désolé le copier-coller sur l'application ajoute le format)
Relation concernée : https://www.openstreetmap.org/relation/11674315

Auriez vous des propositions à me faire ? À moins que des règles 
existent et j'applique... Je serait tenté de placer que le nom de l'arrêt


Bonjour,

Je pense qu'il faut mettre le nom tel que diffusé au public par le 
réseau (en données ouvertes, sur les documents ou sur le terrain).


"name=:  → /" 
/[1][2]//ou autre variante n'est pas un nom mais une 
description//redondante avec les autres tags présents dans la 
relation/. /Pas toutes les applications affichent ces détails-là donc 
une telle description en nom me paraît acceptable, mais uniquement en 
"solution de repli" quand la ligne n'a pas de nom.


[1]https://wiki.openstreetmap.org/wiki/Public_transport#Service_routes
[2]https://lists.openstreetmap.org/pipermail/tagging/2019-May/045180.html


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Bonjour,

Le problème survient quand il y a des variantes sur une ligne.
Le nom officiel de la ligne est toujours le même, mais les trajets et 
arrêts desservis varient.
Comme il faut établir une relation par variante, il faut bien 
différencier les noms.
Dans une petite ville comme la mienne, il y a un nombre restreint de 
lignes, mais suivant les moments de la journée, la ligne x passe ou pas 
par le collège, la zone industrielle ou le cimetière.
J'ai donc dû différentier arbitrairement les noms de variantes de celui 
"fourni" par le gestionnaire du réseau, en général en faisant figurer le 
"via" qui caractérise la variante.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Shawn K. Quinn

On 9/28/20 11:00, Paul Johnson wrote:
> Given NE2 was also in Flordia, I wouldn't rule out it's the same person.

I was considering the same possibility. Given he's been indefinitely
banned from editing, if we find out it is him doing this, should the
project consider legal action? This is rather wide-scale vandalism from
the looks of it.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Vecchi sentieri CAI

2020-09-28 Thread MicheleOSM3



Il 28/09/2020 10.21, danbag--- via Talk-it ha scritto:



Il 28/09/2020 09:43, Martin Koppenhoefer ha scritto:


2) nella wiki ricordata è previsto un tag old_ref per scriverci 
l'eventuale codice obsoleto del percorso
Sì, old_ref nel wiki-CAI ha un significato specifico, ma trattandosi di 
sentieri ex-CAI, altri prima di me lo hanno usato per indicare il n. 
sentiero che aveva prima, a me non sembrava sbagliato, ma se è sbagliato 
non c'è problema, lo tolgo.


3) predisponendo opportunamente i tag previsti nella wiki citata si 
risolvono varie problematiche qui proposte senza andare alla ricerca 
di nuove taggature
Nella wiki citata non ho trovato cosa fare per i sentieri ex-CAI, per 
questo credo cha altri prima di me abbiano usato il prefisso disused, 
sia per non visualizzare più il n. di sentiero sia per il symbol che 
altrimenti verrebbe visualizzato su Waymarked Trails.

Sull’operator sono indeciso, probabilmente va meglio disused:operator perché 
non è più gestito, mentre senza disused: si potrebbe pensare che si tratta di 
un ex sentiero comunque gestito dal cai (nello stato attuale).


A proposito del tag operator, prima di scriverci il nome di un Ente o 
altro è necessario essere al 1000 per 100 sicuri che si occupi 
realmente della sua manutenzione: in Piemonte come già indicato da Ivo 
esiste la Legge 12 del 2010 che indica essere i Comuni proprietari dei 
sentieri e ad essi spetta l'obbligo della manutenzione, quindi in 
teoria in Piemonte il tag operator dovrebbe contenere il nome del 
Comune. In realtà i Comuni disattendono quasi totalmente l'obbligo di 
manutenzione ... però espongono ordinanze di divieto di transito 
quando il sentiero diventa pericoloso
Quindi in questo stato di cose vengono stipulate Convenzioni dove le 
singole sezione del CAI si impegnano alla manutenzione di alcuni 
percorsi oggetto della convenzione. Ecco che in questo caso l'operator 
diventa la sezione CAI che ha stipulato la convenzione.Qui un esempio 
di relazione dove la sezione CAI è divenuta l'operator 


https://hiking.waymarkedtrails.org/#route?id=6805420


Grazie, effettivamente, copiando il lavoro di altri, mi era sfuggito e 
credo di aver erroneamente impostato (operator=Club Alpino Italiano) per 
alcuni sentieri CAI che ho aggiunto in OSM, correggerò le mie 
modifiche... mi rimane il dubbio se correggere anche i sentieri CAI 
inseriti da altri...
Tra l'altro, anche il sentiero italia ha (operator=Club Alpino 
Italiano): ttps://www.openstreetmap.org/relation/1021025  Non è strano 
che per una relazione così estesa nessuno abbia corretto il tag?



___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

Hi Rodrigo

Before you create a vote on the wiki, can I suggest a different
method? "OSM UK" has started using Loomio for discussions and votes,
and it generally seems to work out well. I think Loomio is designed
for the purpose of making good decisions together:
https://www.loomio.org/openstreetmap-uk/

I'm sorry, I don't wish to confuse you with tools and differing opinions...

Cheers
Dan

Op ma 28 sep. 2020 om 15:31 schreef Rodrigo Díez Villamuera
:
>
> Thanks all of you for your messages.
>
> As a new joiner, I could not ask for more than other members engaging in such 
> a passionate way :)
>
> It's fair to say that there is no clear consensus of whether the proposal, in 
> its current form, is acceptable or not. So, I am going to create a voting 
> section on the wiki page to help us visualise what people think
>
> However, before I do that I would like to reply to a point that was made by 
> Andy
>
> Andy,
>
> I'm not actually convinced that's a problem - as others have said, web 
> browsers are perfectly capable of converting "www.mypub.com" into either 
> "https://www.mypub.com"or ""http://www.mypub.com"as appropriate, so this 
> doesn't really add any value.  "Letting the browser sort it out" is a great 
> approach as it can deal with now/near future things such as removal TLS 1.0 
> and 1.1 support as well.
>
> This is not true based on my experience. I just tested on the latest version 
> of Chrome and Firefox and, if the URL scheme is not specified, they both open 
> the the URL using http even if https is also available for it.
>
> You may have experienced a behaviour by which the user gets redirected from 
> the http url to the https one but that depends on the configuration of the 
> site server which is not always set-up.
>
> This is also well documented for Firefox here: 
> https://wiki.mozilla.org/Firefox/URL_Bar_Algorithm
>
> I see value in updating schemaless :website tags with the https version if 
> available.
> --
> Rodrigo Díez Villamuera
>
> w: http://rodrigodiez.io
> t: @rodrigodiez_pro
> p: 00 44 7513 638225
>
>
>
> On Mon, 28 Sep 2020 at 13:50, Andy Mabbett  wrote:
>>
>> On Mon, 28 Sep 2020 at 10:00, Frederik Ramm  wrote:
>>
>> > The change you plan to execute is of limited use. Yes, it ensures more
>> > conformity in the data, but it will be a temporary fix (since new
>> > "wrong" URLs can be added at any time).
>>
>> This seems like an argument for never fixing any error.
>>
>> > So what your edit does is, it "touches" lots of objects and adds no
>> > meaningful information whatsoever.
>>
>> This statement is false, not least because in some cases "http://; is
>> added, in others "https://;; each of those - and the difference
>> between them - conveys meaningful information.
>>
>> > It creates load on the database
>>
>> The level of load is trivial. Have our database maintainers ever said
>> that a load of such small magnitude is problematic?
>>
>> > There are many, many better ways to contribute to OSM than runnning a
>> > useless automated conformity edit. Take a notebook or mobile editor, go
>> > outside, check if the phone booths on OSM are still there on the ground,
>> > add a few opening times, or even trees for that matter - a single hour
>> > of such original work is more useful to OSM that what you are proposing
>> > here.
>>
>> Denigrating another's contribution - a valid and valuable contribution
>> - in this manner is antithetical to the spirit in which OSM activity
>> is supposed to be conducted.
>>
>> > Remember: OSM is not an IT project.
>>
>> Of course it is. "Information technology (IT) is the use of computers
>> to store, retrieve, transmit, and manipulate data or information." [1]
>>
>>
>> [1] https://en.wikipedia.org/wiki/Information_technology
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-us] Recent Trunk road edits

On Monday, September 28, 2020, Paul Johnson  wrote:

> On Mon, Sep 28, 2020 at 11:07 AM Matthew Woehlke 
> wrote:
>
>> On 28/09/2020 11.42, Jack Burke wrote:
>> > I'm willing to bet that most OSM editors who drive on either of those
>> two
>> > will think "this is a great freeway, just with occasional traffic
>> signals."
>>
>> That's an oxymoron. Freeways are, by definition, limited access (no
>> crossing intersections, period) and do not have (permanent¹) signs or
>> signals to halt traffic. IMNSHO, if it has traffic lights, stop signs,
>> or the possibility of vehicles suddenly driving *across* the way, it
>> isn't a freeway.
>
>
> True, but highway=trunk can mean either expressways (think like freeways
> that have some or all at-grade intersections; note that having
> freeway-style ramps in between junctions doesn't make it a
> highway=motorway), or single-carriageway freeways.  In both cases, they
> tend to get built as an incremental case to building a full motorway, but
> are not yet motorways.
>
> That's not to say there aren't non-interstate highways that meet these
>> definitions.
>>
>> But... is it a highway=trunk? *I* don't see where the wiki excludes the
>> possibility. (It does, however, seem to me that only *actual* interstate
>> freeways should be highway=motorway in the US.)
>>
>
> That's not true at all...heck, not all sections of Interstates qualify for
> highway=motorway, there's at least a couple dozen spots where this is true,
> like pretty much any customs checkpoint, the transitions to where an
> interstate ends and it continues as another kind of highway past the last
> exit before a junction,
>
>
>> Related: if it's I-## or I-###, shouldn't it be a highway=motorway,
>> period? (Unless those, for some reason, are ever *not* freeways?)
>>
>
> No.  Very much not, in fact.  Network and classification are, relative to
> the UK, quite disconnected.  Most of the Interstate network that is
> bannered as Detour (more common in disaster prone areas where getting
> around a freeway closure isn't obvious and yet happens frequently enough to
> have permanently signposted detour routes for such occasions) or Business
> tends to be trunk at most (I can think of a couple places where a Business
> Interstate runs down expressway sections that used to be US 66) but usually
> is *extremely* not a freeway (usually boulevards and two lane roads).
> Get up to Alaska and mainline interstates aren't freeways and usually
> aren't even signposted (I'd be surprised if anything outside Fairbanks and
> Anchorage warrants higher than a secondary tag realistically, but the US
> loves to creep everything upwards, overstating connectivity).  Some cities
> operate full blown freeways, some interstates are gravel barely-a-road.
>
>
Matthew and Paul, hang on!

I am *not* trying to say that the roads in question should be
highway=motorway (except for the part of Georgia 400 that is, in fact, a
motorway).  I *am* trying to say that they should be highway=trunk.  My use
of the term "freeway" to describe them was artistic in nature, to describe
how it feels actually driving on them.   That's all.

Now back to our regularly scheduled program.

-jack
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Paul Johnson

On Mon, Sep 28, 2020 at 11:07 AM Matthew Woehlke 
wrote:

> On 28/09/2020 11.42, Jack Burke wrote:
> > I'm willing to bet that most OSM editors who drive on either of those two
> > will think "this is a great freeway, just with occasional traffic
> signals."
>
> That's an oxymoron. Freeways are, by definition, limited access (no
> crossing intersections, period) and do not have (permanent¹) signs or
> signals to halt traffic. IMNSHO, if it has traffic lights, stop signs,
> or the possibility of vehicles suddenly driving *across* the way, it
> isn't a freeway.

True, but highway=trunk can mean either expressways (think like freeways
that have some or all at-grade intersections; note that having
freeway-style ramps in between junctions doesn't make it a
highway=motorway), or single-carriageway freeways.  In both cases, they
tend to get built as an incremental case to building a full motorway, but
are not yet motorways.

That's not to say there aren't non-interstate highways that meet these
> definitions.
>
> But... is it a highway=trunk? *I* don't see where the wiki excludes the
> possibility. (It does, however, seem to me that only *actual* interstate
> freeways should be highway=motorway in the US.)
>

That's not true at all...heck, not all sections of Interstates qualify for
highway=motorway, there's at least a couple dozen spots where this is true,
like pretty much any customs checkpoint, the transitions to where an
interstate ends and it continues as another kind of highway past the last
exit before a junction,

> Related: if it's I-## or I-###, shouldn't it be a highway=motorway,
> period? (Unless those, for some reason, are ever *not* freeways?)
>

No.  Very much not, in fact.  Network and classification are, relative to
the UK, quite disconnected.  Most of the Interstate network that is
bannered as Detour (more common in disaster prone areas where getting
around a freeway closure isn't obvious and yet happens frequently enough to
have permanently signposted detour routes for such occasions) or Business
tends to be trunk at most (I can think of a couple places where a Business
Interstate runs down expressway sections that used to be US 66) but usually
is *extremely* not a freeway (usually boulevards and two lane roads).  Get
up to Alaska and mainline interstates aren't freeways and usually aren't
even signposted (I'd be surprised if anything outside Fairbanks and
Anchorage warrants higher than a secondary tag realistically, but the US
loves to creep everything upwards, overstating connectivity).  Some cities
operate full blown freeways, some interstates are gravel barely-a-road.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-be] Hoppin / Mobipunt

2020-09-28 Thread Yves bxl-forever

Hello,

A Hoppin point normally has a digital display where people can get information. 
 I suppose it should be included in the relation as well.
An example here: https://www.nieuwsblad.be/cnt/dmf20200927_95769504

Yves




On Mon, 28 Sep 2020 17:33:18 +0200
Jo  wrote:

> Hi,
>
> I wanted to map our shiny new Hoppin points meant to group sharing
> facilities for bicycles and cars + public transport.
>
> https://www.openstreetmap.org/relation/11683352/history#map=16/50.8633/4.7005
> https://www.openstreetmap.org/relation/11683353#map=18/50.86545/4.69504
>
> are my first attempts.
>
> I used a site relation, because we already have tags for the amenities that
> form part of the group. They are supposed to be concentrated in a 'point',
> but sometimes the bus or train stops are a bit further away.
>
> There should also be a sign, possibly with a map on them, but I didn't map
> those yet.
>
> For those I thought of
>
> tourism=information
> information=board
> maybe
> board_type
>
>
> Any comments?
>
> Jo

___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-fr] Écoles maternelles -> amenity=school et school:FR=maternelle / et primaire-élémentaire-maternelle / était [Re: Osmose - Demande d'aide pour les écoles en France]

2020-09-28 Thread Vincent Bergeot


Le 27/09/2020 à 11:22, Frédéric Rodrigo a écrit :

Bonjour,

La liste des signalements de dysfonctionnement d'Osmose à propos des 
écoles en France ne fait que s'allonger. Mais personne ne traite le 
sujet.


https://github.com/osm-fr/osmose-backend/issues

Le sujet de l'éducation intéresse ici du monde. Si quelqu’un veut bien 
regarder ça. Il faut faire le point sur les issues dans github et les 
analyses Osmose. Puis proposer les corrections qui vont bien dans les 
analyses Osmose (modification du code ou au moins signaler quoi 
changer où).


Bonjour,

je veux bien y regarder, sachant donc que le choix discuté ici est de 
transformer les écoles maternelles ayant "amenity=*kindergarten*" (avec 
soit maternelle dans le name, soit school:FR=maternelle, soit 
reconnaissance terrain) en amenity=*school* et school:FR=maternelle. Il 
s'agit de ne pas transformer les amenity=kindergarten correspondant à 
des crèches en school :)


On garde le school:FR avec maternelle, élémentaire, primaire (3 "formes 
différentes" maternelle=Petite Section -> Grande Section, 
élémentaire=CP-CM2, primaire:PS -> CM2) / j'ai demandé des précisions à 
l'éducation nationale car même sur le site annuaire de l'éducation 
nationale il y a des contradictions.


On voit comment la ref:UAI arrive à se glisser la dedans.

Merci Frédéric du signalement

--
Vincent Bergeot

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites




On 28/09/2020 15:29, Rodrigo Díez Villamuera wrote:

Thanks all of you for your messages.

As a new joiner, I could not ask for more than other members engaging 
in such a passionate way :)


It's fair to say that there is no clear consensus of whether the 
proposal, in its current form, is acceptable or not. So, I am going to 
create a voting section on the wiki page to help us visualise what 
people think


However, before I do that I would like to reply to a point that was 
made by Andy


Andy,

/I'm not actually convinced that's a problem - as others have said, 
*web browsers are perfectly capable of converting "www.mypub.com 
" into either "https://www.mypub.com; 
or ""http://www.mypub.com; 
as appropriate*, so this doesn't really add any 
value. "Letting the browser sort it out" is a great approach as it can 
deal with now/near future things such as removal TLS 1.0 and 1.1 
support as well./


This is not true based on my experience. I just tested on the latest 
version of Chrome and Firefox and, if the URL scheme is not specified, 
they both open the the URL using http even if https is also available 
for it.


An example is Overpass Turbo which has three different pages:
https://overpass-turbo.eu/
http://overpass-turbo.eu/
www.overpass-turbo.eu/

If you've previously run different routines on each you'll see it 
displays them for each URL (tested on Firefox latest)


DaveF

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Matthew Woehlke


On 28/09/2020 11.42, Jack Burke wrote:

I'm willing to bet that most OSM editors who drive on either of those two
will think "this is a great freeway, just with occasional traffic signals."


That's an oxymoron. Freeways are, by definition, limited access (no 
crossing intersections, period) and do not have (permanent¹) signs or 
signals to halt traffic. IMNSHO, if it has traffic lights, stop signs, 
or the possibility of vehicles suddenly driving *across* the way, it 
isn't a freeway.


That's not to say there aren't non-interstate highways that meet these 
definitions.


But... is it a highway=trunk? *I* don't see where the wiki excludes the 
possibility. (It does, however, seem to me that only *actual* interstate 
freeways should be highway=motorway in the US.)


Related: if it's I-## or I-###, shouldn't it be a highway=motorway, 
period? (Unless those, for some reason, are ever *not* freeways?)


(¹ In case of active construction or accidents, all bets are off.)

--
Matthew

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Paul Johnson

On Mon, Sep 28, 2020 at 10:42 AM Jack Burke  wrote:

>
>
> On Monday, September 28, 2020, Paul Johnson  wrote:
>
>> On Sun, Sep 27, 2020 at 8:35 PM Jack Burke  wrote:
>>
>>> Recently, someone has taken it on himself to downgrade most (all?)
>>> highway=trunk roads in the eastern U.S. to just primary.  The odd
>>> thing is that the very wiki page he cites as his reason fully supports
>>> keeping them as trunk.  Many of them I'm personally familiar with, and
>>> even absent the wiki's definition, they actually make more sense as
>>> trunk from a driving perspective.
>>
>>
>> The wiki's pretty inconsistent but the generally accepted standard is
>> "it'd be a motorway if it didn't have intersections" or "it'd be a motorway
>> if it was dual carriageway".  I think some context would help.
>>
>
> How about a pair of highways that "would be motorways if they didn't have
> intersections" for context?
>
> Georgia 400 is a grade-separated, divided, high-speed freeway from its
> southern endpoint at I 85, all the way to where it meets GA 369 near Coal
> Mountain, 37 miles later. From there, it's an at-grade, divided, high-speed
> (mostly 65mph, with short sections of 55mph in denser areas) highway with
> extremely long straight sections and other sections with high-speed curves,
> until it ends at GA 60 just outside Dahlonega, 16 miles past Coal Mountain.
>

Yeah, not looking very hard at this so don't know if I missed any at-grade
intersections looking at Maxar/Mapbox. I'd call that a motorway pretty
solidly from I 85 to GA 306 and a trunk north of that to GA 60.  Looks like
it turns into GA 115 at GA 60, didn't trace that further but I'd call GA 60
a secondary.

> GA 515 begins life where I 575 ends, at Ball Ground. From there, it is a
> grade-separated, divided, high-speed (mostly 65mph, with a few sections of
> 55mph, and a couple of 45mph when it passes through Ellijay and Blue Ridge)
> freeway that travels north to Blue Ridge, almost at the Tennessee border,
> where it arcs eastward and continues to Blairsville.  That's 63 miles of
> divided high-speed goodness. There it finally becomes an undivided highway
> that continues on to Young Harris, "ending" a few miles past there. GA 515
> was upgraded to its dual-carriageway status about 30 years ago as part of
> the Appalachian development highway program.
>

Looking at the same imagery as above, yeah, I'd call I 575 a trunk north of
Howell Bridge Road and GA 515 a trunk from I 575 until the south end of
Blue Ridge, where the single carriageway through town is primary (it stops
being an expressway and becomes a boulevard for a bit), and then picks back
up as trunk on the north end of town before going primary again at
Blairsville.

> All of these, and others, were highway=trunk until floridaeditor decided
> to downgrade them (and challenge anyone to change them back)
>

So far it seems like floridaeditor is the exact opposite of NE2 (who
smashed everything in network=US:US to highway=trunk even if it's not an
expressway or super-two freeway, something we're *still* cleaning up
particularly in the midwest and Texas).  Given NE2 was also in Flordia, I
wouldn't rule out it's the same person.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

On Monday, September 28, 2020, Paul Johnson  wrote:

> On Sun, Sep 27, 2020 at 8:35 PM Jack Burke  wrote:
>
>> Recently, someone has taken it on himself to downgrade most (all?)
>> highway=trunk roads in the eastern U.S. to just primary.  The odd
>> thing is that the very wiki page he cites as his reason fully supports
>> keeping them as trunk.  Many of them I'm personally familiar with, and
>> even absent the wiki's definition, they actually make more sense as
>> trunk from a driving perspective.
>
>
> The wiki's pretty inconsistent but the generally accepted standard is
> "it'd be a motorway if it didn't have intersections" or "it'd be a motorway
> if it was dual carriageway".  I think some context would help.
>

How about a pair of highways that "would be motorways if they didn't have
intersections" for context?

Georgia 400 is a grade-separated, divided, high-speed freeway from its
southern endpoint at I 85, all the way to where it meets GA 369 near Coal
Mountain, 37 miles later. From there, it's an at-grade, divided, high-speed
(mostly 65mph, with short sections of 55mph in denser areas) highway with
extremely long straight sections and other sections with high-speed curves,
until it ends at GA 60 just outside Dahlonega, 16 miles past Coal Mountain.

GA 515 begins life where I 575 ends, at Ball Ground. From there, it is a
grade-separated, divided, high-speed (mostly 65mph, with a few sections of
55mph, and a couple of 45mph when it passes through Ellijay and Blue Ridge)
freeway that travels north to Blue Ridge, almost at the Tennessee border,
where it arcs eastward and continues to Blairsville.  That's 63 miles of
divided high-speed goodness. There it finally becomes an undivided highway
that continues on to Young Harris, "ending" a few miles past there. GA 515
was upgraded to its dual-carriageway status about 30 years ago as part of
the Appalachian development highway program.

I'm willing to bet that most OSM editors who drive on either of those two
will think "this is a great freeway, just with occasional traffic signals."

And then there's US 27/GA 1, a highway that was upgraded as part of the
GRIP initiative a bunch of years ago.  It's a north-south highway in west
Georgia that connects Chattanooga to Tallahassee. It's a mixture of divided
and undivided sections (far more divided than undivided), that switches
between 65mph (in most of the divided sections) and 55 mph (many of the
undivided sections) except when it passes through Rome and a couple of
other cities. And there are several other highways that meet this
description, too.

When all of these were upgraded to their current configuration, they were
built specifically to provide smooth, high-speed highway access to more
rural areas of the state, with the possibility of being upgraded further to
Interstate-level one day (think the new I 22).

All of these, and others, were highway=trunk until floridaeditor decided to
downgrade them (and challenge anyone to change them back).

Does that help any, Paul?

-jack
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk-be] Hoppin / Mobipunt

2020-09-28 Thread Jo

Hi,

I wanted to map our shiny new Hoppin points meant to group sharing
facilities for bicycles and cars + public transport.

https://www.openstreetmap.org/relation/11683352/history#map=16/50.8633/4.7005
https://www.openstreetmap.org/relation/11683353#map=18/50.86545/4.69504

are my first attempts.

I used a site relation, because we already have tags for the amenities that
form part of the group. They are supposed to be concentrated in a 'point',
but sometimes the bus or train stops are a bit further away.

There should also be a sign, possibly with a map on them, but I didn't map
those yet.

For those I thought of

tourism=information
information=board
maybe
board_type


Any comments?

Jo
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread Rodrigo Díez Villamuera

Thanks all of you for your messages.

As a new joiner, I could not ask for more than other members engaging in
such a passionate way :)

It's fair to say that there is no clear consensus of whether the proposal,
in its current form, is acceptable or not. So, I am going to create a
voting section on the wiki page to help us visualise what people think

However, before I do that I would like to reply to a point that was made by
Andy

Andy,

*I'm not actually convinced that's a problem - as others have said, web
browsers are perfectly capable of converting "www.mypub.com
" into either "https://www.mypub.com;
or ""http://www.mypub.com; as
appropriate, so this doesn't really add any value.  "Letting the browser
sort it out" is a great approach as it can deal with now/near future things
such as removal TLS 1.0 and 1.1 support as well.*

This is not true based on my experience. I just tested on the latest
version of Chrome and Firefox and, if the URL scheme is not specified, they
both open the the URL using http even if https is also available for it.

You may have experienced a behaviour by which the user gets redirected from
the http url to the https one but that depends on the configuration of the
site server which is not always set-up.

This is also well documented for Firefox here:
https://wiki.mozilla.org/Firefox/URL_Bar_Algorithm

I see value in updating schemaless :website tags with the https version if
available.
--
Rodrigo Díez Villamuera

w: http://rodrigodiez.io
t: @rodrigodiez_pro
p: 00 44 7513 638225

On Mon, 28 Sep 2020 at 13:50, Andy Mabbett 
wrote:

> On Mon, 28 Sep 2020 at 10:00, Frederik Ramm  wrote:
>
> > The change you plan to execute is of limited use. Yes, it ensures more
> > conformity in the data, but it will be a temporary fix (since new
> > "wrong" URLs can be added at any time).
>
> This seems like an argument for never fixing any error.
>
> > So what your edit does is, it "touches" lots of objects and adds no
> > meaningful information whatsoever.
>
> This statement is false, not least because in some cases "http://; is
> added, in others "https://;; each of those - and the difference
> between them - conveys meaningful information.
>
> > It creates load on the database
>
> The level of load is trivial. Have our database maintainers ever said
> that a load of such small magnitude is problematic?
>
> > There are many, many better ways to contribute to OSM than runnning a
> > useless automated conformity edit. Take a notebook or mobile editor, go
> > outside, check if the phone booths on OSM are still there on the ground,
> > add a few opening times, or even trees for that matter - a single hour
> > of such original work is more useful to OSM that what you are proposing
> > here.
>
> Denigrating another's contribution - a valid and valuable contribution
> - in this manner is antithetical to the spirit in which OSM activity
> is supposed to be conducted.
>
> > Remember: OSM is not an IT project.
>
> Of course it is. "Information technology (IT) is the use of computers
> to store, retrieve, transmit, and manipulate data or information." [1]
>
>
> [1] https://en.wikipedia.org/wiki/Information_technology
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites


Three things to note:
SO3166-1=GB is misnomered & includes Northern Ireland. (As I found out, 
some contributors there get annoyed with UK wide edits). You may want to 
use area(id:3600058447,3600058437,3600058446); // England Wales Scotland 
instead.


Many pubs are mapped as ways/relations so node won't return the full 
amount. Use nwr instead.


If you need the output to be as individual nodes use 'out center' option.

area["ISO3166-1"=GB];
rel(pivot)->.UK;
nwr(area)[amenity=pub][website][website!~"http"];
out center;
.UK out geom;

DaveF

On 27/09/2020 16:28, Rodrigo Díez Villamuera wrote:

Hi all,

First of all, I would like to introduce myself on this email list and 
to thank you all for your contributions to OSM. Great work!


After some time using OSM as a user, I decided to make my first step 
as a contributor, hence this email and the proposal inside.


Please bear in mind that this is my first attempt to contribute with a 
proposal and, although I have done my best reading the community 
conventions and best practices, I am sure I have made some mistakes on 
the way. Be merciful! :P


To the point now.

I am importing a subset of nodes from UK (those tagged with 
amenity:pub) for a pet project.


When analysing the data I realised that some of these nodes contain a 
website: tag that does not contain an appropriate URL schema (http/https).


Ie: www.mypub.com  rather than 
http://www.mypub.com or https://www.mypub.com


This goes in contradiction with the Wiki documentation for website. 



I created a proposal for a one-off, scoped, automated edit for these 
nodes to find the appropiate scheme for the existing URL and retag the 
nodes.


I added the proposal to the Automated edits log. You can read it here 
.


Just wanted to share the proposal with the UK community, gather your 
feedback, comments and advises on how to proceed from here


Thanks in advance!








--
Rodrigo Díez Villamuera

w: http://rodrigodiez.io
t: @rodrigodiez_pro
p: 00 44 7513 638225


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Paul Johnson

On Sun, Sep 27, 2020 at 8:35 PM Jack Burke  wrote:

> Recently, someone has taken it on himself to downgrade most (all?)
> highway=trunk roads in the eastern U.S. to just primary.  The odd
> thing is that the very wiki page he cites as his reason fully supports
> keeping them as trunk.  Many of them I'm personally familiar with, and
> even absent the wiki's definition, they actually make more sense as
> trunk from a driving perspective.

The wiki's pretty inconsistent but the generally accepted standard is "it'd
be a motorway if it didn't have intersections" or "it'd be a motorway if it
was dual carriageway".  I think some context would help.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Tagging an abandoned path?

2020-09-28 Thread Dave F via talk




On 25/09/2020 17:53, Andy Townsend wrote:

On 25/09/2020 17:43, Dave F via talk wrote:

Nick's description is "overgrown, unclear, prone to flooding"

These are all subjective interpretations.
There are many official PROW's in those conditions.


(for the benefit of people outside of England and Wales a "public 
right of way" is a special legal designation here)


To be fair, what Nick was talking about wasn't a PROW though.


Hmm.. Disagree He made no mention in the first paragraph, & he gave just 
one example which happened to not be official.

I mentioned PROWs as another example, not as an absolute.

DaveF

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

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread Andy Mabbett

On Mon, 28 Sep 2020 at 10:00, Frederik Ramm  wrote:

> The change you plan to execute is of limited use. Yes, it ensures more
> conformity in the data, but it will be a temporary fix (since new
> "wrong" URLs can be added at any time).

This seems like an argument for never fixing any error.

> So what your edit does is, it "touches" lots of objects and adds no
> meaningful information whatsoever.

This statement is false, not least because in some cases "http://; is
added, in others "https://;; each of those - and the difference
between them - conveys meaningful information.

> It creates load on the database

The level of load is trivial. Have our database maintainers ever said
that a load of such small magnitude is problematic?

> There are many, many better ways to contribute to OSM than runnning a
> useless automated conformity edit. Take a notebook or mobile editor, go
> outside, check if the phone booths on OSM are still there on the ground,
> add a few opening times, or even trees for that matter - a single hour
> of such original work is more useful to OSM that what you are proposing
> here.

Denigrating another's contribution - a valid and valuable contribution
- in this manner is antithetical to the spirit in which OSM activity
is supposed to be conducted.

> Remember: OSM is not an IT project.

Of course it is. "Information technology (IT) is the use of computers
to store, retrieve, transmit, and manipulate data or information." [1]

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

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[OSM-talk-nl] De Grote Geo Show a.s. do 1 okt 19:00-21:00

2020-09-28 Thread Just van den Broecke


Beste Mensen,

Voor wie nog niet wist.

De Grote Geo Show Draait Door! Nu elke eerste donderdag van de maand, 
twee uur van 19:00-21:00. Meer via https://tv.osgeo.nl.

Volgende uitzending a.s. donderdag 1 okt al.

Eerst aandacht voor volgende: voor laatste item “De Zeepkist” zoeken we 
nog sprekers: wil je een project promoten, een event aankondigen, een 
statement of whatever mededelen, kom in de uitzending!
Laat ons weten: hier via een DM naar mij, via t...@osgeo.nl of onze 
Telegram Groep.


Het programma voor Aflevering 11, zie ook via de website tv.osgeo.nl:
Thema Uitzending: “De Zomer Voorbij - en (OGC) API’s Kijken”
Uw Talkshow Host: Erik Meerburg!

- Opening: Geo-Events tijdens en voor en na de zomer - door Erik
- API’s Kijken: Interview met Linda van den Brink (Geonovum) - door 
Niene Boeijen - Spatial Data on the Web/OGC APIs

- API’s Kijken: Kort gedichtje door Jonna - over API’s Apen
- API’s Kijken: Interview Tom Kralidis - door Just - implementation of 
OGC APIs - pygeoapi - real world examples

- Grote Geo Quiz - “Voorbij De Zomer” - door Mariëlle Geers-Plasmans
- Interview met Just van den Broecke - Open Source als Manier van Leven 
- door Jonna
- Marielle’s University - over M1M0 - Coderen Leren Kan Leuk Zijn! 
https://getmimo.com

- De Zeepkist - Kom in de show! Open Vloer. Wie wil en durft!

Met groet,

Just

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Mike N


On 9/27/2020 11:22 PM, Jack Burke wrote:

I'm on Slack, and I originally posted a comment about this editor on
some roads in Florida (that I'm familiar with), but the responses I
saw seemed to be somewhat "meh" so I didn't pursue it.


  There are so many small arguments "this is a trunk" "no, a motorway" 
"no, primary", so it's often hard to give a firm fact based opinion. 
I'd say this goes a bit beyond that.


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites


On 28/09/2020 10:56, Philip Barnes wrote:

On Mon, 2020-09-28 at 10:10 +0100, Mark Goodge wrote:

On 28/09/2020 10:00, Frederik Ramm wrote:


Remember: OSM is not an IT project.

Indeed not. But this is also a good example of the truism that OSM
is
not a map, it's a database. Having the right data in the database
matters. Fixing clear and obvious errors, such as invalid URLs in a
"website" tag, seems to me to be a worthwhile project if someone is
prepared to put the time and effort into doing it.


Although in my experience the concept of pubs having websites is kind
of dated, typically online communication with customers is via facebook
these days.


Anything other than your experience, as mine is the opposite. Facebook 
is for short lifespan messages not information which needs to be 
repeatedly accessed (menus, opening times etc)

Simply fixing invalid urls is not really a solution, the question needs
to be asked is this data still valid and rather than a mechanical fix
these entries need to be visited and checked.


Two, separate endeavours.

DaveF

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-us] Recent Trunk road edits

2020-09-28 Thread Mike N


On 9/27/2020 11:22 PM, Jack Burke wrote:

and he has a diary
entry about what he's doing (in addition to what he has on his profile
page about it).  He changed*every single*  trunk road in Georgia to
primary, and from what I can tell, in Florida, too.  I haven't yet
expanded my examination into other states yet.



  Eliminating an OSM class of road in an entire state is an indicator 
of someone with an internal ruleset - something as simple as they don't 
like the color of Mapnik trunk roads in the current rendering scheme.


  It's interesting that someone from Indonesia added some observations 
about eastern US trunk roads to the wiki (which makes no sense). 
https://wiki.openstreetmap.org/w/index.php?title=Tag:highway%3Dtrunk=1959532=1959503


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Tagging an abandoned path?

2020-09-28 Thread Nick Whitelegg


Thanks for the replies, will probably go with something like overgrown=yes.

The path concerned has not been closed - it looks like a forestry track which 
was formerly used by vehicles but hasn't for many years. However, unlike many 
of the paths in the same area it doesn't appear to be popular as a 'desire 
path' and is definitely less pleasurable to negotiate than many of the others 
in the area. Just wanted some way of distinguishing this path from others in 
the area in active use, so that those seeking a 'nice walk in the woods' could 
avoid it!

Nick


From: Andrew Harvey 
Sent: 26 September 2020 03:58
To: Talk Openstreetmap 
Subject: Re: [OSM-talk] Tagging an abandoned path?

Abandoned is a tricky concept for a path, what make is abandoned? If there is a 
sign up saying track closed or keep out for re-vegetation it's clear, but 
otherwise it's less clear.

On Sat, 26 Sep 2020 at 01:36, Andy Townsend 
mailto:ajt1...@gmail.com>> wrote:
Once it's definitely disappeared, I'd have no qualms about deleting it 
altogether.  Sometimes I update the tags on a path before deleting it to 
something like "note=nothing on this alignment any more".

If there is still some evidence on the ground, I think using the lifecycle 
prefix is preferable because usually it takes a few years for a path to be 
completely revegetated and provides a more accurate picture of what's happening 
on the ground and helps data consumers track the it through the different 
states.

On Sat, 26 Sep 2020 at 02:06, Mike Thompson 
mailto:miketh...@gmail.com>> wrote:
I use:
disused:highway=path/footway/etc
or
abandoned:highway=path/footway/etc

I have used that too where it really is closed via signage, but if it's just 
overgrown from lack of use, it could still be in active use.

On Sat, 26 Sep 2020 at 02:55, Andy Townsend 
mailto:ajt1...@gmail.com>> wrote:
Indeed - https://taginfo.openstreetmap.org/keys/overgrown has some usage

I didn't know about that, usually I've just been adding description=overgrown, 
but that tag is better. It's in need of some discussion and documentation 
though to make it not subjective.

I suggest overgrown=yes would apply if you're constantly brushing against the 
vegetation (not just occasionally but to the the point that you're almost 
always in contact with the vegetation for the whole segment).

Then light if it has negligible affect on walking pace, dense if it slows you 
down considerably.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread Frederik Ramm

Hi,

On 28.09.20 13:53, Dave F wrote:
> Anyone can contribute to OSM in ways that best suits them.
> He's here asking for advice & guidance

... and that's what he got from me. You're free to give different
advice, though I didn't find yours convincing in any way.

In my opinion the improvement that can be made by investing one hour in
a survey - any survey really - far outweighs the improvement that can be
made by investing one hour in automatically adding a string of
characters to a certain tag. And even besides that, I am not alone in
recommending that anyone getting more involved with OSM should do some
mapping first, before they embark on anything else. Just to know what
we're about.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Simplification représentation "Cédez-le-passage cycliste au feu"

2020-09-28 Thread Vincent de Château-Thierry

Bonjour,

> De: "Éric Gillet" 

> C'est plus complexe qu'un seul tag sur un seul nœud, de là à dire
> "hyper-complexe" pas sûr. Le monde est complexe, pas tout n'est
> forcément cartographiable facilement. 

Pour moi c'est le coeur du sujet ici.

On passe notre temps à modéliser le terrain pour le faire entrer dans une base 
de données, avec la conviction que ce qu'on fait peut servir à d'autres, et 
sans préjuger des usages. Dans le cas d'un cédez-le-passage cycliste, on peut 
se demander à quoi donc cela peut servir. Un domaine d'usage reconnu est l'aide 
à la mobilité, quand on veut exploiter la base OSM pour proposer un trajet, un 
itinéraire, voire un guidage en temps réel. Et dans ces contextes, où un 
algorithme va devoir interpréter les données qu'on a saisies, il faut autant 
que possible supprimer les ambiguïtés, afin que le robot fonctionne au mieux.

Pour le guidage, mentionner une manoeuvre implique à la fois de savoir d'où on 
vient et où on va. Ca permet de donner des instructions comme "tournez à 
droite", etc. C'est là que les relations OSM sont utiles, car elles décrivent 
un parcours, depuis un axe (role from) vers un autre axe (role to) en passant 
par un certain point (role via). Ces 3 infos sont précieuses, et on n'a pas 
d'autre formalisme que les relations pour les renseigner. C'est plus lourd 
qu'un simple point, mais beaucoup moins ambigu, donc plus utile. On augmente la 
valeur des données en allant à ce niveau de détail, clairement.

> Certains pourraient suggérer une approche hybride (panneau quand pas
> d'ambiguïté, relation quand ambiguïté possible), mais ça veut dire
> implémenter logiciellement (et faire comprendre aux contributeurs)
> les deux manières de cartographier, ce qui me semble empirer le
> problème.

D'accord avec ça. Les modélisations multiples sont parfois un mal nécessaire 
dans OSM (exemple typique : les relations associatedStreet vs les simples nodes 
addr:housenumber & addr:street) mais quand on part d'une situation assez 
uniforme comme dans le cas des cédez-le-passage cycliste, je trouverais dommage 
qu'on évolue vers une modélisation multiple, hétérogène et plus complexe à 
consommer.

vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Vecchi sentieri CAI

sent from a phone

> On 28. Sep 2020, at 11:35, Volker Schmidt  wrote:
> 
> Non è generalizzabile.
> Localmente abbiamo, nei Colli Euganei, dei sentieri cui segnaletica è la 
> piccola manutenzione è curata dal CAI Padova, ma sotto contratto con il Parco 
> dei Colli Euganei per alcuni e singoli comuni per altri di questi sentieri.
> In termini pratici, non so come l'utente finale (turista) può saperlo, e come 
> funziona, ma nel senso del tag "operatore" questi sentieri ne hanno due.

per il tag operator questa è una situazione abbastanza comune: si trovano più 
responsabili dietro una cosa. Pensa alle strade, dove ci potrebbe essere ANAS 
ma poi dietro il ministero delle infrastrutture e del trasporto. In 
OpenStreetMap ci interessa solitamente il diretto responsabile (o quello che il 
mappatore ritiene più appropriato da mettere), solitamente colui che veramente 
fa il lavoro o che è visibile all’esterno.

Ciao Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites




On 28/09/2020 10:00, Frederik Ramm wrote:

Rodrigo,

On 27.09.20 17:28, Rodrigo Díez Villamuera wrote:

After some time using OSM as a user, I decided to make my first step as
a contributor, hence this email and the proposal inside.

If your first idea of "how to contribute to OSM" is "how to write a
script that runs an automated edit on the body of OSM data", then
something is amiss!


Anyone can contribute to OSM in ways that best suits them.
He's here asking for advice & guidance & appears to be following the 
rules..



The change you plan to execute is of limited use. Yes, it ensures more
conformity in the data, but it will be a temporary fix (since new
"wrong" URLs can be added at any time).


Moot. Your claim applies to all tags, all the time. By your logic we 
might as well not amend anything.



Anyone consuming OSM data must
be able to work with URLs that miss a schema, and indeed today any
browser can do that.


I noted links without http or www. ie zonzorestaurant.com isn't 
recognized by OSM website, but is interpreted by web browsers.



So what your edit does is, it "touches" lots of objects and adds no
meaningful information whatsoever.


Conformity, accuracy.


  It creates load on the database;


Seriously? For how long?


it creates a new version of every object you touch which, informationally
speaking, is identical to the old version. It produces larger diff
files, larger history files, and on top of that runs the risk of making
data look more current than it is ("oh, this pub has last been changed
by someone two months ago, so surely it will still be in business" when
in fact the last OSMer who saw that pub with their own eyes did so five
years ago).


These are nit-picking excuses, that occur with all edits.

Unsure why some are against improving the quality of the database, 
especially by automated/mass edit*. Having one user amend hundreds of 
tags is the same as have hundreds of contributors amending individual 
tags, except there're all  checkable within one changeset & can *easily* 
be reverted if required.


* Please remember those who conceived this anti mass edit ruling were 
the ones who messed up the US TIGER import & couldn't be bothered to fix it.




There are many, many better ways to contribute to OSM than runnning a
useless automated conformity edit. Take a notebook or mobile editor, go
outside, check if the phone booths on OSM are still there on the ground,
add a few opening times, or even trees for that matter - a single hour
of such original work is more useful to OSM that what you are proposing
here.


This is my retort to the requests to join OSMF & sit through long, 
tedious committee meetings.

Again, we contribute to OSM in the way which best suits us.


Remember: OSM is not an IT project.


Tell that to the organisers/speakers at State of the Maps


DaveF

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-nl] Importing trees in Utrecht

2020-09-28 Thread Pander


On 9/28/20 12:07, Pander via Talk-nl wrote:
> On 9/27/20 19:25, Sebastiaan Couwenberg wrote:
>> On 9/27/20 6:44 PM, Pieter van Mill via Talk-nl wrote:
>>> If there are any comments I would love to hear them,
>> More mappers are active on the forum, you'll get more feedback there.
>>
>>  https://forum.openstreetmap.org/viewforum.php?id=12
>>
>> Since you only talk about importing, also think about how the data will
>> be updated.
> And how to merge with existing trees that are (almost) on the same
> location to prevent duplicates. This step could also be repeated with
> update actions. Probably a generated list of possible duplicates that
> have to be merged semi automatically. Must be tools for this available
> already. Note that exiting trees can have more data, so that should be
> kept in the merge.
Note, StreetComplete also adds details to trees that should not get lost
in uploads or upgrades.
>> Kind Regards,
>>
>> Bas
>>
> ___
> Talk-nl mailing list
> Talk-nl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-nl

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread Andy Townsend


On 27/09/2020 16:28, Rodrigo Díez Villamuera wrote:


I am importing a subset of nodes from UK (those tagged with 
amenity:pub) for a pet project.


Firstly - welcome!




When analysing the data I realised that some of these nodes contain a 
website: tag that does not contain an appropriate URL schema (http/https).


Ie: www.mypub.com  rather than 
http://www.mypub.com  or https://www.mypub.com 



I'm not actually convinced that's a problem - as others have said, web 
browsers are perfectly capable of converting "www.mypub.com" into either 
"https://www.mypub.com"or ""http://www.mypub.com"as appropriate, so this 
doesn't really add any value.  "Letting the browser sort it out" is a 
great approach as it can deal with now/near future things such as 
removal TLS 1.0 and 1.1 support as well.





This goes in contradiction with the Wiki documentation for website. 



Unfortunately, OSM's wiki doesn't always reflect actual usage and this 
is one example.  Changing "www.mypub.com" to "https://www.mypub.com; 
doesn't really add any value unless you're actually updating something 
else about the pub.  Actually, using "www.mypub.com" has some advantages 
here as it allows the user's web browser to negotiate https if available 
(the default nowadays) but fall back to http if not.




I created a proposal for a one-off, scoped, automated edit for these 
nodes to find the appropiate scheme for the existing URL and retag the 
nodes.


I added the proposal to the Automated edits log. You can read it here 
.



What would be rather more interesting would be detecting websites that 
"don't or no longer represent the pub" in some way:


 * Perhaps the pub had a website, but now has new tenants, and they now
   communicate with customers on the facebook page?
 * Perhaps the website is (like one of your examples) just for the brewery?
 * Perhaps the website now points at domain parking?
 * Perhaps the https certificate has expired, which at the very least
   indicates that the website is unlikely to be kept up to date?

Any problems found would likely need to be resolved manually, but some 
at least of the above should be detectable automatically.


Best Regards,

Andy


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-nl] Importing trees in Utrecht

2020-09-28 Thread St Niklaas

Beste Pieter van Mill,

Het klinkt aardig, maar een korte en vluchtige blik brengt enige lacunes aan 
het licht. De database zou slechts de Utrechtse bomen behelsen, maar niet de er 
naast staande andere bomen.
Dit kwam aan het licht bij een blik op bijvoorbeeld Fort bij Rhijnauwen, 
gelegen midden in het Amelisweerdse landgoed.
Dat brengt me op eerder aangeroerde acties als controle en updates, 150.000 is 
nogal een groot aantal, is het misschien een idee om de import slechts dan uit 
te voeren als er een werkgroep >1 aan mee werkt en ook de noodzakelijke 
controles (als noodzakelijk) uitvoerd.
Deze methode is ook bij de BAG import gevolgd, geen import zonder lokale en 
plaatselijk controle !

Hendrikklaas

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Importing trees in Utrecht

2020-09-28 Thread St Niklaas



Van: Pieter van Mill via Talk-nl 
Verzonden: zondag 27 september 2020 18:44
Aan: impo...@openstreetmap.org ; 
talk-nl@openstreetmap.org 
CC: pie...@osmstart.com 
Onderwerp: [OSM-talk-nl] Importing trees in Utrecht

Hello everyone,

I would like to start a project to import trees in the city of Utrecht, The 
Netherlands.

The wiki page of this project can be found here: 
https://wiki.openstreetmap.org/wiki/Utrecht_tree_import

Before I do more work on this project I would like to see if this is a good 
project to do. The data that could be imported can be found on this map: 
https://gemu.maps.arcgis.com/apps/webappviewer/index.html?id=53c67672c1fa46e5bef555a611b58301

The license for the dataset is CC-0 which makes it compatible with the ODbL 
license.

If there are any comments I would love to hear them,

Pieter (pcmill)

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [OSM-talk-nl] Importing trees in Utrecht

2020-09-28 Thread Pander via Talk-nl


On 9/27/20 19:25, Sebastiaan Couwenberg wrote:
> On 9/27/20 6:44 PM, Pieter van Mill via Talk-nl wrote:
>> If there are any comments I would love to hear them,
> More mappers are active on the forum, you'll get more feedback there.
>
>  https://forum.openstreetmap.org/viewforum.php?id=12
>
> Since you only talk about importing, also think about how the data will
> be updated.
And how to merge with existing trees that are (almost) on the same
location to prevent duplicates. This step could also be repeated with
update actions. Probably a generated list of possible duplicates that
have to be merged semi automatically. Must be tools for this available
already. Note that exiting trees can have more data, so that should be
kept in the merge.
>
> Kind Regards,
>
> Bas
>

___
Talk-nl mailing list
Talk-nl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-nl

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread Andy Townsend


On 28/09/2020 10:25, Dave F via Talk-GB wrote:


Anyone know if there's a way to at least use a UK based server or to 
conveniently ping multiple websites directly? 


In this case I don't see how that helps - it wouldn't detect domain 
parking pages, which is usually where a domain goes after the business 
that registers it folds and the domain has actual words in it (often the 
case here I suspect).


Best Regards,

Andy



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread Philip Barnes

On Mon, 2020-09-28 at 10:10 +0100, Mark Goodge wrote:
> 
> On 28/09/2020 10:00, Frederik Ramm wrote:
> 
> > Remember: OSM is not an IT project.
> 
> Indeed not. But this is also a good example of the truism that OSM
> is 
> not a map, it's a database. Having the right data in the database 
> matters. Fixing clear and obvious errors, such as invalid URLs in a 
> "website" tag, seems to me to be a worthwhile project if someone is 
> prepared to put the time and effort into doing it.
> 
Although in my experience the concept of pubs having websites is kind
of dated, typically online communication with customers is via facebook
these days.

Simply fixing invalid urls is not really a solution, the question needs
to be asked is this data still valid and rather than a mechanical fix
these entries need to be visited and checked. Easy at the moment as any
valid site will have recent covid (table service/one way systems and
facemask information).

A simple sanity check of the three examples, and my browser does click
through without an issue.

The first does appear to be valid, although part of a large chain hence
the pub hence has IT support.

The second https://www.openstreetmap.org/node/20940218 leads to an
invalid url so a simple fix would be wrong.

The third https://www.openstreetmap.org/node/21648679 leads to the pub
operating companys site, a url should be for the actual object not the
owning company. 

All of the examples I note are from Cambridge, which is certainly not
typical of the UK in general.

Phil (trigpoint)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread Rodrigo Díez Villamuera

Thanks for your replies,

Frederik thanks for your reply and advice as well. I know it comes from a
good place and from the experience of working on this project, which I
respect.

However, please allow me to humbly disagree with the overall message as I
think it makes some assumptions, generalizations and false dilemmas. Also
please take my comments on a constructive way

The fact that I am addressing this community to talk about a specific
proposal does not mean that my contribution to OSM will be limited to it.

Your comment seems to assume that the fix will be temporary and dismiss it
for it, but my idea is for this change to be a first baby step which
hopefully can evolve into a more permanent and recurrent process. By
dismissing the former because of its limited usage we are killing the later.

"Anyone consuming OSM data must be able to work with URLs that miss a
schema", from an engineering perspective we are introducing lots of
unnecessary work to the project ecosystem, especially consumers. A problem
that can be solved easily in origin is ignored and we force all consumers
to implement workaround independently potentially leading to
inconsistencies in how users see OSM data. I myself had to implement a
temporary workaround.

Another wrong assumption is that :website tags are only consumed by
browsers. This is definitely not the case.

Regarding the overhead and load in the database, I confess that I am not
quite familiar with the implications of an edit like that. Thanks for
pointing it out, I will definitely try to get more familiar with it

I have to disagree with your comment regarding the changes adding "no
meaninful information whatsoever". With a 22% of websites that can be
migrated to an https scheme and being http highly discouraged and
considered plainly unsafe by all major browsers, these changes will
positively impact end users and the owners of the amenities themselves.

You say that there are multiple better ways to contribute to OSM and this,
although it may be 100% true IMHO is a false dilemma. The fact that I am
proposing to fix an issue in the data does not imply my contribution will
end there.

Think for a second about the content of your message if who was reading it
was an impaired person who can't go outside with a notebook and browse pubs
around but rather has to stay at home with IT being their only way of
contribute to the project. This is not my case, but, did you know about it
beforehand?

--
Rodrigo Díez Villamuera

w: http://rodrigodiez.io
t: @rodrigodiez_pro
p: 00 44 7513 638225

On Mon, 28 Sep 2020 at 10:28, Dave F via Talk-GB 
wrote:

> On 27/09/2020 19:35, Andrew Hain wrote:
>
> Keep Right flags web links that have gone offline.
>
>
> Unfortunately it doesn't really do that. After a discussion with the
> developer I found out it tests whether a server in central Europe has a
> link to the UK URLs not if the actual link is current. I was coming across
> far too many time consuming false-positives for it to be useful.
>
> Anyone know if there's a way to at least use a UK based server or to
> conveniently ping multiple websites directly?
>
> DaveF
>
>
>
> --
> Andrew
> --
> *From:* Philip Barnes  
> *Sent:* 27 September 2020 18:49
> *To:* talk-gb@openstreetmap.org 
> 
> *Subject:* Re: [Talk-GB] Hello world and automated change proposal: Add
> missing URL scheme on UK's Pubs websites
>
> On Sun, 2020-09-27 at 16:28 +0100, Rodrigo Díez Villamuera wrote:
>
> Hi all,
>
> First of all, I would like to introduce myself on this email list and to
> thank you all for your contributions to OSM. Great work!
>
> After some time using OSM as a user, I decided to make my first step as a
> contributor, hence this email and the proposal inside.
>
> Please bear in mind that this is my first attempt to contribute with a
> proposal and, although I have done my best reading the community
> conventions and best practices, I am sure I have made some mistakes on the
> way. Be merciful! :P
>
> To the point now.
>
> I am importing a subset of nodes from UK (those tagged with amenity:pub)
> for a pet project.
>
> When analysing the data I realised that some of these nodes contain a
> website: tag that does not contain an appropriate URL schema (http/https).
>
> Ie: www.mypub.com rather than http://www.mypub.com or
> https://www.mypub.com
>
> This goes in contradiction with the Wiki documentation for website.
> 
>
> I created a proposal for a one-off, scoped, automated edit for these nodes
> to find the appropiate scheme for the existing URL and retag the nodes.
>
> I added the proposal to the Automated edits log. You can read it here
> 
> .
>
> Just wanted to share the proposal with the UK community, gather your
> feedback, comments and advises on how to proceed from here
>
> One issue I can think of with

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread ndrw


On 27/09/2020 16:28, Rodrigo Díez Villamuera wrote:

Hi all,

First of all, I would like to introduce myself on this email list and 
to thank you all for your contributions to OSM. Great work!


After some time using OSM as a user, I decided to make my first step 
as a contributor, hence this email and the proposal inside.


Please bear in mind that this is my first attempt to contribute with a 
proposal and, although I have done my best reading the community 
conventions and best practices, I am sure I have made some mistakes on 
the way. Be merciful! :P


To the point now.

I am importing a subset of nodes from UK (those tagged with 
amenity:pub) for a pet project.


When analysing the data I realised that some of these nodes contain a 
website: tag that does not contain an appropriate URL schema (http/https).


Ie: www.mypub.com  rather than 
http://www.mypub.com or https://www.mypub.com


This goes in contradiction with the Wiki documentation for website. 




The proposed procedure looks good and since the scale is so small (127 
records) it's not very different from performing it by hand. IMHO it's a 
good mini project for starting your journey with osm.



I would go a step further though:

"If no valid scheme is found, do nothing" - that's OK, but as the next 
step please could you *manually* verify these links and either fix them 
or add a fixme tag.


Ndrw



___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Simplification représentation "Cédez-le-passage cycliste au feu"

2020-09-28 Thread Éric Gillet


Le 28/09/2020 à 11:02, Axel Listes a écrit :

Bonjour,

Le 28/09/2020 à 09:40, Éric Gillet a écrit :

Donc, dans le schéma d'origine que je découvre, il faudrait trois

relations.

Mais les éditeurs facilitent la création de telles relations.

Exactement ça me semble être une question d'éditeurs plus qu'une
question de tags/objets OSM.

Alors voici globalement les « défauts » qui en découlent :
- Les multiples césures des chemins, il faut les couper à l'emplacement
du point « via » de la relation.


Dans la plupart des cas l'intersection sera composée de 2 voies de la 
manière suivante : -|-, donc ça fait 2 coupures au maximum. J'ai 
l'impression que les intersections plus complexes avec + de voies (donc 
plus dangereuses) n'ont pas de cédez-le-passage tout-droit ou à gauche.



- La maintenance, comme toutes relations, celles-ci sont susceptibles
d’être cassées lorsque qu'un contributeur débutant ou non vigilant
intervient sur l'un des éléments intégrés dans la relation.


Oui en effet, mais ça malheureusement il n'y a pas de solution. Même 
avec une myriade d'avertissement des contributeurs arrivent 
régulièrement à fusionner des nœuds de routes 1km plus loin sur iD. 
Pourtant ce sont des opérations simple (fusion de nœuds) sur des 
"données simples" (nœuds, pas de relation), donc je ne suis pas sûr que 
ce soit un problème de complexité du modèle de données.


Si l'éditeur a une vue dédiée aux cédez-le-passage, il serait sûrement  
facile de mettre cette vue lors d'erreurs de validation pour faire 
corriger le contributeur.



Les systèmes
de suivi d’éditions ont plus de difficultés à donner des informations
concernant des éditions de relations que de points (Achavi, OSMcha ...)
Oui en effet. Je pense que c'est l’œuf et la poule, il y a beaucoup plus 
de modifications (et donc d'erreurs à surveiller) sur les nœuds et 
voies, donc plus d'attention est portée à leur rendu.

- La complexité de l'usage des relations, honnêtement pourquoi
obligatoirement passer par un système hyper complexe alors que l'on peut
juste ajouter une balise sur un point pour arriver au même résultat ?
L'exemple d'Éric est intéressant, car il permet de se poser cette
question : Une balise sur un point déjà existant ou trois relations ?


C'est plus complexe qu'un seul tag sur un seul nœud, de là à dire 
"hyper-complexe" pas sûr. Le monde est complexe, pas tout n'est 
forcément cartographiable facilement. Par exemple on pourrait dire qu'il 
serait plus simple de cartographier les arbres de la manière suivante :


natural=tree
espece=platane

Au lieu de :

natural=tree
genus=Platanus
species=Platanus × hispanica
deciduous=leaf_cycle
leaf_type=broadleaved

Mais ça me semble pas pertinent pour une base de données.

Pour revenir sur les panneaux, il faut se demander ce que l'on veut 
cartographier : le panneau (ce que tu suggères si j'ai bien compris) ou 
son effet.


Panneau :

 * Plus simple à cartographier
 * Ne représente que le panneau, et nécessite donc une interprétation
   pour savoir quelle voie sont concernées. Cette interprétation est
   potentiellement différente par pays/état.

Relations:

 * Plus complexe à cartographier
 * Pas d'ambiguïté pour les utilisateurs

Certains pourraient suggérer une approche hybride (panneau quand pas 
d'ambiguïté, relation quand ambiguïté possible), mais ça veut dire 
implémenter logiciellement (et faire comprendre aux contributeurs) les 
deux manières de cartographier, ce qui me semble empirer le problème.


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Vecchi sentieri CAI

2020-09-28 Thread Volker Schmidt

On Mon, 28 Sep 2020 at 10:43, Martin Koppenhoefer 
wrote:

> farei distinzione tra highway e route. Il comune sarebbe l’operator del
> highway mentre il cai della route. È il cai che assegna il numero e mette i
> cartelli e segni della route.
>

Non è generalizzabile.
Localmente abbiamo, nei Colli Euganei, dei sentieri cui segnaletica è la
piccola manutenzione è curata dal CAI Padova, ma sotto contratto con il
Parco dei Colli Euganei per alcuni e singoli comuni per altri di questi
sentieri.
In termini pratici, non so come l'utente finale (turista) può saperlo, e
come funziona, ma nel senso del tag "operatore" questi sentieri ne hanno
due. :-(

Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites


On 27/09/2020 19:35, Andrew Hain wrote:

Keep Right flags web links that have gone offline.


Unfortunately it doesn't really do that. After a discussion with the 
developer I found out it tests whether a server in central Europe has a 
link to the UK URLs not if the actual link is current. I was coming 
across far too many time consuming false-positives for it to be useful.


Anyone know if there's a way to at least use a UK based server or to 
conveniently ping multiple websites directly?


DaveF




--
Andrew

*From:* Philip Barnes 
*Sent:* 27 September 2020 18:49
*To:* talk-gb@openstreetmap.org 
*Subject:* Re: [Talk-GB] Hello world and automated change proposal: 
Add missing URL scheme on UK's Pubs websites

On Sun, 2020-09-27 at 16:28 +0100, Rodrigo Díez Villamuera wrote:

Hi all,

First of all, I would like to introduce myself on this email list and 
to thank you all for your contributions to OSM. Great work!


After some time using OSM as a user, I decided to make my first step 
as a contributor, hence this email and the proposal inside.


Please bear in mind that this is my first attempt to contribute with 
a proposal and, although I have done my best reading the community 
conventions and best practices, I am sure I have made some mistakes 
on the way. Be merciful! :P


To the point now.

I am importing a subset of nodes from UK (those tagged with 
amenity:pub) for a pet project.


When analysing the data I realised that some of these nodes contain a 
website: tag that does not contain an appropriate URL schema 
(http/https).


Ie: www.mypub.com  rather than 
http://www.mypub.com  or https://www.mypub.com


This goes in contradiction with the Wiki documentation for website. 



I created a proposal for a one-off, scoped, automated edit for these 
nodes to find the appropiate scheme for the existing URL and retag 
the nodes.


I added the proposal to the Automated edits log. You can read it here 
.


Just wanted to share the proposal with the UK community, gather your 
feedback, comments and advises on how to proceed from here


One issue I can think of with pubs and websites is that they need 
checking to ensure they are still current.


The defacto method most pubs use to communicate with customers is 
facebook.


A more general fix of urls missing http(s)://, why only pubs?.  is 
probably a maproulette quest.


Phil (trigpoint)


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

Thank you Frederik - that's a good way to put it all.

Welcome Rodrigo! You'll find that Frederik's advice fits pretty well
to a common strand of thinking in OpenStreetMap. His advice is
surprising, for many of us joining OSM from an IT background (or even
a Wikipedia background, where automated edits are more widespread).
But please do take some time to think about his advice.

Best wishes
Dan

Op ma 28 sep. 2020 om 10:02 schreef Frederik Ramm :
>
> Rodrigo,
>
> On 27.09.20 17:28, Rodrigo Díez Villamuera wrote:
> > After some time using OSM as a user, I decided to make my first step as
> > a contributor, hence this email and the proposal inside.
>
> If your first idea of "how to contribute to OSM" is "how to write a
> script that runs an automated edit on the body of OSM data", then
> something is amiss!
>
> The change you plan to execute is of limited use. Yes, it ensures more
> conformity in the data, but it will be a temporary fix (since new
> "wrong" URLs can be added at any time). Anyone consuming OSM data must
> be able to work with URLs that miss a schema, and indeed today any
> browser can do that.
>
> So what your edit does is, it "touches" lots of objects and adds no
> meaningful information whatsoever. It creates load on the database; it
> creates a new version of every object you touch which, informationally
> speaking, is identical to the old version. It produces larger diff
> files, larger history files, and on top of that runs the risk of making
> data look more current than it is ("oh, this pub has last been changed
> by someone two months ago, so surely it will still be in business" when
> in fact the last OSMer who saw that pub with their own eyes did so five
> years ago).
>
> There are many, many better ways to contribute to OSM than runnning a
> useless automated conformity edit. Take a notebook or mobile editor, go
> outside, check if the phone booths on OSM are still there on the ground,
> add a few opening times, or even trees for that matter - a single hour
> of such original work is more useful to OSM that what you are proposing
> here.
>
> Remember: OSM is not an IT project.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread Mark Goodge




On 28/09/2020 10:00, Frederik Ramm wrote:


Remember: OSM is not an IT project.


Indeed not. But this is also a good example of the truism that OSM is 
not a map, it's a database. Having the right data in the database 
matters. Fixing clear and obvious errors, such as invalid URLs in a 
"website" tag, seems to me to be a worthwhile project if someone is 
prepared to put the time and effort into doing it.


Mark

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Simplification représentation "Cédez-le-passage cycliste au feu"

2020-09-28 Thread Axel Listes

Bonjour,

Le 28/09/2020 à 09:40, Éric Gillet a écrit :
>> > Donc, dans le schéma d'origine que je découvre, il faudrait trois
>> relations.
>>
>> Mais les éditeurs facilitent la création de telles relations.
> 
> Exactement ça me semble être une question d'éditeurs plus qu'une
> question de tags/objets OSM.

Alors voici globalement les « défauts » qui en découlent :
- Les multiples césures des chemins, il faut les couper à l'emplacement
du point « via » de la relation.
- La maintenance, comme toutes relations, celles-ci sont susceptibles
d’être cassées lorsque qu'un contributeur débutant ou non vigilant
intervient sur l'un des éléments intégrés dans la relation. Les systèmes
de suivi d’éditions ont plus de difficultés à donner des informations
concernant des éditions de relations que de points (Achavi, OSMcha ...)
- La complexité de l'usage des relations, honnêtement pourquoi
obligatoirement passer par un système hyper complexe alors que l'on peut
juste ajouter une balise sur un point pour arriver au même résultat ?
L'exemple d'Éric est intéressant, car il permet de se poser cette
question : Une balise sur un point déjà existant ou trois relations ?

Axel.

-- 

"Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne
mérite ni l'une ni l'autre, et finit par perdre les deux."
Citation de Benjamin Franklin.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread Frederik Ramm

Rodrigo,

On 27.09.20 17:28, Rodrigo Díez Villamuera wrote:
> After some time using OSM as a user, I decided to make my first step as
> a contributor, hence this email and the proposal inside.

If your first idea of "how to contribute to OSM" is "how to write a
script that runs an automated edit on the body of OSM data", then
something is amiss!

The change you plan to execute is of limited use. Yes, it ensures more
conformity in the data, but it will be a temporary fix (since new
"wrong" URLs can be added at any time). Anyone consuming OSM data must
be able to work with URLs that miss a schema, and indeed today any
browser can do that.

So what your edit does is, it "touches" lots of objects and adds no
meaningful information whatsoever. It creates load on the database; it
creates a new version of every object you touch which, informationally
speaking, is identical to the old version. It produces larger diff
files, larger history files, and on top of that runs the risk of making
data look more current than it is ("oh, this pub has last been changed
by someone two months ago, so surely it will still be in business" when
in fact the last OSMer who saw that pub with their own eyes did so five
years ago).

There are many, many better ways to contribute to OSM than runnning a
useless automated conformity edit. Take a notebook or mobile editor, go
outside, check if the phone booths on OSM are still there on the ground,
add a few opening times, or even trees for that matter - a single hour
of such original work is more useful to OSM that what you are proposing
here.

Remember: OSM is not an IT project.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Simplification représentation "Cédez-le-passage cycliste au feu"

2020-09-28 Thread Axel Listes

Bonjour,

Le 27/09/2020 à 22:35, osm.sanspourr...@spamgourmet.com a écrit :
> Sauf que si tu mets ça sur un point, comment savoir de quelle route tu
> parles si la voie piétonne est autorisée aux cycles.

Dans le cas d’existence d'une rue ou place piétonne autorisées aux
cyclistes (à l'allure du pas donc), alors la solution est la même que
pour tous carrefours ou le vélo ne peut pas céder-le-passage vers toutes
les directions disponibles : on utilise le système de relations.

L'idée n'est pas de remplacer les relations, mais d’éviter de les
utiliser pour des cas simples.

> En deux mots : simple mais pas pris en compte par les outils. Devrait
> donc passer par une proposition officielle notant cela.

À ma connaissance les relations non plus ne sont pas prises en compte.
C'est justement le bon moment pur tout remettre à plat ...

Axel.

-- 

"Un peuple prêt à sacrifier un peu de liberté pour un peu de sécurité ne
mérite ni l'une ni l'autre, et finit par perdre les deux."
Citation de Benjamin Franklin.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Hello world and automated change proposal: Add missing URL scheme on UK's Pubs websites

2020-09-28 Thread Rodrigo Díez Villamuera

Thanks for your replies!

Regarding the question of why I am proposing to fix only pubs in this run.
I think it would be good to try this script with a reduced scope of nodes
first before raising a more global conversation. I imagine changesets will
be easy to retrieve and un-do.

Worth mentioning that, for the majority of the nodes affected, the websites
are not incorrect per-se, but they are not URLs because they miss a scheme.
This will cause problems to consumers depending on how they use the field
(I first noticed this issue when passing the :website tag to a third party
library which complained about this)

I ran the script on a local database and I have some numbers:

For a total of 159 :amenity=pub nodes with missing scheme on their :website

- 41 (~26%) can be updated with https as a scheme (safer for the end-user)
- 92 (~58%) don't work on https but http can be added as a scheme
- 26 (~16%) seem to be offline, not accessible neither on http or https
(maybe they can be automatically tagged for fixing? thoughts?)

How do I proceed from here? I have a small subset of nodes to test the
proposal with, I have tried the script locally with good results and I
believe the proposal makes the dataset better for consumers and safer for
end-users by adding an https URL to websites that support it

--
Rodrigo Díez Villamuera

w: http://rodrigodiez.io
t: @rodrigodiez_pro
p: 00 44 7513 638225



On Sun, 27 Sep 2020 at 19:38, Andrew Hain 
wrote:

> Keep Right flags web links that have gone offline.
>
> --
> Andrew
> --
> *From:* Philip Barnes 
> *Sent:* 27 September 2020 18:49
> *To:* talk-gb@openstreetmap.org 
> *Subject:* Re: [Talk-GB] Hello world and automated change proposal: Add
> missing URL scheme on UK's Pubs websites
>
> On Sun, 2020-09-27 at 16:28 +0100, Rodrigo Díez Villamuera wrote:
>
> Hi all,
>
> First of all, I would like to introduce myself on this email list and to
> thank you all for your contributions to OSM. Great work!
>
> After some time using OSM as a user, I decided to make my first step as a
> contributor, hence this email and the proposal inside.
>
> Please bear in mind that this is my first attempt to contribute with a
> proposal and, although I have done my best reading the community
> conventions and best practices, I am sure I have made some mistakes on the
> way. Be merciful! :P
>
> To the point now.
>
> I am importing a subset of nodes from UK (those tagged with amenity:pub)
> for a pet project.
>
> When analysing the data I realised that some of these nodes contain a
> website: tag that does not contain an appropriate URL schema (http/https).
>
> Ie: www.mypub.com rather than http://www.mypub.com or
> https://www.mypub.com
>
> This goes in contradiction with the Wiki documentation for website.
> 
>
> I created a proposal for a one-off, scoped, automated edit for these nodes
> to find the appropiate scheme for the existing URL and retag the nodes.
>
> I added the proposal to the Automated edits log. You can read it here
> 
> .
>
> Just wanted to share the proposal with the UK community, gather your
> feedback, comments and advises on how to proceed from here
>
> One issue I can think of with pubs and websites is that they need checking
> to ensure they are still current.
>
> The defacto method most pubs use to communicate with customers is facebook.
>
> A more general fix of urls missing http(s)://, why only pubs?.  is
> probably a maproulette quest.
>
> Phil (trigpoint)
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] Vecchi sentieri CAI

sent from a phone

> On 28. Sep 2020, at 10:22, danbag--- via Talk-it  
> wrote:
> 
> in Piemonte come già indicato da Ivo esiste la Legge 12 del 2010 che indica 
> essere i Comuni proprietari dei sentieri e ad essi spetta l'obbligo della 
> manutenzione, quindi in teoria in Piemonte il tag operator dovrebbe contenere 
> il nome del Comune.

farei distinzione tra highway e route. Il comune sarebbe l’operator del highway 
mentre il cai della route. È il cai che assegna il numero e mette i cartelli e 
segni della route.

Al riguardo della responsabilità penso  chi va su sentieri dovrebbe essere 
cosciente che non è la stessa cosa che fare una passeggiata in paese. Nessuno 
può garantire che un percorso sia “sicuro”, bisogna sempre stare attenti, 
osservare il percorso, il tempo ecc. La responsabilità del proprietario nonché 
di chi mette la segnaletica è sempre relativa. 

Ciao Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Vecchi sentieri CAI

2020-09-28 Thread danbag--- via Talk-it




Il 28/09/2020 09:43, Martin Koppenhoefer ha scritto:

io penso senza conoscere i tags avrei messo disused:route=hiking
(o abandoned).

Mentre symbol e sopratutto name non avrei modificato. Ne nella chiave 
(disused:name) ne nel valore (ex123), anzi, per il nome credo che fare tutt’e 
due sarebbe quasi sbagliato (ex123 non è il vecchio nome, al massimo è il nome 
attuale).


A questo proposito ricordo che:
1) i sentieri del catasto generale italiano del CAI andrebbero 
codificati nelle relazioni OSM che vengono recepite e visualizzate da 
WMT e da Infomont (catasto del CAI centrale) secondo i criteri definiti 
dal CAI qui 

https://wiki.openstreetmap.org/wiki/CAI

2) nella wiki ricordata è previsto un tag old_ref per scriverci 
l'eventuale codice obsoleto del percorso


3) predisponendo opportunamente i tag previsti nella wiki citata si 
risolvono varie problematiche qui proposte senza andare alla ricerca di 
nuove taggature


Sull’operator sono indeciso, probabilmente va meglio disused:operator perché 
non è più gestito, mentre senza disused: si potrebbe pensare che si tratta di 
un ex sentiero comunque gestito dal cai (nello stato attuale).


A proposito del tag operator, prima di scriverci il nome di un Ente o 
altro è necessario essere al 1000 per 100 sicuri che si occupi realmente 
della sua manutenzione: in Piemonte come già indicato da Ivo esiste la 
Legge 12 del 2010 che indica essere i Comuni proprietari dei sentieri e 
ad essi spetta l'obbligo della manutenzione, quindi in teoria in 
Piemonte il tag operator dovrebbe contenere il nome del Comune. In 
realtà i Comuni disattendono quasi totalmente l'obbligo di manutenzione 
... però espongono ordinanze di divieto di transito quando il sentiero 
diventa pericoloso
Quindi in questo stato di cose vengono stipulate Convenzioni dove le 
singole sezione del CAI si impegnano alla manutenzione di alcuni 
percorsi oggetto della convenzione. Ecco che in questo caso l'operator 
diventa la sezione CAI che ha stipulato la convenzione.Qui un esempio di 
relazione dove la sezione CAI è divenuta l'operator 


https://hiking.waymarkedtrails.org/#route?id=6805420

Ciao
Danilo (danbag)



Cheers Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it




Ciao

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-TW] weeklyOSM reminders dominating list

2020-09-28 Thread weeklyOSM -

... and thanks for the hint with the French list ...

here it one of them
- [OSM-talk-fr] hebdoOSM Nº 528 2020-08-25-2020-08-31

  *theweekly.osm at gmail.com  *

Am Mo., 28. Sept. 2020 um 10:08 Uhr schrieb weeklyOSM - <
theweekly@gmail.com>:

> Hi Dan,
>
> Just ignore it, it costs nothing.
>
> Am Sa., 26. Sept. 2020 um 17:53 Uhr schrieb 積丹尼 Dan Jacobson <
> jida...@jidanni.org>:
>
>> Actually, Talk-TW originally was for talking.
>> Now it is 99% just these
>> [Talk-TW] weeklyOSM #523 2020-07-21-2020-07-26   weeklyteam
>> [Talk-TW] weeklyOSM #524 2020-07-28-2020-08-03   weeklyteam
>> [Talk-TW] weeklyOSM #527 2020-08-11-2020-08-17   weeklyteam
>> reminders.
>>
>> I checked https://lists.openstreetmap.org/listinfo/talk-fr
>> and didn't see any reminders.
>>
>> So maybe Talk-TW should be unsub*scribed too.
>> Let each user personally sub*scribe to the reminders if they want.
>>
>
>
> --
> --
> ## weeklyteam
>


-- 
-- 
## weeklyteam
___
Talk-TW mailing list
Talk-TW@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-tw

Re: [Talk-TW] weeklyOSM reminders dominating list

2020-09-28 Thread weeklyOSM -

Hi Dan,

Just ignore it, it costs nothing.

Am Sa., 26. Sept. 2020 um 17:53 Uhr schrieb 積丹尼 Dan Jacobson <
jida...@jidanni.org>:

> Actually, Talk-TW originally was for talking.
> Now it is 99% just these
> [Talk-TW] weeklyOSM #523 2020-07-21-2020-07-26   weeklyteam
> [Talk-TW] weeklyOSM #524 2020-07-28-2020-08-03   weeklyteam
> [Talk-TW] weeklyOSM #527 2020-08-11-2020-08-17   weeklyteam
> reminders.
>
> I checked https://lists.openstreetmap.org/listinfo/talk-fr
> and didn't see any reminders.
>
> So maybe Talk-TW should be unsub*scribed too.
> Let each user personally sub*scribe to the reminders if they want.
>


-- 
-- 
## weeklyteam
___
Talk-TW mailing list
Talk-TW@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-tw

Re: [OSM-talk-fr] Choisir le bon name pour les trajets de bus

2020-09-28 Thread Éric Gillet


Le 27/09/2020 à 16:46, Gad Jo a écrit :

Bonjour a tous,

Exemple extrême (y aura pas pire que ça) : Bus 12 bis : 
Montredon-des-Corbières - Montredon Pôle d’échanges → 
Montredon-des-Corbières - Clos des Ormeaux

(Désolé le copier-coller sur l'application ajoute le format)
Relation concernée : https://www.openstreetmap.org/relation/11674315

Auriez vous des propositions à me faire ? À moins que des règles 
existent et j'applique... Je serait tenté de placer que le nom de l'arrêt


Bonjour,

Je pense qu'il faut mettre le nom tel que diffusé au public par le 
réseau (en données ouvertes, sur les documents ou sur le terrain).


"name=:  → /" /[1][2]//ou 
autre variante n'est pas un nom mais une description//redondante avec 
les autres tags présents dans la relation/. /Pas toutes les applications 
affichent ces détails-là donc une telle description en nom me paraît 
acceptable, mais uniquement en "solution de repli" quand la ligne n'a 
pas de nom.


[1]https://wiki.openstreetmap.org/wiki/Public_transport#Service_routes
[2]https://lists.openstreetmap.org/pipermail/tagging/2019-May/045180.html

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-it-lazio] Fwd: [Talk-it] Alert tematici


vi inoltro questo, forse interessa...

Begin forwarded message:

> From: Cascafico Giovanni 
> Date: 28. September 2020 at 08:21:30 CEST
> To: openstreetmap list - italiano 
> Subject: Re: [Talk-it] Alert tematici
> Reply-To: openstreetmap list - italiano 
> 
> 
> BIKELAZ
> Alerts on OSM changes in bicycle routes of Lazio (Italy)
> https://t.me/bikelaz
> 
> 




contesto:


> Il gio 24 set 2020, 14:20 Luca Delucchi  ha scritto:
>> 
>> 
>>> On Wed, 23 Sep 2020 at 10:00, Cascafico Giovanni  
>>> wrote:
>>> Ciao Volker ed in Cc Ciao Lista,
>>> 
>> ciao a tutti,
>> 
>>> 
>>> Uno strumento analogo è stato fatto in python (presumo meglio) anche
>>> da LucadeLu, per cui se Luca si basa su servizi online più "robusti",
>>> che batta un colpo :-)
>>> 
>> La mia implementazione si trova qui [3] per quanto riguarda la richiesta a 
>> overpass api e la trasformazione in diversi formati e per ottenere i 
>> changeset interessati. La spedizione via telegram e mail invece è gestita 
>> qui [4]
>> 
>> [3] 
>> https://github.com/osmItalia/cai_scripts/blob/c21d96bc07ac2d00c97a540ddc538d57af01e296/caiosm/data_from_overpass.py#L608
>> [4] 
>> https://github.com/osmItalia/cai_scripts/blob/c21d96bc07ac2d00c97a540ddc538d57af01e296/caiosm/data_diff.py#L14
>> 
>> -- 
>> ciao
>> Luca
>> 
>> www.lucadelu.org
>> ___
>> Talk-it mailing list
>> talk...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
> ___
> Talk-it mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
___
Talk-it-lazio mailing list
Talk-it-lazio@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-lazio

Re: [Talk-it] Vecchi sentieri CAI