date:20171012

AAAH - all my questions are answered.

The City of Austin's use of google base map has "fooled" me into thinking
that the map data was theirs rather than googles. If I click on the "blue
line" then I see the actual City of Austin data and indeed it is "REED WILL
DRIVE".

Damm - So I have actually just gone and put in a google mistake into OSM.
Easily fixed tonight and I will check any other roads that I have "fixed"
in the last two days.

Ok - so after all this, the only error was in the google data, which is no
great surprise.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Texas - redacted roads.

Clifford wrote
"Looking at the data from
Austin, the road should be name Reed Will Drive."

Hi Clifford.
Which site did you find the authoritive data for Austin from?  (Tiger has
nothing and is not authorative anyway, as far as I can tell)

The Cit of Austin  site
https://data.austintexas.gov/Locations-and-Maps/Street-Segment/t4fe-kr8c
has "Redwill Drive"

CAPCOG
http://regional-open-data-capcog.opendata.arcgis.com/datasets/roads-2015
has "Reed Will Drive"

There is annecdotal evidence that the street signs have (or maybe had)
"Reed Will Drive"

So, firstly I think we need to find out what the street signs say
currently. Then we need to contact all authoritive holders of this data to
clarify what name is correct and to ensure all occurrences are fixed as
necessary.

In the meantime what would you suggest is the best action to take?
Lets say the street sign is wrong (REED WILL) and the correct data is City
of Austin's Redwil.

Should we (in OSM) put what the user will probably search for, the correect
(hypothetically) Redwil or should we put the "ground truth" (REED WILL)
which is what the user will see if he acually ever makes it to that
location.

PS - I have just noticed that the City of Austin website has an attribution
of "Map data @2017 Google"
Does this mean that the displayed names are from google rather than City of
Austin and therefore not usable by us.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Texas - redacted roads.

2017-10-12 Diskussionsfäden Clifford Snow

On Thu, Oct 12, 2017 at 3:15 PM, Nick Hocking 
wrote:

> Nathan wrote
>
>
> has the road listed as REED WILL and with a type of DR.  I've been told
> that this is an acceptable source or road names,
>
>
> Maybe somebody could drive past this road and report back what the actual
> street signs do say. If they do say "Reed Will" then I will try to contact
> the Austin authorities to clarify the situation.
>

Nathan,
I haven't been following this discussion closely. Looking at the data from
Austin, the road should be name Reed Will Drive. The pre_dir and pre_type
are null. Plus the full_name is shown as Reed Will Dr.

Let me apologize in advance if I misunderstood your question.

Clifford

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

On 3 October 2017 at 18:56, Christoph Hormann  wrote:

> * systematic wikidata ID addition/editing efforts (there seems to be
> nothing listed currently on
> https://wiki.openstreetmap.org/wiki/Category:Automated_edits_log)

That may be because there is a bug in wiki, that I have reported a few
months ago. Adding a category in the page does not cause this page appear
in the category. I have just created a page, documenting my edits of
wikidata tags and I can see the problem persists.
See
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Rmikke/Adding_wikidata_entries
and try to find it in the "Automated edits log" category.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

On 12 October 2017 at 23:23, Christoph Hormann  wrote:

> As i have pointed out elsewhere doing QA in OSM based on Wikidata does
> not in any way depend on the automatic addition of Wikidata IDs to
> OSM - or in other words: Any ID you'd add based on some matching
> algorithm just for QA purposes you would not need to add at all.
>

How exactly would you approach detecting OSM objects with wikipedia=*
pointing to disambiguation page in wikipedia, instead of the correct one,
without using wikidata? This is a real problem - e.g. wikipedia link
"pl:Józefów" is useless as it points to a list of about a hundred places of
this name. With wikidata one can locate all similar cases and correct them
- I have done this for Poland as well as for other countries, using Yuri's
QA tool. Without it, disambig wikipedia links would stay there until
someone accidentally finds one and will be willing to correct it. One by
one. There were hundreds of such cases in Poland alone.


> With practical applications i was referring to actual external use of
> the data.  If the only practical use of the wikidata IDs is internal QA
> that would be a pretty bad ROI in terms of Mapper's work (the time
> adding IDs would be much better invested into doing actual validation
> work).
>

But how could a mapper validate anything if he (or she) has no way to know
there is a problem?


> > > * To what extent has there been information transferred
> > > systematically from Wikidata and Wikipedia to OSM based on wikidata
> > > ID references (like adding names in different languages).  As
> > > others have explained this would be legally problematic and it
> > > would be important to know how common this is.
> >
> > To my knowledge nothing automatic of this kind exists so far, so
> > there should be only a few manual edits of this kind.
>
> Yesterday i showed examples of systematic node and name tag additions to
> OSM clearly sourced from Wikidata.  It is clear that this is happening.
> The question is only how extensive such data transfer is.


Yup, you are right, I can see now it's happening.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-uy] Edificaciones dentro de la cota de inundación 2016 - Durazno, Uruguay

2017-10-12 Diskussionsfäden hyan...@gmail.com

Apreciados maperos del Uruguay,

en agosto pasado hicimos un taller sobre mapeo de desastres naturales
enfocado en la Intendencia de Durazno, puntualmente se trató de hacer mapeo
remoto y en campo sobre las edificaciones que se vieron afectadas durante
la pasada inundación de abril 2016.

La noticia fue publicada en
http://sinae.gub.uy/comunicacion/archivo-noticias/se-presento-la-plataforma-del-programa-openstreetmap

Un grupo de nuevos mapeadores hicimos toda la actividad (incluyendo el
traslado por 3 horas hasta Durazno) en un solo día, con más de 1.000
edificaciones mapeadas (nada mal eh!) y nos quedaron algunas áreas
pendientes por cubrir.

Los resultados de análisis van a ser compartidos en una conferencia en la
próxima Asamblea General del Instituto Panamericano de Geografía e Historia
(IPGH), a celebrarse en Panamá entre el 21 y 27 de octubre.  Con el objeto
de presentar cifras completas sobre el impacto de esa inundación, les ruego
el favor encarecidamente que contribuyan a completar las edificaciones que
aun no han sido mapeadas:

https://tareas.openstreetmap.co/project/75

Muchas gracias,

Humberto Yances 
Voluntario
Proyecto de Asistencia Técnica 2017 - IPGH
___
Talk-uy mailing list
Talk-uy@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-uy

Re: [Talk-us] Texas - redacted roads.

2017-10-12 Diskussionsfäden Rihards

On 2017.10.13. 01:15, Nick Hocking wrote:
> Nathan wrote
> "Best to stay well on the correct side of the line "**//___^
> **//___^
> Ok - point taken.

yes, google so far has not flat out denied permission, but their terms
of service would make data not usable in some countries.
it's safer to do a bit of an extra effort now to avoid data removal later.

> Did I mention that at the location I posted (using OSM) the CAPCOG
> website (roads dataset)
> 
> http://regional-open-data-capcog.opendata.arcgis.com/datasets/roads-2015
> 
> has the road listed as REED WILL and with a type of DR.  I've been told
> that this is an acceptable source or road names, 

it might be, cannot comment

> Maybe somebody could drive past this road and report back what the
> actual street signs do say. If they do say "Reed Will" then I will try
> to contact the Austin authorities to clarify the situation.

they could also consider taking mapillary and/or osv images - if we had
them, this would be easily resolved ;)

as far as i know, austin has published quite a lot of data and is fairly
open. it might be possible to reach somebody there who would appreciate
feedback. definitely worth trying.
-- 
 Rihards

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

Re: [Talk-us] Texas - redacted roads.

Nathan wrote
"Best to stay well on the correct side of the line "

Ok - point taken.


Did I mention that at the location I posted (using OSM) the CAPCOG website
(roads dataset)

http://regional-open-data-capcog.opendata.arcgis.com/datasets/roads-2015

has the road listed as REED WILL and with a type of DR.  I've been told
that this is an acceptable source or road names,


Maybe somebody could drive past this road and report back what the actual
street signs do say. If they do say "Reed Will" then I will try to contact
the Austin authorities to clarify the situation.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

2017-10-12 Diskussionsfäden Christoph Hormann

On Thursday 12 October 2017, Ryszard Mikke wrote:
>
> * How many of the wikidata=* tags currently in the database have been
>
> > added through normal mapping (while adding or significantly
> > modifying the object otherwise) and how many have been added
> > through systematic efforts outside normal mapping?
>
> Given that semi-automated edits might be done by unknown number of
> users, i'm afraid this information might be hard to obtain.

If it was easy to determine i would not have asked.

> > * What practical applications exist for the wikidata IDs?  And i am
> > not talking about theoretical ideas here but specific uses for
> > practical purposes in actual use, in particular with open source
> > implementation.
>
> There are QA tools by Yuri Astrakhan and Mateusz Konieczny, both
> based on wikidata.

As i have pointed out elsewhere doing QA in OSM based on Wikidata does 
not in any way depend on the automatic addition of Wikidata IDs to 
OSM - or in other words: Any ID you'd add based on some matching 
algorithm just for QA purposes you would not need to add at all.

With practical applications i was referring to actual external use of 
the data.  If the only practical use of the wikidata IDs is internal QA 
that would be a pretty bad ROI in terms of Mapper's work (the time 
adding IDs would be much better invested into doing actual validation 
work).

> > * To what extent has there been information transferred
> > systematically from Wikidata and Wikipedia to OSM based on wikidata
> > ID references (like adding names in different languages).  As
> > others have explained this would be legally problematic and it
> > would be important to know how common this is.
>
> To my knowledge nothing automatic of this kind exists so far, so
> there should be only a few manual edits of this kind.

Yesterday i showed examples of systematic node and name tag additions to 
OSM clearly sourced from Wikidata.  It is clear that this is happening.  
The question is only how extensive such data transfer is.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk-fr] Nouvelle analyses Osmose sur la France : numéro de téléphone et intégration des restrictions de hauteur

2017-10-12 Diskussionsfäden Philippe Verdy

Le 12 octobre 2017 à 22:00,  a écrit :

> 00, c'est une faute. + c'est la norme. Dans le temps depuis la France on
> faisait 19 pas 00 pour l'international.
>
> Il y a une volonté d'avoir 00 partout mais je ne sais si c'est déjà le cas.
>
Ce n'est pas le cas en Amérique du Nord (zone +1, USA, Canada et tous les
pays du plan de numérotation nord-américain : composer le 011 avant
l'indicatif pays), en Russie et au Kazakhstan (zone +7 : composer le 90
avant le code pays pour l'opérateur par défaut, de même encore dans
d'autres pays de l'ancienne Union soviétique, sauf au moins ceux ayant
rejoint l'Union européenne), au Japon (composer le 010 avant l'indicatif
pays), en Australie (composer le 0011 avant l'indicatif pays, ou 001x avec
x!=0 pour sélectionner un autre opérateur que l'opérateur par défaut), au
Kenya/Tanzanie/Ouganda (composer le 000 avant l'indicatif pays), au Nigeria
(composer le 009 avant l'indicatif pays), et le 00x ou 00xx dans d'autres
pays (un ou deux chiffres x ou xx pour sélectionner l'opérateur alternatif:
pratiquement toute l'Asie du Sud-Est et le Brésil), à Cuba (composer le 119
avant l'indictof pays), 8xx encore en Russie (pour sélectionner
l'opérateur, le préfixe 810 étant pour l'opérateur présélectionné qui est
aussi composé avec le préfixe 90).

Donc non le 00 n'est pas encore généralisé dans le monde, dont les plans de
numérotation nationaux (ou plurinationaux) n'ont pas été harmonisés pour
réserver le 00 au préfixe international.

En France ou en Europe pour faire une sélection d'opérateur alternatif on
compose un préfixe de sélection avant le numéro national (à 10 chiffres
commençant par 0), ou international (commençant par 00 plus l'indicatif
pays)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Wochennotiz Nr. 377 03.10.2017–09.10.2017

2017-10-12 Diskussionsfäden Wochennotizteam

Hallo,

die Wochennotiz Nr. 377 mit vielen wichtigen Neuigkeiten aus der 
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2017/10/wochennotiz-nr-377/

Viel Spaß beim Lesen!
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Wochennotiz Nr. 377 03.10.2017–09.10.2017

2017-10-12 Diskussionsfäden Wochennotizteam

Hallo,

die Wochennotiz Nr. 377 mit vielen wichtigen Neuigkeiten aus der 
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2017/10/wochennotiz-nr-377/

Viel Spaß beim Lesen!
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

On 3 October 2017 at 23:21, Yuri Astrakhan  wrote:

> While I have nothing against pausing bulk wikidata additions for a month,
> we should be very clear here:
> * several communities use bots to maintain and inject these tags, e.g.
> Israel. Should they pause their bots?
> * If a specific community is ok with it, does it override world wide ban
> for that location?
> * Has anyone actually been doing world-wide bulk wikidata additions ever
> since this discussion has restarted after what I thought was a settled
> matter about two weeks ago?
>

Yup, I have been updating wikidata entries for northern and central Europe
more or less every weekend, with Overpass and JOSM's Wikipedia plugin.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] fin d'une route secondaire ou tertiaire vers un hameau

2017-10-12 Diskussionsfäden David Crochet


Bonjour


Le 12/10/2017 à 20:52, marc marc a écrit :

les bretelles d'une ex-nationale
https://osmose.openstreetmap.fr/fr/error/13896659937


Sauf erreur de ma part, un rond point doit être catégorisé par la 
catégorie la plus importante des routes y accédant ou y partant


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] fin d'une route secondaire ou tertiaire vers un hameau

2017-10-12 Diskussionsfäden Stéphane Péneau


De mon point de vue, ce ne sont pas des _link.
D'ailleurs, c'est un type de tag que je n'utilise qu'avec parcimonie.

Stf

Le 12/10/2017 à 20:52, marc marc a écrit :

Bonsoir,

@ Christian:
qu'appelles-tu bretelle si la bretelle de sortie de la route
secondaire/tertiaire n'en est pas une ?

ceci dit, y a 2 jours, même problème avec une route tertiaire
qui se termine à un croisement avec 2 routes unclassified

@djakk
quelques exemple :
les bretelles d'une ex-nationale
https://osmose.openstreetmap.fr/fr/error/13896659937
un branchement vers une ex-nationale
http://www.openstreetmap.org/way/2508513511
un branchement d'une nationale vers un hameau
http://www.openstreetmap.org/way/113803882
une secondary_link vers unclassified (le link gagnerait à être
prolongé mais cela ne fait que reporter le problème + loin)
https://www.openstreetmap.org/way/445981943

https://osmose.openstreetmap.fr/fr/error/13898474315

@Philippe : le problème n'est pas la route secondaire/tertiaire
elle est tagé de manière cohérente avec les panneaux et tout les indices
que tu donnes vont dans la même direction.
Le problème est :
- sur la bretelle entre la route secondaire entre 2 villages et
la route unclassified du hameau
- lorsque la route tertiaire (qui relie plusieurs villages et hameau)
s'arrête (la route tertiaire ne traverse pas le hameau parce qu'il
n'y a "rien" de l'autre côté de ce hameau)

Cordialement,
Marc

Le 12. 10. 17 à 19:10, Philippe Verdy a écrit :

Egalement si la route communale passant par les hameaux relie facilement
le bourg principal de la commune au réseau secondaire. Un bon signe:
s'il y a des lignes de bus régulières dessus, des passages piétons
protégés ou marqués, c'est sans doute plus une tertiaire qu'une
"unclassified" à vocation plus rurale et non desservie par les
transports en commun.

Le 12 octobre 2017 à 19:08, Philippe Verdy > a écrit :

 tout à fait d'accord les "highway=xxx_link" relient un "highway=" à
 un autre highway de niveau inférieur, sans aucune autre issue
 possible pour la circulation normale (hormis éventuellement un
 chemin piéton ou cycliste qui y aboutit ou le traverse, ou les
 "highway=service"+"service=driveway" pour les accès aux propriétés
 privées)
 Pour être au minimum tertiaire, cela doit relier deux villages d'un
 même commune ou deux bourgs de deux communes différentes communes
 par une voie non classée départementale ou métropolitaine. Ceci dit
 si le hameau est significatif dans la commune, et que c'est une voie
 communale entretenue, on peut éventuellement la classer comme
 tertiaire si elle relie le hameau au bourg principal de la commune
 et qu'au delà du hameau cela se prolonge vers d'autres hameaux avec
 d'éventuels embranchements.

 Le 12 octobre 2017 à 12:03, Christian Quest a écrit :

 Les "link" ce sont en principe des bretelles.

 Vu la description, là c'est du unclassified qui permet d'aller
 de la route au hameau (qui a dit sur-tagging ?)



 Le 12/10/2017 à 10:02, marc marc a écrit :

 Bonjour,

 Que faire lorsqu'une route secondaire ou tertiaire raccorde
 un hameau ?
 le hameau est en highway=unclassified
 j'ai mis la bretelle d'accès à la route secondaire en
 secondary_link
 mais osmose est d'avis que c'est pas ainsi qu'il faut faire :)

 Cordialement,
 Marc

___
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] Could we just pause any wikidata edits for a month or two?

On 3 October 2017 at 18:56, Christoph Hormann  wrote:

> On Tuesday 03 October 2017, Frederik Ramm wrote:
> > Hi,
> >
> >seeing that the matter is discussed quite intensively and opinions
> > vary widely, could we perhaps agree to pause any (large scale)
> > wikidata edits for a while until more members of our community have
> > had a chance to form an opinion?
>
> I think that is a good idea.
>

I'm not happy with it, as the way I do it is sensitive to amount of data to
work with, so if I don't run it regularly, I have to restart from fragments.
But well, I might limit the query to Poland where the adding of wikidata
entries is widely accepted.
I will repeat Yuri's question here:
If a specific community is ok with it, does it override world wide ban for
that location?

Also, I'm going to remove wikidata entries where the wikipedia tag points
to a section in a wikipedia article as Spiegel0 pointed in
http://www.openstreetmap.org/changeset/52744495 (next weekend, I hope) as
they are obviously erroneous. I won't do it globally, though, only in the
region i have been adding wikidata entries (Denmark, Norway, Sweden,
Finland, Baltic countries, Kaliningrad region, Poland, Belarus, Ukraine,
Czech Republic, Slovakia, Austria and Hungary).

* How many of the wikidata=* tags currently in the database have been
> added through normal mapping (while adding or significantly modifying
> the object otherwise) and how many have been added through systematic
> efforts outside normal mapping?
>

Given that semi-automated edits might be done by unknown number of users,
i'm afraid this information might be hard to obtain.

> * What practical applications exist for the wikidata IDs?  And i am not
> talking about theoretical ideas here but specific uses for practical
> purposes in actual use, in particular with open source implementation.
>

There are QA tools by Yuri Astrakhan and Mateusz Konieczny, both based on
wikidata.

> * To what extent has there been information transferred systematically
> from Wikidata and Wikipedia to OSM based on wikidata ID references
> (like adding names in different languages).  As others have explained
> this would be legally problematic and it would be important to know how
> common this is.
>

To my knowledge nothing automatic of this kind exists so far, so there
should be only a few manual edits of this kind.

> Also i think it would be of great importance for OSM and a functioning
> communication in the community to have better documentation of:
>
> * systematic wikidata ID addition/editing efforts (there seems to be
> nothing listed currently on
> https://wiki.openstreetmap.org/wiki/Category:Automated_edits_log)
>

Ummm, I think I should document my edits...

Now, to be frank, I can't see anything wrong in adding wikidata entries to
existing wikipedia links in OSM objects and using them e.g. to display
Wikipedia articles in users' preferred langages instead of "native"
language of article pointed by wikipedia=* tag as long as we don't copy the
data into OSM.

mi...@pl.vwfsag.de ryszard.mi...@gmail.com

دراجة أكبر
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

2017-10-12 Diskussionsfäden Eugene Alvin Villar

On Fri, Oct 13, 2017 at 3:52 AM, Martin Koppenhoefer  wrote:

> yes, currently it doesn’t seem the deletionists are active in wikidata,
> but also wikipedia was not always like it is today. The notability policy
> is there and one day someone might come and say: these roads are just
> ordinary roads, nothing notable about them to keep, they will likely never
> ever have their own article, image, or page in Wikipedia, Wikimedia
> Commons, or Wikivoyage..
>

But having a corresponding page/article/image is just the 1st of the 3
criteria for keeping an item in Wikidata. These Dutch streets fulfill the
2nd criteria which you already quoted: "The entity must be notable, in the
sense that it can be described using serious and publicly available
references" and the Notability policy only requires that at least 1 of the
3 criteria is met.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Nouvelle analyses Osmose sur la France : numéro de téléphone et intégration des restrictions de hauteur

2017-10-12 Diskussionsfäden osm . sanspourriel

https://www.osm.org/node/2108115408 : selon Free leurs numéros sont le 
3244 en national et +33 1 78 56 95 60 à l'international.


Mais c'est pour Free, pas pour cette boutique.

Selon les Pages Jaunes , c'est 
le 1044 (donc un operator:phone).


Autre bizarrerie : ajouter des name:fr et name:en alors qu'il s'agit 
d'un nom (de plus c'est Free Center, Metz, c'est la ville).


D'une manière générale si l'auteur des bizarreries est encore actif, je 
préfère le contacter.


Car soit c'est une erreur et il appréciera qu'on vérifie et l'aident 
soit c'est du vandalisme et là encore c'est utile de monter qu'on 
contrôle un peu.


00, c'est une faute. + c'est la norme. Dans le temps depuis la France on 
faisait 19 pas 00 pour l'international.


Il y a une volonté d'avoir 00 partout mais je ne sais si c'est déjà le 
cas. + est toujours bon (préfixe de l'international, 0 long sur les 
claviers de téléphone).


33 sans + est faux.

Jean-Yvon


Le 11/10/2017 à 11:27, Julien Lepiller - o...@lepiller.eu a écrit :

Bonjour,

comme je m'ennuyais hier soir, j'ai regardé ce que donnait l'analyse 
et j'ai commencé à corriger les numéros pour lesquels il manquait 
l'indicatif (+33) à peu près dans le nord de la France (vu ce que dit 
Philippe, je ne me suis pas aventuré dans les dom-com). J'ai trouvé 
quelques bizarreries comme des numéros à 11 ou 12 chiffres (par 
exemple https://www.osm.org/node/4883765418 ou 
https://www.osm.org/way/263891587. On peut les retrouver avec la 
requête overpass : http://overpass-turbo.eu/s/sgy). J'ai aussi ce nœud 
: https://www.osm.org/node/2108115408, dont le numéro est 01, 
que j'ai corrigé un peu bêtement.


Qu'est-ce que vous conseilleriez de faire pour ces numéros ? Ça me 
semble faux donc je dirais supprimer, mais je ne voudrais pas faire de 
bêtises.


Si on veut continuer dans la correction des numéros de téléphone, il y 
en a quelques uns qui utilisent des points au lieu d'espaces pour 
séparer les nombres (et qui ne sont pas trouvés par osmose même quand 
il n'y a pas d'indicatif). D'autres utilisent l'indicatif mais avec 
"00" au lieu de "+" (je ne sais pas si c'est une faute, mais autant 
tout harmoniser, non ?). Certains semblent utiliser "033" comme 
indicatif (ça collerait avec le nombre de chiffres dans un numéro de 
téléphone, plutôt qu'un numéro en 03 à 12 chiffres), d'autres juste "33".


Des avis ?

Le 2017-10-09 19:47, Frédéric Rodrigo a écrit :

Bonjour,


Sont disponible maintenant sur Osmose :


La validation des numéros des téléphones sur la Métropole et DOM (avec
les bons indicatifs)

http://osmose.openstreetmap.fr/fr/errors/?item=3092

http://osmose.openstreetmap.fr/fr/map/#item=3092


Les proposition d'intégration des restrictions de hauteur sur le
France depuis le Route 500 de l'IGN et sur le 92 depuis un fichier du
département

http://osmose.openstreetmap.fr/fr/errors/?item=8320

http://osmose.openstreetmap.fr/fr/map/#item=8320


Frédéric.



___
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: [OSM-talk] Could we just pause any wikidata edits for a month or two?

sent from a phone

> On 12. Oct 2017, at 20:17, Eugene Alvin Villar  wrote:
> 
> Wikidata's notability policy is actually very liberal. If you're familiar 
> with the Inclusionist versus Deletionist debate in Wikipedia, Wikidata is 
> heaven for Inclusionists. For instance, Wikidata now has items for 
> practically all streets in the Netherlands. 99% of these will likely never 
> ever have their own article, image, or page in Wikipedia, Wikimedia Commons, 
> or Wikivoyage.

yes, currently it doesn’t seem the deletionists are active in wikidata, but 
also wikipedia was not always like it is today. The notability policy is there 
and one day someone might come and say: these roads are just ordinary roads, 
nothing notable about them to keep, they will likely never ever have their own 
article, image, or page in Wikipedia, Wikimedia Commons, or Wikivoyage..
;-)

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

Re: [Talk-us] [OSM-talk] Redacting 75, 000 street names contributed by user chdr

2017-10-12 Diskussionsfäden Kevin Kenny

On Sat, Oct 7, 2017 at 7:47 PM, Frederik Ramm  wrote:
> http://www.remote.org/frederik/tmp/chdr.details
>
> A new list (CSV file) with way id, coordinates, and country/state/county
> information. I've eliminated all objects that have been reported to be
> ok, and plan to remove or change the names on these remaining ones. (To
> avoid misunderstandings: There's a column in the file that says what I
> plan to do, either "change to XYZ" or "delete", but that does NOT mean
> "delete the object", just "delete the name tag"!)

Thanks for taking care of this. Could I make a suggestion for future work
of this kind: add a note:redaction (or some similar key) with value
identifying the particular redaction that the object belongs to? At Max's
suggestion, I was doing Overpass queries with the set of way ID's
looking for ones that were still last modified by 'woodpeck_repair',
but I realize that if the ways had an identifiable tag, I could easily
hack up a reusable script to say, "give me the next object from
this redaction" - and remove the tag when the object is re-uploaded.
Simply having a tag like "note:redaction=chdr_20171008" on
the redacted way would do it.

I may be too much of an old woman here, worrying about identifying
objects from the wrong repair. It appears that for this particular
incident,
way(newer:"2017-10-07T00:00:00Z")(user:"woodpeck_repair")({{bbox}});
is a perfectly workable Overpass query for "tell me the work to do
in this particular bbox".

With that in hand, I can probably finish up New Jersey this week.

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

Re: [OSM-talk-fr] fin d'une route secondaire ou tertiaire vers un hameau

Bonsoir,

@ Christian:
qu'appelles-tu bretelle si la bretelle de sortie de la route 
secondaire/tertiaire n'en est pas une ?

ceci dit, y a 2 jours, même problème avec une route tertiaire
qui se termine à un croisement avec 2 routes unclassified

@djakk
quelques exemple :
les bretelles d'une ex-nationale
https://osmose.openstreetmap.fr/fr/error/13896659937
un branchement vers une ex-nationale
http://www.openstreetmap.org/way/2508513511
un branchement d'une nationale vers un hameau
http://www.openstreetmap.org/way/113803882
une secondary_link vers unclassified (le link gagnerait à être
prolongé mais cela ne fait que reporter le problème + loin)
https://www.openstreetmap.org/way/445981943

https://osmose.openstreetmap.fr/fr/error/13898474315

@Philippe : le problème n'est pas la route secondaire/tertiaire
elle est tagé de manière cohérente avec les panneaux et tout les indices 
que tu donnes vont dans la même direction.
Le problème est :
- sur la bretelle entre la route secondaire entre 2 villages et
la route unclassified du hameau
- lorsque la route tertiaire (qui relie plusieurs villages et hameau) 
s'arrête (la route tertiaire ne traverse pas le hameau parce qu'il
n'y a "rien" de l'autre côté de ce hameau)

Cordialement,
Marc

Le 12. 10. 17 à 19:10, Philippe Verdy a écrit :
> Egalement si la route communale passant par les hameaux relie facilement 
> le bourg principal de la commune au réseau secondaire. Un bon signe: 
> s'il y a des lignes de bus régulières dessus, des passages piétons 
> protégés ou marqués, c'est sans doute plus une tertiaire qu'une 
> "unclassified" à vocation plus rurale et non desservie par les 
> transports en commun.
> 
> Le 12 octobre 2017 à 19:08, Philippe Verdy  > a écrit :
> 
> tout à fait d'accord les "highway=xxx_link" relient un "highway=" à
> un autre highway de niveau inférieur, sans aucune autre issue
> possible pour la circulation normale (hormis éventuellement un
> chemin piéton ou cycliste qui y aboutit ou le traverse, ou les
> "highway=service"+"service=driveway" pour les accès aux propriétés
> privées)
> Pour être au minimum tertiaire, cela doit relier deux villages d'un
> même commune ou deux bourgs de deux communes différentes communes
> par une voie non classée départementale ou métropolitaine. Ceci dit
> si le hameau est significatif dans la commune, et que c'est une voie
> communale entretenue, on peut éventuellement la classer comme
> tertiaire si elle relie le hameau au bourg principal de la commune
> et qu'au delà du hameau cela se prolonge vers d'autres hameaux avec
> d'éventuels embranchements.
> 
> Le 12 octobre 2017 à 12:03, Christian Quest a écrit :
> 
> Les "link" ce sont en principe des bretelles.
> 
> Vu la description, là c'est du unclassified qui permet d'aller
> de la route au hameau (qui a dit sur-tagging ?)
> 
> 
> 
> Le 12/10/2017 à 10:02, marc marc a écrit :
> 
> Bonjour,
> 
> Que faire lorsqu'une route secondaire ou tertiaire raccorde
> un hameau ?
> le hameau est en highway=unclassified
> j'ai mis la bretelle d'accès à la route secondaire en
> secondary_link
> mais osmose est d'avis que c'est pas ainsi qu'il faut faire :)
> 
> Cordialement,
> Marc
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

2017-10-12 Diskussionsfäden Eugene Alvin Villar

On Wed, Oct 11, 2017 at 9:02 PM, Martin Koppenhoefer  wrote:

> From what I have seen so far, this should probably be less of a concern,
> but it is an uncertainty (because it could be interpreted more rigidly in
> the future), I agree. Requirements seem to be much lower than they are for
> wikipedia inclusion, for one because a link to any of these wikimedia
> projects is sufficient: Wikipedia, Wikivoyage, Wikisource, Wikiquote,
> Wikinews, Wikibooks, Wikidata, Wikispecies, Wikiversity, or Wikimedia
> Commons (this paragraph is followed by some clarification and limitation).
> In other words, if you want to save your pet wikidata object from deletion
> it is sufficient to take a picture of it and upload it to wm commons.
>
> There's also a very soft criterion in the next paragraph which allows
> object that "[refer] to an instance of a *clearly identifiable conceptual
> or material entity*. The entity must be notable, in the sense that it *can
> be described using serious and publicly available references*."
> It requires references to be "serious" (how subjective is this?).
>

Wikidata's notability policy is actually very liberal. If you're familiar
with the Inclusionist versus Deletionist debate in Wikipedia, Wikidata is
heaven for Inclusionists. For instance, Wikidata now has items for
practically all streets in the Netherlands. 99% of these will likely never
ever have their own article, image, or page in Wikipedia, Wikimedia
Commons, or Wikivoyage.

Here is the import request (bot task) that imported the Dutch streets into
Wikidata:
https://www.wikidata.org/wiki/Wikidata:Requests_for_permissions/Bot/RobotMichiel1972_2
And here is the Wikidata SPARQL query to extract the street items:
http://tinyurl.com/y7k6cfc7
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

2017-10-12 Diskussionsfäden Mike N


On 10/12/2017 9:52 AM, Ian Dees wrote:

The vast majority of roads seem to be correctly missing from OSM.


 Along that line of thought - for cases where local government data is 
not open, I'd find it useful to detect where a name changed in TIGER 
from previous year, or a road was added.


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

Re: [Talk-us] Davis Senior High School, California

2017-10-12 Diskussionsfäden David Kewley

I've just now sent an email through the school's portal to Mr. Birdsall,
asking whether he can help. I live in California, and have met folks from
Davis, but don't have enough of a personal connection to go a more direct
route.

David


On Thu, Oct 12, 2017 at 2:40 AM, Andy Townsend  wrote:

> Among rather more serious problems (smoke from the Napa wildfires) Davis
> Senior High School is home to some Pokemon fans who don't like doing their
> homework. http://www.openstreetmap.org/way/23646951/history has been
> changed a number of times to a park labelled "Please let us drop tests Mr.
> Birdsall".
>
> I'm sending this mail to the list on the off chance that someone here may
> know someone there - a quiet word from a friend would be a nicer approach
> than an "official" email from OSM.  What'd be great is if we can convert
> the mapper(s) concerned into mapping things that actually exist rather than
> adding fake Pokemon parks called "Hi Albert".
>
> Best Regards,
>
> Andy Townsend, on behalf of OSM's Data Working Group
>
> PS: In case anyone wonders "why don't you just IP block them", some of the
> edits are from iPhones, so that wouldn't be an option here (and probably
> wouldn't be proportionate even if that wasn't the case).  Also, while some
> of the edits may seem to suggest the name of one student, I wouldn't assume
> that that person is a perpetrator - they may be just the victim of a kind
> of joe-job.
>
>
> ___
> 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: [OSM-talk-fr] fin d'une route secondaire ou tertiaire vers un hameau

2017-10-12 Diskussionsfäden Philippe Verdy

Egalement si la route communale passant par les hameaux relie facilement le
bourg principal de la commune au réseau secondaire. Un bon signe: s'il y a
des lignes de bus régulières dessus, des passages piétons protégés ou
marqués, c'est sans doute plus une tertiaire qu'une "unclassified" à
vocation plus rurale et non desservie par les transports en commun.

Le 12 octobre 2017 à 19:08, Philippe Verdy  a écrit :

> tout à fait d'accord les "highway=xxx_link" relient un "highway=" à un
> autre highway de niveau inférieur, sans aucune autre issue possible pour la
> circulation normale (hormis éventuellement un chemin piéton ou cycliste qui
> y aboutit ou le traverse, ou les "highway=service"+"service=driveway"
> pour les accès aux propriétés privées)
> Pour être au minimum tertiaire, cela doit relier deux villages d'un même
> commune ou deux bourgs de deux communes différentes communes par une voie
> non classée départementale ou métropolitaine. Ceci dit si le hameau est
> significatif dans la commune, et que c'est une voie communale entretenue,
> on peut éventuellement la classer comme tertiaire si elle relie le hameau
> au bourg principal de la commune et qu'au delà du hameau cela se prolonge
> vers d'autres hameaux avec d'éventuels embranchements.
>
> Le 12 octobre 2017 à 12:03, Christian Quest  a
> écrit :
>
>> Les "link" ce sont en principe des bretelles.
>>
>> Vu la description, là c'est du unclassified qui permet d'aller de la
>> route au hameau (qui a dit sur-tagging ?)
>>
>>
>>
>> Le 12/10/2017 à 10:02, marc marc a écrit :
>>
>>> Bonjour,
>>>
>>> Que faire lorsqu'une route secondaire ou tertiaire raccorde un hameau ?
>>> le hameau est en highway=unclassified
>>> j'ai mis la bretelle d'accès à la route secondaire en secondary_link
>>> mais osmose est d'avis que c'est pas ainsi qu'il faut faire :)
>>>
>>> Cordialement,
>>> Marc
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>>
>> ___
>> 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] fin d'une route secondaire ou tertiaire vers un hameau

2017-10-12 Diskussionsfäden Philippe Verdy

tout à fait d'accord les "highway=xxx_link" relient un "highway=" à un
autre highway de niveau inférieur, sans aucune autre issue possible pour la
circulation normale (hormis éventuellement un chemin piéton ou cycliste qui
y aboutit ou le traverse, ou les "highway=service"+"service=driveway" pour
les accès aux propriétés privées)
Pour être au minimum tertiaire, cela doit relier deux villages d'un même
commune ou deux bourgs de deux communes différentes communes par une voie
non classée départementale ou métropolitaine. Ceci dit si le hameau est
significatif dans la commune, et que c'est une voie communale entretenue,
on peut éventuellement la classer comme tertiaire si elle relie le hameau
au bourg principal de la commune et qu'au delà du hameau cela se prolonge
vers d'autres hameaux avec d'éventuels embranchements.

Le 12 octobre 2017 à 12:03, Christian Quest  a
écrit :

> Les "link" ce sont en principe des bretelles.
>
> Vu la description, là c'est du unclassified qui permet d'aller de la route
> au hameau (qui a dit sur-tagging ?)
>
>
>
> Le 12/10/2017 à 10:02, marc marc a écrit :
>
>> Bonjour,
>>
>> Que faire lorsqu'une route secondaire ou tertiaire raccorde un hameau ?
>> le hameau est en highway=unclassified
>> j'ai mis la bretelle d'accès à la route secondaire en secondary_link
>> mais osmose est d'avis que c'est pas ainsi qu'il faut faire :)
>>
>> Cordialement,
>> Marc
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> --
> Christian Quest - OpenStreetMap France
>
>
>
> ___
> 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

[OSM-talk-be] Foss4g.be: Call for volunteers & registration

2017-10-12 Diskussionsfäden joost schouppe

Hi,

We're looking for volunteers to help out at the foss4g.be event. All info
below.

If you don't want to volunteer, you should still come, because we have an
entire OpenStreetMap track at the event!

Check 2017.foss4g.be for the full program.

-- Doorgestuurd bericht --
Van: "Dirk Frigne" 
Datum: 11 okt. 2017 8:44 p.m.
Onderwerp: [Belgium] Call for volunteers
Aan: "belg...@lists.osgeo.org" 
Cc: 

Dear Belgiuan OSGeo-list subscribers,

On October 26, the 3th FOSS4G will take place in BEL at the Tour and
Taxis site in Brussels. We will need also this year volunteers to help
during the event.

If you want to volunteer and contribute to OSGeo - this is your chance!
Please reply to the volunt...@osgeo.be if you want to help out and we
will contact you.

Don't forget to register on the website[1] that you come - places are as
every year limited and registration goes hard...


[1] http://2017.foss4g.be/inscription.php

--
Yours sincerely,


ir. Dirk Frigne
CEO @geosparc

Geosparc n.v.
Brugsesteenweg 587
B-9030 Ghent
Tel: +32 9 236 60 18
GSM: +32 495 508 799

http://www.geomajas.org
http://www.geosparc.com

@DFrigne
be.linkedin.com/in/frigne

___
Belgium mailing list
belg...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/belgium
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

2017-10-12 Diskussionsfäden Andreas Lattmann

>ma il risultato nei tratti con millemila
>rwn/nwn è quello che temevo >https://imgur.com/a/JDpnz (cioè, sono >tratti che
>sono già orrendi anche semplicemente >con le ref ma così è peggio).

Effettivamente non è il massimo... l'ho notato anch'io purtroppo.

Il 12 ottobre 2017 17:32:42 CEST, matteocalosi  ha 
scritto:
>Magari arbitrari è il termine sbagliato, mi riferivo semplicemente
>all'assegnazione in massa (catasto sentieri?) della formula
>partenza-arrivo
>come nome relazione. Che magari se si decide che un sentiero DEVE avere
>un
>nome è anche la soluzione migliore ma personalmente vederli sulla mappa
>non
>mi piace. 
>
>Non sapevo che osmand facesse anche il render del nome relazione (io
>abitualmente uso openandromaps/elevate), devo dire che effettivamente
>la
>qualità render del nome a partire dalla relazione piuttosto che dalle
>way è
>superiore (e ci mancherebbe) ma il risultato nei tratti con millemila
>rwn/nwn è quello che temevo https://imgur.com/a/JDpnz (cioè, sono
>tratti che
>sono già orrendi anche semplicemente con le ref ma così è peggio).
>
>
>
>
>Alfredo Gattai wrote
>> Nelle wiki in inglese
>> 
>> http://wiki.openstreetmap.org/wiki/Hiking
>> 
>> il name e' indicato come un tag opzionale mentre risulta essere
>necessario
>> per le relazion.
>> Detto questo se un sentiero che fa parte di una relation e' gia'
>> conosciuto
>> con un certo nome ovviamente il nome sulla way ha senso ed e' giusto
>che
>> rimanga. La mia precisazione era tesa ad evitare quello che succede a
>> volte
>> dove si trova sulle way "Sentiero CAI 151" oppure "Sentiero bolli
>rossi"
>> oppure anche qualcuno che ripete il nome della relazione dentro la
>way
>> dove
>> magari quel pezzo di sentiero e' una scalinata antica che ha un nome
>> proprio che nulla ha a che fare con la relazione.
>> Personalmene non mi piace mappare per il rendering e quindi non metto
>nomi
>> nelle way perche' sulla pagina principale di OSM non si vedono i nomi
>> delle
>> relazioni, ma non sono un fondamentalista. Molto spesso trovo nomi
>sulle
>> way che mi sembrano sensati e li lascio li anche se c'e' la relation.
>> 
>> Mi fai qualche esempio di nome arbitrario sulle relazioni liguri? Me
>le
>> sto
>> ripassando tutte per consolidare la Rete Escursionistica Ligure ed il
>> repertorio FIE e CAI prima di farlo confluire nel catasto nazionale
>del
>> CAI. Per ora al di fuori di quello che e' stato deciso con la
>Regione,
>> all'interno del catasto CAI e FIE non ho trovato molte stranezze, se
>mi
>> fai
>> qualche esempio mi daresti una mano.
>> 
>> Grazie
>> Alfredo
>> 
>> 
>> 
>> 2017-10-11 18:47 GMT+02:00 matteocalosi 
>
>> matteocalosi@
>
>> :
>> 
>>> Ma questa è una linea guida condivisa? Non la trovo nè in pagina CAI
>nè
>>> in
>>> IT:Hiking.
>>> E non è che sia completamente d'accordo.
>>> Mi spiego, è ovvio che non si mette come name della way quello di
>una
>>> relation a lunga percorrenza tipo alta via oppure di relation che
>hanno
>>> nomi
>>> arbitrari come quelli che vedo sono stati assegnati ai sentieri
>liguri.
>>> Ma quando una relation ha un nome che sarebbe in ogni caso assegnato
>alle
>>> way che la costituiscono anche se la relation non avesse nome
>(esempio
>>> http://www.caimarostica.it/778.html) non vedo perchè non si possa
>>> aggiungere
>>> alle singole way. Al massimo sarà ridondante ma non mi sembra
>errato,
>>> quel
>>> tratto di sentiero lì ha effettivamente quel nome e non è che lo
>perda
>>> nel
>>> momento in cui una sezione CAI decide che è quello ufficiale del
>>> sentiero.
>>> Lo so che non si mappa per il rendering ma i renderer
>escursionistici non
>>> fanno in genere vedere i nomi delle relazioni sui sentieri (anche a
>>> ragione
>>> perchè visivamente il risultato non sarebbe spesso piacevole/utile,
>vedi
>>> l'esempio delle relazioni liguri) quindi aggiungere il nome di un
>>> sentiero
>>> sulla way è di fatto l'unico modo di vederlo. Se non fosse
>formalmente
>>> errata come cosa io preferirei aggiungerlo piuttosto che perdere la
>>> visualizzazione del nome dei soli sentieri che lo hanno
>ufficializzato.
>>>
>>>
>> 
>> ___
>> Talk-it mailing list
>
>> Talk-it@
>
>> https://lists.openstreetmap.org/listinfo/talk-it
>
>
>
>
>
>--
>Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html
>
>___
>Talk-it mailing list
>Talk-it@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-it

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

2017-10-12 Diskussionsfäden matteocalosi

Magari arbitrari è il termine sbagliato, mi riferivo semplicemente
all'assegnazione in massa (catasto sentieri?) della formula partenza-arrivo
come nome relazione. Che magari se si decide che un sentiero DEVE avere un
nome è anche la soluzione migliore ma personalmente vederli sulla mappa non
mi piace. 

Non sapevo che osmand facesse anche il render del nome relazione (io
abitualmente uso openandromaps/elevate), devo dire che effettivamente la
qualità render del nome a partire dalla relazione piuttosto che dalle way è
superiore (e ci mancherebbe) ma il risultato nei tratti con millemila
rwn/nwn è quello che temevo https://imgur.com/a/JDpnz (cioè, sono tratti che
sono già orrendi anche semplicemente con le ref ma così è peggio).




Alfredo Gattai wrote
> Nelle wiki in inglese
> 
> http://wiki.openstreetmap.org/wiki/Hiking
> 
> il name e' indicato come un tag opzionale mentre risulta essere necessario
> per le relazion.
> Detto questo se un sentiero che fa parte di una relation e' gia'
> conosciuto
> con un certo nome ovviamente il nome sulla way ha senso ed e' giusto che
> rimanga. La mia precisazione era tesa ad evitare quello che succede a
> volte
> dove si trova sulle way "Sentiero CAI 151" oppure "Sentiero bolli rossi"
> oppure anche qualcuno che ripete il nome della relazione dentro la way
> dove
> magari quel pezzo di sentiero e' una scalinata antica che ha un nome
> proprio che nulla ha a che fare con la relazione.
> Personalmene non mi piace mappare per il rendering e quindi non metto nomi
> nelle way perche' sulla pagina principale di OSM non si vedono i nomi
> delle
> relazioni, ma non sono un fondamentalista. Molto spesso trovo nomi sulle
> way che mi sembrano sensati e li lascio li anche se c'e' la relation.
> 
> Mi fai qualche esempio di nome arbitrario sulle relazioni liguri? Me le
> sto
> ripassando tutte per consolidare la Rete Escursionistica Ligure ed il
> repertorio FIE e CAI prima di farlo confluire nel catasto nazionale del
> CAI. Per ora al di fuori di quello che e' stato deciso con la Regione,
> all'interno del catasto CAI e FIE non ho trovato molte stranezze, se mi
> fai
> qualche esempio mi daresti una mano.
> 
> Grazie
> Alfredo
> 
> 
> 
> 2017-10-11 18:47 GMT+02:00 matteocalosi 

> matteocalosi@

> :
> 
>> Ma questa è una linea guida condivisa? Non la trovo nè in pagina CAI nè
>> in
>> IT:Hiking.
>> E non è che sia completamente d'accordo.
>> Mi spiego, è ovvio che non si mette come name della way quello di una
>> relation a lunga percorrenza tipo alta via oppure di relation che hanno
>> nomi
>> arbitrari come quelli che vedo sono stati assegnati ai sentieri liguri.
>> Ma quando una relation ha un nome che sarebbe in ogni caso assegnato alle
>> way che la costituiscono anche se la relation non avesse nome (esempio
>> http://www.caimarostica.it/778.html) non vedo perchè non si possa
>> aggiungere
>> alle singole way. Al massimo sarà ridondante ma non mi sembra errato,
>> quel
>> tratto di sentiero lì ha effettivamente quel nome e non è che lo perda
>> nel
>> momento in cui una sezione CAI decide che è quello ufficiale del
>> sentiero.
>> Lo so che non si mappa per il rendering ma i renderer escursionistici non
>> fanno in genere vedere i nomi delle relazioni sui sentieri (anche a
>> ragione
>> perchè visivamente il risultato non sarebbe spesso piacevole/utile, vedi
>> l'esempio delle relazioni liguri) quindi aggiungere il nome di un
>> sentiero
>> sulla way è di fatto l'unico modo di vederlo. Se non fosse formalmente
>> errata come cosa io preferirei aggiungerlo piuttosto che perdere la
>> visualizzazione del nome dei soli sentieri che lo hanno ufficializzato.
>>
>>
> 
> ___
> Talk-it mailing list

> Talk-it@

> https://lists.openstreetmap.org/listinfo/talk-it





--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk-fr] traces gps

2017-10-12 Diskussionsfäden Stéphane Péneau


En général, je mets :
- Le récepteur Gnss utilisé
- La fréquence
- Le moyen de locomotion

Stf

Le 12/10/2017 à 12:59, marc marc a écrit :

Bonjour,

Le 12. 10. 17 à 12:20, Anne-Marie Candès a écrit :

Quels tags utiliser quand on envoie une trace gps ?
Je trouve parmis les tags des dernières traces envoyées : divers, Walking 
Trace,walking,

  > et très souvent pas de tag.

Les mots clefs ont l'air en effet rarement utilisé dans les traces gps.
tu peux éventuellement y mettre le(s) quelques mots-clef de ta description.
C'est d'ailleurs la description qui me semble le plus utile :
trace d'une voie qui n'existe pas dans osm ou qui a changé ou
amélioration de la précision ? voir vitesse de déplacement (parce
qu'une trace à pied est souvent de meilleur qualité qu'en voiture).


Doit-on utiliser la langue de son compte, la langue du pays où se situe la 
trace ou l’anglais par défaut ?

Le plus utile me semble d'utiliser une langue courante (si tu la parles)
de l'endroit où se situe la trace (ou évidement l'omniprésent anglais).

Cordialement,
Marc
___
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-ca] Mapping of bilingual destination signs

2017-10-12 Diskussionsfäden Martijn van Exel

I think that should be fine. Your proposal also follows the convention in
OSM that the 'default' name is the name in the primary language for the
area.

On Wed, Oct 11, 2017 at 7:23 PM, Matthew Darwin  wrote:

> Should we follow the convention that the local language does not need a
> language tag and the alternate language does.  So for Fredericton (or
> Ottawa), it is
> destination=New Maryland
> destination:street:fr=Rue Regent Sud
> destination:street=Regent Street South
> destination:ref=101 South
>
> This way existing renderers that don't understand the language extension
> continue to work.
>
> On 2017-10-09 03:52 PM, Martijn van Exel wrote:
>
> Hi all,
>
> I contacted the most active mappers in NB. It seems that mapping bilingual
> street destinations with destination:street:fr and destination:street:en
> respectively is an acceptable solution. So the exit way related to the
> image in our ticket (https://github.com/TelenavMapping/mapping-
> projects/issues/27) would be mapped as:
>
> destination=New Maryland
> destination:street:fr=Rue Regent Sud
> destination:street:en=Regent Street South
> destination:ref=101 South
>
> (just destination tags, ignoring the other tags obviously needed)
>
> As promised, I will update the OSM wiki to clarify the destination:street
> tagging some.
>
> Does this sound okay to you?
>
> Thanks for all your feedback.
> Martijn
>
>
> On Fri, Oct 6, 2017 at 3:36 PM, Martijn van Exel  wrote:
>
>> Hi all,
>>
>> Thanks all for your input. I get a sense that there is a preference for
>> separating out the names on these destination signs in separate language
>> tags, even though documentation for destination:street is sparse. To be
>> sure I contacted what I hope are the top mappers in NB. A list of mappers I
>> contacted and the message I sent is in the github ticket (
>> https://github.com/TelenavMapping/mapping-projects/issues/27). This is
>> based on the Pascal Neis web site http://resultmaps.neis-one.org/oooc .
>>
>> It would be nice to update the NB wiki page with a French / English map
>> but I will leave that to the experts.
>>
>> I will try and clarify the destination:street documentation on the wiki
>> next week.
>>
>> Martijn
>>
>> On Mon, Oct 2, 2017 at 10:16 PM, J.P. Kirby  wrote:
>>
>>>
>>> On 2017-10-03, at 12:33 AM, Matthew Darwin  wrote:
>>>
>>> > Hi J.P.
>>> >
>>> > This sounds reasonable.  Do we have a map that shows which areas of
>>> the province are French area vs English area.  For us non-NBers.   Or I
>>> suppose one could guess by looking at the existing tags there.  (I would
>>> assume Fredericton is English area?)  If we have a list then could update
>>> the NB wiki page. https://wiki.openstreetmap.org/wiki/New_Brunswick
>>>
>>> The general rule is that southern and western NB is English, northern
>>> and eastern is French; but there are exceptions, and a couple places like
>>> Bathurst and Campbellton are 50/50.
>>>
>>> But yes, you can almost always tell from the tags and the street names
>>> themselves (e.g. "St. Mary's" vs "Sainte-Marie").
>>>
>>> JPK
>>>
>>>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>
>>
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

2017-10-12 Diskussionsfäden Badita Florin

I started processing, State by State, the Tiger 2017 dataset, because i get
less errors from overpass this way then if i process in bulk of 10 states.

The first state is Alabama.It took around 5 hours to complete,and it shows
over 20.000 possible ways that are not added in OSM.
The total length of the ways is 5042 km, or 3133 miles.
The xml size is 36Mb, and can be found in this folder.
https://drive.google.com/drive/folders/0B7aOUf0DFRnLU3hUWFNuS05JS2c?
usp=sharing

There are 5 35x35 miles tiles missing from the data.

Be mindful that this is the raw output, and even if Tiger 2017 is better
then older versions, there are still a lot of bad data in Tiger.

I expect more then 50% of the data to not be good for mapping into OSM.
Also, you can filter this data-set and keep just the road with the names,
that could be more important roads compared to the ones that don`t have a
name.

@joe, regarding the dataset for the twin cities, if you can create/provide
a translation file for the shapefile, i can run it and post the results in
the folder.

Some examples here

https://github.com/ToeBee/ogr2osm-translations








On Wed, Oct 11, 2017 at 6:46 PM, Ian Dees  wrote:

> Yes, it'd be great to do this. I started a project to track open road
> centerlines like this on GitHub here: https://github.com/osmla
> b/centerlines
>
> In theory, we could download that data and then do the same process using
> the presumably higher quality road data.
>
> On Wed, Oct 11, 2017 at 10:42 AM, Joe Sapletal 
> wrote:
>
>> This is really cool.  Can I suggest for the Twin Cities metro area
>> someone doing something similar with the Metro Regional Centerlines
>> Collaborative Local Centerlines (MRCC)?  I know that Dakota County hasn’t
>> submitted centerlines to Tiger in a couple of years, but will be for the
>> next update.  Not sure about the other counties though.  There very well
>> may be areas that the MRCC will be a better source than the Tiger data.
>>
>>
>>
>> https://gisdata.mn.gov/dataset/us-mn-state-metrogis-trans-mr
>> cc-centerlines
>>
>>
>>
>> Joe
>>
>>
>>
>> *From: *Ian Dees 
>> *Sent: *Wednesday, October 11, 2017 10:25 AM
>> *To: *Badita Florin 
>> *Cc: *talk-us@openstreetmap.org Openstreetmap 
>> *Subject: *Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a
>> automatedway.
>>
>>
>>
>> It would be interesting to see what differences CYGNUS would turn up.
>> What would the output of CYGNUS be?
>>
>>
>>
>> I put together the TIGER 2017 layer that's in the editors right now. I'll
>> work on writing up how I did it later today.
>>
>>
>>
>> Basically: I used tiger-tiles (https://github.com/iandees/tiger-tiles)
>> to generate a vector tiles database with expanded road names from TIGER
>> 2017. Then I downloaded an osm-qa-tiles (https://osmlab.github.io/osm-
>> qa-tiles/) file for the United States and ran osmlint's tigerDelta (
>> https://github.com/osmlab/osmlint/tree/master/validators/tigerDelta) to
>> find the segments that had different geometry. The output was then ran
>> through Tippecanoe to generate a vector tileset and posted to Mapbox as the
>> low zoom red features.
>>
>>
>>
>> On Wed, Oct 11, 2017 at 4:03 AM, Badita Florin 
>> wrote:
>>
>> Hi, i wanted to ask if there will be interest around comparing TIGER 2017
>> with what we have in OSM, using CYGNUS, in a automated way.
>> http://www.openstreetmap.org/user/mvexel/diary/36746
>>
>>
>>
>> On top of cygnus, i have developed shgp2cygnus, were you can place any
>> shapefile, any size, you provide a translation file, and, in the end, you
>> get a list with all the ways that are in the TIGER dataset, but not in OSM.
>>
>> This would be something useful for the community ?
>>
>>
>>
>> I don`t know if somebody is already doing something similar, or what is
>> the status ? Were can i read more ?
>>
>> I knoiw that the TIGER 2017 Overlay in JOSM shows in red the roads that
>> are not in OSM, but are in TIger 2017.
>>
>> But I don`t know were to read more, and if the data is accessible to
>> download directly, not just show as a WMS Layer.
>>
>>
>>
>> It will take around 7-14 days to process all USA”
>>
>>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Texas - redacted roads.

2017-10-12 Diskussionsfäden Nathan Mills

The problem as I understand it is less copyright violation (in the US, so long 
as what you see in Google isn't ever put into the OSM database), and more 
database licensing difficulty in the rest of the world where the law is less 
permissive and even using Google to identify possible errors in to be corrected 
by survey or open data could be legally questionable in terms of sublicensing 
the work as a whole.

Best to stay well on the correct side of the line just to avoid any possible 
issues since we have to be legal globally, not just in the US or UK or the EU.

-Nathan

On October 12, 2017 6:04:37 AM EDT, Nick Hocking  wrote:
>richlv wrote "just a quick reminder that we should try not to use
>google
>maps or
>streetview, the legal status of "just looking" is also fuzzy :)"
>
>
>Ok, so I if want to find out what a road is called, I'm not allowed to
>use
>a street directory to do this?  This would be extremely weird.
>
>If I am allowed to use a street directory for this, then I'm not
>allowed to
>tell anybody else what I think the name of the road is.  Also extremely
>weird.
>
>I don't believe that writing what someone else thinks is the name of
>the
>roads constitutes republishing their proprietary work and I'm certainly
>not
>putting this information into any other work or database. (Mind you
>IANAL).
>
>A few years ago this topic came up and IIRC Google said that it was ok
>to
>look at "some" amount of their published data but not systematically
>trawl
>through a LOT of it.
>All very subjective, I know.

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

Re: [Talk-lt] 3D žemėlapis

2017-10-12 Diskussionsfäden Tomas Straupis

> Kad deda info, labai gerai. Bet kad pavogė Gedimino kalną iš po pilies
> bokšto, tai nežinau kaip vertinti. Gal dėl to ten tie bokštiniai kranai
> stovi. :-)

  Yra galimybė įjungti ir aukščio info (reikia susirasti parinkčių
dialogą ir ten įsijungti aukščio informaciją), bet aukščio info panašu
eina iš SRTM duomenų, o jie, kaip tyčia, kaip tik per Gedimino kalną
turi duomenų (jungimo?) problemą. Ir šiaip turimą aukštį norisi
didinti, nes labai jau „maži“ tie Lietuvos kalniukai, labai jau
„lygiai“ atrodo...

-- 
Tomas

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

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-12 Diskussionsfäden Vincent Privat

Hello,
Si vous constatez des bugs du support geojson dans JOSM merci de les
remonter ici: https://github.com/JOSM/geojson/issues
A+
Vincent

Le 12 octobre 2017 à 12:04, Christian Quest  a
écrit :

> C'est un comportement habituel (bug pour moi) de JOSM avec les geojson, et
> pas spécifique aux fichiers du cadastre à ce qu'il me semble.
>
> Le 12/10/2017 à 10:49, David Marchal a écrit :
>
> Bonjour.
>
>
> En effet, j’ai résolu les problèmes, mais, si ça peut être automatisé,
> autant le faire, je pense, non ?
>
>
> Cordialement.
>
>
> --
> *De :* HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI
> PERFORMANCE)  
> *Envoyé :* mercredi 11 octobre 2017 09:09
> *À :* Discussions sur OSM en français
> *Objet :* Re: [OSM-talk-fr] Publication OpenData du cadastre
>
>
> Hello,
>
>
>
> Tu sélectionnes  tous tes objets avec type :way puis tu demandes la
>  validation  des objets puis la réparation et hop JOSM ne râle plus
>
>
>
> *De :* David Marchal [mailto:pene...@live.fr ]
> *Envoyé :* mercredi 11 octobre 2017 08:33
> *À :* Discussions sur OSM en français 
> 
> *Objet :* Re: [OSM-talk-fr] Publication OpenData du cadastre
>
>
>
> Bonjour.
>
>
>
> Je viens de remarquer un bug sur l’import du GéoJSON du bâti : les
> polygones des bâtiments ne sont pas fermés, ce qui fait hurler JOSM ;
> apparemment, les bâtiments sont constitués d’une ligne dont le premier et
> le dernier point ont les mêmes coordonnées, mais ne sont pas le même point.
> Pour JOSM, le polygone n’est pas fermé.
>
>
>
> Cordialement.
>
>
>
> --
> Christian Quest - OpenStreetMap France
>
>
> ___
> 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-lt] 3D žemėlapis

2017-10-12 Diskussionsfäden Aidas Kasparas


On 2017.10.12 14:57, Tomas Straupis wrote:

Sveiki

   Paskutiniu metu naudotojas chachafish pridėjo nemažai labai detalios
3D informacijos (ir dar pildo).
   Prašome pasigrožėti:

http://demo.f4map.com/#lat=54.6859166=25.2881861=19=63.048=-145.245

http://demo.f4map.com/#lat=54.6525444=24.9337558=19=59.037=28.934

Kad deda info, labai gerai. Bet kad pavogė Gedimino kalną iš po pilies 
bokšto, tai nežinau kaip vertinti. Gal dėl to ten tie bokštiniai kranai 
stovi. :-)



--
Aidas Kasparas

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

Re: [Talk-lt] 3D žemėlapis

2017-10-12 Diskussionsfäden Tomas Straupis

> 3D informacijos į osm duomenų bazę?

  Taip.

-- 
Tomas

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

Re: [Talk-lt] 3D žemėlapis

2017-10-12 Diskussionsfäden Mantas

3D informacijos į osm duomenų bazę?

2017 m. spalio 12 d. 14:57, Tomas Straupis  rašė:

> Sveiki
>
>   Paskutiniu metu naudotojas chachafish pridėjo nemažai labai detalios
> 3D informacijos (ir dar pildo).
>   Prašome pasigrožėti:
>
> http://demo.f4map.com/#lat=54.6859166=25.2881861=
> 19=63.048=-145.245
>
> http://demo.f4map.com/#lat=54.6525444=24.9337558=
> 19=59.037=28.934
>
> --
> Tomas
>
> ___
> Talk-lt mailing list
> Talk-lt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-lt
>



-- 
 Mantas aka sirex
  __o   /\
_ \<,_   -- http://t.me/sirexo --/\/  \
___(_)/_(_)_/_/\
^
___
Talk-lt mailing list
Talk-lt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-lt

[Talk-lt] 3D žemėlapis

2017-10-12 Diskussionsfäden Tomas Straupis

Sveiki

  Paskutiniu metu naudotojas chachafish pridėjo nemažai labai detalios
3D informacijos (ir dar pildo).
  Prašome pasigrožėti:

http://demo.f4map.com/#lat=54.6859166=25.2881861=19=63.048=-145.245

http://demo.f4map.com/#lat=54.6525444=24.9337558=19=59.037=28.934

-- 
Tomas

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

Re: [Talk-it] R: Digest di Talk-it, Volume 131, Numero 24

2017-10-12 Diskussionsfäden paolo bubici

io ho votato si!

Il giorno 12 ottobre 2017 10:30, Martin Koppenhoefer  ha scritto:

>
>
> 2017-10-12 0:17 GMT+02:00 Alberto :
>
>> > 1. perché dobbiamo cambiare il tag da "fire_hydrant:*" a "*" se ci sono
>> già
>> > millioni di questo tag, se non cambia nient'altro che togliere il
>> prefisso?
>>
>> Innanzi tutto perché nella discussione diversi avevano proposto così e
>> gli altri sembravano tutti d'accordo.
>> Ma soprattutto ci sono diversi tag che non sono specifici per gli
>> idranti, quali pressure, location e diameter e quasi tutti quelli nuovi
>> proposti (water_source, water_volume, couplings, couplings:type,
>> couplings:diameters, ecc).
>>
>
>
> si, avevo visto anch'io adesso che sia pressure che diameter sono già
> definiti sulla pagina man_made=pipeline (ma non ci sono pagine per la
> chiave, quindi si rischia di definire le chiave diversamente su pagine
> diverse):
> https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpipeline
>
>
> Visto che queste chiavi sono già in uso e documentati sulla pagina
> pipeline, uno potrebbe creare delle pagine di definizione per queste
> chiavi, e poi proporre di usare le chiavi "alternative" senza prefisso ;-),
> ma sarebbe comunque potenzialmente difficile di convincere tutti, perché
> fire_hydrant:diameter è usato 400.000 volte, diameter 10.000 volte:
> https://taginfo.openstreetmap.org/search?q=diameter
>
> francamente, per tags in uso centinaia di migliaia di volte non tenterei
> di cambiarli. E' uno sforzo enorme (ci sono già le applicazioni che usano
> questi tag), ed il guadagno è relativamente piccolo. Mi concentrerei sui
> tags nuovi da aggiungere al sistema in uso. D'altro canto, l'idea di avere
> un sistema più consistente e uniforme mi piace pure.
>
>
>
>
>> Forse per type si potrebbe anche mantenere il prefisso fire_hydrant:, ma
>> si era scelto così per uniformare il più possibile.
>>
>
>
> però adesso è già uniforme (sempre con prefisso).
>
>
> Per quanto riguarda i milioni di tag coinvolti, una volta stabilito cosa
>> fare, non vedo grande differenza tra cambiarne 100 o 1.000.000, visto che
>> si dovranno solamente selezionare tutti i fire_hydrant:pressure=*,
>> fire_hydrant:diameter=*,  fire_hydrant:position=*, ecc. e sostituirli con
>> pressure=*, diameter=*, location=*, ecc.
>>
>
>
> questo è il lato database, c'è anche il lato mappatore, preset,
> applicazioni, rendering, ecc. Tutti gli sviluppatori dovrebbero aggiornare
> i loro software e gli utenti dovrebbero aggiornarli. Parliamo di un
> contesto dove già usano questi dati (presso alcuni vigili del fuoco). Al
> meno una fase di transizione (uso doppio) si dovrebbe prevedere (IMHO).
>
> Non dico che non si può fare, ma il fatto che tanti adesso hanno votato
> "no" vuol dire che c'è ancora da fare per convincere le persone.
>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[talk-ph] Name of Festival Alabang

2017-10-12 Diskussionsfäden Jherome Miguel

The name of Festival Alabang is continually being changed repeatedly by
"rjamz" to an anachronistic name, Festival Supermall Alabang, and my
frequent reverts may end in edit war If not addressed (unless I will report
this to the DWG). I strongly agree that Festival Alabang is the correct
name, as it is the one used now on signage, and the old signage using
"Festival Supermall" are now removed, so, using it as the name is already
old-fashioned. Are there users who agree that Festival Alabang is the
correct name now?
--TagaSanPedroAko
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

Re: [Talk-it] tabelle accesso su ciclabili e ciclopedonali

2017-10-11 20:07 GMT+02:00 Volker Schmidt :

> Secondo l'esperto Enrico Chiarini della FIAB (che ho contatto
> appositamente) l'affermazione del ciclistaurbano che le ciclopedonali in
> Italia hanno l'obbligo di uso per ciclisti è falsa.
>


lo potresti anche chiedere come ci possono essere limiti di velocità sulle
piste ciclabili? Visto che non sei obbligato ad avere un tachimetro in bici
e anche quando ce l'hai non è tarato, come puoi sapere la tua velocità?

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

Re: [Talk-it] Tag wikipedia su via

2017-10-12 13:00 GMT+02:00 Jo :

> anche ho fatto correzione addizionale. Ho creato nuovo entrata per la
> persona correcta in Wikidata.
>


sisi, l'avevi già scritto, il commento non era riferito a te.

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

Re: [Talk-it] Tag wikipedia su via

2017-10-12 Diskussionsfäden Jo

anche ho fatto correzione addizionale. Ho creato nuovo entrata per la
persona correcta in Wikidata.

Polyglot

2017-10-12 11:49 GMT+02:00 Martin Koppenhoefer :

> 2017-10-12 0:13 GMT+02:00 Marco_T :
>
>> Ciao Daniele,
>> concordo che è sbagliato in quanto l'oggetto mappato è la via, non il
>> personaggio a cui è dedicata.
>> Diverso sarebbe se la via avesse una denominazione particolare con un item
>> wikipedia riferito poroprio a quella specifica via, tipo queste:
>> https://it.wikipedia.org/wiki/Vie_di_Firenze
>> Consiglio di segnalare la cosa con un commento al changeset (magari
>> allegando un link a questa discussione), in questo modo il mappatore può
>> imparare qualcosa di nuovo e se non è convinto può chiedere spiegazioni o
>> motivare le sue scelte.
>>
>
>
> avete visto la modifica di Polyglot?
> Ha cambiato la chiave in "name:etymology:wikidata"
> un tag apposito per mettere un riferimento di etimologia di un nome.
>
> La cosa più grave la vedo nell'inserimento della persona sbagliata
> (omonima). E' proprio il caso per cui si mettono questi riferimenti, e se
> non si mettono con cura e certezza è meglio non mettere niente...
>
> Ciao,
> Martin
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] fin d'une route secondaire ou tertiaire vers un hameau

2017-10-12 Diskussionsfäden djakk djakk

J'ai pas compris, as-tu le lien direct sur osm ?

Le 12 octobre 2017 à 10:02, marc marc  a écrit :

> Bonjour,
>
> Que faire lorsqu'une route secondaire ou tertiaire raccorde un hameau ?
> le hameau est en highway=unclassified
> j'ai mis la bretelle d'accès à la route secondaire en secondary_link
> mais osmose est d'avis que c'est pas ainsi qu'il faut faire :)
>
> Cordialement,
> Marc
> ___
> 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] traces gps

Bonjour,

Le 12. 10. 17 à 12:20, Anne-Marie Candès a écrit :
> Quels tags utiliser quand on envoie une trace gps ?
> Je trouve parmis les tags des dernières traces envoyées : divers, Walking 
> Trace,walking,
 > et très souvent pas de tag.

Les mots clefs ont l'air en effet rarement utilisé dans les traces gps.
tu peux éventuellement y mettre le(s) quelques mots-clef de ta description.
C'est d'ailleurs la description qui me semble le plus utile :
trace d'une voie qui n'existe pas dans osm ou qui a changé ou 
amélioration de la précision ? voir vitesse de déplacement (parce
qu'une trace à pied est souvent de meilleur qualité qu'en voiture).

> Doit-on utiliser la langue de son compte, la langue du pays où se situe la 
> trace ou l’anglais par défaut ?

Le plus utile me semble d'utiliser une langue courante (si tu la parles) 
de l'endroit où se situe la trace (ou évidement l'omniprésent anglais).

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

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

2017-10-12 Diskussionsfäden Andreas Lattmann

>Così per sapere, hai visto la faccina e letto il resto del messaggio?

No, in sincerità no. Ero di corsa. 

Ho solo dato un occhiata veloce alle mail.

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

[OSM-talk-fr] traces gps

2017-10-12 Diskussionsfäden Anne-Marie Candès

Bonjour à tous
Quels tags utiliser quand on envoie une trace gps ? 
Je trouve parmis les tags des dernières traces envoyées : divers, Walking 
Trace,walking,et très souvent pas de tag.
Doit-on utiliser la langue de son compte, la langue du pays où se situe la 
trace ou l’anglais par défaut ?
Merci
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Texas - redacted roads.

richlv wrote "just a quick reminder that we should try not to use google
maps or
streetview, the legal status of "just looking" is also fuzzy :)"


Ok, so I if want to find out what a road is called, I'm not allowed to use
a street directory to do this?  This would be extremely weird.

If I am allowed to use a street directory for this, then I'm not allowed to
tell anybody else what I think the name of the road is.  Also extremely
weird.

I don't believe that writing what someone else thinks is the name of the
roads constitutes republishing their proprietary work and I'm certainly not
putting this information into any other work or database. (Mind you IANAL).

A few years ago this topic came up and IIRC Google said that it was ok to
look at "some" amount of their published data but not systematically trawl
through a LOT of it.
All very subjective, I know.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-12 Diskussionsfäden Christian Quest

C'est un comportement habituel (bug pour moi) de JOSM avec les geojson, 
et pas spécifique aux fichiers du cadastre à ce qu'il me semble.



Le 12/10/2017 à 10:49, David Marchal a écrit :


Bonjour.


En effet, j’ai résolu les problèmes, mais, si ça peut être automatisé, 
autant le faire, je pense, non ?



Cordialement.




*De :* HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI 
PERFORMANCE) 

*Envoyé :* mercredi 11 octobre 2017 09:09
*À :* Discussions sur OSM en français
*Objet :* Re: [OSM-talk-fr] Publication OpenData du cadastre

Hello,

Tu sélectionnes  tous tes objets avec type :way puis tu demandes la 
 validation  des objets puis la réparation et hop JOSM ne râle plus


*De :*David Marchal [mailto:pene...@live.fr]
*Envoyé :* mercredi 11 octobre 2017 08:33
*À :* Discussions sur OSM en français 
*Objet :* Re: [OSM-talk-fr] Publication OpenData du cadastre

Bonjour.

Je viens de remarquer un bug sur l’import du GéoJSON du bâti : les 
polygones des bâtiments ne sont pas fermés, ce qui fait hurler JOSM ; 
apparemment, les bâtiments sont constitués d’une ligne dont le premier 
et le dernier point ont les mêmes coordonnées, mais ne sont pas le 
même point. Pour JOSM, le polygone n’est pas fermé.


Cordialement.




--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] fin d'une route secondaire ou tertiaire vers un hameau

2017-10-12 Diskussionsfäden Christian Quest


Les "link" ce sont en principe des bretelles.

Vu la description, là c'est du unclassified qui permet d'aller de la 
route au hameau (qui a dit sur-tagging ?)



Le 12/10/2017 à 10:02, marc marc a écrit :

Bonjour,

Que faire lorsqu'une route secondaire ou tertiaire raccorde un hameau ?
le hameau est en highway=unclassified
j'ai mis la bretelle d'accès à la route secondaire en secondary_link
mais osmose est d'avis que c'est pas ainsi qu'il faut faire :)

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


--
Christian Quest - OpenStreetMap France


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

Re: [Talk-it] Tag wikipedia su via

2017-10-12 0:13 GMT+02:00 Marco_T :

> Ciao Daniele,
> concordo che è sbagliato in quanto l'oggetto mappato è la via, non il
> personaggio a cui è dedicata.
> Diverso sarebbe se la via avesse una denominazione particolare con un item
> wikipedia riferito poroprio a quella specifica via, tipo queste:
> https://it.wikipedia.org/wiki/Vie_di_Firenze
> Consiglio di segnalare la cosa con un commento al changeset (magari
> allegando un link a questa discussione), in questo modo il mappatore può
> imparare qualcosa di nuovo e se non è convinto può chiedere spiegazioni o
> motivare le sue scelte.
>


avete visto la modifica di Polyglot?
Ha cambiato la chiave in "name:etymology:wikidata"
un tag apposito per mettere un riferimento di etimologia di un nome.

La cosa più grave la vedo nell'inserimento della persona sbagliata
(omonima). E' proprio il caso per cui si mettono questi riferimenti, e se
non si mettono con cura e certezza è meglio non mettere niente...

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

[Talk-us] Davis Senior High School, California

2017-10-12 Diskussionsfäden Andy Townsend

Among rather more serious problems (smoke from the Napa wildfires) Davis 
Senior High School is home to some Pokemon fans who don't like doing 
their homework. http://www.openstreetmap.org/way/23646951/history has 
been changed a number of times to a park labelled "Please let us drop 
tests Mr. Birdsall".


I'm sending this mail to the list on the off chance that someone here 
may know someone there - a quiet word from a friend would be a nicer 
approach than an "official" email from OSM.  What'd be great is if we 
can convert the mapper(s) concerned into mapping things that actually 
exist rather than adding fake Pokemon parks called "Hi Albert".


Best Regards,

Andy Townsend, on behalf of OSM's Data Working Group

PS: In case anyone wonders "why don't you just IP block them", some of 
the edits are from iPhones, so that wouldn't be an option here (and 
probably wouldn't be proportionate even if that wasn't the case).  Also, 
while some of the edits may seem to suggest the name of one student, I 
wouldn't assume that that person is a perpetrator - they may be just the 
victim of a kind of joe-job.



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

Re: [OSM-talk-fr] Publication OpenData du cadastre

2017-10-12 Diskussionsfäden David Marchal

Bonjour.

En effet, j’ai résolu les problèmes, mais, si ça peut être automatisé, autant
le faire, je pense, non ?

Cordialement.

De : HELFER Denis (SNCF RESEAU / SIEGE SNCF RESEAU / DT GE APPUI PERFORMANCE)

Envoyé : mercredi 11 octobre 2017 09:09
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre

Hello,

Tu sélectionnes tous tes objets avec type :way puis tu demandes la validation
des objets puis la réparation et hop JOSM ne râle plus

De : David Marchal [mailto:pene...@live.fr]
Envoyé : mercredi 11 octobre 2017 08:33
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre

Bonjour.

Je viens de remarquer un bug sur l’import du GéoJSON du bâti : les polygones
des bâtiments ne sont pas fermés, ce qui fait hurler JOSM ; apparemment, les
bâtiments sont constitués d’une ligne dont le premier et le dernier point ont
les mêmes coordonnées, mais ne sont pas le même point. Pour JOSM, le polygone
n’est pas fermé.

Cordialement.

De : Vincent Privat >
Envoyé : mardi 3 octobre 2017 23:34
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Publication OpenData du cadastre

Hello,

Quelques compléments d'info sur JOSM.

Le support du cadastre est disponible, il faut utiliser la toute dernière
version stable (12921) de JOSM et la version 33690 du greffon cadastre-fr.

J'ai annoncé la nouvelle version du greffon il y a quelques jours sur la liste
dev-fr, et on en a parlé aussi au dernier meeting toulousain, j'ai déjà corrigé
quelques soucis de jeunesse suite aux tests préliminaires des mappeurs
toulousains :)

Le greffon permet d'ouvrir les lots Edigéo via file/open, file/open location,
ou en drag, soit de l'archive tar.bz2, soit du fichier .THF.

Les géométries sont automatiquement simplifiées pour éviter d'avoir des
piscines avec 500 nœuds. Le souci des bâtiments coupés en 2 au milieu d'une
limite de parcelle ne se pose pas, vu qu'il s'agit des géométries natives du
cadastre (sauf dans les cas de bâtiments à cheval sur plusieurs planches).

Actuellement sont chargés le bâti, les limites administratives, les parcelles &
sections, les adresses, la voirie, et diverses autres choses (puits, pylônes,
cimetières, bâtiment de culte, etc.). Tout est sourcé avec le tag habituel
"cadastre-fr ... DGFiP 2017 etc.".

Ne sont pas chargés: les infos de mitoyenneté (mur, fossé) parce que
représentées par un nœud, et les choses qui sont bizarrement regroupées dans le
cadastre telles que "terrains de sport et petits ruisseaux" (WTF?!), ou bien
"parking, terrasse, surplomb", etc.

Pour les curieux la correspondance entre les données du cadastre et les tags
OSM se fait ici:

https://github.com/openstreetmap/josm-plugins/blob/master/cadastre-fr/src/org/openstreetmap/josm/plugins/fr/cadastre/edigeo/pci/EdigeoPciReader.java#L37

[https://avatars1.githubusercontent.com/u/261431?v=4=400]

openstreetmap/josm-plugins

github.com

josm-plugins - Mirror of the JOSM plugin repository in Subversion

Les calques chargés ainsi dans JOSM sont flaggués "envoi dissuadé". C'est à
dire: JOSM va vous crier dessus si vous essayez d'envoyer ces données vers OSM,
pour sensibiliser tout le monde qu'il y a un gros travail de vérification &
d'intégration à mener avant de faire ça. Si je vois qu'il y a des dérives et
des imports massifs sans travail préalable, je basculerai rapidement en mode
"envoi interdit", ce qui bloquera complètement l'envoi direct à partir de ces
calques.

Il me manque à exploiter la date de dernière mise à jour (je pense à la mettre
dans un tag source:date).

J'attends l'API Etalab avec impatience, ça permettra à JOSM de télécharger les
données du cadastre pour une zone donnée (actuellement il faut connaître le
numéro de planche du cadastre).

Si vous trouvez des bugs n'hésitez pas à me les remonter :)

A+

Vincent

Le 3 octobre 2017 à 14:47, Christian Quest
> a écrit :

Oui, officiellement dispo depuis hier... :)

Les données brutes de la DGFiP sont au format EDIGEO, format peu courant mais
ouvrable avec gdal (donc QGis).

Dans cette première livraison, Etalab propose une extraction des principales
couches d'infos surfaciques remise au format geojson en WGS84: limites de
communes, de section cadastrale, de parcelle, et l'emprise des bâtiments.

Des données sont téléchargeables par département et par communes pour les

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

2017-10-11 23:30 GMT+02:00 Massimiliano Guidi :

> Ma si che si mappa per il rendering, tu vai in giro per monti a fare query
> da terminale con un laptop? ;-)
>


oramai non serve più il laptop, puoi usare uno smartphone. Ma sono
d'accordo con te, stai in giro è più conveniente avere qualcosa già
preparato con te.


>
> Seriamente, ci sono due problemi:
> 1) Il circolo vizioso: tu metti i nomi sulle way perché i renderer
> ignorano le relazioni e i renderer continuano a ignorare le relazioni
> perché tanto tu metti i nomi sulle way.
>


bisogno usare un rendering che già interpreta le relazioni, esistono.




> 2) per il rendering le relazioni sono meglio, perché rappresentano il
> sentiero nella sua interezza. La way prima o poi finisce invariabilmente
> spezzata in enne segmenti in seguito alle variazioni di incline,
> trail_visibility, sac_scale, mtb:scale, surface e quant'altro.
>


+1, e highway (path / service / track, ecc.), talvolta ci sono anche brevi
tratti su strada, ecc.


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

Re: [Talk-us] Texas - redacted roads.

2017-10-12 Diskussionsfäden Rihards

On 2017.10.11. 13:37, Nick Hocking wrote:
> Andrew wrote "I would check out the City of Austin's OpenData portal:
> https://data.austintexas.gov/Locations-and-Maps/Street-Segment/t4fe-kr8c
> 
> The license is the same (PD) as when the initial building import was
> completed, so you are good to go."
> 
> Thanks Andrew, I'm now replacing some names adding new roads and
> neighbourhoods etc.
> 
> One interesting road is Redwil Drive.
>  https://www.openstreetmap.org/#map=18/30.23189/-97.59361
> 
> Tiger has no name, Google maps and Austin-gov have Redwill Drive but
> google street view shows both street signs as Reed Will Drive.
just a quick reminder that we should try not to use google maps or
streetview, the legal status of "just looking" is also fuzzy :)
-- 
 Rihards

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

Re: [Talk-it] R: Digest di Talk-it, Volume 131, Numero 24

2017-10-12 0:17 GMT+02:00 Alberto :

> > 1. perché dobbiamo cambiare il tag da "fire_hydrant:*" a "*" se ci sono
> già
> > millioni di questo tag, se non cambia nient'altro che togliere il
> prefisso?
>
> Innanzi tutto perché nella discussione diversi avevano proposto così e gli
> altri sembravano tutti d'accordo.
> Ma soprattutto ci sono diversi tag che non sono specifici per gli idranti,
> quali pressure, location e diameter e quasi tutti quelli nuovi proposti
> (water_source, water_volume, couplings, couplings:type,
> couplings:diameters, ecc).
>


si, avevo visto anch'io adesso che sia pressure che diameter sono già
definiti sulla pagina man_made=pipeline (ma non ci sono pagine per la
chiave, quindi si rischia di definire le chiave diversamente su pagine
diverse):
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpipeline


Visto che queste chiavi sono già in uso e documentati sulla pagina
pipeline, uno potrebbe creare delle pagine di definizione per queste
chiavi, e poi proporre di usare le chiavi "alternative" senza prefisso ;-),
ma sarebbe comunque potenzialmente difficile di convincere tutti, perché
fire_hydrant:diameter è usato 400.000 volte, diameter 10.000 volte:
https://taginfo.openstreetmap.org/search?q=diameter

francamente, per tags in uso centinaia di migliaia di volte non tenterei di
cambiarli. E' uno sforzo enorme (ci sono già le applicazioni che usano
questi tag), ed il guadagno è relativamente piccolo. Mi concentrerei sui
tags nuovi da aggiungere al sistema in uso. D'altro canto, l'idea di avere
un sistema più consistente e uniforme mi piace pure.




> Forse per type si potrebbe anche mantenere il prefisso fire_hydrant:, ma
> si era scelto così per uniformare il più possibile.
>


però adesso è già uniforme (sempre con prefisso).


Per quanto riguarda i milioni di tag coinvolti, una volta stabilito cosa
> fare, non vedo grande differenza tra cambiarne 100 o 1.000.000, visto che
> si dovranno solamente selezionare tutti i fire_hydrant:pressure=*,
> fire_hydrant:diameter=*,  fire_hydrant:position=*, ecc. e sostituirli con
> pressure=*, diameter=*, location=*, ecc.
>


questo è il lato database, c'è anche il lato mappatore, preset,
applicazioni, rendering, ecc. Tutti gli sviluppatori dovrebbero aggiornare
i loro software e gli utenti dovrebbero aggiornarli. Parliamo di un
contesto dove già usano questi dati (presso alcuni vigili del fuoco). Al
meno una fase di transizione (uso doppio) si dovrebbe prevedere (IMHO).

Non dico che non si può fare, ma il fatto che tanti adesso hanno votato
"no" vuol dire che c'è ancora da fare per convincere le persone.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk-fr] fin d'une route secondaire ou tertiaire vers un hameau

Bonjour,

Que faire lorsqu'une route secondaire ou tertiaire raccorde un hameau ?
le hameau est en highway=unclassified
j'ai mis la bretelle d'accès à la route secondaire en secondary_link
mais osmose est d'avis que c'est pas ainsi qu'il faut faire :)

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

Re: [Talk-it] ASSEGNAZIONE NOMI SENTIERI e RELAZIONI

2017-10-12 Diskussionsfäden Massimiliano Guidi

Così per sapere, hai visto la faccina e letto il resto del messaggio?

Il gio 12 ott 2017, 07:41 Andreas Lattmann  ha
scritto:

> >Ma si che si mappa per il rendering, tu vai in giro per monti a fare
> query da terminale con un laptop? ;-)
>
> Non si mappa per il rendering per ovvi motivi: mapnik non renderizza le
> relazioni ma altri renderer si (e comunque ci vuole uno standard comune).
> Su Osmand ad esempio li renderizza. Poi non è detto che la relazione non
> includano way che hanno un nome proprio, tipo quelle che includono vie del
> paese. In quel caso come fai? Via pinco Sentiero dei forsennati?
> La migliore soluzione è sempre non mappare per il rendering.
>
> Andreas Lattmann
> --
> Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Nouvelle analyses Osmose sur la France : numéro de téléphone et intégration des restrictions de hauteur