Re: [Talk-it] pronto soccorso ospedali italiani

[Aury88]

dieterdreist wrote
> Am Mo., 4. Feb. 2019 um 08:01 Uhr schrieb Aury88 

> spacedriver88@

> :
> 
> dai, non ci sono traduttori automatici che soddisfano i requisiti di
> qualità che abbiamo, sennò il wiki diventerebbe un posto incomprensibile
> come le pagine di "aiuto" della microsoft, che si capiscono soltanto
> ritraducendole in inglese. In generale i traduttori stanno migliorando
> però
> e non escludo che arrivano ad un punto dove gli errori sono talmente poci
> da rischiare. Se fosse come dici tu, non ci sarebbero più traduttori
> (veri,
> persone che lo fanno come lavoro).

 non abbiamo neanche requisiti di qualià visto come sono scritte/tradotte
molte voci xD
non considererei valido il traduttore microsoft. mi sembra mlto migliore
quello di google. 
i traduttori di professione non fanno certo traduzioni di testi con un
linguaggio semplice...sono ormai  adibiti a tradurre testi di una certa
complessità nei quali i traduttori automatici ancora fanno fatica. 


> i casi specifici locali però sono legati ad un luogo, non ad una lingua.
> Il
> wiki "italiano" non è il wiki per l'Italia (al meno non nella parte
> generale dei tags), è il wiki in italiano. Il wiki per l'Italia è qui:
> https://wiki.openstreetmap.org/wiki/WikiProject_Italy

di fatto pur non essendo la wiki italiana dedicata all'italia è una wiki
usata praticamente solo da persone che mappano in molto in italia e parlano
italiano.. la situazione sarebbe stata problematica se fosse stato descritti
tag specifici per l'italia e non applicabili al resto del mondo o stili del
tutto contrari, ma non è così; semplicemente si ricordano tag che in italia
spesso non vengono messi e che potrebbe avere  senso ricordare ai mappatori
italiani sia quando mappano in italia sia quando mappano all'estero. a
livello internazionale gli entrance mi sembrano molto  più diffusi me se lo
ritieni utile ricordarlo fai pure


 la pagina di cui parli te è più una pagina di coordinamento mi sembra molto
diversa quindi dalla wiki dove viene descritto l'uso dei tag...ha uno scopo
differente 


> non pensare che le modifiche nel wiki internazionale siano più discusse o
> approvate rispetto a questa tua modifica. Per me potresti mettere le cose
> anche in inglese nel wiki ;-)
> Tanto i tag (al meno che non mi sfugge qualcosa) sono già diffusi, e non
> mi
> risultano contestati.

 non sono solito apportare modifiche così sostanziali ad una voce così
importante senza discuterle, seppur limitata a introdurre tag già approvati
ed usati. ma visto che non sono in grado di farlo in inglese non posso farlo
io.

in ambito internazionale comunque non mi risulta ci siano, per esempio,
carenze lato indicazione degli accessimentre è da noi che nalla maggio
parte defgli ospedali non è indicato alcun accesso agli edifici...temo
quindi che una modifica del genere nella voce inglese verrà vista come
superflua per non dire del tutto  inutile quando da noi ha sicuramente
un'utilità ricordare di mappare gli accessi.


>
> solo un appunto Martin...è da due settimane che è possibile vedere la
> sandox
> e discutere delle modifiche, due settimane in cui nessuno ha avuto da
> obbiettare all'aggiunta di elementi in più rispetto la voce in inglese
> nonostante l'ampia discussione qui e la diffusione della notizia sul
> canale
> telegram, non capisco quindi perchè hai aspettato che pubblicassi la
> modifica prima di intervenire. non era meglio farlo prima che fosse fatto
> il
> danno?
>


> mi era sfuggito ;-)
> Comunque, non sto obiettando sui contenuti da mettere, penso semplicemente
> che siano da inserire anche in inglese. Non c'è niente di particolare
> italiano che non si applica in altri paesi ("simili"). Un'altra pagina
> dove
> avrebbe senso parte del contenuto è questa:
> https://wiki.openstreetmap.org/wiki/Tag:emergency%3Demergency_ward_entrance

Martin io ho proposto, discusso e apportato modifiche che, visto l'utilizzo
e gli errori in italia, mi è sembrato utile inserire, specialmente per noi
italiani.  se ritieni che tali elemeni siano utili anche a livello
internazionale fai pure le modifiche del caso sulla wiki inglese. parli
sicuramente meglio di me l'inglese xD





-
Ciao,
Aury
--
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: [Talk-es] Toponimia en Cataluña

[dcapillae]

No hay problema ni hay nada que lamentar, Rafael. Se hace una propuesta, se
comenta sus ventajas e inconvenientes y listo.

A mí no me parece adecuada la propuesta por lo que ya he expuesto y el
peligro que conlleva. La comunidad OSM no es quién para decidir si un nombre
se usa o no se usa. Para eso están las fuentes, que pueden ser el
conocimiento local, las referencias de topónimos nacionales, el uso
reconocido por las academias de la lengua o cualquier otra fuente que
consideremos con autoridad y solvencia suficiente. Nosotros no somos quiénes
para decidirlo, y no tengas dudas de que este asunto se dirige a establecer
los nombres que se pueden o no se pueden usar en según que lenguas. ¿O lo
dudas? 

Comprendería más la polémica si fuese un par de nombres en un mismo idioma
que se disputan ocupar el espacio de la etiqueta «name=*» o pasar por ser un
nombre alternativo en «alt_name=*», pero trantándose de idiomas diferentes,
no debería existir conflicto. Que cada nombre se ponga en su lugar y listo.
OSM lo permite. Si se usa poco o solo por un número muy reducido de
personas, no es nuestro problema. El conflicto es artificial, provocado
precisamente por el deseo de que los lugares no sean reconocidos en idiomas
diferentes del idioma local, en especial, en español (o castellano, para que
a los bien pensantes no se les oprima el cerebro).

Si alguien quiere poner los topónimos de Andalucía en vasco, catalán,
asturiano, euskera o en el idioma que quiera, me parece bien. No le veo
mucho sentido si nadie los usa, pero tampoco me parece que sea un asunto que
debiera generar polémica ni que haya que formar un grupo de decisión para
saber si se usan o no se usan. Cada nombre tiene su espacio en OSM, con su
etiqueta correspondiente. Lo de formar grupos de decisión para censurar
según qué nombres en según que idiomas lo encuentro sumamente indeseable.

Por hoy ya he tenido suficientes conflictos y dosis de censura por defender
lo que para mí es completamente natural, que cada cual use el topónimo en la
lengua que quiera. Si alguien lo usa, se pone. Estoy bastante harto de que
se traten estos temas siempre con intención de crear polémica. Pasó con la
bandera y siempre con el idioma. Una lástima.



-
Daniel Capilla 
OSM user: dcapillae 
--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [Talk-es] Toponimia en Cataluña

[Rafael Avila Coya]

Hola, Daniel:

Siento mucho que digas que mi humilde propuesta de crear grupos para 
saber, que no decidir, si un nombre está en desuso o no en una lengua 
dada, lo veas como una propuesta de grupos que dicten qué se debe hacer 
con qué nombres de lugares. No iba para nada de eso. Sólo iba de 
proponer una solución para poder llevar la opción 2 de Joan a buen 
puerto (la complicada, pero seguramente la más acorde con los principios 
de buenas prácticas de OSM).


Un saludo,

Rafael.

O 04/02/19 ás 21:45, dcapillae escribiu:

Hola, Iñaki.

Bueno, sí, esa siempre ha sido mi posición: dejar la política fuera de OSM.
Tiene gracia que los saques a colación justo ahora cuando me acaban de
censurar unos mensajes en el grupo de Telegram por su contenido «político e
ideológico». Ya ves, el que siempre defiende dejar la política fuera de las
discusiones de OSM, el que no hace más que replicar a todo el que argumenta
desde sus propios prejuicios ideológicos, ya sea sobre banderas, idiomas,
territorios o sobre la virginidad de la Virgen, censurado por «hablar de
política». En fin. Uno es ya demasiado viejo para juzgar con inocencia este
tipo de acciones y actitudes.

Lo de hacer grupos de discusión abiertos para decidir que topónimo está en
uso y cuál no lo está no me parece adecuado si luego se va a usar para
censurar a todo aquel que quiera poner el nombre de un lugar en su propio
idioma. ¿Con qué autoridad? La comunidad de OSM puede decidir sobre
convenciones, estándares de edición y directrices de mapeo, no sobre si un
nombre está en uso o no lo está. Para eso están las academias de la lengua,
las guías de topónimos o las personas del lugar, que sabrán mejor que nadie
como llaman esos sitios en su idioma. Esos grupos abiertos,
multilingüísticos, pluridisciplinares o lo que queráis, no tienen autoridad
alguna para decirle a nadie qué nombres puede usar y cuáles no.

El mensaje de Joan me pareció sensato inicialmente. Con algunos matices,
pero bien: si un nombre no se usa, pues no lo pongas. Hasta ahí, correcto.
Pero de ahí a construir grupos de discusión que se dediquen a dictar lo que
está bien y lo que está mal, que decidan lo que se usa y lo que no se usa,
esto es, lo que «debes» o «no debes» usar, pues mira, va a ser que no.

Para corrección política y afirmaciones prejuiciosas, ya tenemos bastante
con el grupo de Telegram.



-
Daniel Capilla
OSM user: dcapillae
--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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



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

Re: [Talk-ca] Building Import update

[john whelan]

So are we happy with Yaro's suggestions?  Or perhaps I should rephrase that
can we live with them?

On the task manager square size I take it these have been split and split
again?

Thanks John

On Mon, 4 Feb 2019 at 18:08, Yaro Shkvorets  wrote:

> Briefly, here are my thoughts.
> 1) *Simplification*, i.e. removing nodes in the middle of a straight
> line. We should be able to apply this fix to the original data. Looks like
> James has done it a couple of weeks ago, so we can try take this data and
> go with it if there are no objections.
> 2) *Almost square angles*. Simple squaring in JOSM (Q) is a non-starter
> as it ruins geometries. Looks like we found a way to do it using JOSM
> Validator (this thread:
> https://lists.openstreetmap.org/pipermail/talk-ca/2019-February/009099.html).
> I think it should work. I don't like preprocessing data for this step since
> there would be no way to go back if the algorithm makes a mistake. Besides,
> I don't think we were able to find a working script to do it to begin with.
> 3) Preserving *building history*. I agree we should absolutely try to
> preserve the history whenever possible. "Replace geometry" (Ctrl-Shift-G)
> is the way to go here. For the record, here's what I meant when I was
> writing about possibility of deleting clusters of low quality generic
> buildings (there exist far worse than that):
> https://i.imgur.com/CNfDjvw.png If we want to preserve history for these
> buildings as well - fine by me.
> 4) *Import data quality vs existing OSM quality*. If there is any
> difference it should be addressed on a case-by-case basis by a person doing
> the import. Checking building history, imagery, etc. From my experience in
> Toronto East, import data is almost always more recent and has better
> details. IMO in the end we should try to replace geometries in most cases.
> 5) Secondary bulidings that are not in the dataset (*sheds, garages*). We
> should leave those to local mappers. Import should only be about importing
> data from the dataset.
> 6) *Square sizes*. I agree, in the high density Toronto core current
> squares are indeed too big. However, creating new smaller project at this
> point would make things quite complicated along the edges since we would
> have to deal with already imported data. I would prefer to finish Ontario
> project the way it is right now. If a square turns out to be too massive,
> the person doing the import will need to tackle that square in several
> changesets.
>
>
> On Sun, Feb 3, 2019 at 7:06 PM john whelan  wrote:
>
>> I'm not hearing we have a clear consensus on modifying the shape of
>> buildings with scripts and the Q button.
>>
>> My own personal view is it could introduce errors and unless it is very
>> obviously wrong when it should get picked up by the importing mapper it
>> should be left as is.
>>
>> Cheerio John
>>
>> On Sun, 3 Feb 2019 at 18:26, john whelan  wrote:
>>
>>> I'm hearing we keep the single import project as such.
>>>
>>> I'm hearing that we should preprocess the data first splitting out
>>> outlines that meet Pierre's right angle checks.  This data can just be
>>> imported using the current processes.
>>>
>>> I'm hearing we should then run the correcting scripts and extract the
>>> corrected buildings.  This becomes the second stage.  This data should be
>>> imported separately to the first since it needs to be more closely
>>> inspected in case the script has caused some deformation.
>>>
>>> At the moment I'm not sure if the two scripts above exist.
>>>
>>> I'm hearing what is left becomes the third stage which needs to be
>>> sorted out manually before being made available for import.  Again I see
>>> this as a separate task since the outlines will have been modified from the
>>> original.
>>>
>>> Note to James is the above practical?  Do we have the resources to do
>>> it?  Please do not do anything until we have an agreement to proceed.
>>>
>>> I'm hearing the existing imported building outlines will be subject to
>>> an overpass to pick out those building outlines that are not square.
>>>
>>> Then the "a miracle occurs" box on the project plan gets these into a
>>> JOSM todo list and mappers manually sort them out.  I'm not certain how
>>> this will happen.  I suspect if the overpass query is small enough and
>>> the buildings are loaded up from an off line source this might work.
>>>
>>> To come back to Toronto my feeling is this is best left to the local
>>> mappers in Toronto to decide how to proceed.  There is/was room for a local
>>> coordinator in the project plan.  Nate's expectations are different to mine
>>> and I think it makes sense for the local mappers to decide what they would
>>> like to do together with Nate and a Toronto mapper set themselves up to
>>> coordinate in Toronto.  The speed at which the buildings were added has
>>> been raised as a concern.  I'm unable to think of a way to address this
>>> other than a "please take it slowly" added to the instructions.
>>>
>>> 

Re: [OSM-talk] Renaming Macedonia

[Jóhannes Birgir Jensson]

Do we need a plan?

I noticed someone overzealous had changed the name in Icelandic to a 
translation of Northern Macedonia, however that is not the name of the country 
in Icelandic except for possibly now in official usage. We always referred to 
it as Macedonia before and FYROM equivalent only in very specific 
circumstances. We will continue to do so - also according to the Icelandic 
State Department current lists it is still Makedónía.

A name given to a country by others doesn't always reflect the locals 
preferences, indeed the Czechs deciding between Czechia and Czech Republic 
doesn't affect us as we will refer to them always as Tékkland.

This renaming will be done on a language by language basis I believe, and 
possibly the only things that need to be updated are official_name:lang tags, 
not the name:lang tags.

-- JBJ / Stalfur

4. febrúar 2019 kl. 19:31, skrifaði "Steve Doerr" :

> Is there a plan?

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

Re: [Talk-ca] Building Import update

[Yaro Shkvorets]

Briefly, here are my thoughts.
1) *Simplification*, i.e. removing nodes in the middle of a straight line.
We should be able to apply this fix to the original data. Looks like James
has done it a couple of weeks ago, so we can try take this data and go with
it if there are no objections.
2) *Almost square angles*. Simple squaring in JOSM (Q) is a non-starter as
it ruins geometries. Looks like we found a way to do it using JOSM
Validator (this thread:
https://lists.openstreetmap.org/pipermail/talk-ca/2019-February/009099.html).
I think it should work. I don't like preprocessing data for this step since
there would be no way to go back if the algorithm makes a mistake. Besides,
I don't think we were able to find a working script to do it to begin with.
3) Preserving *building history*. I agree we should absolutely try to
preserve the history whenever possible. "Replace geometry" (Ctrl-Shift-G)
is the way to go here. For the record, here's what I meant when I was
writing about possibility of deleting clusters of low quality generic
buildings (there exist far worse than that): https://i.imgur.com/CNfDjvw.png
If we want to preserve history for these buildings as well - fine by me.
4) *Import data quality vs existing OSM quality*. If there is any
difference it should be addressed on a case-by-case basis by a person doing
the import. Checking building history, imagery, etc. From my experience in
Toronto East, import data is almost always more recent and has better
details. IMO in the end we should try to replace geometries in most cases.
5) Secondary bulidings that are not in the dataset (*sheds, garages*). We
should leave those to local mappers. Import should only be about importing
data from the dataset.
6) *Square sizes*. I agree, in the high density Toronto core current
squares are indeed too big. However, creating new smaller project at this
point would make things quite complicated along the edges since we would
have to deal with already imported data. I would prefer to finish Ontario
project the way it is right now. If a square turns out to be too massive,
the person doing the import will need to tackle that square in several
changesets.


On Sun, Feb 3, 2019 at 7:06 PM john whelan  wrote:

> I'm not hearing we have a clear consensus on modifying the shape of
> buildings with scripts and the Q button.
>
> My own personal view is it could introduce errors and unless it is very
> obviously wrong when it should get picked up by the importing mapper it
> should be left as is.
>
> Cheerio John
>
> On Sun, 3 Feb 2019 at 18:26, john whelan  wrote:
>
>> I'm hearing we keep the single import project as such.
>>
>> I'm hearing that we should preprocess the data first splitting out
>> outlines that meet Pierre's right angle checks.  This data can just be
>> imported using the current processes.
>>
>> I'm hearing we should then run the correcting scripts and extract the
>> corrected buildings.  This becomes the second stage.  This data should be
>> imported separately to the first since it needs to be more closely
>> inspected in case the script has caused some deformation.
>>
>> At the moment I'm not sure if the two scripts above exist.
>>
>> I'm hearing what is left becomes the third stage which needs to be sorted
>> out manually before being made available for import.  Again I see this as a
>> separate task since the outlines will have been modified from the original.
>>
>> Note to James is the above practical?  Do we have the resources to do
>> it?  Please do not do anything until we have an agreement to proceed.
>>
>> I'm hearing the existing imported building outlines will be subject to an
>> overpass to pick out those building outlines that are not square.
>>
>> Then the "a miracle occurs" box on the project plan gets these into a
>> JOSM todo list and mappers manually sort them out.  I'm not certain how
>> this will happen.  I suspect if the overpass query is small enough and
>> the buildings are loaded up from an off line source this might work.
>>
>> To come back to Toronto my feeling is this is best left to the local
>> mappers in Toronto to decide how to proceed.  There is/was room for a local
>> coordinator in the project plan.  Nate's expectations are different to mine
>> and I think it makes sense for the local mappers to decide what they would
>> like to do together with Nate and a Toronto mapper set themselves up to
>> coordinate in Toronto.  The speed at which the buildings were added has
>> been raised as a concern.  I'm unable to think of a way to address this
>> other than a "please take it slowly" added to the instructions.
>>
>> Again this option is available to any other areas who would like to use
>> this method.
>>
>> I feel for Quebec the best thing to do is hold back until we have an
>> agreement for the rest of the country since there are Quebec mappers who
>> are not following this thread on talk-ca and to be honest we do seem to be
>> evolving on a hourly basis so waiting until the dust 

[Talk-is] Makedónía

[Jóhannes Birgir Jensson]

Sæl verið þið.

Sá að einhver hafði endurnefnt Makedóníu sem Norður-Makedóníu, það er 
hugsanlega opinbert nafn landsins og mætti fara inn í viðeigandi tag en við 
erum ekki að fara að endurnefna landið þó að formlegt heiti þess hafi breyst. 
Ég breytti þessu því til baka.

Sjá hugtakasafn utanríkisráðuneytisins þar sem "fyrrum lýðveldi Júgóslavíu" 
(FYROM) var alltaf aukanafn, ekki aðalnafn landsins. 
https://hugtakasafn.utn.stjr.is/leit-nidurstodur.adp?leitarord=Maked%C3%B3n%C3%ADa=oll=o
 
(https://hugtakasafn.utn.stjr.is/leit-nidurstodur.adp?leitarord=Maked%C3%B3n%C3%ADa=oll=o)

Á sama máta er okkur sama hvort Tékkar noti Republica Cska eða Czechia, það 
heitir áfram Tékkland hjá okkur. Við erum með Ísland á kortinu en ekki 
Lýðveldið Ísland sem name, það á heima í official_name.
--JBJ / Stalfur
___
Talk-is mailing list
Talk-is@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-is

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Florimond Berthoux]

Je ne vois pas pourquoi cycleway:left=opposite serait incorrecte, je
connais une rue à Paris ou les pictos vélo sont en cycleway:right (oui les
cyclistes en contre sens rouleraient à gauche, à l'anglaise).
La magie de la cartographie vélo c'est que tout est possible et tout a été
fait :D.

Les séparateurs barcelonais n'empêchent pas le franchissement par un
motorisés donc ce n'est pas une piste, donc il faut créer un nouvel
attribut pour son cycleway.
Et il en existe à Montreuil.
J'ai pris cette exemple pas pour demander la création d'un nouvel attribut,
mais pour illustrer qu'il existe une grande variété de
cycleway:=opposite_y, d'où l'utilité d'un tag d'accès non implicite
oneway:bicycle.


Le lun. 4 févr. 2019 à 21:58, Romain MEHUT  a
écrit :

> Bonsoir,
>
> Je reprends le sujet depuis le début car parcouru un peu vite.
>
> Shoreh dans son message initial donne en exemple
> https://www.openstreetmap.org/way/24692380/history avec des tags qui ne
> correspondent pas aux différents de cas de figure décrits sur le wiki. Un
> tour sur Streetview (désolé je n'ai pas trouvé mieux) montre qu'il s'agit
> du cas S1 (un double-sens cyclable sans voie dédiée) pour lequel il y a 2
> façon de le représenter. Il me semble que Shoreh a voulu choisir la 2ème
> mais au lieu d'avoir utilisé cycleway=opposite, il a utilisé
> cycleway:left=opposite. Ce qui est donc incorrect. La version précédente
> modifiée par Cartocité était correcte. Et en choisissant la 2ème façon, il
> n'est pas question d'utiliser en plus le tag oneway:bicycle=no.
>
> Concernant l'exemple barcelonais en photo, je ne vois pas la difficulté,
> il y a des séparateurs (certes modestes) donc c'est un piste cyclable.
>
> Romain
>
> Le lun. 4 févr. 2019 à 15:46, Florimond Berthoux <
> florimond.berth...@gmail.com> a écrit :
>
>
>> Je verrais bien un opposite_pictogram, et comment décrire les
>> pistes/bandes cyclables barcelonaise ?
>>
>> https://i2.wp.com/www.zicla.com/wp-content/uploads/2018/02/carrill-bici-calle-paris.png
>> Ce ne sont ni des pistes ni des bandes, il faudrait donc rajouter un
>> nouvel attribut, et donc demander aux render et router de prendre en compte
>> ce nouvel attribut ?
>> La galère.
>>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [Talk-it] accesso carraio

[Andrea Canevazzi]

Ciao a tutti,
tra l' attraversamento pedonale (highway=footway footway=crossing) e il
marciapiede (highway=footway footway=sidewalk)   io ho taggato il nodo con
kerb=lowered
è uno degli attraversamenti versoil Giardino dela Guastalla a Milano, su
via San Barnaba.

grazie per le risposte!
Andrea

*Arch. Andrea Canevazzi, Ph.D.*
 +39 3482453713
 andrea.caneva...@gmail.com 

*Via Novara, 160 | 20153 Milano | Italia*

*L’invio di documenti anche contabili  tramite posta elettronica è un mezzo
consentito, ai sensi dell’art.21 DPR 633/72 e a seguito della CM n. 45/E
del 19/10/2005; il documento informatico dovrà essere materializzato da chi
lo riceve tramite stampa su supporto cartaceo e quindi conservato come ogni
altro documento su carta.  *



Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno ven 1 feb 2019 alle ore 22:46 Martin Koppenhoefer <
dieterdre...@gmail.com> ha scritto:

>
>
> sent from a phone
>
> > On 1. Feb 2019, at 15:54, Andrea Canevazzi 
> wrote:
> >
> > Se ci fossero solo le lastre inclinate userei  kerb=lowered , ma in
> questo, con le due pietre arrotondate tipiche dei passi carrai forse c'è un
> tag diverso da usare.
> > Che cosa ne pensate?
>
>
> per me un nodo alla posizione del bordo strada con kerb=lowered ci
> starebbe. Invece per “le due pietre arrotondate tipiche” non conosco un
> tag, ma si potrebbe aggiungere volendo qualcosa. Sarebbe o un’altro tag al
> crossing o un nuovo oggetto (kerb mappato esplicitamente). Questi dettagli
> dipendono molto dal contesto, ed è difficile che si sviluppino sistemi
> concordati al livello globale.
>
> 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] Moulinette pour ajouter "oneway:bicycle=no" ?

[Shohreh]

Romain MEHUT wrote
> Il me semble que Shoreh a voulu choisir la 2ème mais au lieu d'avoir
> utilisé cycleway=opposite, il a utilisé cycleway:left=opposite. Ce qui est
> donc incorrect.

Il semble qu'Id vienne très récemment d'être modifié et permettre d'indiquer
si une rue à sens unique est en DSC pour les vélos :

https://i.postimg.cc/W4WQ75Lf/35-CA6-C0-D-ADCB-40-C4-A38-E-A16-AFCC07532.png



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [Talk-at] Fußwege in Mürzzuschlag

[grubernd]

On 04.02.19 19:46, Horst Willingshofer wrote:

In Mürzzuschlag gibt es im Zentrum viele Fußwege (highway:footway) auf OSM

Z.B.: https://www.openstreetmap.org/way/543134742#map=18/

Das sind fast alles ganz normale Gehsteige wie es sie in jedem Ort gibt.
Kann mir jemand sagen was es damit auf sich hat?



Ich denke die Frage solltest du am besten direkt an user:geri1213 
stellen. Der hat nach einem kurzen Blick in die Changesets die meisten 
dieser Wege vor einem Jahr eingetragen und sich seitdem in den Ruhestand 
begeben.



grüsse,
grubernd

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

Re: [Talk-it] mappe Umap con immagini Flickr

[liste DOT girarsi AT posteo DOT eu]

Il 04/02/19 22:49, liste DOT girarsi AT posteo DOT eu ha scritto:
> Dimenticavo, uso firefox come browser.
> 

Questa mi sembra megliore come suggerimento:

http://www.scattigolosi.com/2015/02/come-condividere-foto-da-flickr-su-wordpress-e-blogspot.html/


-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [Talk-it] mappe Umap con immagini Flickr

[liste DOT girarsi AT posteo DOT eu]

Il 04/02/19 22:45, liste DOT girarsi AT posteo DOT eu ha scritto:
> Ho provato adesso su un'immagine a caso, praticamente devi fare su ogni
> foto, click destro, "visualizza informazioni pagina", e dal listato,
> copiare il link della voce og:image, oppure ho trovato questo, ha
> qualche passaggio in più, anche se parla per foto protette, penso
> articolo vecchio, comunque dovrebbe essere valido anche questo:
> 
> https://pejone.wordpress.com/2011/12/14/come-scaricare-le-foto-protette-da-flickr/
> 
> 

Dimenticavo, uso firefox come browser.

-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [talk-cz] Penzion vs Pension

[Martin Janda]

Souhlas,
  pokud vznesete dotaz na Ustav Pro JazIk Cesky tak se dockate odpovedi ze 
zalezi na kontextu.  Takze se s tim musi vyporadat vyhledavani. Stejne jako 
razeni C+H a CH.

M

4. 2. 2019 v 20:02, Jan Martinec :

> Ahoj,
> 
> Řešil bych to podle stavu v terénu. Někdo má penzión Sluníčko, někdo Pension 
> Sluníčko - to první medle není součást názvu, a pak nemá být v name, to druhý 
> pak budiž v name tak, jak je v názvu. 
> 
> Zdar,
> Honza Piškvor Martinec 
> 
> Dne po 4. 2. 2019 19:59 uživatel Marek  napsal:
>> Jak správně označit název penzionu? Dát do názvu třeba "Penzion Sluníčko" 
>> nebo jen "Sluníčko" když je už stejně zařazen v tagu Penzion. Problém totiž 
>> je v tom, že někde je napsán penzion se "s" a někde se "z" a pak hledání v 
>> navigaci  najde rozdílné výsledky.
>> Marek Polák
>> 
>> 
>> 
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-it] mappe Umap con immagini Flickr

[liste DOT girarsi AT posteo DOT eu]

Il 04/02/19 21:39, Dario Zontini Gmail ha scritto:
> Vorrei realizzare una mappa con Umap e aggiungere alcune foto.
> 
> La cosa non è difficile in quanto basta inserire il codice
> {{http://image.url.com}} ma non mi funziona con immagini caricate in
> www.flickr.com
> 
> Qualcuno ha qualche soluzione?
> 
> Ciao
> 

Ho provato adesso su un'immagine a caso, praticamente devi fare su ogni
foto, click destro, "visualizza informazioni pagina", e dal listato,
copiare il link della voce og:image, oppure ho trovato questo, ha
qualche passaggio in più, anche se parla per foto protette, penso
articolo vecchio, comunque dovrebbe essere valido anche questo:

https://pejone.wordpress.com/2011/12/14/come-scaricare-le-foto-protette-da-flickr/


-- 
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

Re: [Talk-ca] Building Import update

[Begin Daniel]

La discussion en cours va dans la bonne direction, il est nécessaire de 
prétraiter correctement les données avant de les mettre à la disposition du 
gestionnaire de tâches OSM. Nous devons (simplement !-) nous entendre sur ce 
qui doit être fait.
La partie qui m’inquiète est la seconde étape du processus d’importation.
Premièrement, la discussion actuelle semble parfois supposer que les données à 
importer sont plus actuelles/meilleures que la couche OSM. Dans une version 
précédente du wiki (processus d’importation), il était même suggéré de 
supprimer les grappes d’anciens bâtiments (building=yes) et de les remplacer 
par les nouvelles données pour accélérer le processus, sans vérifier si les 
données sont valides?
Ce qui m’amène à ma deuxième préoccupation. Je trouve irrespectueux de 
supprimer le travail des contributeurs précédents simplement pour importer plus 
rapidement de nouvelles données. Procéder de cette façon risque de décourager 
tous ceux qui verront leurs contributions ‘imparfaites’ détruites et remplacées 
par cet import. OSM est aussi une communauté.

Daniel

PS. Google translate makes a good translation of this text.

From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: Sunday, February 03, 2019 19:05
To: Pierre Béland
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Building Import update

I'm not hearing we have a clear consensus on modifying the shape of buildings 
with scripts and the Q button.

My own personal view is it could introduce errors and unless it is very 
obviously wrong when it should get picked up by the importing mapper it should 
be left as is.

Cheerio John

On Sun, 3 Feb 2019 at 18:26, john whelan 
mailto:jwhelan0...@gmail.com>> wrote:
I'm hearing we keep the single import project as such.

I'm hearing that we should preprocess the data first splitting out outlines 
that meet Pierre's right angle checks.  This data can just be imported using 
the current processes.

I'm hearing we should then run the correcting scripts and extract the corrected 
buildings.  This becomes the second stage.  This data should be imported 
separately to the first since it needs to be more closely inspected in case the 
script has caused some deformation.

At the moment I'm not sure if the two scripts above exist.

I'm hearing what is left becomes the third stage which needs to be sorted out 
manually before being made available for import.  Again I see this as a 
separate task since the outlines will have been modified from the original.

Note to James is the above practical?  Do we have the resources to do it?  
Please do not do anything until we have an agreement to proceed.

I'm hearing the existing imported building outlines will be subject to an 
overpass to pick out those building outlines that are not square.

Then the "a miracle occurs" box on the project plan gets these into a JOSM todo 
list and mappers manually sort them out.  I'm not certain how this will happen. 
 I suspect if the overpass query is small enough and the buildings are loaded 
up from an off line source this might work.

To come back to Toronto my feeling is this is best left to the local mappers in 
Toronto to decide how to proceed.  There is/was room for a local coordinator in 
the project plan.  Nate's expectations are different to mine and I think it 
makes sense for the local mappers to decide what they would like to do together 
with Nate and a Toronto mapper set themselves up to coordinate in Toronto.  The 
speed at which the buildings were added has been raised as a concern.  I'm 
unable to think of a way to address this other than a "please take it slowly" 
added to the instructions.

Again this option is available to any other areas who would like to use this 
method.

I feel for Quebec the best thing to do is hold back until we have an agreement 
for the rest of the country since there are Quebec mappers who are not 
following this thread on talk-ca and to be honest we do seem to be evolving on 
a hourly basis so waiting until the dust settles might well be sensible.

Am I missing something apart from my sanity?

Thanks John

On Sun, 3 Feb 2019 at 17:07, Pierre Béland 
mailto:pierz...@yahoo.fr>> wrote:
Je suggère oui, d'abord le script avec 2 fichiers d'output parce qu'ensuite il 
sera beaucoup plus simple d'importer les données déja corrigées. Sinon une 
variable pour distinguer les deux et risque de l'importer dans OSM ? Et je 
pense à un autre aspect. Le script pourrait s'assurer qu'il n'y a pas de 
superpositions entre bâtiments une fois les données corrigées.

L'importation des données orthogonales devrait être grandement facilitée. Selon 
l'exemple d'Ottawa, quelque 75% des bâtiments répondent à ce critère une fois 
les polygones qasi-orthogonaux corrigés. Pour ces données, il s'agirait 
davantage de valider avec l'imagerie et de faire la conflation avec les données 
existantes.

Pour l'importation des données irrégulières, il faudrait oui valider / 
corriger. A ne pas oublier que dans ce 

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Romain MEHUT]

Re,

Le lun. 4 févr. 2019 à 22:06,  a écrit :

> Non, une piste c'est si c'est une chaussée séparée, là c'est sur la même
> chaussée.
>
Euh pourtant sur le wiki la photo
https://wiki.openstreetmap.org/wiki/File:Copenhagen_Style_Bike_Lane.jpg
illustrant une piste ne correspond pas à ce que tu décris.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[osm . sanspourriel]

Non, une piste c'est si c'est une chaussée séparée, là c'est sur la même 
chaussée.


Pourtant c'est plus qu'une bande.

La question est : est-ce que pour les cyclistes ça vaut une piste ou une 
bande ou faut-il une autre valeur ?


Est-ce que ce cas ne devrait pas être sur le wiki ?

Ceci dit ce n'est pas parce que Manu est barcelonais que Barcelone est 
en France ;-), laissons les Espagnols et les Catalans gérer ça si on n'a 
pas le cas ici.


Le 04/02/2019 à 21:57, Romain MEHUT - romain.me...@gmail.com a écrit :
Concernant l'exemple barcelonais en photo, je ne vois pas la 
difficulté, il y a des séparateurs (certes modestes) donc c'est un 
piste cyclable.


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

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Romain MEHUT]

Bonsoir,

Je reprends le sujet depuis le début car parcouru un peu vite.

Shoreh dans son message initial donne en exemple
https://www.openstreetmap.org/way/24692380/history avec des tags qui ne
correspondent pas aux différents de cas de figure décrits sur le wiki. Un
tour sur Streetview (désolé je n'ai pas trouvé mieux) montre qu'il s'agit
du cas S1 (un double-sens cyclable sans voie dédiée) pour lequel il y a 2
façon de le représenter. Il me semble que Shoreh a voulu choisir la 2ème
mais au lieu d'avoir utilisé cycleway=opposite, il a utilisé
cycleway:left=opposite. Ce qui est donc incorrect. La version précédente
modifiée par Cartocité était correcte. Et en choisissant la 2ème façon, il
n'est pas question d'utiliser en plus le tag oneway:bicycle=no.

Concernant l'exemple barcelonais en photo, je ne vois pas la difficulté, il
y a des séparateurs (certes modestes) donc c'est un piste cyclable.

Romain

Le lun. 4 févr. 2019 à 15:46, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :


> Je verrais bien un opposite_pictogram, et comment décrire les
> pistes/bandes cyclables barcelonaise ?
>
> https://i2.wp.com/www.zicla.com/wp-content/uploads/2018/02/carrill-bici-calle-paris.png
> Ce ne sont ni des pistes ni des bandes, il faudrait donc rajouter un
> nouvel attribut, et donc demander aux render et router de prendre en compte
> ce nouvel attribut ?
> La galère.
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-it] mappe Umap con immagini Flickr

[Dario Zontini Gmail]

Vorrei realizzare una mappa con Umap e aggiungere alcune foto.

La cosa non è difficile in quanto basta inserire il codice 
{{http://image.url.com}} ma non mi funziona con immagini caricate in 
www.flickr.com


Qualcuno ha qualche soluzione?

Ciao

--


Dario Zontini


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


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

Re: [Talk-it] Catalogazione sentieri CAI Emilia-Romagna

[mircozorzo via Talk-it]

Ciao, grazie molte dell'informazione, sono interessato a fare parte della
squadra.

Ciao, Mirco



--
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: [Talk-es] Toponimia en Cataluña

[Rafael Avila Coya]

Hola, Iñaki:

2 aclaraciones.

1. Lo que se escribe en la wiki OSM no lo decide un australiano. Es escrita por 
toda la comunidad global, con discusiones en diferentes listas globales como 
tagging, osm-talk y otras. Nos debemos principalmente a lo que decidimos entre 
todos, lo cual no quiere decir que las comunidades locales no podamos adaptar 
al contexto local. Pero no tiene sentido tomar decisiones que contradigan lo 
que decidimos globalmente. Estoy de acuerdo en que las otras organizaciones que 
mencionas son referentes, pero nada más.

2. En el naming de OSM podemos añadir muchas traducciones (name:xx), nombres 
alternativos (alt_name, alt_name:xx), nombres abreviados (short_name) y muchos 
otros. El nominatim usa la mayoría de ellos en su motor de búsqueda (buscaría 
indistintamente el name="Arantzazu" como el name:es="Aranzazu" o cualquier 
otro), así que no hay porqué preocuparse de un "andaluz" que busca "El puente 
de las brujas" y no "Unanibiako zubia", siempre que hayamos añadido la etiqueta 
correspondiente.

Un saludo,

Rafael. 

El 4 de febrero de 2019 19:01:36 CET, "Iñaki"  
escribió:
>Buenas tardes:
>
>En torno a este interesante debate sobre los topónimos, y dado que el 
>forero gallego Antón Vega parece haberse enfadado con mis aportaciones,
>
>quisiera explayarme más, pues, como he indicado en el Foro, aquel no es
>
>el ámbito adecuado para dirimir cuestiones que adquieren tal calado 
>para, o entre, los participantes.
>
>Como en otras ocasiones, diré que la verdad no la tiene nadie, la
>verdad 
>no está en un lado,  y lo siento por el que crea que su verdad es la 
>única y la auténtica. Cada uno, a nuestra manera, aportamos granos de 
>verdad, a esa verdad mayor. Y si esa verdad es la búsqueda del 
>equilibrio que se da en todos los aspectos de la vida, flaco favor 
>haremos si nos encasillamos en posturas numantinas. Aunque yerre, desde
>
>luego que servidor no busca eso.
>
>También es verdad que la edad me ha privado de cierto filtros sin los 
>cuales disfruto más; aunque veo que, sin pretenderlo, sazono demasiado 
>mis aportes, pues parece que tienen la extraña virtud de generar 
>polémica cuando no lo pretendo.
>
>Así pues, en lo que respecta al forero Antón, públicamente asumo la 
>parte de responsabilidad que me corresponde por lo que ha podido ser un
>
>planteamiento inadecuado por mi parte. Pero tampoco dejaré de invitarle
>
>a que haga una lectura más allá de la literal, pues cuando le he citado
>
>al difunto académico Lázaro Carreter, lo hacia con el convencimiento de
>
>que leer a alguien con quien, creo, no comulgará, le daría más 
>ingredientes para hacerse una más exacta composición de lugar, para 
>acercarse al equilibrio antes mentado.
>
>Pero como he dicho que me faltan algunos filtros, antes de hablar de
>dos 
>ejemplos de topónimos, me recrearé en algunos aspectos para cuya
>defensa 
>me encontraré yo solo. A saber. Ni las diferentes academias, ni la 
>Wikipedia, ni la propia OSM mundial, ni sursuncorda son la Biblia (o no
>
>deberían ser) para OSM España. O no deberían serlo frente al SENTIDO 
>COMÚN. En la Wiki, en general, hay tendenciosidad (que va en aumento). 
>Las academias son un referente importante, pero están tan contaminadas 
>por la política que son UN REFERENTE MÁS, importante, pero ni de lejos,
>
>dogma de fe. Por supuesto que no me gusta, que alguien de OSM mundial
>me 
>dicte cómo tengo que mapear (ahora acúseseme de nacionalista español), 
>pero el debate aquel famoso sobre bar-pub sacó a flote ese trasfondo. 
>Ante lo que me diga quien resida, por ejemplo en Australia, y lo que me
>
>diga el sentido común, no tendré ninguna duda (aunque vaya en contra
>del 
>mismísimo espíritu santo de OSM). Tampoco estoy de acuerdo con foreros 
>como Daniel cuando afirman que hay que dejar la política fuera. Sí,
>pero 
>es que todo es política; o, mejor dicho, en la toponimia podemos 
>encontrar, fácilmente, reflejo de la política. Y por ahí van mis dos 
>ejemplos. Modelos que el lector podrá encontrarlos en el mapa de OSM.
>
>El primero el santuario de Aranzazu en Guipúzcoa. Su nombre en eusquera
>
>es “Arantzazu” (traducción casi literal: Ud. sobre la zarza). Pues
>bien, 
>ni el Generalísimo de los ejércitos con su cohorte de censores fue
>capaz 
>de traducir al español el término, porque, como afirmaba esta mañana,
>el 
>forero Antón, hay cosas que son intraducibles. A lo sumo logró en el 
>aspecto fonético “transformar” sonidos eusquéricos (tz) que en 
>castellano no existen. Y ahora pregunto: ¿cuál sería el nombre oficial 
>adecuado para OSM? ¿Voy a tratar de borrar el rastro del franquismo 
>(acúseseme ahora de nacionalista vasco)?... Sinceramente, busco ese 
>equilibrio y si estoy pensando en una máquina gps que busca el destino 
>para un andaluz, pues no tendré inconveniente en usar los dos. ¿A cuál 
>le doy prioridad? Me remito al sentido común. Si mi propósito es 
>reivindicar la vasquidad del término, ya escribiré un artículo al 
>respecto, pero OSM 

[OSM-talk] Renaming Macedonia

[Steve Doerr]

Is there a plan?


--

Steve


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [talk-cz] Penzion vs Pension

[Jan Martinec]

Ahoj,

Řešil bych to podle stavu v terénu. Někdo má penzión Sluníčko, někdo
Pension Sluníčko - to první medle není součást názvu, a pak nemá být v
name, to druhý pak budiž v name tak, jak je v názvu.

Zdar,
Honza Piškvor Martinec

Dne po 4. 2. 2019 19:59 uživatel Marek  napsal:

> Jak správně označit název penzionu? Dát do názvu třeba "Penzion Sluníčko"
> nebo jen "Sluníčko" když je už stejně zařazen v tagu Penzion. Problém
> totiž
> je v tom, že někde je napsán penzion se "s" a někde se "z" a pak hledání v
> navigaci  najde rozdílné výsledky.
> Marek Polák
>
>
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[talk-cz] Penzion vs Pension

[Marek]

Jak správně označit název penzionu? Dát do názvu třeba "Penzion Sluníčko" 
nebo jen "Sluníčko" když je už stejně zařazen v tagu Penzion. Problém totiž 
je v tom, že někde je napsán penzion se "s" a někde se "z" a pak hledání v 
navigaci  najde rozdílné výsledky.

Marek Polák



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

[Talk-at] Fußwege in Mürzzuschlag

[Horst Willingshofer]

In Mürzzuschlag gibt es im Zentrum viele Fußwege (highway:footway) auf OSM

Z.B.: https://www.openstreetmap.org/way/543134742#map=18/

Das sind fast alles ganz normale Gehsteige wie es sie in jedem Ort gibt.
Kann mir jemand sagen was es damit auf sich hat?

Horst

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

Re: [Talk-es] Toponimia en Cataluña

[Iñaki]

Buenas tardes:

En torno a este interesante debate sobre los topónimos, y dado que el 
forero gallego Antón Vega parece haberse enfadado con mis aportaciones, 
quisiera explayarme más, pues, como he indicado en el Foro, aquel no es 
el ámbito adecuado para dirimir cuestiones que adquieren tal calado 
para, o entre, los participantes.


Como en otras ocasiones, diré que la verdad no la tiene nadie, la verdad 
no está en un lado,  y lo siento por el que crea que su verdad es la 
única y la auténtica. Cada uno, a nuestra manera, aportamos granos de 
verdad, a esa verdad mayor. Y si esa verdad es la búsqueda del 
equilibrio que se da en todos los aspectos de la vida, flaco favor 
haremos si nos encasillamos en posturas numantinas. Aunque yerre, desde 
luego que servidor no busca eso.


También es verdad que la edad me ha privado de cierto filtros sin los 
cuales disfruto más; aunque veo que, sin pretenderlo, sazono demasiado 
mis aportes, pues parece que tienen la extraña virtud de generar 
polémica cuando no lo pretendo.


Así pues, en lo que respecta al forero Antón, públicamente asumo la 
parte de responsabilidad que me corresponde por lo que ha podido ser un 
planteamiento inadecuado por mi parte. Pero tampoco dejaré de invitarle 
a que haga una lectura más allá de la literal, pues cuando le he citado 
al difunto académico Lázaro Carreter, lo hacia con el convencimiento de 
que leer a alguien con quien, creo, no comulgará, le daría más 
ingredientes para hacerse una más exacta composición de lugar, para 
acercarse al equilibrio antes mentado.


Pero como he dicho que me faltan algunos filtros, antes de hablar de dos 
ejemplos de topónimos, me recrearé en algunos aspectos para cuya defensa 
me encontraré yo solo. A saber. Ni las diferentes academias, ni la 
Wikipedia, ni la propia OSM mundial, ni sursuncorda son la Biblia (o no 
deberían ser) para OSM España. O no deberían serlo frente al SENTIDO 
COMÚN. En la Wiki, en general, hay tendenciosidad (que va en aumento). 
Las academias son un referente importante, pero están tan contaminadas 
por la política que son UN REFERENTE MÁS, importante, pero ni de lejos, 
dogma de fe. Por supuesto que no me gusta, que alguien de OSM mundial me 
dicte cómo tengo que mapear (ahora acúseseme de nacionalista español), 
pero el debate aquel famoso sobre bar-pub sacó a flote ese trasfondo. 
Ante lo que me diga quien resida, por ejemplo en Australia, y lo que me 
diga el sentido común, no tendré ninguna duda (aunque vaya en contra del 
mismísimo espíritu santo de OSM). Tampoco estoy de acuerdo con foreros 
como Daniel cuando afirman que hay que dejar la política fuera. Sí, pero 
es que todo es política; o, mejor dicho, en la toponimia podemos 
encontrar, fácilmente, reflejo de la política. Y por ahí van mis dos 
ejemplos. Modelos que el lector podrá encontrarlos en el mapa de OSM.


El primero el santuario de Aranzazu en Guipúzcoa. Su nombre en eusquera 
es “Arantzazu” (traducción casi literal: Ud. sobre la zarza). Pues bien, 
ni el Generalísimo de los ejércitos con su cohorte de censores fue capaz 
de traducir al español el término, porque, como afirmaba esta mañana, el 
forero Antón, hay cosas que son intraducibles. A lo sumo logró en el 
aspecto fonético “transformar” sonidos eusquéricos (tz) que en 
castellano no existen. Y ahora pregunto: ¿cuál sería el nombre oficial 
adecuado para OSM? ¿Voy a tratar de borrar el rastro del franquismo 
(acúseseme ahora de nacionalista vasco)?... Sinceramente, busco ese 
equilibrio y si estoy pensando en una máquina gps que busca el destino 
para un andaluz, pues no tendré inconveniente en usar los dos. ¿A cuál 
le doy prioridad? Me remito al sentido común. Si mi propósito es 
reivindicar la vasquidad del término, ya escribiré un artículo al 
respecto, pero OSM es otra cosa aunque supongo que incluso yo me dejo 
llevar en ocasiones.


Otro topónimo que puede Ud., amable lector, encontrar en OSM: Unanibiako 
zubia (traducción: el puente de Unanibia). Es un topónimo rural, alejado 
del medio urbano. Así, en eusquera, lo encontrará, pero resulta que en 
el uso popular también se conoce como “el puente de las brujas” en puro 
español. ¿Cómo surgió? No se sabe, ni lo logro descifrar la autora de un 
estudio toponímico. Sí que procede del medio urbano y de la época en que 
la localidad fue protagonista de una fuerte inmigración extremeña y 
castellana en los primeros albores de la segunda mitad del siglo XX. 
Ahora me vuelvo a vestir de nacionalista vasco y reivindico la vasquidad 
frente al nombre surgido en un medio español… Pues qué quieren que les 
diga… Estoy pensando en ese andaluz que con gps busca el lugar con el 
nombre en español. Ahora vuelvo a estar de acuerdo con Daniel en que OSM 
no es un estudio toponímico y que aunque pueda destilar un origen 
“extraño”, yo hubiera colocado los dos nombres, dando prioridad al 
eusquérico, de acuerdo, pero reconociendo que el nombre en español está 
más o menos asentado en la localidad. Otro 

Re: [OSM-talk-fr] [import] Mise à jour population et codes postaux

[marc marc]

Bonjour,

Le 04.02.19 à 17:50, Sébastien Mariaux a écrit :
> Ceci est ma première contribution à ce groupe !

Bienvenue !

> Je prépare actuellement un import pour mettre à jour les données de 
> population sur OSM, ainsi que les codes postaux.
> Tous les commentaires et conseils sont les bienvenus !

sur la forme :
- un import doit se faire en collaboration avec la communauté,
pas uniquement parce qu'une entreprise en a besoin.
cela aurait dans l'idéal sans doute mieux de regarder que le sujet
avait été discuté récemment (pour les codes postaux) et d'en discuter
AVANT d'annoncer un import solo (qui nécessite accord local & mondial).
- si tu penses que tout est prêt pour l'import [2],
il reste à faire la page wiki qui documente celle-ci parce
que quelques fichiers de code ne sont pas une doc.
je pense que c'est pas le cas et que tu met la charrue avant les bœufs.

sur la fond :
- je ne suis pas sur que cela soie une bonne idée de faire un import 
comme première contribution. c'est probablement mieux de se familiariser 
un minimum avec une contribution "classique" : faire un groupe de modif 
(changeset), y mettre un bon commentaire de groupe de modif, un tag 
source, etc sur un objet sans aucun rapport avec l'import, histoire 
d'avoir un mini bagage avant d'aborder (affronter ?) le monde de 
l'import qui est parfois (surtout au niveau mondial) très... 
bureaucratique ? démotivant ? pointilleux ? c'est selon le point de vue.

- vouloir faire les 2 (population et codes postaux) en une fois
est une mauvaise idée,
c'est 2 choses totalement différentes, avec des difficultés très 
différentes. c'est mieux de faire 2 imports, cela augmente les chances
de succès, rend le tout plus lisible et paradoxalement te ferra gagner
du temps.

- pour la maj de la population, je n'ai aucune objection,
au contraire j'avais évoqué l'idée il y plus d'un an et je suis
content que quelqu'un y contribue.
reste à documenter comment tu vas identifier l'objet osm à mettre à 
jour, surtout vu le décalage entre 2016 et ajd (fusion de communes)

- d'ailleurs sur quoi porte les stats de population de l'insee ?
sur la ml import [1] tu parles de ville et population,
je pensais que c'était dispo pour les communes et non les villes

- pour les codes postaux, je t'invite à chercher/lire le thread précédent.
sans aucune doc sur comment tu penses compléter ce qu'il manque,
c'est impossible de donner un avis (cas des communes multi-cp,
cas des cp multi-commune deja renseigné comme zone postale,
cas des communes multi-cp avec des cp multi-communes)

sur la technique :
- est ce que les api en question acceptent que tu les utilisent autant ?
souvent la "lecture" se fait à partir de fichier "plat" au lieu d'api

[1] 
https://lists.openstreetmap.org/pipermail/imports/2019-February/005907.html
[2] https://wiki.openstreetmap.org/wiki/FR:Import

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

Re: [Talk-ca] Some feedback on import quality in Toronto

[Pierre Béland via Talk-ca]

J'ai constaté la même chose a tester CATools. Décevant.

Et merci à Dany, cette fonctionnalité est intéressante.La requête Overpass 
ci-dessous extrait de grands immeubles à Ottawa, certains avec des formes 
rectangulaires, d'autres avec des formes plus complexes, moitié rectangulaire, 
plus divers angles.http://overpass-turbo.eu/s/FNY

Ce qui manque pour corriger de telles géométrie, c'est un outil qui permettrait 
de redresser partiellement, de mettre en parallèle certains cotes, ou redresser 
un angle à 90 degrés, voire 60, 45 a un certain point.  

Pour les demi-cercles, on sélectionne  3 points et outil / Arc de cercle.
 
Pierre 
 

Le lundi 4 février 2019 10 h 50 min 02 s HNE, Yaro Shkvorets 
 a écrit :  
 
 Thanks, it works. Need to run it a few times it looks like. On a random 
Markham block went from 88 warnings down to 4 without ruining geometries, which 
is acceptable IMO. May need to look into its parameters 
(validator.RightAngleBuilding.maximumDelta and 
validator.RightAngleBuilding.minimumDelta) to tweak it for our data.
I've looked into CADTools and BuildingGeneralization plugins but unfortunately 
they don't work properly destroying geometries and rotating polygons.
-- 
Best Regards,
          Yaro Shkvorets  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[OSM-talk-fr] Mise à jour population et codes postaux

[Sébastien Mariaux]

Bonjour à tous,


Ceci est ma première contribution à ce groupe ! Je travaille chez 
High-Testing R à Marseille, et nous  utilisons OSM pour un projet interne.


Je prépare actuellement un import pour mettre à jour les données de 
population sur OSM, ainsi que les codes postaux.


En effet, la population est renseignée à partir des données de l'INSEE 
de 2013, j'aimerais les mettre à jour avec les données les plus récentes 
(2016).


Il apparait aussi que certains codes postaux sont manquants, l'import 
pourrait les compléter à partir des données de La Poste.


J'ai déjà préparé les scripts de collecte des données, ils sont 
disponibles en OpenSource sur notre dépot : 
https://bitbucket.org/high-testing/osm-data-import/src/master/ . Toutes 
les données à importer sont bien sous licence ODbL ou compatible.


Un sujet est également ouvert sur la liste de diffusion "import".

Tous les commentaires et conseils sont les bienvenus !

Merci et bonne fin de journée.


Sébastien - Novazeo / high-Testing R


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

Re: [Talk-ca] New MapRoulette challenge to address highway class flip-flops

[Martijn van Exel]

Harald — you can go into your User profile and change the Default Editor 
setting to ‘Edit just features in JOSM’. This will load just the ‘abnormal’ 
highway. You can then load more data around if if needed. If you don’t want to 
change the setting globally you can use keyboard shortcut ‘y’ to trigger this 
type of loading in JOSM on a task by task basis.

Hope this helps, 
Martijn

> On Feb 4, 2019, at 9:44 AM, Harald Kliems  wrote:
> 
> Hi Martijn:
> I just tried the challenge, and all of the first four tasks that came up 
> produce an "area too big" error in JOSM (long highways in very rural areas). 
> Is there any way to fix this? Or maybe warn people to not use JOSM for this 
> challenge?
>  Harald.
> 
> On Mon, Feb 4, 2019 at 10:37 AM Martijn van Exel  > wrote:
> Hi all, 
> 
> Per Matthew Darwin’s request on Twitter, my team prepared a MapRoulette 
> challenge for ‘highway class flip-flops’. What does this mean? Consecutive 
> ways that have a suspicious change from one highway= value to another and 
> then back to the former. This happens sometimes when mappers change the 
> highway= value for some way but miss a bridge somewhere. An example is 
> https://www.openstreetmap.org/way/53514358#map=19/51.23309/-116.65373 
>  where 
> the bridge is marked as residential but the two adjoining ways are marked as 
> unclassified.
> 
> You can find the challenge at https://maproulette.org/mr3/challenge/3588 
>  and your feedback is very 
> welcome.There are ~300 tasks.
> 
> If you have other ideas for challenges to clean up / review existing data let 
> me know and we can discuss.
> 
> Martijn
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-ca 
> 
> 
> 
> -- 
> Please use encrypted communication whenever possible!
> Key-ID: 0x34cb93972f186565

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

Re: [Talk-ca] New MapRoulette challenge to address highway class flip-flops

[Harald Kliems]

Hi Martijn:
I just tried the challenge, and all of the first four tasks that came up
produce an "area too big" error in JOSM (long highways in very rural
areas). Is there any way to fix this? Or maybe warn people to not use JOSM
for this challenge?
 Harald.

On Mon, Feb 4, 2019 at 10:37 AM Martijn van Exel  wrote:

> Hi all,
>
> Per Matthew Darwin’s request on Twitter, my team prepared a MapRoulette
> challenge for ‘highway class flip-flops’. What does this mean? Consecutive
> ways that have a suspicious change from one highway= value to another and
> then back to the former. This happens sometimes when mappers change the
> highway= value for some way but miss a bridge somewhere. An example is
> https://www.openstreetmap.org/way/53514358#map=19/51.23309/-116.65373 where
> the bridge is marked as residential but the two adjoining ways are marked
> as unclassified.
>
> You can find the challenge at https://maproulette.org/mr3/challenge/3588 and
> your feedback is very welcome.There are ~300 tasks.
>
> If you have other ideas for challenges to clean up / review existing data
> let me know and we can discuss.
>
> Martijn
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>


-- 
Please use encrypted communication whenever possible!
Key-ID: 0x34cb93972f186565
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] New MapRoulette challenge to address highway class flip-flops

[Martijn van Exel]

Just as an addendum, you may find false positives like this one 
https://maproulette.org/mr3/challenge/3588/task/11055949 
 where a service road 
connects to residential roads in a perfectly valid way. You should mark these 
as ’not an issue’ in MapRoulette.

Martijn

> On Feb 4, 2019, at 9:36 AM, Martijn van Exel  wrote:
> 
> Hi all, 
> 
> Per Matthew Darwin’s request on Twitter, my team prepared a MapRoulette 
> challenge for ‘highway class flip-flops’. What does this mean? Consecutive 
> ways that have a suspicious change from one highway= value to another and 
> then back to the former. This happens sometimes when mappers change the 
> highway= value for some way but miss a bridge somewhere. An example is 
> https://www.openstreetmap.org/way/53514358#map=19/51.23309/-116.65373 
>  where 
> the bridge is marked as residential but the two adjoining ways are marked as 
> unclassified.
> 
> You can find the challenge at https://maproulette.org/mr3/challenge/3588 
>  and your feedback is very 
> welcome.There are ~300 tasks.
> 
> If you have other ideas for challenges to clean up / review existing data let 
> me know and we can discuss.
> 
> Martijn
> ___
> 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

[Talk-ca] New MapRoulette challenge to address highway class flip-flops

[Martijn van Exel]

Hi all, 

Per Matthew Darwin’s request on Twitter, my team prepared a MapRoulette 
challenge for ‘highway class flip-flops’. What does this mean? Consecutive ways 
that have a suspicious change from one highway= value to another and then back 
to the former. This happens sometimes when mappers change the highway= value 
for some way but miss a bridge somewhere. An example is 
https://www.openstreetmap.org/way/53514358#map=19/51.23309/-116.65373 
 where 
the bridge is marked as residential but the two adjoining ways are marked as 
unclassified.

You can find the challenge at https://maproulette.org/mr3/challenge/3588 
 and your feedback is very 
welcome.There are ~300 tasks.

If you have other ideas for challenges to clean up / review existing data let 
me know and we can discuss.

Martijn___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Some feedback on import quality in Toronto

[Yaro Shkvorets]

Thanks, it works. Need to run it a few times it looks like. On a random
Markham block went from 88 warnings down to 4 without ruining geometries,
which is acceptable IMO. May need to look into its parameters
(validator.RightAngleBuilding.maximumDelta
and validator.RightAngleBuilding.minimumDelta) to tweak it for our data.

I've looked into CADTools and BuildingGeneralization plugins but
unfortunately they don't work properly destroying geometries and rotating
polygons.

On Mon, Feb 4, 2019 at 10:31 AM Danny McDonald  wrote:

> In JOSM, open the preferences dialog (F12), go to the data validator tab,
> and click the "show informational level" checkbox (it is third from the
> top).  Any validation done will then check for "Building with an almost
> square angle", which will appear under the Other tab.  "Building with an
> almost square angle" used to cause a Warning, but it was downgraded to
> Other due to complaints - see https://josm.openstreetmap.de/ticket/16280.
> Danny
>
> On Mon, Feb 4, 2019 at 9:45 AM Yaro Shkvorets  wrote:
>
>> Danny,
>> Do you mind sharing how to fix almost square angles in JOSM? I remember
>> seeing such warning a year or two ago but for some reason I don't see it
>> anymore and can't find it in the Validator settings.
>> Did they remove it from the latest version of JOSM or you need to add
>> this rule manually?
>> If there is an easy way to do it then we should do it I guess.
>>
>> On Sun, Feb 3, 2019 at 7:51 PM Danny McDonald 
>> wrote:
>>
>>> I largely agree with Yaro, but will say
>>> 1) It is possible to square almost square angles with JOSM - it has an
>>> informational warning in validation, and automatically squares the angle by
>>> slightly moving the offending node.  This fix doesn't ruin the geometry of
>>> the building, as pressing Q so often does.  Unfortunately, it also leads to
>>> other angles in the building not being square.
>>> 3) I'm fine with importing smaller buildings as well (they don't seem to
>>> be in the source data in Toronto, they are for some of the other data
>>> sets).  I believe they were excluded because of their relatively low
>>> importance/permanence.
>>>
>>> I would also like to know how the Toronto building footprints were
>>> produced.  Does anyone know?
>>> DannyMcD
>>>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>
>>
>> --
>> Best Regards,
>>   Yaro Shkvorets
>>
>

-- 
Best Regards,
  Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-it] One feature, one element - scuole

[Martin Koppenhoefer]

Am Mo., 4. Feb. 2019 um 15:59 Uhr schrieb Cascafico Giovanni <
cascaf...@gmail.com>:

> Quindi faccio una relazione multipoligono amenity=school con dentro i
> poligoni building=school, building=sports_hall come inner e poi
> entrance=main, entrance=service ecc. come cosa?
> Poi i tag specifici (ref, phone, ecc) li assegno a quale amenity?
>
>

se parliamo di 2 scuole che insieme risiedono nello stesso spazio fisico,
farei così:

1. Contorno della scuola fatto di way(s), spesso questo sono recinzioni
come fence, wall, ecc.
2. Poi 2 multipoligoni con il contorno del punto 1 come outer. Ciascuna
relazione ottiene i tags
amenity=school
name
ref
phone
...


questo per le scuole.
Dentro le scuole ci saranno i building=* ecc., e questi potranno avere i
loro entrance, ecc., ma non devi inserire niente di ciò nella relazione per
le scuole.
Soltanto quando un edificio, giardino, ecc. non fa parte di una delle
scuole dovresti escluderlo con ruolo "inner", altrimenti non compare.

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

Re: [Talk-ca] Some feedback on import quality in Toronto

[Danny McDonald]

In JOSM, open the preferences dialog (F12), go to the data validator tab,
and click the "show informational level" checkbox (it is third from the
top).  Any validation done will then check for "Building with an almost
square angle", which will appear under the Other tab.  "Building with an
almost square angle" used to cause a Warning, but it was downgraded to
Other due to complaints - see https://josm.openstreetmap.de/ticket/16280.
Danny

On Mon, Feb 4, 2019 at 9:45 AM Yaro Shkvorets  wrote:

> Danny,
> Do you mind sharing how to fix almost square angles in JOSM? I remember
> seeing such warning a year or two ago but for some reason I don't see it
> anymore and can't find it in the Validator settings.
> Did they remove it from the latest version of JOSM or you need to add this
> rule manually?
> If there is an easy way to do it then we should do it I guess.
>
> On Sun, Feb 3, 2019 at 7:51 PM Danny McDonald  wrote:
>
>> I largely agree with Yaro, but will say
>> 1) It is possible to square almost square angles with JOSM - it has an
>> informational warning in validation, and automatically squares the angle by
>> slightly moving the offending node.  This fix doesn't ruin the geometry of
>> the building, as pressing Q so often does.  Unfortunately, it also leads to
>> other angles in the building not being square.
>> 3) I'm fine with importing smaller buildings as well (they don't seem to
>> be in the source data in Toronto, they are for some of the other data
>> sets).  I believe they were excluded because of their relatively low
>> importance/permanence.
>>
>> I would also like to know how the Toronto building footprints were
>> produced.  Does anyone know?
>> DannyMcD
>>
>> ___
>> Talk-ca mailing list
>> Talk-ca@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>
>
> --
> Best Regards,
>   Yaro Shkvorets
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-es] Toponimia en Cataluña

[David Marín Carreño]

Sobre esto, sólo comentar que se debe tener en cuenta, en cuanto al uso o
no uso del topónimo en castellano, el punto de vista de castellanoparlantes
alejados del lugar en cuestión.

Me explico: en los comentarios y páginas de discusión de Wikipedia-ES hay
mucha gente que, por ejemplo, dice que Tarrasa o Sangenjo como topónimos en
castellano de *Terrasa* o *Sanxenxo* no se usan... Esto probablemente sea
cierto en el ámbito local... Pero en lugares alejados y exclusivamente
castellano parlantes ambos exónimos son habituales y normales, al igual que
Gerona, Lérida, Orense y La Coruña.

Un cordial saludo,

--
David Marín Carreño 



El lun., 4 feb. 2019 a las 16:17, Rafael Avila Coya ()
escribió:

> Hola a todos/as:
>
> Antes que nada, añadir que la problemática de naming en Cataluña es
> idéntica a la que hay en Galicia: topónimos en castellano que se usan en
> mayor o menor medida, y otros que nadie usa ya.
>
> Antes que nada, no debemos olvidar que OSM es un proyecto global, y que
> las normas o acuerdos no deben nunca ir en contra de los acuerdos de
> toda la comunidad OSM global, plasmados en su gran mayoría en la wiki de
> OSM.
>
> De esta wiki tenemos las Buenas prácticas [1]. Os recomiendo que leais
> los apartados de "Mapear lo que hay sobre el terreno" y "Verificabilidad".
>
> Creo que hay unanimidad en que los nombres de los topónimos deben ir en
> la lengua oficial, pues es así como aparece en los carteles de
> carreteras y otros.
>
> En cuanto a lo del name:es, yo me inclinaría por la opción 2 de Joan,
> pues basicamente es la que se adapta más al acuerdo global. El problema
> viene cuando hay que discernir los nombres españolizados/castellanizados
> que están en uso (aunque sea minoritario) y los que francamente ya no
> usa nadie o casi nadie.
>
> Se me ocurriría que, por comunidades con esta problemática, se crearan
> grupos de discusión totalmente abiertos, y que de una forma sistemática
> identificasen qué nombres name:es están en desuso y los que no, y se
> aplicase la propuesta de Joan. En caso de duda se optaría por mantener
> el nombre castellano en name:es.
>
> Para concretar un poco más, yo empezaría por los nombres de los
> municipios. Al menos en Galicia es inabarcable toda la toponimia: la
> mitad de las ~60.000 entidades de población de España están en Galicia.
> En cambio, son algo más de 300 municipios, que es asumible.
>
> Un saludo,
>
> Rafael.
>
> [1] https://wiki.openstreetmap.org/wiki/ES:Buenas_pr%C3%A1cticas
>
> O 04/02/19 ás 15:33, Javi Rodriguez via Talk-es escribiu:
> > Buenas tardes,
> >
> >
> > Yo también prefiero la opción 2 que plantea Joan.
> >
> > Desconozco que problema tienen en Wikipedia en Español para usar el
> topónimo oficial, insisten en que todo debe estar en Español, aunque eso
> les obligue a citar fuentes como el diccionario de Madoz (1845) o el INE de
> una determinada época (1857 a 1981). Y se quedan tan anchos.
> >
> > Lo mismo pasa en la Wikipedia en catalán, donde Cataluña es un país
> europeo porque así lo indica una fuente citada. Y también se quedan tan
> anchos.
> >
> > Parece que en la Wikipedia han perdido la cordura, como Don Quijote...
> >
> >
> > Las directrices de mapeado deben responder a criterios razonablemente
> claros y objetivos para poder mapear la realidad de manera util. La
> toponimia oficial y la RAE deben servirnos de apoyo.
> >
> >
> > Saludos.
> >
> > ___
> > Talk-es mailing list
> > Talk-es@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-es
> >
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Toponimia en Cataluña

[Rafael Avila Coya]

Hola a todos/as:

Antes que nada, añadir que la problemática de naming en Cataluña es 
idéntica a la que hay en Galicia: topónimos en castellano que se usan en 
mayor o menor medida, y otros que nadie usa ya.


Antes que nada, no debemos olvidar que OSM es un proyecto global, y que 
las normas o acuerdos no deben nunca ir en contra de los acuerdos de 
toda la comunidad OSM global, plasmados en su gran mayoría en la wiki de 
OSM.


De esta wiki tenemos las Buenas prácticas [1]. Os recomiendo que leais 
los apartados de "Mapear lo que hay sobre el terreno" y "Verificabilidad".


Creo que hay unanimidad en que los nombres de los topónimos deben ir en 
la lengua oficial, pues es así como aparece en los carteles de 
carreteras y otros.


En cuanto a lo del name:es, yo me inclinaría por la opción 2 de Joan, 
pues basicamente es la que se adapta más al acuerdo global. El problema 
viene cuando hay que discernir los nombres españolizados/castellanizados 
que están en uso (aunque sea minoritario) y los que francamente ya no 
usa nadie o casi nadie.


Se me ocurriría que, por comunidades con esta problemática, se crearan 
grupos de discusión totalmente abiertos, y que de una forma sistemática 
identificasen qué nombres name:es están en desuso y los que no, y se 
aplicase la propuesta de Joan. En caso de duda se optaría por mantener 
el nombre castellano en name:es.


Para concretar un poco más, yo empezaría por los nombres de los 
municipios. Al menos en Galicia es inabarcable toda la toponimia: la 
mitad de las ~60.000 entidades de población de España están en Galicia. 
En cambio, son algo más de 300 municipios, que es asumible.


Un saludo,

Rafael.

[1] https://wiki.openstreetmap.org/wiki/ES:Buenas_pr%C3%A1cticas

O 04/02/19 ás 15:33, Javi Rodriguez via Talk-es escribiu:

Buenas tardes,


Yo también prefiero la opción 2 que plantea Joan.

Desconozco que problema tienen en Wikipedia en Español para usar el topónimo 
oficial, insisten en que todo debe estar en Español, aunque eso les obligue a 
citar fuentes como el diccionario de Madoz (1845) o el INE de una determinada 
época (1857 a 1981). Y se quedan tan anchos.

Lo mismo pasa en la Wikipedia en catalán, donde Cataluña es un país europeo 
porque así lo indica una fuente citada. Y también se quedan tan anchos.

Parece que en la Wikipedia han perdido la cordura, como Don Quijote...


Las directrices de mapeado deben responder a criterios razonablemente claros y 
objetivos para poder mapear la realidad de manera util. La toponimia oficial y 
la RAE deben servirnos de apoyo.


Saludos.

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



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

Re: [Talk-ca] Some feedback on import quality in Toronto

[Pierre Béland via Talk-ca]

En faisant une recherche josm + orthogonal, je trouve ce greffon qui semble 
intéressanthttps://wiki.openstreetmap.org/wiki/JOSM/Plugins/CADTools Il 
contient différentes fonctions pour corriger les polygones. Je vois que l'on 
utilise une tolérance 85-95 pour les angles droits. Il est aussi possible de 
modifier les paramètres.


Pierre 
 

Le lundi 4 février 2019 09 h 46 min 17 s HNE, Yaro Shkvorets 
 a écrit :  
 
 Danny,Do you mind sharing how to fix almost square angles in JOSM? I remember 
seeing such warning a year or two ago but for some reason I don't see it 
anymore and can't find it in the Validator settings. Did they remove it from 
the latest version of JOSM or you need to add this rule manually?If there is an 
easy way to do it then we should do it I guess.
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-it] One feature, one element - scuole

[Cascafico Giovanni]

Quindi faccio una relazione multipoligono amenity=school con dentro i
poligoni building=school, building=sports_hall come inner e poi
entrance=main, entrance=service ecc. come cosa?
Poi i tag specifici (ref, phone, ecc) li assegno a quale amenity?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-ca] Some feedback on import quality in Toronto

[Yaro Shkvorets]

Danny,
Do you mind sharing how to fix almost square angles in JOSM? I remember
seeing such warning a year or two ago but for some reason I don't see it
anymore and can't find it in the Validator settings.
Did they remove it from the latest version of JOSM or you need to add this
rule manually?
If there is an easy way to do it then we should do it I guess.

On Sun, Feb 3, 2019 at 7:51 PM Danny McDonald  wrote:

> I largely agree with Yaro, but will say
> 1) It is possible to square almost square angles with JOSM - it has an
> informational warning in validation, and automatically squares the angle by
> slightly moving the offending node.  This fix doesn't ruin the geometry of
> the building, as pressing Q so often does.  Unfortunately, it also leads to
> other angles in the building not being square.
> 3) I'm fine with importing smaller buildings as well (they don't seem to
> be in the source data in Toronto, they are for some of the other data
> sets).  I believe they were excluded because of their relatively low
> importance/permanence.
>
> I would also like to know how the Toronto building footprints were
> produced.  Does anyone know?
> DannyMcD
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>


-- 
Best Regards,
  Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Florimond Berthoux]

Le lun. 4 févr. 2019 à 10:36, Axelos  a écrit :

> N'oublions pas que beaucoup d'attributs inclus nativement des sous
> attributs, exemple highway=motorway (autoroute) qui interdit bon nombre
> de moyens de transports par défaut. Cette logique permet d’éviter
> d'ajouter 36 attributs de fait et donc de complexifier inutilement la
> description des objets.
>
Il y a une différence entre un attribut engendre des valeurs par défaut
d'autres clés (très bien listé sur le wiki)
et un ensemble d'attribut non limitatif engendre la valeur d'une clé.

Je verrais bien un opposite_pictogram, et comment décrire les pistes/bandes
cyclables barcelonaise ?
https://i2.wp.com/www.zicla.com/wp-content/uploads/2018/02/carrill-bici-calle-paris.png
Ce ne sont ni des pistes ni des bandes, il faudrait donc rajouter un nouvel
attribut, et donc demander aux render et router de prendre en compte ce
nouvel attribut ?
La galère.


>
> En revanche je vais suivre le sujet sur la question de la représentation
> des DSC sans pictogramme, car effectivement cela peut être amélioré bien
> qu'accessoire.
>


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

Re: [Talk-es] Toponimia en Cataluña

[Javi Rodriguez via Talk-es]

Buenas tardes,


Yo también prefiero la opción 2 que plantea Joan.

Desconozco que problema tienen en Wikipedia en Español para usar el topónimo 
oficial, insisten en que todo debe estar en Español, aunque eso les obligue a 
citar fuentes como el diccionario de Madoz (1845) o el INE de una determinada 
época (1857 a 1981). Y se quedan tan anchos.

Lo mismo pasa en la Wikipedia en catalán, donde Cataluña es un país europeo 
porque así lo indica una fuente citada. Y también se quedan tan anchos.

Parece que en la Wikipedia han perdido la cordura, como Don Quijote...


Las directrices de mapeado deben responder a criterios razonablemente claros y 
objetivos para poder mapear la realidad de manera util. La toponimia oficial y 
la RAE deben servirnos de apoyo.


Saludos.

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

Re: [Talk-es] Toponimia en Cataluña

[dcapillae]

Hola, Joan.

Gracias por tu mensaje. Me parece muy sensato en su conjunto. Creo estar de
acuerdo en casi todo. Descripo, no obstante, en el criterio que consideras
óptimo para decidir cuándo un término está en desuso, aunque no del todo. Me
explico.

La Academia nunca debe dejarse de lado como referencia última de la
corrección del uso de la lengua. Más bien, al contrario, debería ser una
primera referencia. No se puede seguir el criterio de considerar que «Un
topónimo está en desuso cuando deja de usarse!!!» porque eso no es un
criterio, es una tautología. Sin embargo, estoy casi de acuerdo en lo que
apuntas justo inmediatamente después: «Esto es, si, en un tiempo razonable,
los medios y la administración dejan de usar la forma españolizada, entonces
esa forma está en desuso». En primero lugar, no es lo mismo la «forma
españolizada» que ula «forma en español». En segundo lugar, precisamente a
eso es a lo que se dedican las academias de la lengua, entre otras cosas, a
valorar no solo cuando los medios de comunicación o la Administración dejan
de usar ciertos términos, sino que hace extensivo ese estudio a la comunidad
de hablantes en general.

Por tanto, considero que seguir el criterio de las academias de la lengua
debería ser nuestro criterio de referencia último para determinar cuando un
término está en desuso. Son las academias las que determinan, mediante el
estudio científico de textos escritos y lengua oral, que términos están en
desuso y cuáles están en uso. Ni la Wikipedia ni la comunidad OSM tienen
autoridad para decidir tales cosas.



-
Daniel Capilla 
OSM user: dcapillae 
--
Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html

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

Re: [OSM-talk] [Osmf-talk] Board decision on Crimea complaint

[Heather Leson]

Martin, thank you. As mentioned,  I am working on that internal deadline.
The draft is currently under review.

How was your Saturday morning? Mine was writing and reviewing these drafts
on Crimea and other topics. I warmly remind you that consensus building
does take time. We are very much making every effort to meet the need.


Heather

Heather Leson
heatherle...@gmail.com
Twitter/skype: HeatherLeson
Blog: textontechs.com


On Mon, Feb 4, 2019 at 2:18 PM Martin Koppenhoefer 
wrote:

>
>
> Am Mo., 28. Jan. 2019 um 18:33 Uhr schrieb Heather Leson <
> heat...@osmfoundation.org>:
>
>> Dear Martin and Colleagues,
>>
>> Since December, the Board has attempted to draft a public response. We
>> are still discussing.  I provided an update in the board meeting of January
>> 17, 2019 - https://wiki.osmfoundation.org/wiki/Board/Minutes/2019-01-17
>>
>> Since that time, I have tried again to get agreement from the Board on
>> the full details. We have a new board and there is much discussion about
>> the text.
>>
>> I will try again tomorrow night to rewrite it and ask for permission to
>> share from the Board. Also, a quick note about the comments in Weekly OSM.
>> I am obliged to issue statements on discussions when the Board agrees to
>> the content of the statements.
>>
>> Thank you,
>>
>> Heather
>>
>
>
> Dear Heather, dear Board,
>
> thank you for the update. I understand you are all volunteers and there
> are also other pressing issues at the moment. Still it is now a lot of time
> that has passed since Nov. 17 / Dec. 10, 2018, and we are in a kind of
> limbo, because the board, in apparent conflict with its own
> disputed-territories policy [1], reversed the Data Working Group decision
> just a few days before the 2018 board elections, but so far did not provide
> any kind of explanation or new policy to replace the former one.
>
> While it already felt quite strange on Dec. 10 that you just proclaimed
> the annulation of the well-founded DWG decision without providing any kind
> of explanations or motivations, it is now alarming that there are still no
> explanations. While we do not have many general rules with regard to
> mapping, the on-the-ground rule was certainly for many years the guiding
> principle and foundation of every "OpenStreetMapping", and assured us peace
> in problem areas, so deviating from it would seem such a major change of
> direction, that I could not believe my eyes when I read it and no
> explanation was provided along.
>
> Frankly, the way it was done, just before the upcoming elections of a new
> board, and without actually bringing it to an end, would probably be
> considered terrible political style, in the regions I am familiar with.
>
> My suggestion to the board would be to set yourself a deadline, until
> which you will try to reach consensus within the new Board, and if you
> cannot come to a common statement which supports the decision of the old
> Board, you should reenact the DWG decision so we can get back to normal
> operations.
>
>
> Cheers,
> Martin
>
>
>
>
> [1]
> https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-es] Toponimia en Cataluña

[Joan Montané]

Hola,

A raíz de una serie de mensajes en el grupo de Telegram, me animo a
escribir este mensaje a la lista sobre la toponimia en Cataluña. Excluyo
expresamente otras zonas del Estado español. No conozco su realidad con
detalle. Deseo que el debate que surja en este hilo sea útil para todos.

Antecedentes:

En la Wikipedia en español (en adelante ESwiki) tienen un criterio
particular/polémico en relación a los topónimos de Cataluña y otras zonas
del Estado.

OSM permite diferentes etiquetas, neutra o asociarlas a diferentes lenguas
(name, name:ca, name:es, ...)

Los toponimos oficiales en Cataluña son en catalán, salvo el Vall de Aran,
donde son en occitano. Esto no tiene relación directa con OSM (los name:xx
no tienen porqué usar nombres oficiales), pero sí guarda cierta relación
puesto que si cambia el nombre oficial, habitualmente cambia la realidad y,
en consecuencia, OSM (si se cambia el nombre de un aeropuerto/calle/pueblo
lo cambiamos en OSM, verdad?)

La mayoría de pueblos en Cataluña tienen name, name:ca y name:es.

Via ESwiki, el valor de name:es en OSM, muchas veces se corresponde con un
topónimo histórico que hace décadas que ya no tiene uso, ni en la calle ni
en los medios de comunicación. Ejemplo: Sant Boi de Llobregat [1]


Opciones:

En OSM pueden hacerse 2 cosas:

1.- Seguir a ciegas el critero de ESwiki. Fácil y sencillo. Lo que se está
haciendo, más o menos, ahora. ¿Cómo si no se han añadido topónimos
españolizados en desuso en OSM?

2.- Definir un criterio propio. Adaptado a OSM. Más trabajoso? Sí.

Prefiero la opción 2.
No estoy de acuerdo en seguir a ciegas ESwiki. Porqué los usos de una
enciclopédia no son los usos de una base de datos cartográfica. La realidad
no encaja con ESwiki, y OSM tiene como objectivo cartografiar la realidad.

¿Es útil el valor "name:es" en Cataluña? Afirmo que no. No refleja la
realidad. Ni el uso en el territorio ni el uso de los castellanoparlantes.
Puesto que gran parte de la población española tiene el navegador
configurado en español, visualiza el mapa (o lo que sea) en español con
unos topónimos que, honestamente, están en desuso y se consideran de otros
tiempos, un fósil producto de la historia.

Podríamos pensar qué topónimos españolizados tradicionales **sí** deben
aparecer en "name:es". Obviamente, hay algunos topónimos que no estan en
desuso, por ejemplo "Cataluña", "Gerona" o "Lérida" donde "name:es" sí
refleja la realidad. (aunque algun periódico estatal ha dejado de usarlos)
Tal vez tambien "Hospitalet de Llobregat " (sin el articulo "L'").

La dificultad está en definir cuando un topónimo españolizado pasa a ser
considerado en desuso. ESwiki considera que mientras una autoridad (la RAE)
no lo designe como tal (ejemplo, Maastrich [2]), el topónimo españolizado
sigue en uso. Opino distinto. Un topónimo está en desuso cuando deja de
usarse!!! Esto es, si, en un tiempo razonable, los medios y la
administración dejan de usar la forma españolizada, entonces esa forma está
en desuso.


Propuesta:

Definir un criterio para OSM. Pensar que topónimos españolizados **no**
estan en desuso (Gerona, Lérida, Cataluña,...) y que criterios para
considerar en desuso un topónimo españolizado. Por ejemplo, ¿15 años sín
publicación escrita en una selección de medios de comunicación ni en la
administración pública? Esto es, sin un uso feaciente de la forma
españolizada en un franja temporal reciente. Si no se ha usado... está en
desuso!

Para aquellos topónimos españolizados en desuso (San Baudilio): en
"name:es=..." poner el mismo valor que "name" (catalán o occitano segun el
caso), lo mismo que tienen "name:en" o "name:fr".

Los topónimos españolizados en desuso, si se quieren tener en OSM, mejor en
la etiqueta "old_name:es=...", que para eso está.

Saludos,
Joan Montané

[1] https://www.openstreetmap.org/relation/347545
[2] http://lema.rae.es/dpd/srv/search?key=Maastricht
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk] [Osmf-talk] Board decision on Crimea complaint

[Martin Koppenhoefer]

Am Mo., 28. Jan. 2019 um 18:33 Uhr schrieb Heather Leson <
heat...@osmfoundation.org>:

> Dear Martin and Colleagues,
>
> Since December, the Board has attempted to draft a public response. We are
> still discussing.  I provided an update in the board meeting of January 17,
> 2019 - https://wiki.osmfoundation.org/wiki/Board/Minutes/2019-01-17
>
> Since that time, I have tried again to get agreement from the Board on the
> full details. We have a new board and there is much discussion about the
> text.
>
> I will try again tomorrow night to rewrite it and ask for permission to
> share from the Board. Also, a quick note about the comments in Weekly OSM.
> I am obliged to issue statements on discussions when the Board agrees to
> the content of the statements.
>
> Thank you,
>
> Heather
>


Dear Heather, dear Board,

thank you for the update. I understand you are all volunteers and there are
also other pressing issues at the moment. Still it is now a lot of time
that has passed since Nov. 17 / Dec. 10, 2018, and we are in a kind of
limbo, because the board, in apparent conflict with its own
disputed-territories policy [1], reversed the Data Working Group decision
just a few days before the 2018 board elections, but so far did not provide
any kind of explanation or new policy to replace the former one.

While it already felt quite strange on Dec. 10 that you just proclaimed the
annulation of the well-founded DWG decision without providing any kind of
explanations or motivations, it is now alarming that there are still no
explanations. While we do not have many general rules with regard to
mapping, the on-the-ground rule was certainly for many years the guiding
principle and foundation of every "OpenStreetMapping", and assured us peace
in problem areas, so deviating from it would seem such a major change of
direction, that I could not believe my eyes when I read it and no
explanation was provided along.

Frankly, the way it was done, just before the upcoming elections of a new
board, and without actually bringing it to an end, would probably be
considered terrible political style, in the regions I am familiar with.

My suggestion to the board would be to set yourself a deadline, until which
you will try to reach consensus within the new Board, and if you cannot
come to a common statement which supports the decision of the old Board,
you should reenact the DWG decision so we can get back to normal operations.


Cheers,
Martin




[1]
https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Doublons landuse=residential et place=town

[osm . sanspourriel]

L'autre question est : est-ce qu'un name sur landuse=residential a un 
sens quand ce nom est celui de la commune (sauf à avoir une commune 
purement dortoir sans autre activité) ?


C'est l'origine du soucis observé. Si on devait mettre un nom en 
Bretagne ce serait "Le Bourg" et non le nom de la commune. Donc pas de nom.


Jean-Yvon

Le 04/02/2019 à 11:10, Thomas Ruchin - truchi...@gmail.com a écrit :

Bonjour

OSM est un projet itératif.
A mon avis, le plus propre est de créer des polygones 
landuse=residential qui correspondent grosso-modo aux zones 
résidentielles et de les affiner dans un second temps.
Nous sommes d'accord que la relation de la commune n'est pas adaptée 
pour supporter ce type d'information.


Thomas

Le lun. 4 févr. 2019 à 09:12, Phyks > a écrit :


Bonjour,

Il y a un attribut "landuse=residential" à Montrouge sur le même
polygone que le "boundary=administrative" :
https://www.openstreetmap.org/relation/37026. En revanche, la ville en
elle-même est séparée, sur un nœud "place=town" :
https://www.openstreetmap.org/node/26692584.

Je suis tombé dessus en rapportant un bug sur le rendu
https://github.com/gravitystorm/openstreetmap-carto/issues/3664, qui
fait apparaître le nom "Montrouge" en plusieurs exemplaires sur la
carte.

Le problème est que le "landuse=residential" correspond à toute
l'étendue de la ville de Montrouge et a un nom associé. Or, le rendu
osm.org  affiche les noms des
"landuse=residential" (pour afficher les
noms des résidences et aires d'accueil des gens du voyage par
exemple).
Le nom sur ce landuse fait doublon avec celui sur le nœud place=town,
d'où le double affichage sur le fond de carte, à certains niveaux de
zooms uniquement.

J'ai l'impression que d'une part ce landuse est incorrect (toute la
ville n'est pas purement résidentielle, il y a des activités
commerciales ou industrielles par exemple) et d'autre part ce
landuse ne
devrait probablement pas contenir de nom, qui est déjà sur le
place=town.

Pourtant c'est fait de la même façon sur certaines villes alentour
comme
Malakoff, Arcueil etc. Donc il y a probablement une justification
et je
ne sais pas comment le corriger vraiment. En particulier, je ne
sais pas
si le doublon de nom "Montrouge" entre le "boundary=administrative"
(https://www.openstreetmap.org/relation/37026) et le "place=town"
(https://www.openstreetmap.org/node/26692584) est normal ?

Je vois deux solutions pour l'instant :

1. La solution naïve : créer un polygone séparé qui recouvre la même
surface que https://www.openstreetmap.org/relation/37026 et ajouter le
"landuse=residential" dessus (pour séparer le
"landuse=residential" du nom).
2. Faire une vraie correction, probablement en créant un multipolygone
exact pour le landuse=residential ?

Auriez-vous plus d'informations ou de conseils à ce sujet ?

Bonne journée,
-- 
Phyks


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


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

Re: [Talk-us] Wake County Missing Buildings Import

[mangokm40 via Talk-us]

Do you need donkey work, like in Miami?

‐‐‐ Original Message ‐‐‐
On Sunday, February 3, 2019 11:50 AM, Leif Rasmussen <354...@gmail.com> wrote:

> Hi everyone,
> Joe Caruso contacted the City of Raleigh about the license of the building 
> footprints, and received a promising reply.  The data is OSM compatible.
> The building import will begin some time soon, after all comments have been 
> addressed.  The bus stop and address imports will begin after this import is 
> complete.
>
> * Wiki page: 
> https://wiki.openstreetmap.org/wiki/Wake_County_North_Carolina_Building_Import
> * Tasking Manager Project: https://tasks.openstreetmap.us/project/110
> * Size of Import: 31, 730 buildings.
>
> Please let me know if I have missed anything.
> Thanks,
> Leif Rasmussen___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk] Strang (non-)rendering issue

[Tom Hughes]

On 04/02/2019 10:10, Maarten Deen wrote:

On 2019-01-30 17:45, Tom Hughes wrote:

On 30/01/2019 16:22, Maarten Deen wrote:

Are there different rendering servers for those regions? I know that 
there are different tileservers, but I didn't know the rendering was 
also different. Is that not really inefficient to have two servers 
render the same tiles?


There are currently five render servers.


The changes still don't show up. Also in another area [1] I've made 
changes (Kirchstraße is not pedestrian and added to memorials) that 
don't show up.
Also someone on the dutch mailing list complained about changes not 
showing up.

Is the renderer that caters for the Netherlands working ok?


It is, like all the other renderers, fully up to date.

It is however very busy due to the recent style change so it
currently unable to perform non-urgent renders for most of
the day.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

Re: [Talk-it] pronto soccorso ospedali italiani

[Martin Koppenhoefer]

Am Mo., 4. Feb. 2019 um 08:01 Uhr schrieb Aury88 :

> dieterdreist wrote
> > generalmente le pagine che descrivono i features, sono definiti in
> > inglese, e le traduzioni dovrebbero essere appunto questo: traduzioni.
> > Quindi la pagina italiana di amenity=hospital dovrebbe essere una
> > traduzione della pagina inglese, e se si intende aggiungere informazioni
> > sarebbe la cosa migliore farlo per prima in inglese.
> >
> > Non è una critica dei contenuti che vuoi mettere, ma è come penso
> dovrebbe
> > funzionare il wiki.
>


> non sono d'accordo. se fosse come dici tu non servirebbe avere le voci
> nelle
> varie lingue ma basterebbe la possibilità di effettuare la traduzione
> online.



dai, non ci sono traduttori automatici che soddisfano i requisiti di
qualità che abbiamo, sennò il wiki diventerebbe un posto incomprensibile
come le pagine di "aiuto" della microsoft, che si capiscono soltanto
ritraducendole in inglese. In generale i traduttori stanno migliorando però
e non escludo che arrivano ad un punto dove gli errori sono talmente poci
da rischiare. Se fosse come dici tu, non ci sarebbero più traduttori (veri,
persone che lo fanno come lavoro).



> ci sono troppi casi specifici locali, o utilizzi errati locali per i
> quali vale la pena sottolineare, solo nelle singole lingue, cosa fare o non
> fare.



i casi specifici locali però sono legati ad un luogo, non ad una lingua. Il
wiki "italiano" non è il wiki per l'Italia (al meno non nella parte
generale dei tags), è il wiki in italiano. Il wiki per l'Italia è qui:
https://wiki.openstreetmap.org/wiki/WikiProject_Italy



> inoltre, come hai modo di vedere da questa discussione, le modifiche
> sono state discusse, proposte, testate ed infine trasferite sulla voce
> wiki.
> avessi dovuto farlo anche per la wiki "internazionale", ipotizzando che
> fossi in grado di fare tutto questo in maniera corretta in un altra lingua,
> per un tema del genere saremmo ancora  a parlare delle modifiche per i
> futuri anni mentre in italia, aspettando che a livello internazionali si
> decida di integrare nella voce accenni a altri* tag già esistenti ed
> approvati*, si continuerebbe a vedere applicato male e contrario allo stile
> internazionale il tag amenity=hospitalanche a causa di una voce in
> italiano che asseriva "Se più edifici adibiti ad ospedale sono presenti in
> un'unica grande area considerate l'eventualità di combinare queste
> informazioni in una relazione al posto di taggare ogni singolo edificio
> come
> tale"[cit] questa si una invenzione italiana e addirittura il cui effetto è
> quello di vedere applicato il tag sui singoli edifici; contrario quindi a
> quanto asserito alla wiki inglesequesto non va bene, non imho integrare
> una voce con elementi secondari e che fanno riferimento a std approvato a
> liv. internazionale
>


non pensare che le modifiche nel wiki internazionale siano più discusse o
approvate rispetto a questa tua modifica. Per me potresti mettere le cose
anche in inglese nel wiki ;-)
Tanto i tag (al meno che non mi sfugge qualcosa) sono già diffusi, e non mi
risultano contestati.



>
> solo un appunto Martin...è da due settimane che è possibile vedere la
> sandox
> e discutere delle modifiche, due settimane in cui nessuno ha avuto da
> obbiettare all'aggiunta di elementi in più rispetto la voce in inglese
> nonostante l'ampia discussione qui e la diffusione della notizia sul canale
> telegram, non capisco quindi perchè hai aspettato che pubblicassi la
> modifica prima di intervenire. non era meglio farlo prima che fosse fatto
> il
> danno?
>


mi era sfuggito ;-)
Comunque, non sto obiettando sui contenuti da mettere, penso semplicemente
che siano da inserire anche in inglese. Non c'è niente di particolare
italiano che non si applica in altri paesi ("simili"). Un'altra pagina dove
avrebbe senso parte del contenuto è questa:
https://wiki.openstreetmap.org/wiki/Tag:emergency%3Demergency_ward_entrance
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] One feature, one element - scuole

[Martin Koppenhoefer]

Am Mo., 4. Feb. 2019 um 08:55 Uhr schrieb Cascafico Giovanni <
cascaf...@gmail.com>:

> > Se proprio le due scuole condividono la stessa identica area si possono
> usare le relazioni multipoligono per creare più elementi area con lo stesso
> unico poligono esterno.
>


> Ma il multipoligono: credo serva a risolvere problemi geometrici come i
> buchi. Come nella wiki a me piacerebbe usare la relazione "site".
>
>

il multipoligono può essere utilizzato per qualsiasi scopo che sia in grado
di risolvere (geometricamente). Si tratta di creare aree, ed è vantaggioso
quando ci sono: tanti nodi (perché con un singolo poligono di 3-5 nodi è
troppo overhead di creare una relazione, aumentare quindi la complessità,
quando si può risolvere con un semplice secondo poligono), e/o più way che
ne definiscono il contorno. La presenza di buchi come anche 2 e più aree
distaccate sono indicazioni obbligatorie per MP, ma non sono gli unici casi
dove sono utili.



>  > Immagino una poligono senza tag che sarà poi utilizzato in due
> relazioni, una per ogni scuola e con i propri tag.
> Sarebbe logico inserire in due relazioni "site" con i tag specifici di
> ciascuna scuola, però un poligono senza tag come verrebbe interpretato in
> OSM?
>
>


i site li eviterei. Non sono ben definiti (ciascuno si sogna che risolva il
suo problema, ci sono tante varianti di impiego), e quando parliamo di solo
poligoni (quindi niente nodi o ways lineari come membri, niente ruoli
particolari, ecc.) ci sono solo svantaggi di un site rispetto ad un
multipoligono (in sostanza nessuno dei grandi utilizzatori di dati fa uso
dei site).

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

Re: [OSM-talk] Strang (non-)rendering issue

[Maarten Deen]

On 2019-02-04 11:52, Hartmut Holzgraefe wrote:

On 04.02.19 11:10, Maarten Deen wrote:


The changes still don't show up. Also in another area [1] I've made
changes (Kirchstraße is not pedestrian and added to memorials) that
don't show up.
Also someone on the dutch mailing list complained about changes not
showing up.
Is the renderer that caters for the Netherlands working ok?



At first try I only got updated tiles partially, ways on the parking
lot from example #1 ended in the middle of the lot, and one part of
Kirchstraße in example #2 was still showing as pedestrian.

After reloading the browser page with CTRL-R everything looked fine
in Firefox.

Chromium was still showing old tiles though for all of Kirchstraße,
even after CTRL-R. Only after a forced reload with SHIFT-CTRL-R
the pedestrian section was gone.

So the issue is not so much with tile rendering, but seems to be
about the different cacheing layers involved ...


My normal browser is Firefox and no amount of reloading works, but sure, 
this could be a caching issue.
I also have Pale Moon and IE and both have not been used to view the 
area before and they both show the old tiles. No amount of zooming in or 
out or reloading helps.
If it is a caching issue, it is upstream from me and I find it very 
strange that tiles would get cached that long (in the case of my edits 
around Drauffelt).


Regards,
Maarten

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

Re: [OSM-talk] Strang (non-)rendering issue

[Hartmut Holzgraefe]

On 04.02.19 11:10, Maarten Deen wrote:

> The changes still don't show up. Also in another area [1] I've made
> changes (Kirchstraße is not pedestrian and added to memorials) that
> don't show up.
> Also someone on the dutch mailing list complained about changes not
> showing up.
> Is the renderer that caters for the Netherlands working ok?


At first try I only got updated tiles partially, ways on the parking
lot from example #1 ended in the middle of the lot, and one part of
Kirchstraße in example #2 was still showing as pedestrian.

After reloading the browser page with CTRL-R everything looked fine
in Firefox.

Chromium was still showing old tiles though for all of Kirchstraße,
even after CTRL-R. Only after a forced reload with SHIFT-CTRL-R
the pedestrian section was gone.

So the issue is not so much with tile rendering, but seems to be
about the different cacheing layers involved ...

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

Re: [Talk-es] Calles residenciales en Madrid

[Santiago Crespo]

Hola buenas Alejandro,

No veo ningún ejemplo de "source:maxspeed=inherit" en OSM:

https://taginfo.osm.org/keys/?key=source:maxspeed=inherit

Creo que lo más correcto es usar el valor "ES:zone30". Algo así:

maxspeed=30
source:maxspeed=ES:zone30

https://wiki.osm.org/wiki/Key%3Asource%3Amaxspeed

¿Has pensado cómo añadir estas etiquetas? Deberíamos de poder
automatizarlo, aunque primero quizá deberíamos de dar un repaso a las
líneas de bus, pues las calles que forman parte de la "Red Básica de
Transportes" mantienen el límite de 50 km/h. También añadir todas las
calles que tienen plataforma única (acera a nivel de la calzada) pues en
estas el límite es de 20 km/h.

Las líneas de bus están publicadas en el portal de datos abiertos del
Ayuntamiento y creo recordar que la información sobre las calles con
plataforma única también (en el conjunto de datos "Cartografía municipal
por distritos a escala 1:1000, formato SHP, ETRS89")

https://wiki.osm.org/wiki/ES:Importaci%C3%B3n_Ayuntamiento_de_Madrid

Saludos!
Crespo


On 2/4/19 11:08 AM, Alejandro Moreno wrote:
> Buenos días.
> 
> Sigo dándole una vuelta al problema que tenemos en Madrid al tener una
> normativa de velocidad específica solo para nuestra ciudad. Con la nueva
> normativa el 85% de las calles han pasado a tener un límite de velocidad
> de 30km/h pero no porque haya señalización específica, si no por las
> características de número de carriles de la calle.
> 
> Pensando en como mapear eso veo que una solución el siguiente etiquetado.
> 
> maxspeed=30
> source:maxspeed=inherit
> 
> El valor /inherit/ tiene mucho uso en el mapa y yo lo entiendo como
> "inherente a la vía" que es justo el etiquetado que yo busco. ¿Cómo lo veis?
> 
> El mié., 24 oct. 2018 a las 19:36, Jorge Sanz Sanfructuoso
> (mailto:sanc...@gmail.com>>) escribió:
> 
> Buenas.
> 
> Lo de source:maxspeed=ES-Madrid:urban lo veo como una cosa demasiado
> especifica de Madrid. No sé todas las limitaciones, sé más o menos
> por encima pero creo que esta etiqueta solo se referiría al límite
> de 30Km/h. Esa limitación esta en estudio en más sitios y no estoy
> seguro, pero me suena que en alguna ciudad más ya se ha puesto.
> 
> Si solo se refiere al límite de 30 y es una cosa que se esta
> haciendo en más sitios creo que se debería buscar algo más genérico.
> 
> En la wiki vienen ejemplos de FR:zone30 a lo mejor ES:zone30 ?
> 
> Un saludo.
> 
> 
> El mié., 24 oct. 2018 a las 19:07, Alejandro Moreno
> (mailto:almo...@gmail.com>>) escribió:
> 
> Buscando en la wiki veo que se puede usar la
> etiqueta source:maxspeed para ampliar la información del porqué
> de la limitación de velocidad.
> 
> ¿Qué os parece usar
> source:maxspeed=ES-Madrid:urban para esas calles limitadas por
> la normativa y no por ninguna señal específica? Así es fácil
> tenerlas localizadas.
> 
> El mié., 24 oct. 2018 8:43, Jo  > escribió:
> 
> Si hay este
> señal: https://practicavial.com/senal-de-la-calle-residencial/
> 
> Es highway=living_street. maxspeed=20 es implicada, pero no
> molesta agregarlo.
> 
> sino
> 
> highway=residential
> maxspeed=30
> 
> Pienso que lo mejor es de agregarlo a todas las calles
> individualmente.
> 
> Polyglot
> 
> Op wo 24 okt. 2018 om 08:30 schreef Alejandro Moreno
> mailto:almo...@gmail.com>>:
> 
> Relacionado con este tema yo tengo otra duda.
> 
> Todas las calles de un solo sentido y un solo carril
> pasan a tener una velocidad máxima de 30km/h y las de
> plataforma única pasan a estar limitadas a 20 km/h
> ¿Cómo representamos esto en OSM?¿Se puede hacer algo que
> afecte a todo el área de Madrid, hay que modificar el
> max-speed calle a calle o lo dejamos como está y
> representamos solo la velocidad máxima cuándo haya
> señalética?
> 
> El mié., 24 oct. 2018 a las 8:01, Jo
> (mailto:winfi...@gmail.com>>) escribió:
> 
> cycleway=opposite no es necesario si no hay pistas
> ciclables dedicadas en contradirección.
> 
> oneway:bicycle=no       dice todo.
> 
> Polyglot
> 
> Op di 23 okt. 2018 om 23:16 schreef ikanian
> mailto:ader...@gmail.com>>:
> 
> Buenas noches,
> 
> mi duda viene rebotada del grupo de telegram y
> me han dicho que la pase
> también por aquí, ya que puede haber gente
> interesada en este asunto.
> Básicamente, el 24 de octubre (mañana) entra en
>  

Re: [Talk-si] Začetniška vprašanja

[colored stone]

Aleš, zdravo.

Kar precej vprašanj si postavil, spodaj nekaj odgovorov.




*Zelo očitno se vidi zamik med mapiranimi elementi, verjetno pretežno
iz rabe tal, in Bingovim posnetkom v ozadju. Kaj je prav? Kako mapirati?
Po posnetku ali po občutku, kakor je mapirana okolica?  *

Praviloma je potrebno pri uporabi različnih rastrskih podlag, ki so podlaga
za urejanje OSM vsebin, vedno upoštevati offset (začetniki imajo običajno s
tem problem in dostikrat po nepotrebnem "popravljajo" obstoječo vsebino
recimo na Bing, kakor se jim prikaže na začetku). Offset satelitskih podlag
ni konstanten, ampak se spreminja od lokacije do lokacije. Podatki RABA,
katerih vir so podatki dejanske rabe kmetijskih zemljišč (
https://wiki.openstreetmap.org/wiki/Slovenia_Landcover_Import_-_RABA-KGZ),
v praksi predstavljajo precej dobro referenco.
Zelo dobra osnova namesto Bing je tudi slovenski DOF, ki je na voljo v
urejevalniku JOSM (pa še par drugih vsebin kot ozadje: stavbe, ceste,
raba).





*Katero kategorijo cest pripeti javnim cestam, praviloma v občinski lasti,
po vaseh, ki povezujejo različne dele vasi, ne pa tudi različne vasi med
seboj? A je to Unclassified road? Ali Residential road, čeprav v neposredni
okolici ni nobenih hiš? Kaj tretjega?*

Poglej tule: https://wiki.openstreetmap.org/wiki/Sl:Map_Features




*Kako je s hitrostmi na cestah? A se tam piše formalno dovoljeno
hitrost? Ali neko realistično hitrost? Obstaja recimo ogromno kolovozov,
kjer je formalno dovoljeno voziti 90 km/h, v praksi pa gre bolj kaj okrog
5 km/h. Če imaš dober traktor. Z običajnim avtom pa verjetno 0.*

Praviloma se vpiše formalno dovoljena hitrost. Ta se potem uproablja tudi
za navigacijske aplikacije.Glej še tule:
https://wiki.openstreetmap.org/wiki/Speed_limits



*Ali se da kako zrenderirati ceste tako, da se vidijo tudi vozni
pasovi? Lahko tudi samo ob velikem zoomu. Po možnosti z oznakami, kam se
iz katerega pasu lahko zavija? *

Nekatere ceste (npr. dvopasovnice, avtoceste) se vnašajo z vsaki voznim
pasovom posebej. Iz tega je mogoče prikazato tudi kako in kam se zavija. Je
pa potrebno ločevati podatke v OSM in rendering, ki je lahko zelo različen.
Osnovni rendering, ki je dostopen na openstreetmap.org je samo eden od
načinov prikaza podatkov in ne prikazuje vseh podatkov (prikazuje pa tudi
smeri voznih pasov: https://www.openstreetmap.org/#map=19/46.05665/14.50116
).




*Kako pri krožiščih, kjer ti napiše, po katerem izvozu zapustiti krožišče,
preskočiti povečevanja tega števca z uvozi? In kako enega izvoza (na isto
cesto) preko dveh ločenih vozišč (vmes je dvignjen betonski robnik) ne
šteti dvakrat? *

Tule bi ti znal kdo pomagati, če navedeš kokretni primer.



*Ali se poti morajo dotikati hiš z naslovom? Se mi zdi, da se potem
pri iskanju poti ob vpisu naslova nekako bolj pogosto najde tisto
lokacijo, oz. manjkrat reče, da na tisti relaciji pot ne obstaja. *

Ne, nikakor ne!
https://help.openstreetmap.org/questions/35795/map-buildings-connecting-the-road-or-not


*Kako narediti recimo transformer_tower? Sem poskušal narisati zgradbo in *



*potem izbrati, da je transformer tower, pa nikakor ni šlo. Na nek način je
uspelo, če sem izbral transformer, ki sem mu potem dodal
tag building:transformer_tower, ampak je spet čudno.  *

Tule bi moralo nekaj pisati o tem:
https://wiki.openstreetmap.org/wiki/Tag:building%3Dtransformer_tower


Kakršna koli dodatna vprašanja so seveda dobrodošla.

Lep pozdrav,

Martin
(coloredstone)
___
Talk-si mailing list
Talk-si@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-si

Re: [OSM-talk] Strang (non-)rendering issue

[Maarten Deen]

On 2019-01-30 17:45, Tom Hughes wrote:

On 30/01/2019 16:22, Maarten Deen wrote:

Are there different rendering servers for those regions? I know that 
there are different tileservers, but I didn't know the rendering was 
also different. Is that not really inefficient to have two servers 
render the same tiles?


There are currently five render servers.


The changes still don't show up. Also in another area [1] I've made 
changes (Kirchstraße is not pedestrian and added to memorials) that 
don't show up.
Also someone on the dutch mailing list complained about changes not 
showing up.

Is the renderer that caters for the Netherlands working ok?

[1] 

Regards,
Maarten

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

Re: [OSM-talk-fr] Doublons landuse=residential et place=town

[Thomas Ruchin]

Bonjour

OSM est un projet itératif.
A mon avis, le plus propre est de créer des polygones landuse=residential
qui correspondent grosso-modo aux zones résidentielles et de les affiner
dans un second temps.
Nous sommes d'accord que la relation de la commune n'est pas adaptée pour
supporter ce type d'information.

Thomas

Le lun. 4 févr. 2019 à 09:12, Phyks  a écrit :

> Bonjour,
>
> Il y a un attribut "landuse=residential" à Montrouge sur le même
> polygone que le "boundary=administrative" :
> https://www.openstreetmap.org/relation/37026. En revanche, la ville en
> elle-même est séparée, sur un nœud "place=town" :
> https://www.openstreetmap.org/node/26692584.
>
> Je suis tombé dessus en rapportant un bug sur le rendu
> https://github.com/gravitystorm/openstreetmap-carto/issues/3664, qui
> fait apparaître le nom "Montrouge" en plusieurs exemplaires sur la carte.
>
> Le problème est que le "landuse=residential" correspond à toute
> l'étendue de la ville de Montrouge et a un nom associé. Or, le rendu
> osm.org affiche les noms des "landuse=residential" (pour afficher les
> noms des résidences et aires d'accueil des gens du voyage par exemple).
> Le nom sur ce landuse fait doublon avec celui sur le nœud place=town,
> d'où le double affichage sur le fond de carte, à certains niveaux de
> zooms uniquement.
>
> J'ai l'impression que d'une part ce landuse est incorrect (toute la
> ville n'est pas purement résidentielle, il y a des activités
> commerciales ou industrielles par exemple) et d'autre part ce landuse ne
> devrait probablement pas contenir de nom, qui est déjà sur le place=town.
>
> Pourtant c'est fait de la même façon sur certaines villes alentour comme
> Malakoff, Arcueil etc. Donc il y a probablement une justification et je
> ne sais pas comment le corriger vraiment. En particulier, je ne sais pas
> si le doublon de nom "Montrouge" entre le "boundary=administrative"
> (https://www.openstreetmap.org/relation/37026) et le "place=town"
> (https://www.openstreetmap.org/node/26692584) est normal ?
>
> Je vois deux solutions pour l'instant :
>
> 1. La solution naïve : créer un polygone séparé qui recouvre la même
> surface que https://www.openstreetmap.org/relation/37026 et ajouter le
> "landuse=residential" dessus (pour séparer le "landuse=residential" du
> nom).
> 2. Faire une vraie correction, probablement en créant un multipolygone
> exact pour le landuse=residential ?
>
> Auriez-vous plus d'informations ou de conseils à ce sujet ?
>
> Bonne journée,
> --
> Phyks
>
> ___
> 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-es] Calles residenciales en Madrid

[Alejandro Moreno]

Buenos días.

Sigo dándole una vuelta al problema que tenemos en Madrid al tener una
normativa de velocidad específica solo para nuestra ciudad. Con la nueva
normativa el 85% de las calles han pasado a tener un límite de velocidad de
30km/h pero no porque haya señalización específica, si no por las
características de número de carriles de la calle.

Pensando en como mapear eso veo que una solución el siguiente etiquetado.

maxspeed=30
source:maxspeed=inherit

El valor *inherit* tiene mucho uso en el mapa y yo lo entiendo como
"inherente a la vía" que es justo el etiquetado que yo busco. ¿Cómo lo veis?

El mié., 24 oct. 2018 a las 19:36, Jorge Sanz Sanfructuoso (<
sanc...@gmail.com>) escribió:

> Buenas.
>
> Lo de source:maxspeed=ES-Madrid:urban lo veo como una cosa demasiado
> especifica de Madrid. No sé todas las limitaciones, sé más o menos por
> encima pero creo que esta etiqueta solo se referiría al límite de 30Km/h.
> Esa limitación esta en estudio en más sitios y no estoy seguro, pero me
> suena que en alguna ciudad más ya se ha puesto.
>
> Si solo se refiere al límite de 30 y es una cosa que se esta haciendo en
> más sitios creo que se debería buscar algo más genérico.
>
> En la wiki vienen ejemplos de FR:zone30 a lo mejor ES:zone30 ?
>
> Un saludo.
>
>
> El mié., 24 oct. 2018 a las 19:07, Alejandro Moreno ()
> escribió:
>
>> Buscando en la wiki veo que se puede usar la etiqueta source:maxspeed
>> para ampliar la información del porqué de la limitación de velocidad.
>>
>> ¿Qué os parece usar
>> source:maxspeed=ES-Madrid:urban para esas calles limitadas por la
>> normativa y no por ninguna señal específica? Así es fácil tenerlas
>> localizadas.
>>
>> El mié., 24 oct. 2018 8:43, Jo  escribió:
>>
>>> Si hay este señal:
>>> https://practicavial.com/senal-de-la-calle-residencial/
>>>
>>> Es highway=living_street. maxspeed=20 es implicada, pero no molesta
>>> agregarlo.
>>>
>>> sino
>>>
>>> highway=residential
>>> maxspeed=30
>>>
>>> Pienso que lo mejor es de agregarlo a todas las calles individualmente.
>>>
>>> Polyglot
>>>
>>> Op wo 24 okt. 2018 om 08:30 schreef Alejandro Moreno >> >:
>>>
 Relacionado con este tema yo tengo otra duda.

 Todas las calles de un solo sentido y un solo carril pasan a tener una
 velocidad máxima de 30km/h y las de plataforma única pasan a estar
 limitadas a 20 km/h
 ¿Cómo representamos esto en OSM?¿Se puede hacer algo que afecte a todo
 el área de Madrid, hay que modificar el max-speed calle a calle o lo
 dejamos como está y representamos solo la velocidad máxima cuándo haya
 señalética?

 El mié., 24 oct. 2018 a las 8:01, Jo () escribió:

> cycleway=opposite no es necesario si no hay pistas ciclables dedicadas
> en contradirección.
>
> oneway:bicycle=no   dice todo.
>
> Polyglot
>
> Op di 23 okt. 2018 om 23:16 schreef ikanian :
>
>> Buenas noches,
>>
>> mi duda viene rebotada del grupo de telegram y me han dicho que la
>> pase
>> también por aquí, ya que puede haber gente interesada en este asunto.
>> Básicamente, el 24 de octubre (mañana) entra en vigor la nueva
>> ordenanza de
>> movilidad de Madrid. Una de las nuevas cosas que prevee es que en las
>> calles
>> residenciales las bicicletas puedan ir a contradirección. Por ello,
>> me había
>> surgido la duda de cómo etiquetarlas.
>>
>> He visto que hay muchas calles residenciales que no tienen aplicada la
>> etiqueta highway=living_street y por eso me ha surgido la duda de cómo
>> etiquetarla. La propuesta que me han dado es la siguiente, que es  la
>> misma
>> que propone la wiki
>>   :
>>
>> highway = living_street
>> cycleway = opposite
>> oneway = yes
>> oneway:bicycle = no
>>
>> Un saludo a todos!
>>
>>
>>
>> --
>> Sent from: http://gis.19327.n8.nabble.com/Spain-f5409873.html
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
 ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
> --
> Jorge Sanz Sanfructuoso - Sanchi
> Blog http://jorgesanz.es/
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Axelos]

Le 02/02/2019 à 19:36, Florimond Berthoux a écrit :
> C'est ça, et ça rejoint la version anglaise :
> «Add the cycleway=* tag to a highway=* to map cycling infrastructure that
> is an inherent part of the road.»
> puis :
> «cycleway=opposite
> Use cycleway=opposite for situations where cyclists are permitted to
> travel in both directions on a road which is one-way for normal traffic, in
> situations where there is no dedicated contra-flow lane marked for
> cyclists. In practice there is typically a very short section of road,
> sometimes called a "cycle plug", where cycles are excepted from the
> no-entry by means of a short lane separated by an island. These roads
> should normally also be tagged with oneway=yes and also oneway:bicycle=no.
> Streets like this are common in Belgium, the Netherlands and Denmark. They
> are rarer in the UK, but are becoming more common due to a recent change in
> road signage allowing no entry signs qualified with "except cycles".»

C'est effectivement intéressant.
Toutefois, avant de partir sur une idée de modification en masse,
peut-on se poser une question simple :

Existe-t-il des cas où l'usage de cycleway=opposite,
cycleway=opposite_lane / cycleway:left=opposite_lane serait
contradictoire avec oneway:bicycle=no ?

N'oublions pas que beaucoup d'attributs inclus nativement des sous
attributs, exemple highway=motorway (autoroute) qui interdit bon nombre
de moyens de transports par défaut. Cette logique permet d’éviter
d'ajouter 36 attributs de fait et donc de complexifier inutilement la
description des objets.

En revanche je vais suivre le sujet sur la question de la représentation
des DSC sans pictogramme, car effectivement cela peut être amélioré bien
qu'accessoire.

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

Re: [OSM-talk-fr] Re: Moulinette pour ajouter "oneway:bicycle=no" ?

[Gwenaël Jouvin via Talk-fr]

De la description anglophone de cycleway=lane + cycleway:lane=advisory, ça 
correspond presque point par point à la chaussée à voie centrale banalisée 
récemment apparue en France :

Points communs :
— les véhicules motorisés peuvent s’y arrêter ;
— les cyclistes peuvent y circuler, sans pour autant y être contraints.

Différences :
En France, les marquages délimitent un accotement, donc les véhicules motorisés 
ne peuvent pas y circuler, sauf contrainte majeure comme l’encombrement pour 
croiser un autre véhicule.
De même, ces accotements ne sont pas des itinéraires cyclables et ne doivent 
pas recevoir de pictogrammes « cyclistes ». Les chevrons seuls sont par contre 
autorisés [1]. Le type de marquage est une ligne de rive, pas un marquage de 
bande cyclable. Sur ces derniers points, il y a régulièrement des erreurs sur 
le terrain, par confusion avec des bandes cyclables.



[1] CÉREMA, Chaussée à voie centrale banalisée, Éléments de recommandation, 
Fiche n° 37 - Mai 2017
https://www.cerema.fr/fr/centre-ressources/boutique/velo-amenagements-recommandations-retours-experiences


Le 04/02/2019 à 09:52, Antoine Riche via Talk-fr a écrit :
> Le 03/02/2019 à 22:07, Florimond Berthoux a écrit :
>> entre rien sur la chaussée et des pictos...
>> Bref, le opposite ne permet pas décrire précisément l'infrastructure.
> Si : le tag cycleway:lane permet de préciser la matérialisation d'une bande 
> cyclable, cela inclut les pictogrammes 
> :https://wiki.openstreetmap.org/wiki/FR:Key:cycleway:lane
> 
> Cette page ne décrit pas le cas des double-sens, mais cycleway=shared_lane 
> correspond bien à cycleway=opposite (inutile donc d'inventer un 
> cycleway=opposite_shared_lne ;)  Je proposerais donc  cycleway=opposite + 
> cycleway:lane=pictogram
> 
> Bien qu'ayant traduit cette page je ne comprends pas vraiment la valeur 
> cycleway:lane=advisory. Peut-être qu'un contributeur belge pourrait nous 
> éclairer ?
> 
> Antoine.
> 
> 
> 
> ___
> 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] Moulinette pour ajouter "oneway:bicycle=no" ?

[Antoine Riche via Talk-fr]

Au sujet du sujet de ce thread et de la demande initiale :

> => Est-il acceptable par la communauté de faire une moulinette pour 
ajouter > ce tuple manquant à tous les DSC déjà définis dans OSM avec > 
"cycleway(:left|right)=opposite|opposite_lane|opposite_track" ? Je 
propose cette saine lecture : 
https://wiki.openstreetmap.org/wiki/What's_the_problem_with_mechanical_edits%3F 
Antoine


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

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Antoine Riche via Talk-fr]

Le 03/02/2019 à 22:07, Florimond Berthoux a écrit :

entre rien sur la chaussée et des pictos...
Bref, le opposite ne permet pas décrire précisément l'infrastructure.
Si : le tag cycleway:lane permet de préciser la matérialisation d'une 
bande cyclable, cela inclut les pictogrammes 
:https://wiki.openstreetmap.org/wiki/FR:Key:cycleway:lane


Cette page ne décrit pas le cas des double-sens, mais 
cycleway=shared_lane correspond bien à cycleway=opposite (inutile donc 
d'inventer un cycleway=opposite_shared_lne ;)  Je proposerais donc 
cycleway=opposite + cycleway:lane=pictogram


Bien qu'ayant traduit cette page je ne comprends pas vraiment la valeur 
cycleway:lane=advisory. Peut-être qu'un contributeur belge pourrait nous 
éclairer ?


Antoine.


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

[OSM-talk-fr] Doublons landuse=residential et place=town

[Phyks]

Bonjour,

Il y a un attribut "landuse=residential" à Montrouge sur le même
polygone que le "boundary=administrative" :
https://www.openstreetmap.org/relation/37026. En revanche, la ville en
elle-même est séparée, sur un nœud "place=town" :
https://www.openstreetmap.org/node/26692584.

Je suis tombé dessus en rapportant un bug sur le rendu
https://github.com/gravitystorm/openstreetmap-carto/issues/3664, qui
fait apparaître le nom "Montrouge" en plusieurs exemplaires sur la carte.

Le problème est que le "landuse=residential" correspond à toute
l'étendue de la ville de Montrouge et a un nom associé. Or, le rendu
osm.org affiche les noms des "landuse=residential" (pour afficher les
noms des résidences et aires d'accueil des gens du voyage par exemple).
Le nom sur ce landuse fait doublon avec celui sur le nœud place=town,
d'où le double affichage sur le fond de carte, à certains niveaux de
zooms uniquement.

J'ai l'impression que d'une part ce landuse est incorrect (toute la
ville n'est pas purement résidentielle, il y a des activités
commerciales ou industrielles par exemple) et d'autre part ce landuse ne
devrait probablement pas contenir de nom, qui est déjà sur le place=town.

Pourtant c'est fait de la même façon sur certaines villes alentour comme
Malakoff, Arcueil etc. Donc il y a probablement une justification et je
ne sais pas comment le corriger vraiment. En particulier, je ne sais pas
si le doublon de nom "Montrouge" entre le "boundary=administrative"
(https://www.openstreetmap.org/relation/37026) et le "place=town"
(https://www.openstreetmap.org/node/26692584) est normal ?

Je vois deux solutions pour l'instant :

1. La solution naïve : créer un polygone séparé qui recouvre la même
surface que https://www.openstreetmap.org/relation/37026 et ajouter le
"landuse=residential" dessus (pour séparer le "landuse=residential" du nom).
2. Faire une vraie correction, probablement en créant un multipolygone
exact pour le landuse=residential ?

Auriez-vous plus d'informations ou de conseils à ce sujet ?

Bonne journée,
-- 
Phyks

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