Re: [Talk-it] OpenMtbMap errore rendering pozzi privati \ drinking water

[Francesco Pelullo]

Il 04 mag 2016 22:47, "Federico Cortese"  ha scritto:
>
>
> A quelli che hai verificato mettici qualche tag aggiuntivo così non li
> cancelliamo :(
>
>

Direi di completare la cancellazione a tappeto, poi faremo casomai delle
verifiche sulla qualità dei dati in aree che conosciamo bene per tirare
fuori nuove regole di import applicabili a tutto il dataset, possibilmente
con tag aggiuntivi/più specifici/nuovi inventati ad hoc se possibile.

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

Re: [Talk-es] 10as Jornadas de SIG Libre y 2a Conferencia QGIS: Yaqueda menos!

[Jose Alberto Gonzalez von Schmeling]

Me parece fabuloso que suban algunos videos.
Muchas gracias
Saludos, jose

El 4 de mayo de 2016, 03:27, Lluís Vicens escribió:

> On 04/05/16 05:47, Jose Alberto Gonzalez von Schmeling wrote:
>
> Yo vivo en Paraguay, y me interesa mucho que haya streaming.
>
> Buenos días José Alberto,
>
> Por el momento, y lamentándolo  mucho, no está previsto programar un
> *streaming* por cuestiones de coste y logísticas. Lo que sí hacemos es grabar
> tantas sesiones como podamos y colgar los vídeos, posteriormente, en nuestro
> canal de Vimeo [1]. No están todas las charlas, pero si buena parte de
> ellas.
>
> Saludos,
> Lluís
>
> [1] http://bit.ly/24x7gDH
>
>
>
> El 3 de mayo de 2016, 04:10, pcvalverde escribió:
>
>> Me gustaría mucho ir pero son muchos los gastos estancia, comida,
>> entradas.
>>
>> ¿se verá por streaming?
>>
>> Saludos.
>>
>> Pepe
>>
>> - Original Message -
>> *From:* Jornadas de SIG Libre 
>> *To:* talk-es@openstreetmap.org
>> *Sent:* Thursday, April 28, 2016 3:54 PM
>> *Subject:* [Talk-es] 10as Jornadas de SIG Libre y 2a Conferencia QGIS:
>> Yaqueda menos!
>>
>> Saludos,
>>
>> Quedan menos de 30 días para la celebración de las 10as Jornadas de SIG Libre
>> y la 2a Conferencia Internacional de QGIS, patrocinadas por GeoCat [1] y
>> Boundless [2], y que tendrán lugar en Girona los próximos 24,25 y 26 de
>> Mayo [3]. Ven a celebrar con nosotros, nuestro décimo aniversario!
>>
>> En el sitio web del evento, encontrarás toda la información actualizada
>> con respecto al programa de ponencias plenarias [4], el programa de
>> presentaciones de las Jornadas de SIG Libre [5], el programa de Talleres
>> de las Jornadas de SIG Libre [6] así como los Workshops de QGIS [7], además
>> del programa de presentaciones de QGIS [8].
>>
>> Si aun no estás inscrito al evento, anímate y regístrate en alguna de
>> las modalidades (individual, profesional o empresa) que mejor se ajuste
>> a tus necesidades y posibilidades [9], y acude a las Jornadas de SIG
>> Libre y/o a la 2a Conferencia Internacional de QGIS. Será una ocasión
>> única para compartir conocimientos y experiencias.
>>
>> Ya por último, desde la organización del evento, no podemos dejar de
>> agradecer a Patrocinadores, Colaboradores y Medios asociados, así como a
>> asistentes y presentadores, el apoyo a las Jornadas de SIG y a la
>> Conferencia de QGIS, haciendo posible esta edición especial.
>>
>> Contamos con tu presencia en Girona, este próximo mes de Mayo.
>>
>>
>> --
>> *Local Organizing Committee*
>> 10as Jornadas de SIG Libre
>> 2nd International QGIS User and Developer Conference
>> -
>> Pl. Ferrater Mora 1
>> 17071 Girona
>> infojorna...@sigte.org
>>
>> Web site: http://www.sigte.udg.edu/jornadassiglibre/en/
>> Twitter: http://twitter.com/SIGLibreGirona
>>
>>
>> [1] https://www.geocat.net/
>> [2] http://boundlessgeo.com/
>> [3] 
>> http://www.sigte.udg.edu/jornadassiglibre/
>> [4] 
>> http://www.sigte.udg.edu/jornadassiglibre/ponentes/
>> [5]
>> http://www.sigte.udg.edu/jornadassiglibre/jornadas-sig-libre/programa/
>> [6]
>> 
>> http://www.sigte.udg.edu/jornadassiglibre/jornadas-sig-libre/talleres/
>> [7]
>> 
>> http://www.sigte.udg.edu/jornadassiglibre/international-qgis-user-and-developer-conference/workshops-qgis/
>> [8]
>> 
>> http://www.sigte.udg.edu/jornadassiglibre/international-qgis-user-and-developer-conference/conferencia-qgis/
>> [9] 
>> http://www.sigte.udg.edu/jornadassiglibre/inscripcion/
>>
>>
>>
>> --
>> ___
>> 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
>>
>>
>
>
> --
> Podes encontrarme o comunicarte conmigo en:
>
>- *Mi blog*: http://proyectosbeta.net/
>- *Facebook*:
>http://www.facebook.com/pages/Proyectos-Beta/113277785412256
>
>- *Twitter*: @proyectosbeta 
>
>
>
> ___
> Talk-es mailing 
> listTalk-es@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-es
>
>
>
> --
> *Lluís Vicens*
> Servei de Sistemes d'Informació Geogràfica
> -
> Universitat de Girona
> *SIGTE*
> -
> Pl. Ferrater Mora 1
> 17071 Girona
> Tel +34 972 418 039 (7025 intern)
> 

[Talk-br] limites administrativos

[Sérgio V .]

>Somos poucos e ainda há muito por fazer.
>Números de Abril de 2016 do Osmand Live:
>708 contributors in Brazil
>1382 contributors in Argentina
>Comparando esses números ao da população de cada país, não estamos bem na foto
>-- Helio Cesar Tomio / Mapeador Openstreetmap

Legal o Helio trazer estes dados.
Há 2 coisas importantes em questão, parece. Mas talvez não igualmente 
importantes.

-preocupação com o aperfeiçoamento dos dados no OSM: me parece que há boas 
discussões, de alto nível técnico, quanto ao aperfeiçoamento dos dados, e uma 
boa manutenção da qualidade dos dados; nisto parece que estamos bem;

-número, participação da comunidade: neste, como apontado, parece que temos 
ainda uma baixa taxa de mapeadores.

Estava lendo sobre isso num wiki (que parece que é o DWG que vem desenvolvendo, 
talvez os maiores guardiões da perfeição dos dados no OSM):  
http://wiki.openstreetmap.org/wiki/How_We_Map
(agora também em Pt-br: http://wiki.openstreetmap.org/wiki/Pt-br:How_We_Map).

Uma das coisas destacadas ali é:  "OpenStreetMap values community cohesion over 
data perfection."
Livremente traduzido: "O OSM valoriza em grau mais alto a coesão da comunidade 
do que a perfeição de dados".

Não significa que a que esteja abaixo deva ser descurada. Ambas as coisas são 
importantes.
Mas em se tratando de escala de valores, a ordem afeta o resultado.

Faz toda a diferença quando nos damos conta de qual, aparentemente, esteja 
sendo mais atendido e qual carece mais.
E parece que isso pode se manifestar em várias coisas. Desde o modo como 
eventualmente falamos com os demais frente a uma preocupação por um aspecto do 
projeto que deva ser aperfeiçoado, o contato com novos, a difusão, a instrução, 
etc. Enfim, valores da coesão da comunidade.
Atingindo o que vem primeiro em grau de importância, parece que o outro tende a 
ficar mais fácil de atingir também. Este é o sentido de uma escala de valores.
Parece que é assim que tende a funcionar.

- - - - - - - - - - - - - - - -

Sérgio / user:smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [talk-au] place by remoteness

[Ben Kelley]

Hi.

The remoteness doesn't need to change the definition of the place (e.g.
make a hamlet a town) but rather only change how it is rendered.

A very remote track might show, as might a remote hamlet.

I agree this might be difficult to implement in the renderer.

  - Ben.

-- 
Ben Kelley
ben.kel...@gmail.com
Sent from my Windows XP PC
On 5 May 2016 10:26, "Warin" <61sundow...@gmail.com> wrote:

> Remoteness .. nice!
> It is based on population density .. the same argument I make for lowering
> the population barriers for city/town/village for Australia. So, yes, I do
> like it.
> How far to take the 'remoteness' effect on the population barriers to?
> If the area has very little population then 1 person could be defined as a
> city? NO, certain things are expected in a city .. certainly more than 1
> person!
> So there are limits as to how far to go in this direction.
>
> Would need to revert to
> city>100,000>town>10,000>village>200>hamlet>100
> for 'Major cities' and 'Inner regional' areas -
> as judged by the 'remoteness' thing as I can see no reason not to use the
> world wide population points here as the population densities are similar?
> These areas are in close proximity and would be similar around the world
> so the chosen population points should be suitable.
>
> The 'Outer Regional' areas ... about half the population density so
> city>50,000>town>5,000>village>100>hamlet>50
>  The 'Remote' areas ... about half the population density so
> city>25,000>town>2,500>village>50>hamlet>25
> The 'Very Remote' areas ... about half the population density so
> city>12,500>town>2,500>village>50>hamlet>25
>
> Err Winton would be come a village .. Longreach becomes a town... would
> that be acceptable?
> I think that works for my perception of those places.
>
> It will add to the complexity but be justifiable technically. Is it worth
> the added complexity?
>
> On 4/05/2016 6:28 PM, Alex Sims wrote:
>
> I’ve had an involvement in this discussion in the past and wonder if a way
> forward might be to include an adjusting factor for remoteness.
>
> If you have a look at the map at
> http://www.abs.gov.au/websitedbs/d3310114.nsf/home/remoteness+structure
>
> which shows the Australian Remoteness Index this suggests that we could
> define town, hamlet, etc according to population but then adjust the
> population limits downward for remote areas.
>
> The other point I’d make (as I did some time ago) is that the labels are
> “British English” labels and form a hierarchy where the names make sense in
> the UK but shouldn’t be taken as a slight against any area. They are merely
> a series of words that define the level of population centre.
>
> Looking at
> http://wiki.openstreetmap.org/wiki/Key:place#Populated_settlements.2C_urban_and_rural
> this seems to support and adjustment based on remoteness in the Australian
> context.
>
> Alex
>
> On 4 May 2016, at 8:11 AM, Warin <61sundow...@gmail.com> wrote:
>
> On 4/05/2016 12:50 AM, Christopher Barham wrote:
>
>
> On 03 May 2016, at 14:22, Warin <61sundow...@gmail.com> wrote:
>
>
> 
>
> Why judge on the population?
>
> Larger populations get more services - Police, Medical, Education ... they go 
> hand in hand.
>
> Populations are usually stated - on the entry signs to towns, villages .. and 
> collected by the ABS. So verifiable and accessible.
>
> Yes they do change .. but not by vast amounts quickly.
>
> Usually the relationship between population centres remains fairly static .. 
> if one grows so do the surrounding ones.
>
> Much easier to quickly asses and correctly tag this way. So it satisfies the 
> KISS principle.
>
> 
>
> City is not just a function of population - It’s can also be a political
> appointment/status? - e.g. Charters Towers and Redcliffe are cities :
> https://en.wikipedia.org/wiki/List_of_cities_in_Australia
>
>
>
> Yes there is an 'official designation system' ... subject to political
> pressure and separate rules for each state.
> I think the best guide we have is the population, certainly I think it is
> much better than the officially given 'status'.
>
> --
> I did leave out of the original post that the ABS data may include more
> 'cities' with populations over 10,000 than the present OSM data base
> contains ... yet to sort that out.
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
>
>
> ___
> Talk-au mailing 
> listTalk-au@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-au
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] place by remoteness

[Warin]

Remoteness .. nice!
It is based on population density .. the same argument I make for 
lowering the population barriers for city/town/village for Australia. 
So, yes, I do like it.

How far to take the 'remoteness' effect on the population barriers to?
If the area has very little population then 1 person could be defined as 
a city? NO, certain things are expected in a city .. certainly more than 
1 person!

So there are limits as to how far to go in this direction.

Would need to revert to
city>100,000>town>10,000>village>200>hamlet>100
for 'Major cities' and 'Inner regional' areas -
as judged by the 'remoteness' thing as I can see no reason not to use 
the world wide population points here as the population densities are 
similar?
These areas are in close proximity and would be similar around the world 
so the chosen population points should be suitable.


The 'Outer Regional' areas ... about half the population density so
city>50,000>town>5,000>village>100>hamlet>50
 The 'Remote' areas ... about half the population density so
city>25,000>town>2,500>village>50>hamlet>25
The 'Very Remote' areas ... about half the population density so
city>12,500>town>2,500>village>50>hamlet>25

Err Winton would be come a village .. Longreach becomes a town... would 
that be acceptable?

I think that works for my perception of those places.

It will add to the complexity but be justifiable technically. Is it 
worth the added complexity?


On 4/05/2016 6:28 PM, Alex Sims wrote:
I’ve had an involvement in this discussion in the past and wonder if a 
way forward might be to include an adjusting factor for remoteness.


If you have a look at the map at 
http://www.abs.gov.au/websitedbs/d3310114.nsf/home/remoteness+structure


which shows the Australian Remoteness Index this suggests that we 
could define town, hamlet, etc according to population but then adjust 
the population limits downward for remote areas.


The other point I’d make (as I did some time ago) is that the labels 
are “British English” labels and form a hierarchy where the names make 
sense in the UK but shouldn’t be taken as a slight against any area. 
They are merely a series of words that define the level of population 
centre.


Looking at 
http://wiki.openstreetmap.org/wiki/Key:place#Populated_settlements.2C_urban_and_rural 
this seems to support and adjustment based on remoteness in the 
Australian context.


Alex

On 4 May 2016, at 8:11 AM, Warin <61sundow...@gmail.com 
> wrote:


On 4/05/2016 12:50 AM, Christopher Barham wrote:



On 03 May 2016, at 14:22, Warin <61sundow...@gmail.com> wrote:





Why judge on the population?
Larger populations get more services - Police, Medical, Education 
... they go hand in hand.
Populations are usually stated - on the entry signs to towns, 
villages .. and collected by the ABS. So verifiable and accessible.

Yes they do change .. but not by vast amounts quickly.
Usually the relationship between population centres remains fairly 
static .. if one grows so do the surrounding ones.
Much easier to quickly asses and correctly tag this way. So it 
satisfies the KISS principle.



City is not just a function of population - It’s can also be a 
political appointment/status? - e.g. Charters Towers and Redcliffe 
are cities : https://en.wikipedia.org/wiki/List_of_cities_in_Australia





Yes there is an 'official designation system' ... subject to 
political pressure and separate rules for each state.
I think the best guide we have is the population, certainly I think 
it is much better than the officially given 'status'.


--
I did leave out of the original post that the ABS data may include 
more 'cities' with populations over 10,000 than the present OSM data 
base contains ... yet to sort that out.



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




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



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

Re: [talk-au] place=? An oldie but no past conclusion.

[Simon Slater]

On Wed, 4 May 2016 05:58:27 PM Alex Sims wrote:
> The other point I’d make (as I did some time ago) is that the labels are
> “British English” labels and form a hierarchy where the names make sense in
> the UK but shouldn’t be taken as a slight against any area. They are merely
> a series of words that define the level of population centre. 

Looking at the end of this post: 
https://lists.openstreetmap.org/pipermail/talk-au/2008-December/001089.html
made me think of our own experience with small towns.

In 1988 we moved to Kerang, Vic which had a population of 5,500, 5 pubs, 1 
small supermarket, 1 large supermarket with bottleshop, 8 churches and little 
industry.  However, Kerang supported a regional farming population of 20,000.  
When we moved 50 miles up the road 10 years later, the population was 4,500.  
10 years later 1 pub burned down, 5 years later so did another.  Now the 
population is below 4000 I think, but the regional population serviced is 
still about the same and there is more industry in the town.

I assume computerization and mechanization means the increase in industry 
without population increase.  Also with amalgamation of farms, many houses are 
now available for those who work in town, so these would not be counted in the 
town stats.

My thought was to look at the amenities etc listed for a place within OSM 
itself for use as a guide to classification.  Would this be a purely subjective 
process ie looking at the map, or can this type of data be easily queried from 
the database for a more objective approach?

In the latter case, weights could be applied to different amenities, 
combination with other sources eg remoteness index, etc ...

The caveat here is that the more amenities mapped correlate with activity / 
interest in that location.
-- 
Regards
Simon Slater

Registered Linux User #463789
http://linuxcounter.net 


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

Re: [talk-au] place= rendering

[Warin]

On 5/05/2016 9:50 AM, Timothy Ney wrote:

Re: place=? An oldie but no past conclusion.

My other concern is the rendering of urban centres at certain zoom 
extents.  If for example, we demote all of the "towns" between 
Rockhampton and Mackay to Hamlets or Villages, we are going to have 
300 km of highway with nothing shown at higher levels.  At present, 
each of the small towns (may have 1 pub, some services, a shop and a 
few houses), are labelled as towns, and appear nicely if you zoom to a 
level where you can see Mackay and Rockhampton on the same map.  These 
"towns" indicate to drivers where they are likely to find at least 
some services easily.  It is difficult, unless you know the areas, to 
zoom in on a particular area to locate a "village" or "hamlet" on a 
300km piece of highway, where the "towns: are 30-40km apart. The same, 
is likely to happen between almost all "cities" in Queensland, e.g. 
Rockhampton - Emerald (300km) , Emerald to Longreach (500km) , Mackay 
to Bowen (200km), etc


I suspect, an extra tag would have to be added to ensure they render 
at higher zoom levels, which ultimately bring us back to simply 
calling them "towns".


This is a rendering issue.
The same issue exists for roads where none are shown when zoomed out.

It has been previously suggested that renders increase the amount of 
detail seen in those areas where little to nothing is shown.



My concern is that there is a clear inconsistency in the present 
tagging... example


Winton is tagged as more significant than Longreach .. where as 'on the 
ground' Longreach is more significant than Winton - more shops, pubs, 
doctors and yes more people!


I think the 'remoteness' may be the best way to resolve the issue for 
places.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Talk-au Digest, Vol 107, Issue 4

[Timothy Ney]

opulation, certainly I think it
> is much better than the officially given 'status'.
> >
> > --
> > I did leave out of the original post that the ABS data may include more
> 'cities' with populations over 10,000 than the present OSM data base
> contains ... yet to sort that out.
> >
> > ___
> > Talk-au mailing list
> > Talk-au@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-au
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.openstreetmap.org/pipermail/talk-au/attachments/20160504/cfd438de/attachment-0001.html
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
> --
>
> End of Talk-au Digest, Vol 107, Issue 4
> ***
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-ja] SotM Japan 2016ウェブサイト公開しました！

[Satoshi IIDA]

いいだ@SotM Japan実行委員帽子です。

8月6日開催予定のState of the Map Japan 2016ですが、
発表公募（Call for Proposals, CfP）を開始しました！

https://stateofthemap.jp/2016/#cfp
https://jp.surveymonkey.com/r/9QKHPWZ

発表時間は20分、
OSMに関係することで、あなたが思っていること、感じていること、
やってみたこと、やってみたいこと、この機会にお聞かせください！

締め切りは5月末日の予定です。

遠方から講演参加されるかた向けに、
交通費の支援制度もあります。

みなさまの参加をお待ちしております (/･ω･)/






2016年4月29日 0:33 Satoshi IIDA :

>
> いいだ＠SotM Japan実行委員帽子です。
>
> 前回の告知からちょっと時間がかかってしまいましたが、
> State of the Map Japan 2016のウェブページ、公開しました！
>
> https://stateofthemap.jp/2016/
>
> 近日中に、発表公募（Call for Proposals）のページと
> イベントへの申し込みページ（Peatix経由の予定）を作成します。
>
> また、当日（＆当日まで）のボランティアなども募集したいと考えています。
> こちらも随時情報を追加してゆきます。
>
> お楽しみに！ヽ( ´▽` )ﾉ
>
>
>
> --
> Satoshi IIDA
> mail: nyamp...@gmail.com
> twitter: @nyampire
>



-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-cl] Como etiquetar laboratorios clínicos

[Marco Antonio]

On 3 May 2016 21:34:29 GMT-04:00, "Cristián Serpell"  
wrote:
>Sobre lo de western, es ya algo aceptado?

No, se quedó en propuesta aunque en muchos lugares se los usa para clasificar 
mejor estos servicios.

Abrazos,

Marco Antonio
@51114u9

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

Re: [Talk-it] OpenMtbMap errore rendering pozzi privati \ drinking water

[Alberto Nogaro]

>-Original Message-
>From: Federico Cortese [mailto:cortese...@gmail.com]
>Sent: mercoledì 4 maggio 2016 21:51
>To: openstreetmap list - italiano 
>Subject: Re: [Talk-it] OpenMtbMap errore rendering pozzi privati \ drinking
>water
>
>Per cancellare i pozzi ho usato questa procedura:
>1) download mediante API Overpass user:corfedeimport and
>man_made=water_well;
>2) seleziono tutto;
>3) download parent ways/relations;
>4) seleziono con filtro man_made=water_well;
>5) elimino tutto e upload.
>
>Ora che ho aggiornato all'ultima versione JOSM (anche se non so se dipenda
>da questo) il punto 3 non funziona più. Cioè parte la ricerca delle parent ways
>e si conclude normalmente (anche se dura troppo
>poco) ma non ne viene scaricata nessuna.

Se non riesci con JOSM,  potresti scaricare le parent direttamente con 
Overpass, con qualcosa del tipo:

node[man_made=water_well](user:corfedeimport);
(._;<;);
(._;>;);
out meta;

Ciao,
Alberto


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

[Talk-br] limites administrativos

[Helio Cesar Tomio]

Ocorreram muitas opiniões e informações interessantes sobre o tema.
Particularmente sou contra a qualquer modificação enquanto o assunto não
estiver mais amadurecido entre a comunidade brasileira do OSM.
Há poucos debatedores e participantes, me parecendo que o assunto não é uma
prioridade na comunidade.
A idéia de uma wiki sobre este debate achei muito pertinente.

As informações de limites administrativos que realmente acho importantes
são os entes federativos: união, estados e municípios.
Se existem erros ou inadequações nas chaves destes elementos, acho
fundamental a discussão para corrigí-los.
No dia a dia, seja em correspondências postais ou cadastros on line na web,
são estes dados que fornecemos e que são de conhecimento comum a todos.
Demais níveis, inexistentes na Constituição, criados por orgãos
administrativos federais, estaduais e municipais, não reconheço-os como
essenciais ao OSM.

Embora vários dos colaboradores OSM atuem neste sentido, ainda sinto a
falta de sensibilização para conquistar novos mapeadores no OSM.
Somos poucos e ainda há muito por fazer.
Números de Abril de 2016 do Osmand Live:
708 contributors in Brazil
1382 contributors in Argentina
Comparando esses números ao da população de cada país, não estamos bem na
foto.
Tudo isso é apenas uma opinião, sujeita a muitas controvérsias... :)

-- 
Helio Cesar Tomio / Mapeador Openstreetmap
https://www.openstreetmap.org/user/Tomio
OpenStreetMap Brasil / Canal Youtube: https://goo.gl/FlX6al

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

Re: [Talk-it] OpenMtbMap errore rendering pozzi privati \ drinking water

[Federico Cortese]

2016-05-04 22:25 GMT+02:00 Francesco Pelullo :
>
> Il 04 mag 2016 21:51, "Federico Cortese"  ha scritto:
>>
>> Per cancellare i pozzi ho usato questa procedura:
>>
>
> Tra parentesi, ho fatto un controllo a campione e nella mia zona sono
> proprio pozzi a cielo aperto, non sono riuscito a trovare nemmeno un caso
> dubbio.
>
> Sembra incredibile che ne esistano tanti, ma a pensarci bene è verosimile.
>

A quelli che hai verificato mettici qualche tag aggiuntivo così non li
cancelliamo :(

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

Re: [OSM-talk] Gamification in Volunteered Geographic Information in regard with Contributors' Motivations

[Serge Wroclawski]

As someone who was a developer on a gamification of OSM data, I have
questions about this study...

What are the terms of the study results? Will they be released as Open
Science?

Thank you,

- Serge Wroclawski

On Wed, May 4, 2016 at 1:53 PM, Chen Chen  wrote:

> Hello,
>
>
>
> My name is Chen Chen and I am a Masters student working under the
> supervision of Dr. Peter Johnson in the Department of Geography and
> Environmental Management at the University of Waterloo. We are currently
> seeking volunteers from the OpenStreetMap (OSM) community to participate
> in a study that focuses on the impact of game elements on motivations to
> contribute to OSM. We would like to invite you to join our study.
>
> Participation in this study involves a web questionnaire, with a
> potential follow-up interview. The link to the web questionnaire is:
> https://www.surveymonkey.com/r/osmvgigamification. The questionnaire should
> take approximately 20 minutes of your time. This study has been reviewed
> and received ethics clearance through a University of Waterloo Research
> Ethics Committee.
>
>
>
> In appreciation of the time you have given to this study, you can enter
> your email address into a draw for a $50 Amazon Gift Card. Your odds of
> winning the prize is based on the number of individuals who participate in
> the study. The final decision about participation is yours.
>
>
>
> Sincerely,
>
>
>
> Chen Chen
>
>
>
> M.Sc. Geomatics
>
> Geospatial Innovation Laboratory
>
> Department of Geography and Environmental Management
>
> University of Waterloo
>
> c226c...@uwaterloo.ca
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] OpenMtbMap errore rendering pozzi privati \ drinking water

[Francesco Pelullo]

Il 04 mag 2016 21:51, "Federico Cortese"  ha scritto:
>
> Per cancellare i pozzi ho usato questa procedura:
>

Tra parentesi, ho fatto un controllo a campione e nella mia zona sono
proprio pozzi a cielo aperto, non sono riuscito a trovare nemmeno un caso
dubbio.

Sembra incredibile che ne esistano tanti, ma a pensarci bene è verosimile.

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

Re: [Talk-br] RES: Limite de cidades com distritos

[Papibaquígrafo]

Quanto à afirmação de estar "demonstrado que o Brasil é o único país no mundo 
que usa boundary=administrative para algo que foi criado com fins 
geográficos/estatísticos (não apareceu um contra-exemplo até o momento)":


O análogo das subdivisões do IBGE na Europa está explicado aqui: 
https://en.wikipedia.org/wiki/Nomenclature_of_Territorial_Units_for_Statistics. 
Algumas das subdivisões listadas ali são também político-administrativa, e 
outras são "puramente estatísticas"; de acordo com a wiki do OSM, muitas destas 
estão representadas como admin_level (Croácia 5, Eslovênia 5, Bulgaria 4, 
Hungria 5, etc). Por outro lado, Espanha e França não mapearam os seus 
respectivos níveis NUTS 1.


Fora da Europa, olhando rapidamente na wiki, eu encontrei os seguintes 
admin_levels claramente não-políticos:

Turquia 3
Austrália 8
Uganda 3


- Mensagem original -
De: Leonardo Brondani Schenkel 
Para: talk-br@openstreetmap.org
Enviadas: Quinta-feira, 28 de Abril de 2016 13:38
Assunto: Re: [Talk-br] RES: Limite de cidades com distritos

Tenho certeza que as pessoas já estão doentes de me ler aqui na lista,
então só pra avisar que vai ser a última vez que vou responder se for só
para repetir o que já foi dito sobre este assunto — isso não traz
nenhuma informação nova nem é produtivo.

Caso algo concreto e objetivo apareça, volto a me manifestar se necessário.

On 28/04/2016 18:01, Papibaquígrafo wrote:
> As regiões estatísticas do IBGE e os limites administrativos fazem parte
> de uma mesma hierarquia – regiões agregam estados, e estes se subdividem
> em mesoregiões, etc (as regiões metropolitanas são uma exceção aqui).
> Logo, me parece purismo separar as duas coisas só porque o nome da
> etiqueta não é 100% apropriado.

Pela mesma lógica as comarcas do judiciário deveriam estar no
admin_level também, pois as regiões agregam estados, os estados
comarcas, e as comarcas municípios... Há inúmeros outros exemplos de
hierarquia que se aplicam. (Se elas já não estão, seria ótimo ter as
comarcas do judiciário no OSM, por falar nisso.)

Sinceramente não entendo a resistência, pois já foi aqui:

- citada a definição de boundary=administrative e admin_level que está
bem explicada no wiki — que parte lá é ambígua?
- mostrado o uso que os outros países fazem desses tags na prática
- demonstrado que o Brasil é o único país no mundo que usa
boundary=administrative para algo que foi criado com fins
geográficos/estatísticos (não apareceu um contra-exemplo até o momento)
- foi citada a definição de próprios sites do governo dizendo que não
são administrativas
- foi citada uma pessoa que trabalha no IBGE dizendo que não são
administrativas
- foi citada a publicação oficial do IBGE que inventou as regiões
dizendo que não são administrativas
- demonstrado que o próprio mapa político oficial do IBGE não inclui
essa informação

O que mais se precisa em termos de coisas objetivas? Honestamente.

E isso que nem se quer apagar a informação (o que sim seria ridículo),
apenas mudar o boundary=administrative para outro valor mais apropriado.

> O fato é que as diferentes aplicações nunca vão funcionar bem sem
> "entender" o significado específico dos admin_level em cada país, e não
> vai ser essa mudança proposta (statistical_level=* ou similar) que vai
> resolver o problema.

Mas elas podem sim entender o que são limites administrativos e o que
não são. boundary=administrative e boundary!=administrative. Vai
funcionar em todos os países do mundo, menos hoje no Brasil.

> Veja o endereço absurdo que o Nominatim retorna nesta pesquisa
> (e isto que os distritos e subdistritos, se é que existem, não estão
> mapeados em Porto Alegre):
> 
> Paço Municipal, 10, Praça Montevidéu, Esplanada Municipal Célio
> Marques Fernandes, Historic District, Porto Alegre, Microregion of
> Porto Alegre, Metropolitan Region of Porto Alegre, Metropolitan
> Mesoregion of Porto Alegre, Rio Grande do Sul, South Region,
> 90010-170, Brazil
> 
> O endereço que qualquer um de nós (e também o carteiro) esperaria nesta
> busca seria simplesmente "Paço Municipal, Praça Montevidéu, 10,
> 90010-170, Porto Alegre, Brazil".

O objetivo da lista de resultados do Nominatim é de mostrar a hierarquia
administrativa para diminuir ambigüidade e permitir que a pessoa que
procurou poder melhor identificar o resultado que está procurando (que
outra hierarquia você sugere que ele deveria usar por default?), não
mostrar um endereço de correspondência — para isso existem os tags addr:*.

> Enfim: a funcionalidade "formatação de endereços" no Nominatim funciona
> mal, mas não porque a comunidade brasileira flexibilizou um pouco o
> significado de admin_level; funciona mal porque cada país tem a sua
> convenção e o Nominatim não leva isso em conta.

O Nominatim não formata endereços.

Sim, o Brasil "flexibilizou" — eufemismo para usar incorretamente.
Estamos aguardando os exemplos dos outros países que flexibilizaram de
mesma forma. Pode 

Re: [Talk-it] OpenMtbMap errore rendering pozzi privati \ drinking water

[Federico Cortese]

Per cancellare i pozzi ho usato questa procedura:
1) download mediante API Overpass user:corfedeimport and man_made=water_well;
2) seleziono tutto;
3) download parent ways/relations;
4) seleziono con filtro man_made=water_well;
5) elimino tutto e upload.

Ora che ho aggiornato all'ultima versione JOSM (anche se non so se
dipenda da questo) il punto 3 non funziona più. Cioè parte la ricerca
delle parent ways e si conclude normalmente (anche se dura troppo
poco) ma non ne viene scaricata nessuna.
Chiaramente se cancello i pozzi senza scaricare le parent ways,
succede che in fase di upload la procedura si blocca in continuazione
per la creazione di conflitti, che devono essere risolti uno ad uno
anche se la soluzione è sempre la stessa (resolve their version).
Sapete cosa possa inibire il "download parent versions"? Ho provato ad
eseguire il comando solo su una feature e funziona, ma se lo applico
in blocco no.
Grazie

Federico

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

Re: [Talk-it] Diminuzione Tag totali wikipedia

[Simone F.]

Il giorno 3 maggio 2016 21:47, Marco_T  ha scritto:

> Buonasera,
> il giorno 28/04 c'e' stata una diminuzione consistente dei tag

...

>  Si
> puo' ripristinare la situazione aggiornata?


Grazie.

Luca,
è possibile che si sia corrotto il file dell'Italia?
Prova ad eseguire una volta il programma sostituendo l'opzione -u
(--update_osm) con -d (--download_osm), in modo che venga riscaricato da
zero il pbf dell'Italia da Geofabrik.


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

Re: [Talk-es] Propuesta de cambios en la normalización para las vías interurbanas

[Santiago Higuera]

Hola:
Coincido con los que defienden que la etiqueta highway tiene un sentido
más funcional o administrativo. Creo que las características físicas
reales de las vías se deben especificar a través de etiquetas
adicionales.

Un saludo

Santiago Higuera

El mié, 04-05-2016 a las 18:13 +, Diego García escribió:
> Ahondando en lo mismo, y no queriendo ser repetitivo, hay dos puntos
> que menciona Alejandro que son claves, por eso me gustaría hacer
> hincapié:
> 
> - En primer lugar, no habría que revisar la normalización, sino cómo
> tenemos la vías en el mapa. Ahí sí hay mucha tela que cortar.
> - Y en segundo lugar, la propuesta supone dedicir el valor de highway
> según qué valores tengan el resto de etiquetas, lo que resulta en la
> duplicidad de información.
> 
> Un saludo,
> 
> Diego
> 
> El mié., 4 may. 2016 a las 20:03, Alejandro S. (<
> alejandro...@gmail.com>) escribió:
> > Buenas a todos,
> > 
> > En primer lugar, menuda currada Hector, pero coincido con Diego, no
> > creo que sea necesario revisar la normalización. Con tu propuesta
> > (highway en función de características de la vía) lo que se
> > conseguiría es tener duplicada esa información de las
> > características (maxspeed, smothness...), actualmente ya podemos
> > reflejar esa información y adicionalmente mediante el highway el
> > responsable de la vía (¿igual lo deberíamos poner como operator
> > también?). 
> > 
> > Si quisiéramos cambiar la normalización pienso que sería más
> > interesante hacerlo para que la etiqueta highway refleje la función
> > de la vía, Por ejemplo preguntándonos ¿Es la única vía que conecta
> > dos países? ¿Es la vía principal que conecta dos ciudades? ¿Es la
> > única vía que permite acceder a un pueblo?
> > 
> > Desde luego lo que hace falta es darle una revisión gorda a las
> > carreteras añadiendo toda esa información de las características.
> > Una tabla en el wiki con las carreteras por CCAA estaría guay tipo
> > [0] para saber el estado.
> > De hecho la página del wiki que te has currado puede servir en
> > "sentido contrario" para indicar que etiquetas podrían ser
> > interesantes para cada una de las vías.
> > 
> > Desde luego si el gps te lleva por una primary que cruza pueblos si
> > hay una secondary que va directa, la culpa es del gps por no tener
> > en cuenta las etiquetas de velocidad, etc (o nuestra si no están
> > los maxspeed...)
> > 
> > [0]: 
> > https://wiki.openstreetmap.org/wiki/WikiProject_Spain/Autopista
> > 
> > Saludos,
> >   Alejandro Suárez
> > 
> > 2016-05-04 18:47 GMT+02:00 David Marín Carreño :
> > > Hola a todos.
> > > 
> > > Mi granito de arena sobre esta cuestión.
> > > 
> > > Creo que el sistema actual de normalización está funcionando bien
> > > en general, y que el problema viene dado en aquellas comunidades
> > > autónomas en las que la administración ha hecho un uso alegre de
> > > sus potestades, y a una misma carretera (con la misma
> > > nomenclatura, me refiero) le ha dado diversos tratamientos según
> > > el tramo.
> > > 
> > > Sin embargo, en la mayoría de comunidades esto no se ha hecho
> > > así, y según el catálogo de carreteras de cada una de ellas se
> > > deja bien clara la categorización de cada carretera, a la que
> > > suelen corresponderse ciertas características físicas.
> > > 
> > > Dicho lo cual, propongo dejar el sistema como está y poner las
> > > excepciones pertinentes en las CC.AA. en las que existan los
> > > problemas que comentáis.
> > > 
> > > Un cordial saludo.
> > > --
> > > David Marín Carreño
> > > 
> > > El mié., 4 may. 2016 a las 18:14, Diego García (<
> > > dgerv...@gmail.com>) escribió:
> > > > Repasando todo un poco (aún no me he metido del todo "a
> > > > fondo"), hay cosas que no me convencen:
> > > > 
> > > > - La motorways: creo que tenemos todos claro lo que son en
> > > > España: autovías. Si alguna vía no tiene referencia A-XX ó AP
> > > > -XX (azul), pero tiene las características de una autovía,
> > > > debería mapearse igualmente como motorway. Doble sentido de
> > > > circulación, sin accesos a nivel ni a fincas, y máxima genérica
> > > > de 120.
> > > > 
> > > > - Las trunk: según la wiki, son las vías principales (que
> > > > vertebran grandes zonas con otras y entre sí) y que no son
> > > > autovías. En mi opinión, deberían ser todas las nacionales
> > > > (radiales o no), porque esa es precisamente su función. Tienen
> > > > salidas a nivel o excepcionalmente alguna que no, pero no es
> > > > obligado, y genérica de 100km/h. Si la función de vía principal
> > > > se ha perdido (porque hay una autovía que la suple, o porque
> > > > otra carretera la ha asumido), debería bajar a primary, aunque
> > > > tenga ref N-XX. 
> > > > 
> > > > No sigo con el resto de categorías, prefiero estudiar más a
> > > > fondo el resto de la propuesta. Estas dos son las que primero
> > > > he mirado de momento, y las que creo que más polémica
> > > > generarán. Y, por supuesto, en lo que estoy totalmente de
> > > > 

Re: [Talk-es] Propuesta de cambios en la normalización para las vías interurbanas

[Diego García]

Ahondando en lo mismo, y no queriendo ser repetitivo, hay dos puntos que
menciona Alejandro que son claves, por eso me gustaría hacer hincapié:

- En primer lugar, no habría que revisar la normalización, sino cómo
tenemos la vías en el mapa. Ahí sí hay mucha tela que cortar.
- Y en segundo lugar, la propuesta supone dedicir el valor de highway según
qué valores tengan el resto de etiquetas, lo que resulta en la duplicidad
de información.

Un saludo,

Diego

El mié., 4 may. 2016 a las 20:03, Alejandro S. ()
escribió:

> Buenas a todos,
>
> En primer lugar, menuda currada Hector, pero coincido con Diego, no creo
> que sea necesario revisar la normalización. Con tu propuesta (highway en
> función de características de la vía) lo que se conseguiría es tener
> duplicada esa información de las características (maxspeed, smothness...),
> actualmente ya podemos reflejar esa información y adicionalmente mediante
> el highway el responsable de la vía (¿igual lo deberíamos poner como
> operator también?).
>
> Si quisiéramos cambiar la normalización pienso que sería más interesante
> hacerlo para que la etiqueta highway refleje la función de la vía, Por
> ejemplo preguntándonos ¿Es la única vía que conecta dos países? ¿Es la vía
> principal que conecta dos ciudades? ¿Es la única vía que permite acceder a
> un pueblo?
>
> Desde luego lo que hace falta es darle una revisión gorda a las carreteras
> añadiendo toda esa información de las características. Una tabla en el wiki
> con las carreteras por CCAA estaría guay tipo [0] para saber el estado.
> De hecho la página del wiki que te has currado puede servir en "sentido
> contrario" para indicar que etiquetas podrían ser interesantes para cada
> una de las vías.
>
> Desde luego si el gps te lleva por una primary que cruza pueblos si hay
> una secondary que va directa, la culpa es del gps por no tener en cuenta
> las etiquetas de velocidad, etc (o nuestra si no están los maxspeed...)
>
> [0]: https://wiki.openstreetmap.org/wiki/WikiProject_Spain/Autopista
>
> Saludos,
>   Alejandro Suárez
>
> 2016-05-04 18:47 GMT+02:00 David Marín Carreño :
>
>> Hola a todos.
>>
>> Mi granito de arena sobre esta cuestión.
>>
>> Creo que el sistema actual de normalización está funcionando bien en
>> general, y que el problema viene dado en aquellas comunidades autónomas en
>> las que la administración ha hecho un uso alegre de sus potestades, y a una
>> misma carretera (con la misma nomenclatura, me refiero) le ha dado diversos
>> tratamientos según el tramo.
>>
>> Sin embargo, en la mayoría de comunidades esto no se ha hecho así, y
>> según el catálogo de carreteras de cada una de ellas se deja bien clara la
>> categorización de cada carretera, a la que suelen corresponderse ciertas
>> características físicas.
>>
>> Dicho lo cual, propongo dejar el sistema como está y poner las
>> excepciones pertinentes en las CC.AA. en las que existan los problemas que
>> comentáis.
>>
>> Un cordial saludo.
>> --
>> David Marín Carreño
>>
>> El mié., 4 may. 2016 a las 18:14, Diego García ()
>> escribió:
>>
>>> Repasando todo un poco (aún no me he metido del todo "a fondo"), hay
>>> cosas que no me convencen:
>>>
>>> - La motorways: creo que tenemos todos claro lo que son en España:
>>> autovías. Si alguna vía no tiene referencia A-XX ó AP-XX (azul), pero tiene
>>> las características de una autovía, debería mapearse igualmente como
>>> motorway. Doble sentido de circulación, sin accesos a nivel ni a fincas, y
>>> máxima genérica de 120.
>>>
>>> - Las trunk: según la wiki, son las vías principales (que vertebran
>>> grandes zonas con otras y entre sí) y que no son autovías. En mi opinión,
>>> deberían ser todas las nacionales (radiales o no), porque esa es
>>> precisamente su función. Tienen salidas a nivel o excepcionalmente alguna
>>> que no, pero no es obligado, y genérica de 100km/h. Si la función de vía
>>> principal se ha perdido (porque hay una autovía que la suple, o porque otra
>>> carretera la ha asumido), debería bajar a primary, aunque tenga ref N-XX.
>>>
>>> No sigo con el resto de categorías, prefiero estudiar más a fondo el
>>> resto de la propuesta. Estas dos son las que primero he mirado de momento,
>>> y las que creo que más polémica generarán. Y, por supuesto, en lo que estoy
>>> totalmente de acuerdo es en que habría que hacer una buena revisión de lo
>>> que tenemos en el mapa: hay muchas vías que no merecen la highway que
>>> tienen, y todos conocemos ejemplos de ello.
>>>
>>>
>>>
>>> Y lo que para mí es lo más importante de todo, y en lo que apoyo todo mi
>>> argumento: no trabajar (sólo) para el render. Me explico (y a ver si lo
>>> consigo...;) ): una normalización en la que la calidad de la vía se expresa
>>> en el key highway, sirve sólo para que se represente dicha calidad
>>> gráficamente en el mapa. Si utilizamos para ello el resto de claves (ancho
>>> de la via, número de carriles, velocidad de la vía, etc), 

Re: [Talk-us] Per-State relations for the Appalachian Trail

[OSM Volunteer stevea]

Kevin Kenny > writes:
> Breaking apart the AT into separate relations - ideally with a superrelation 
> joining them - would be sensible, I think, but be careful about the 
> assumption about state lines. The AT literally spends a good many miles with 
> the hiker having one foot in North Carolina and the other in Tennessee - the 
> ridge that it follows is the state line.

Yes, “break apart elements so they are in a single state” simply does not make 
logical sense here, so I believe that “logical senseless" alone is a good 
reason for not doing so — it would needlessly frustrate somebody to implement 
this.  There is likely very wide agreement here, but it bears repeating:  be 
sensible, but not slavish to an ideal where it doesn’t make sense to do so.

> We also, I think, need to put some more thought simply into the support of 
> large relations. I've recently found that even the New York Long Path (only a 
> fifth the length of the AT) crashes JOSM (I haven't yet diagnosed the 
> problem) and wound up editing in Meerkartor instead. Trails, highways, 
> rivers, railroads, we have a good many places where things reasonably and 
> predictably break down into thousands of parts over thousands of km, and I 
> don't think we yet have a unified theory of how to handle them.

It would be nice to “have a unified theory,” yes.  However, as this could be 
fraught with endless discussion of “should we here?” or “what’s the best method 
there?” I’d say letting common sense guide us is a very good place to start and 
use as an approach.  “Along state lines” certainly settles out of that nicely, 
and so it sounds like OSM in the USA both does already and can continue going 
forward like this.  When it doesn’t or something else DOES make sense 
(especially MORE sense) then, do that, instead.  Eventually, “more firm rules” 
might be established.  And as this continues to get discussed, there might even 
be some relief from tools (editors, the database itself) which are better 
written or can better accommodate larger relations, although I don't hold my 
breath about that.  Super-relations can help, but they are not always the 
answer, either, and some renderers or other data consumers don’t completely 
implement them as you might hope.  Sometimes technology “naturally” grows to 
accommodate “entire planet sized” data size problems, then again, sometimes 
very focussed, specific efforts are required to “fix” things.  Those seem like 
they will (and have) make themselves more obvious as we go along.

Cheers,
SteveA
California___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-es] Propuesta de cambios en la normalización para las vías interurbanas

[Alejandro S.]

Buenas a todos,

En primer lugar, menuda currada Hector, pero coincido con Diego, no creo
que sea necesario revisar la normalización. Con tu propuesta (highway en
función de características de la vía) lo que se conseguiría es tener
duplicada esa información de las características (maxspeed, smothness...),
actualmente ya podemos reflejar esa información y adicionalmente mediante
el highway el responsable de la vía (¿igual lo deberíamos poner como
operator también?).

Si quisiéramos cambiar la normalización pienso que sería más interesante
hacerlo para que la etiqueta highway refleje la función de la vía, Por
ejemplo preguntándonos ¿Es la única vía que conecta dos países? ¿Es la vía
principal que conecta dos ciudades? ¿Es la única vía que permite acceder a
un pueblo?

Desde luego lo que hace falta es darle una revisión gorda a las carreteras
añadiendo toda esa información de las características. Una tabla en el wiki
con las carreteras por CCAA estaría guay tipo [0] para saber el estado.
De hecho la página del wiki que te has currado puede servir en "sentido
contrario" para indicar que etiquetas podrían ser interesantes para cada
una de las vías.

Desde luego si el gps te lleva por una primary que cruza pueblos si hay una
secondary que va directa, la culpa es del gps por no tener en cuenta las
etiquetas de velocidad, etc (o nuestra si no están los maxspeed...)

[0]: https://wiki.openstreetmap.org/wiki/WikiProject_Spain/Autopista

Saludos,
  Alejandro Suárez

2016-05-04 18:47 GMT+02:00 David Marín Carreño :

> Hola a todos.
>
> Mi granito de arena sobre esta cuestión.
>
> Creo que el sistema actual de normalización está funcionando bien en
> general, y que el problema viene dado en aquellas comunidades autónomas en
> las que la administración ha hecho un uso alegre de sus potestades, y a una
> misma carretera (con la misma nomenclatura, me refiero) le ha dado diversos
> tratamientos según el tramo.
>
> Sin embargo, en la mayoría de comunidades esto no se ha hecho así, y según
> el catálogo de carreteras de cada una de ellas se deja bien clara la
> categorización de cada carretera, a la que suelen corresponderse ciertas
> características físicas.
>
> Dicho lo cual, propongo dejar el sistema como está y poner las excepciones
> pertinentes en las CC.AA. en las que existan los problemas que comentáis.
>
> Un cordial saludo.
> --
> David Marín Carreño
>
> El mié., 4 may. 2016 a las 18:14, Diego García ()
> escribió:
>
>> Repasando todo un poco (aún no me he metido del todo "a fondo"), hay
>> cosas que no me convencen:
>>
>> - La motorways: creo que tenemos todos claro lo que son en España:
>> autovías. Si alguna vía no tiene referencia A-XX ó AP-XX (azul), pero tiene
>> las características de una autovía, debería mapearse igualmente como
>> motorway. Doble sentido de circulación, sin accesos a nivel ni a fincas, y
>> máxima genérica de 120.
>>
>> - Las trunk: según la wiki, son las vías principales (que vertebran
>> grandes zonas con otras y entre sí) y que no son autovías. En mi opinión,
>> deberían ser todas las nacionales (radiales o no), porque esa es
>> precisamente su función. Tienen salidas a nivel o excepcionalmente alguna
>> que no, pero no es obligado, y genérica de 100km/h. Si la función de vía
>> principal se ha perdido (porque hay una autovía que la suple, o porque otra
>> carretera la ha asumido), debería bajar a primary, aunque tenga ref N-XX.
>>
>> No sigo con el resto de categorías, prefiero estudiar más a fondo el
>> resto de la propuesta. Estas dos son las que primero he mirado de momento,
>> y las que creo que más polémica generarán. Y, por supuesto, en lo que estoy
>> totalmente de acuerdo es en que habría que hacer una buena revisión de lo
>> que tenemos en el mapa: hay muchas vías que no merecen la highway que
>> tienen, y todos conocemos ejemplos de ello.
>>
>>
>>
>> Y lo que para mí es lo más importante de todo, y en lo que apoyo todo mi
>> argumento: no trabajar (sólo) para el render. Me explico (y a ver si lo
>> consigo...;) ): una normalización en la que la calidad de la vía se expresa
>> en el key highway, sirve sólo para que se represente dicha calidad
>> gráficamente en el mapa. Si utilizamos para ello el resto de claves (ancho
>> de la via, número de carriles, velocidad de la vía, etc), estas
>> características no aparecerán en el mapnik, pero serán mucho más reales que
>> una sola clave (el tipo de vía). Es decir, si queremos un mapa que nos
>> visualice lo mal (o lo bien) que tenemos las carreteras en España,
>> tendremos que hacer un render que tenga en cuenta dichas etiquetas, y no la
>> etiqueta highway. Es más, en caso de no existir (ya me pierdo con tanta
>> etiqueta), habría que contemplar claves tales como arcén, estado del firme
>> o señalización horizontal. Eso nos daría una flexibilidad completa a la
>> hora de mapear, sean vías completas o tramos de ella, para cualquier tamaño
>> de dicho tramo.
>>
>> Resumiendo: cuando el gps (o 

[OSM-talk] Gamification in Volunteered Geographic Information in regard with Contributors' Motivations

[Chen Chen]

Hello,

 

My name is Chen Chen and I am a Masters student working under the
supervision of Dr. Peter Johnson in the Department of Geography and
Environmental Management at the University of Waterloo. We are currently
seeking volunteers from the OpenStreetMap (OSM) community to participate in
a study that focuses on the impact of game elements on motivations to
contribute to OSM. We would like to invite you to join our study.  

Participation in this study involves a web questionnaire, with a potential
follow-up interview. The link to the web questionnaire is:
https://www.surveymonkey.com/r/osmvgigamification. The questionnaire should
take approximately 20 minutes of your time. This study has been reviewed and
received ethics clearance through a University of Waterloo Research Ethics
Committee.

 

In appreciation of the time you have given to this study, you can enter your
email address into a draw for a $50 Amazon Gift Card. Your odds of winning
the prize is based on the number of individuals who participate in the
study. The final decision about participation is yours.

 

Sincerely,

 

Chen Chen

 

M.Sc. Geomatics

Geospatial Innovation Laboratory

Department of Geography and Environmental Management

University of Waterloo

c226c...@uwaterloo.ca  

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

Re: [Talk-dk] Sammendrag af Talk-dk, Vol 83, Udgave 1

[Martin Hvidberg]

Jeg må give Asger ret. “Styrelsen tidligere kendt som Geodatastyrelsen”
er et formidabelt godt forslag :-)

/Martin (SDFE-ansat)

On 2016-05-04 13:50, talk-dk-requ...@openstreetmap.org wrote:

> Fra: Kurt Forbech Toft [mailto:k...@sdfe.dk]
> Sendt: 4. maj 2016 12:31
> Til: OpenStreetMap Denmark
> Emne: Re: [Talk-dk] Hvad hedder Geodatastyrelsen?
> 
> Hej Asger
> 
> Den officielle forkortelse er SDFE
> 
> Venlig Hilsen
> Kurt Toft
> 

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

Re: [Talk-gb-westmidlands] [OSM-talk-ie] Registration is Now Open for State of the Map!

[Rob Nickerson]

Mark,

Price came up on talk-ie and I responded there. I've copied the reply
below.

The scholarship fund is open to applicants until the 21 May. Feel free to
use it as that is what it's their for. Applicants will be judged by a team
based on the answers provided (questions focus on topics such as commitment
to OSM).

See recent post on blog.OpenStreetMap.org

Best,
Rob

--
Martín,

Thanks for the feedback.

We do a lot to try to keep costs down but we can always do more. The main
way we can get costs down is through sponsorship and, if you have any
ideas, we'd welcome your support. We can also scale back our scholarship
programme but we hope that at 2-4% of attendees we have struck a good
balance.

In terms of current situation:

1. We have a scholarship fund in place to help with costs. Feel free to
apply to that.

2. At 75 EUR tickets are sold at a loss compared to variable costs alone.
When you add in fixed costs the loss per ticket is much bigger. We can do
this because of sponsorship.

3. Our price is in line with SotM 2013 and 5 EUR less than SotM US 2015.

4. The hotel deal is available to try to keep accommodation costs down.

5. We welcome anyone with contacts to airlines to come forward but can't
arrange any deals with them as is.

Once again sorry that we can't get to the price level you want. Please
apply to the scholarship fund and send in sponsorship leads.

Thanks,
Rob
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz

[Tom Ka]

Dne 4. května 2016 10:02 Hynek Řehoř  napsal(a):
> jak často se "párují" fotky nahrané přes http://map.openstreetmap.cz/work2/
> s rozcestníky? O víkendu jsem nafotil 3 rozcestníky v Jindřichovicích pod
> Smrkem, v pondělí uploadoval ,a stále se zobrazují jako bez ref a fota.
> Fotky jsou v pořádku nahraná, kontroloval jsem.

Aktualizuje se kazde 2 hodiny. Pokud se pak dane rozcestniky
nezparovali s fotkama, tak jsou zrejme dal nez 20m od bodu v OSM. Lze
zkontrolovat na http://osm.fit.vutbr.cz/OsmHiCheck/gp/?cache. Kontrola
sama o sobe nic nedoplnuje do OSM, takze dodelani ref a pripadnych
dalsich tagu uz musi nekdo provest - v tabulce jsou to cervene radky.

Bye

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

Re: [OSM-talk-fr] Base OSM en lecture seule

[Stéphane Péneau]

Pareil, du coup je me suis retrouvé avec 3 ou 4 instances de Josm en 
parallèle  :-)


Stf

Le 04/05/2016 à 18:14, Nicolas Moyroud a écrit :

Raaah pile au mauvais moment comme toujours ! :-)
Bon allez copie du fichier osm et envoi en arrivant à la maison d'ici 
30 minutes ça devrait le faire.


Nico

Le 04/05/2016 17:54, Vincent de Château-Thierry a écrit :
La base est actuellement en lecture seule, plus d'édition possible, 
retour escompté à la normale vers 18:15.


cf. https://lists.openstreetmap.org/pipermail/dev/2016-May/029225.html

vincent




___
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-GB] Geolocation on OSM website in Chrome

[Paul Berry]

I wonder if anyone else has noticed this message when they click the "Show
My Location" button in OSM (the arrrow icon) in Chrome:


> *www.openstreetmap.org  says:Geolocation
> error. Only secure origins are allowed (see: https://goo.gl/Y0ZkNV
> ).*


For info, this is the referred page:
https://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features

The solution to enable the location finder again is to load OSM securely,
ie https://www.openstreetmap.org

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

Re: [Talk-es] Propuesta de cambios en la normalización para las vías interurbanas

[David Marín Carreño]

Hola a todos.

Mi granito de arena sobre esta cuestión.

Creo que el sistema actual de normalización está funcionando bien en
general, y que el problema viene dado en aquellas comunidades autónomas en
las que la administración ha hecho un uso alegre de sus potestades, y a una
misma carretera (con la misma nomenclatura, me refiero) le ha dado diversos
tratamientos según el tramo.

Sin embargo, en la mayoría de comunidades esto no se ha hecho así, y según
el catálogo de carreteras de cada una de ellas se deja bien clara la
categorización de cada carretera, a la que suelen corresponderse ciertas
características físicas.

Dicho lo cual, propongo dejar el sistema como está y poner las excepciones
pertinentes en las CC.AA. en las que existan los problemas que comentáis.

Un cordial saludo.
--
David Marín Carreño

El mié., 4 may. 2016 a las 18:14, Diego García ()
escribió:

> Repasando todo un poco (aún no me he metido del todo "a fondo"), hay cosas
> que no me convencen:
>
> - La motorways: creo que tenemos todos claro lo que son en España:
> autovías. Si alguna vía no tiene referencia A-XX ó AP-XX (azul), pero tiene
> las características de una autovía, debería mapearse igualmente como
> motorway. Doble sentido de circulación, sin accesos a nivel ni a fincas, y
> máxima genérica de 120.
>
> - Las trunk: según la wiki, son las vías principales (que vertebran
> grandes zonas con otras y entre sí) y que no son autovías. En mi opinión,
> deberían ser todas las nacionales (radiales o no), porque esa es
> precisamente su función. Tienen salidas a nivel o excepcionalmente alguna
> que no, pero no es obligado, y genérica de 100km/h. Si la función de vía
> principal se ha perdido (porque hay una autovía que la suple, o porque otra
> carretera la ha asumido), debería bajar a primary, aunque tenga ref N-XX.
>
> No sigo con el resto de categorías, prefiero estudiar más a fondo el resto
> de la propuesta. Estas dos son las que primero he mirado de momento, y las
> que creo que más polémica generarán. Y, por supuesto, en lo que estoy
> totalmente de acuerdo es en que habría que hacer una buena revisión de lo
> que tenemos en el mapa: hay muchas vías que no merecen la highway que
> tienen, y todos conocemos ejemplos de ello.
>
>
>
> Y lo que para mí es lo más importante de todo, y en lo que apoyo todo mi
> argumento: no trabajar (sólo) para el render. Me explico (y a ver si lo
> consigo...;) ): una normalización en la que la calidad de la vía se expresa
> en el key highway, sirve sólo para que se represente dicha calidad
> gráficamente en el mapa. Si utilizamos para ello el resto de claves (ancho
> de la via, número de carriles, velocidad de la vía, etc), estas
> características no aparecerán en el mapnik, pero serán mucho más reales que
> una sola clave (el tipo de vía). Es decir, si queremos un mapa que nos
> visualice lo mal (o lo bien) que tenemos las carreteras en España,
> tendremos que hacer un render que tenga en cuenta dichas etiquetas, y no la
> etiqueta highway. Es más, en caso de no existir (ya me pierdo con tanta
> etiqueta), habría que contemplar claves tales como arcén, estado del firme
> o señalización horizontal. Eso nos daría una flexibilidad completa a la
> hora de mapear, sean vías completas o tramos de ella, para cualquier tamaño
> de dicho tramo.
>
> Resumiendo: cuando el gps (o nosotros mismos) nos conduce por una vía no
> debe fijarse en la clave highway para tomar decisiones (porque dicha clave
> expresa función, no calidad), sino en claves tangibles, como el ancho de
> vía, su velocidad, etc.
>
>
>
> Un cordial saludo,
>
> Diego.
>
>
>
> El lun., 2 may. 2016 a las 19:42, Manuel Lladosa ()
> escribió:
>
>> Me parece una iniciativa genial, porque la verdad que habían carreteras
>> "Trunk" en un estado bastante lamentable.
>>
>> En general lo veo todo bien, pero tengo una pregunta, con "enlaces a
>> distinto/mismo nivel", ¿te refieres a cruces a distinto/mismo nivel? Así
>> lo he entendido yo, pienso que la gente entenderá mejor la palabra
>> cruces, por lo menos a mí la palabra enlace me sugiere incorporación a
>> autovía.
>>
>> Un saludo.
>>
>> El 02/05/16 a les 14:00, talk-es-requ...@openstreetmap.org ha escrit:
>> > Después de un proceso de debate con parte de la comunidad OSM de España
>> > vía Telegram y de la necesidad de reformulación de la Normalización de
>> vías
>> > interurbanas os presento como quedaría en la wiki. Es un apartado de la
>> > wiki que además de expresar las diversas categorías de la normalización
>> > basada más en ser física que administrativa también tiene en cuenta las
>> > diversas planificaciones de las administraciones que tienen
>> competencias en
>> > carreteras, desde gobiernos autonómicos a consejos insulares, algunas
>> vías
>> > de los cuales son modernas y por lo tanto pueden cumplir con categorías
>> > físicas más importantes que las que les da una clasificación
>> administrativa.
>> >   El texto está abierto a debate, 

Re: [Talk-gb-westmidlands] [OSM-talk-ie] Registration is Now Open for State of the Map!

[Mark Croft Redditch Linux Mint]

i did not know it was common for OSS/linux/opensource/etc style
projects to charge there volunteers to attend , wish i was rich
computer programmer with lots of free time to kill at these events but
i am not , i am the complete opposition being disabled and unable to
find any neche in the computer world anymore , i found work very hard
when i was a computer programmer starting out and was only in work for
4 years and the company had a restructing. I lost my job and never
found another one been unemployed for 22 years now. I do not have a
degree and did try to get a computer programming degree but cos i was
too bad customer for the banks i could not pay for student halls (i
never paid for accomodation in the end at univeristy of humberside n
licoln at the hull campus) it was a nightmare. I did get a little bit
of support from disabled student suppport services got diagnose with
dyselixa and got a special stamp that i used on my assignments which
really meant that the lectureers just gave me a pass mark on most of
them some of thut programming stuff i was getting merits on.  I found
the degree pretty lame really and a lot of very dishearted lectureers
that where being overworked and stretched across a number of different
campuses.
The maths lecture just told me to copy somebody elses work cos he did
not have time to explain it too me.

so in the end i never went back after the first year and a few grand
in debt to the student loan company i guess they will never get it
back.

very bored mark in  redditch

On 3 May 2016 at 18:08, Martín Ferrari  wrote:
> On 02/05/16 21:56, Rob Nickerson wrote:
>> Hi all,
>>
>> Tickets for State of the Map 2016 are now on sale. Get yours before the
>> price goes up (to EUR 100)!
>
> Sadly, this cost is too high to justify attending. I care about OSM, and
> I have been a silent contributor for years, but spending on plane
> tickets, acommodation, and on top of that 75-100 EUR to attend the
> conference, is just too much money for this little hobby of mine.
>
> I think it is a sad state when most libre projects I care about charge
> its own volunteers to gather and improve the community, specially when
> corporate sponsors could be offsetting this cost. OSM is far from the
> only one, I am just writing this because I am getting increasingly
> annoyed by the situation.
>
> --
> Martín Ferrari (Tincho)
>
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

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

Re: [OSM-talk-fr] Base OSM en lecture seule

[Christian Quest]

Revenue en read-wrtie il y a quelques minutes ;)

Le 4 mai 2016 à 18:14, Nicolas Moyroud  a écrit :

> Raaah pile au mauvais moment comme toujours ! :-)
> Bon allez copie du fichier osm et envoi en arrivant à la maison d'ici 30
> minutes ça devrait le faire.
>
> Nico
>
>
> Le 04/05/2016 17:54, Vincent de Château-Thierry a écrit :
>
>> La base est actuellement en lecture seule, plus d'édition possible,
>> retour escompté à la normale vers 18:15.
>>
>> cf. https://lists.openstreetmap.org/pipermail/dev/2016-May/029225.html
>>
>> vincent
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk] API read-only for next 45mins

[Grant Slater]

Hi All,

The mapping API is now back to normal. Happy mapping all.

Kind regards,

Grant


On 4 May 2016 at 16:33, Grant Slater  wrote:
> Hi All,
>
> Sorry for the extremely short notice...
>
> The OpenStreetMap map API will be read-only for the next 45mins.
> Any unsaved changes can be saved at the end of the of the 45mins
> maintenance window.
>
> Maintenance will end at: 4:15pm GMT / UTC on 4th May 2016.
>
> Please see https://twitter.com/OSM_Tech for updates.
>
> Kind regards,
>
> Grant

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

Re: [Talk-es] Propuesta de cambios en la normalización para las vías interurbanas

[Diego García]

Repasando todo un poco (aún no me he metido del todo "a fondo"), hay cosas
que no me convencen:

- La motorways: creo que tenemos todos claro lo que son en España:
autovías. Si alguna vía no tiene referencia A-XX ó AP-XX (azul), pero tiene
las características de una autovía, debería mapearse igualmente como
motorway. Doble sentido de circulación, sin accesos a nivel ni a fincas, y
máxima genérica de 120.

- Las trunk: según la wiki, son las vías principales (que vertebran grandes
zonas con otras y entre sí) y que no son autovías. En mi opinión, deberían
ser todas las nacionales (radiales o no), porque esa es precisamente su
función. Tienen salidas a nivel o excepcionalmente alguna que no, pero no
es obligado, y genérica de 100km/h. Si la función de vía principal se ha
perdido (porque hay una autovía que la suple, o porque otra carretera la ha
asumido), debería bajar a primary, aunque tenga ref N-XX.

No sigo con el resto de categorías, prefiero estudiar más a fondo el resto
de la propuesta. Estas dos son las que primero he mirado de momento, y las
que creo que más polémica generarán. Y, por supuesto, en lo que estoy
totalmente de acuerdo es en que habría que hacer una buena revisión de lo
que tenemos en el mapa: hay muchas vías que no merecen la highway que
tienen, y todos conocemos ejemplos de ello.



Y lo que para mí es lo más importante de todo, y en lo que apoyo todo mi
argumento: no trabajar (sólo) para el render. Me explico (y a ver si lo
consigo...;) ): una normalización en la que la calidad de la vía se expresa
en el key highway, sirve sólo para que se represente dicha calidad
gráficamente en el mapa. Si utilizamos para ello el resto de claves (ancho
de la via, número de carriles, velocidad de la vía, etc), estas
características no aparecerán en el mapnik, pero serán mucho más reales que
una sola clave (el tipo de vía). Es decir, si queremos un mapa que nos
visualice lo mal (o lo bien) que tenemos las carreteras en España,
tendremos que hacer un render que tenga en cuenta dichas etiquetas, y no la
etiqueta highway. Es más, en caso de no existir (ya me pierdo con tanta
etiqueta), habría que contemplar claves tales como arcén, estado del firme
o señalización horizontal. Eso nos daría una flexibilidad completa a la
hora de mapear, sean vías completas o tramos de ella, para cualquier tamaño
de dicho tramo.

Resumiendo: cuando el gps (o nosotros mismos) nos conduce por una vía no
debe fijarse en la clave highway para tomar decisiones (porque dicha clave
expresa función, no calidad), sino en claves tangibles, como el ancho de
vía, su velocidad, etc.



Un cordial saludo,

Diego.


El lun., 2 may. 2016 a las 19:42, Manuel Lladosa ()
escribió:

> Me parece una iniciativa genial, porque la verdad que habían carreteras
> "Trunk" en un estado bastante lamentable.
>
> En general lo veo todo bien, pero tengo una pregunta, con "enlaces a
> distinto/mismo nivel", ¿te refieres a cruces a distinto/mismo nivel? Así
> lo he entendido yo, pienso que la gente entenderá mejor la palabra
> cruces, por lo menos a mí la palabra enlace me sugiere incorporación a
> autovía.
>
> Un saludo.
>
> El 02/05/16 a les 14:00, talk-es-requ...@openstreetmap.org ha escrit:
> > Después de un proceso de debate con parte de la comunidad OSM de España
> > vía Telegram y de la necesidad de reformulación de la Normalización de
> vías
> > interurbanas os presento como quedaría en la wiki. Es un apartado de la
> > wiki que además de expresar las diversas categorías de la normalización
> > basada más en ser física que administrativa también tiene en cuenta las
> > diversas planificaciones de las administraciones que tienen competencias
> en
> > carreteras, desde gobiernos autonómicos a consejos insulares, algunas
> vías
> > de los cuales son modernas y por lo tanto pueden cumplir con categorías
> > físicas más importantes que las que les da una clasificación
> administrativa.
> >   El texto está abierto a debate, es inclusivo y requerirá de la
> > participación activa de la comunnidad ya que se se tienen en cuenta casos
> > específicos para determinados lugares con determinados usos (a más uso
> más
> > importancia ergo más categoría). Esperemos que esta nueva normalización
> > haga que nuestros mapas sean más reales y más útiles si cabe.
> >
> >   La dirección para consultarla es
> > http://wiki.openstreetmap.org/wiki/User:Yopaseopor y en un futuro
> ocupará
> > el apartado de vías interubanas y de comunidades autónomas de
> > http://wiki.openstreetmap.org/wiki/Normalizaci%C3%B3n
> >
> >   ¿Qué opinais? ¿Cómo lo veis? ¿Qué mejoraríais?
> >   Salud y Normalización
> >   Yopaseopor
> >
>
>
> ___
> 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] Base OSM en lecture seule

[Nicolas Moyroud]

Raaah pile au mauvais moment comme toujours ! :-)
Bon allez copie du fichier osm et envoi en arrivant à la maison d'ici 30 
minutes ça devrait le faire.


Nico

Le 04/05/2016 17:54, Vincent de Château-Thierry a écrit :

La base est actuellement en lecture seule, plus d'édition possible, retour 
escompté à la normale vers 18:15.

cf. https://lists.openstreetmap.org/pipermail/dev/2016-May/029225.html

vincent




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

Re: [OSM-talk-fr] Base OSM en lecture seule

[Philippe Verdy]

Celui-là n'était pas annoncé, notez qu'il y a aussi une maintenance prévue
les 9 et 10 mai.

2016-05-04 17:54 GMT+02:00 Vincent de Château-Thierry :

> La base est actuellement en lecture seule, plus d'édition possible, retour
> escompté à la normale vers 18:15.
>
> cf. https://lists.openstreetmap.org/pipermail/dev/2016-May/029225.html
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Base OSM en lecture seule

[Vincent de Château-Thierry]

La base est actuellement en lecture seule, plus d'édition possible, retour 
escompté à la normale vers 18:15.

cf. https://lists.openstreetmap.org/pipermail/dev/2016-May/029225.html

vincent

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

[OSM-talk] API read-only for next 45mins

[Grant Slater]

Hi All,

Sorry for the extremely short notice...

The OpenStreetMap map API will be read-only for the next 45mins.
Any unsaved changes can be saved at the end of the of the 45mins
maintenance window.

Maintenance will end at: 4:15pm GMT / UTC on 4th May 2016.

Please see https://twitter.com/OSM_Tech for updates.

Kind regards,

Grant

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

Re: [OSM-talk-be] Fwd: Interview pour le journal L'Avenir

[Julien Fastré]

FYI :

http://www.lavenir.net/cnt/dmf20160501_00820099/cartographier-le-globe-depuis-son-ecran
http://www.lavenir.net/cnt/dmf20160501_00820100/une-sorte-d-economie-collaborative

I do not have any access, so if someone could send me a copy of this
article (not on this mailing-list because of copyright...)

There are also other older articles about openstreetmap :

http://www.lavenir.net/Search/Index.aspx?searchString=openstreetmap=1=1

Julien

Le 27/04/16 19:45, Julien Fastré a écrit :
> Thanks, Marc.
>
> If someone else is interested in having such "jobs", I would be happy
> not to be the only French speaker to speak about OSM.
>
> Julien
>
> Le 27/04/16 08:01, Marc Gemis a écrit :
>> Thanks Julien, I was already hoping you would do it.
>>
>> On Tue, Apr 26, 2016 at 11:12 PM, Julien Fastré  wrote:
>>> FYI, she has heard about OSM for the first time after our mapathon of
>>> 16th April.
>>>
>>> Julien
>>>
>>> Le 26/04/16 23:11, Julien Fastré a écrit :
 Hi,

 I have been waiting a couple of hours before contacting her, in the hope
 that someone else would be interested... But when I phoned her this
 afternoon, no one had phoned her...

 So, I have an appointment for a demo on Thursday morning at the
 Coworking Namur. If someone else want to join us. It should last 30
 minutes or so.

 Julien

 Le 25/04/16 16:40, Johan Huysmans a écrit :
> FYI
>
>
>  Forwarded Message 
> Subject: Interview pour le journal L'Avenir
> Date:Mon, 25 Apr 2016 16:18:16 +0200
> From:Marie-Laure Mathot 
> To:  talk-be-ow...@openstreetmap.org 
>
>
>
> Bonjour,
>
>
>
> Je suis journaliste pour le quotidien L'Avenir. Je souhaite écrire un
> article à propos d'OpenStreetMap en Belgique, serait-il possible
> d'interviewer un membre de votre groupe de travail?
>
>
>
> Merci d'avance pour votre réponse.
>
>
>
> Bien à vous,
>
>
>
> Marie-Laure Mathot
>
> Journaliste à l'Avenir
>
> 081 24 89 36
>
> 
>
>
>
> To whom it may concern
>
>
>
> I am journalist for the newspaper L'avenir. I would like to write an
> article about OpenStreetMap in Belgium. Is it possible to interview a
> member of tour working group?
>
>
>
> Thank you for your answer.
>
>
>
> Yours sincerely,
>
>
>
> Marie-Laure Mathot
>
> Journaliste à l'Avenir
>
> 081 24 89 36
>
>
>
>
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>>>
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be



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

[Talk-us] iD news: v1.9.4 released

[Bryan Housel]

iD v1.9.4 was released May 3 2016 and is now available for editing on 
openstreetmap.org 

The release includes:
- Fix bug causing the Save button to remain disabled even when changeset 
comment entered
- Support setting imagery offset via url parameter
- New multiple selection field type (built by Kushan Joshi), used for tagging:
   - `payment:*`  (supported on Vending Machine presets)
   - `currency:*`  (supported on Vending Machine, Money Exchange, ATM presets)
   - `fuel:*`  (supported on Gas Station, Marine Fuel Station presets)
   - `recycling:*`  (supported on Recycling presets)
- Additional bug fixes and usability improvements

Changelog:  https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#194 

Twitter:   https://twitter.com/bhousel/status/727858394414100481 



Thanks,
Bryan

Follow me on Twitter https://twitter.com/bhousel , 
or follow the iD project on GitHub https://github.com/openstreetmap/iD 
 for more iD tips and updates.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk] iD news: v1.9.4 released

[Bryan Housel]

iD v1.9.4 was released May 3 2016 and is now available for editing on 
openstreetmap.org

The release includes:
- Fix bug causing the Save button to remain disabled even when changeset 
comment entered
- Support setting imagery offset via url parameter
- New multiple selection field type (built by Kushan Joshi), used for tagging:
   - `payment:*`  (supported on Vending Machine presets)
   - `currency:*`  (supported on Vending Machine, Money Exchange, ATM presets)
   - `fuel:*`  (supported on Gas Station, Marine Fuel Station presets)
   - `recycling:*`  (supported on Recycling presets)
- Additional bug fixes and usability improvements

Changelog:  https://github.com/openstreetmap/iD/blob/master/CHANGELOG.md#194 

Twitter:   https://twitter.com/bhousel/status/727858394414100481 



Thanks,
Bryan

Follow me on Twitter https://twitter.com/bhousel , 
or follow the iD project on GitHub https://github.com/openstreetmap/iD 
 for more iD tips and updates.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Per-State relations for the Appalachian Trail

[Richard Welty]

On 5/4/16 9:54 AM, Elliott Plack wrote:
> Thanks for all of the feedback. I definitely won't be merging any
> relations based on some of what you have all stated. What I will do is
> go through and look at each relation state by state to ensure there is
> connectivity and what not. I'll update anything of interest here. 
if i found myself looking at a relation which was on a border (as Kenny
pointed out)
i'd probably just give the relation a name like NC-TN. there's no reason
to make this
any harder than that.

richard

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




signature.asc
Description: OpenPGP digital signature
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-gb-westmidlands] Next meeting: Atherstone

[Andy Robinson]

I think last time we were there we used the White Horse on Long Street.

 

If I get time for some mapping I’ll focus on the south side of the railway.

 

See you Thursday.

 

Cheers

Andy

 

From: Rob Nickerson [mailto:rob.j.nicker...@gmail.com] 
Sent: 02 May 2016 23:45
To: Brian Prangle
Cc: talk-gb-westmidlands
Subject: Re: [Talk-gb-westmidlands] Next meeting: Atherstone

 

Thursday works better for me too so let's go for that.

Do we have mapping properties? Location for food/drinks?

Rob

On 27 Apr 2016 11:47 a.m., "Brian Prangle"  wrote:

I can only do Thursday

 

On 26 April 2016 at 23:12, Rob Nickerson  wrote:

Hi all,

The next Midlands meeting is at Atherstone. Normally this would be Wednesday 
4th May however we have an opportunity to move this to the Thursday 5th May.

If you are hoping to join us in Atherstone can you please reply with your 
preferred date. 

Rob


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

 

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

Re: [Talk-it] OpenMtbMap errore rendering pozzi privati \ drinking water

[Federico Cortese]

Ho iniziato la cancellazione dei pozzi.
Qui documenterò i changeset caricati:
http://wiki.openstreetmap.org/wiki/Puglia/CTR_Import#Cancellazione_dei_pozzi

Ciao

Federico

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

Re: [Talk-us] Per-State relations for the Appalachian Trail

[Elliott Plack]

Thanks for all of the feedback. I definitely won't be merging any relations
based on some of what you have all stated. What I will do is go through and
look at each relation state by state to ensure there is connectivity and
what not. I'll update anything of interest here.
On Tue, May 3, 2016 at 22:35 Kevin Kenny  wrote:

> On 05/03/2016 03:09 PM, OSM Volunteer stevea wrote:
> > In the USA, partly because we are such a geographically large part of
> > the North American continent and partly because each of our fifty
> > states is sovereign, I find that breaking apart very large relations
> > so they are across a single state at a time (then perhaps these are
> > collected into a super-relation) is often (though not always) a
> > sensible approach.  It is part size (large relations with vast numbers
> > of members are unwieldy), it is part “what sort of an entity is this
> > politically?"
> >
> > For example, there is a note in OSM’s Amtrak wiki page on the
> > route=train relation for the California Zephyr:  "The relation is said
> > to be so big it is hard to work with.”  That is something we might
> > take to heart and break apart the relation into statewide components.
> >  I haven’t done that, but somebody might, after considering that it
> > makes editing easier, and that state-at-a-time is a good way to do
> > this.  Even a simple web browser request to display this relation
> > results in "Sorry, the data for the relation with the id 905830, took
> > too long to retrieve." The practicality of potentially better avoiding
> > edit conflicts has been mentioned, and is also true.
> >
> Breaking apart the AT into separate relations - ideally with a
> superrelation joining them - would be sensible, I think, but be careful
> about the assumption about state lines. The AT literally spends a good
> many miles with the hiker having one foot in North Carolina and the
> other in Tennessee - the ridge that it follows is the state line.
>
> We also, I think, need to put some more thought simply into the support
> of large relations. I've recently found that even the New York Long Path
> (only a fifth the length of the AT) crashes JOSM (I haven't yet
> diagnosed the problem) and wound up editing in Meerkartor instead.
> Trails, highways, rivers, railroads, we have a good many places where
> things reasonably and predictably break down into thousands of parts
> over thousands of km, and I don't think we yet have a unified theory of
> how to handle them.
>
> --
> 73 de ke9tv/2, Kevin
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
-- 
Elliott Plack
http://elliottplack.me
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-br] Discussão em Changesets

[santamariense]

Sim, Nelson, estava caindo no spam, mas o pior é que estava caindo no
spam dum email que já não costumava usar mais, mudei isso nas
configurações. E agora está ok.

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

Re: [Talk-br] Votação: uso de boundary=administrative para meso/micro-regiões do IBGE

[Gerald Weber]

Prezado Leonardo

se você pretende conduzir uma discussão, votação etc, como parece ser o
caso, então eu sugiro que não responda às mensagens de "cabeça quente" como
esta que você me mandou. Isto tem apenas tem o potencial de gerar mais
mensagens de "cabeça quente" e rapidamente isto se transforma numa briga
improdutiva. Podemos concordar com isto?

Há várias afirmações na sua mensagem abaixo que se eu fosse repondê-las "na
mesma moeda"  só resultaria em mais mensagens improdutivas e com potencial
de gerar briga. Por exemplo eu não tenho nenhum "dever de casa"  a fazer
pois não me comprometi a realizar qualquer tarefa específica que seja. Você
se expressando desta maneira parece que você está nos dando ordens tipo
"Votem", "Façam o seu dever de casa", "Leiam o que escrevi" etc, o que não
vai atrair qualquer tipo de simpatia para os seus argumentos. Imagino que
não tenha sido esta a sua intenção, mas isto pode ser interpretado desta
maneira e causar ressentimento.

Eu reconheço que a mensagem de objeção que enviei também não foi das mais
apropriadas, foi escrita "no susto" no meu celular enquanto estava no
aeroporto esperando para embarcar. Por isto saiu assim "atravessada" e sem
detalhes. Peço desculpas por isto.

Eu procuro ler tudo o que você escreve, mas acho que muitos vão concordar
comigo que se você exercesse um pouco mais de concisão nas suas mensagens
seria mais simples engajar na discussão. Talvez você pudesse dar um pouco
mais de atenção a isto.

De fato não pretendia voltar a postar sobre o tópico, a menos que tivesse
novos elementos concretos para contribuir. Mas me surpreendeu o início de
uma votação e não pude deixar de ignorá-la pelas implicações que poderia
ter. O problema de uma "votação" é que ela acaba se tornando uma "decisão"
mesmo que você esteja querendo realizar apenas uma sondagem como você diz.
Eu tenho vivência suficiente em listas de discussão para saber que logo
depois virá um "mas nós decidimos que..." mesmo que tenha sido apenas uma
sondagem. Pode não vir de você, mas pode vir de outras pessoas.

Penso que a maneira mais apropriada seria primeiro consultar se todo mundo
se sente suficientemente esclarecido para iniciar alguma votação, e esperar
propostas de como encaminhá-la. Se há alguma polêmica, o ideal é ver se há
alguém neutro o suficiente para encaminhar a votação apresentando de
maneira resumida os vários pontos de vista. De outro modo acaba-se
induzindo uma resposta. Por exemplo, quem apenas acompanha o Forum, e não
viu a discussão prévia da lista, não leu as opiniões divergentes sobre o
assunto. Assim, tendo visto apenas um lado da discussão tenderá a concordar
com ela. A pessoa poderia não concordar se lesse a discussão na lista.
Mesmo incluindo os links para a discussão dificilmente vão ler tudo pois
vão considerar que a mensagem de encaminhamento já resume todo o
entendimento, o que não é o caso. Por isto é importante colocar de maneira
equilibrada e imparcial os vários pontos de vista.

Por isto eu te peço que você suspenda a votação que você inicou. Já tem
outra pessoa que se manifestou contrário a realização desta votação,
portanto o correto agora é suspendê-la.

Minha sugestão agora é dar um tempo. Você com certeza consegui uma coisa
importante, estão todos pensando sobre o assunto, coletando informações e
pesando as consequências em alterar ou deixar como está.

um abraço

Gerald




2016-05-04 7:34 GMT-03:00 Leonardo Brondani Schenkel 
:

> Caro Gerald,
>
> On 03/05/2016 00:50, Gerald Weber wrote:
> > Tenho objeção a conduzir a votação desta maneira, isto é uma votação
> > induzida.
>
> Me proponho a criar um terceiro tipo de voto, de "Objeção", que funciona
> exatamente como os outros. Caso responda a este e-mail votando desta
> forma vou interpretar como tal e registrar seu voto e totalizá-lo. Como
> vai existir um link para sua objeção, tem a liberdade para argumentar de
> forma que quiser no seu voto como esta votação não tem fundamento. Daí
> vou colocar um aviso em negrito no topo do texto da votação no wiki
> dizendo que existem objeções à votação e que os links dos votos
> "Objeção" vão ter os detalhes das objeções.
>
> Sobre conduzir a votação, o que eu fiz foi criar um tópico específico
> para discutir o assunto da votação (e não os 20 outros relacionados) por
> questão de objetividade, expliquei o escopo da votação, deixei claro na
> primeira frase do texto da votação que sou eu que escrevi o texto da
> votação e qual minha posição sobre o assunto, coloquei o link para os
> arquivos da talk-br para permitir que as pessoas leiam a discussão
> prévia por elas mesmas e estou apenas totalizando os votos que estão
> sendo feitos usando publicamente — toda a informação é pública, o wiki
> registra histórico e qualquer um pode inspecionar o que estou fazendo. O
> tópico está em aberto, e respondi neste tópico para fazer alguns outros
> pontos adicionais.
>
> Isso ainda é uma lista de discussão, eu não encerrei o assunto. O tópico

[talk-au] osmaustralia.org website and Garmin .img files - current status ?

[Ian Steer]

Does anyone know what's happening with the osmaustralia.org website, and the
regular updates of Garmin .img files ?

 

They used to be updated roughly weekly, but haven't been updated since
February.

 

(I use these files to update my Garmin GPS with the results of my (and
everyone else's) OSM updates.)

 

Ian

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

Re: [OSM-talk-ie] [Talk-gb-westmidlands] Registration is Now Open for State of the Map!

[Martín Ferrari]

Rob,

On 04/05/16 13:56, Rob Nickerson wrote:

> 1. We have a scholarship fund in place to help with costs. Feel free to
> apply to that.
> 
> 2. At 75 EUR tickets are sold at a loss compared to variable costs
> alone. When you add in fixed costs the loss per ticket is much bigger.
> We can do this because of sponsorship.
> 
> 3. Our price is in line with SotM 2013 and 5 EUR less than SotM US 2015.
> 
> 4. The hotel deal is available to try to keep accommodation costs down.
> 
> 5. We welcome anyone with contacts to airlines to come forward but can't
> arrange any deals with them as is.
> 
> Once again sorry that we can't get to the price level you want. Please
> apply to the scholarship fund and send in sponsorship leads.

Thanks for your detailed reply.

I don't think I should apply for sponsorship, as surely there are people
who need it way more than I do.

My complaint here was about the cost of attending the event, not about
the plane tickets or accommodation, which one can always handle in
different ways. It is not that I can't afford the 75/100 EUR, but that I
can't justify to myself to pay that money to attend a community event.

If the tickets are sold at a loss, I guess the problem then is that the
costs are too high. I don't know the cost structure of the SotM, as I
have never attended one, so I can't comment.

I have been involved in the organisation of many Debian events, where
attendance is always free, and in the bigger event (DebConf) even food
and accommodation is paid for the majority of attendees, because we
consider it a way to give back to the community. Of course, this means
finding many sponsors and really cheap venues, catering and places to
sleep; and nobody gets paid to deliver a talk. We also provide travel
sponsorship for a small amount of people, based on financial need.

-- 
Martín Ferrari (Tincho)

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

Re: [Talk-dk] Hvad hedder Geodatastyrelsen?

[Allan Gyldendal Frederiksen]

Må her lige gøre opmærksom på, at den rigtige kreditering af FOT nu GeoDanmark 
Data er som beskrevet i dette dokument:

http://gst.dk/media/gst/64649/Vilkar%20for%20brug%20af%20FOT-data.pdf

Så den rigtige betegnelse må derfor være: SDFE og Danske Kommuner

Venlig hilsen
Allan Gyldendal Frederiksen

Fra: Kurt Forbech Toft [mailto:k...@sdfe.dk]
Sendt: 4. maj 2016 12:31
Til: OpenStreetMap Denmark
Emne: Re: [Talk-dk] Hvad hedder Geodatastyrelsen?

Hej Asger

Den officielle forkortelse er SDFE

Venlig Hilsen
Kurt Toft

Fra: Asger Frank [mailto:asg...@gmail.com]
Sendt: 4. maj 2016 12:23
Til: OpenStreetMap Denmark
Emne: [Talk-dk] Hvad hedder Geodatastyrelsen?

Jeg angiver troligt source som Geodatastyrelsen, selvom jeg godt ved, at det 
hedder den ikke mere, den afdeling der er relevant for OSM.

Men det var sådan et godt navn, og jeg er fristet til at fremover angive source 
som “Styrelsen tidligere kendt som Geodatastyrelsen”, i analogi til afdøde 
Prince, der en overgang af rettighedsproblemer kaldte sig “The Artist Formerly 
Known as Prince”.

Geodætisk Institut, Kort- & Matrikelstyrelsen, Geodatastyrelsen, og nu 
Styrelsen for Dataforsyning og Effektivisering.

Korte af lange, hvad skriver vi (fx ved kreditering af FOT ortofoto):
Fortsætter med “Geodatastyrelsen" resp. GST?
"Styrelsen for Dataforsyning og Effektivisering" resp. SDE?


Mvh. Asger Frank
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-gb-westmidlands] [OSM-talk-ie] Registration is Now Open for State of the Map!

[Martín Ferrari]

On 02/05/16 21:56, Rob Nickerson wrote:
> Hi all,
> 
> Tickets for State of the Map 2016 are now on sale. Get yours before the
> price goes up (to EUR 100)!

Sadly, this cost is too high to justify attending. I care about OSM, and
I have been a silent contributor for years, but spending on plane
tickets, acommodation, and on top of that 75-100 EUR to attend the
conference, is just too much money for this little hobby of mine.

I think it is a sad state when most libre projects I care about charge
its own volunteers to gather and improve the community, specially when
corporate sponsors could be offsetting this cost. OSM is far from the
only one, I am just writing this because I am getting increasingly
annoyed by the situation.

-- 
Martín Ferrari (Tincho)

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

Re: [Talk-us] Improving coverage of exit numbers and destinations on motorways

[Elliott Plack]

So, I am confused here. What Paul is talking about, isn't that what is
being proposed (besides the junction:ref bit)? This is a proposal to use
the node and way approach, like the one Duane points too, right?


On Tue, May 3, 2016 at 10:31 AM Duane Gearhart  wrote:

> Hey all,
>
> I believe the way-junction:ref should be used in addition to the node-ref
> only when needed at splits - like this example:
> http://wiki.openstreetmap.org/wiki/Exit_Info#A.2FB_Split_Example
> These types of splits do not happen very often - however, when they do -
> having the way-junction:ref helps to improve the guidance for the user at
> key decision points.
>
> Regards,
> Duane
>
>
> On Tue, May 3, 2016 at 10:02 AM, Jinal Foflia 
> wrote:
>
>> Hi Paul,
>>
>> These are good points, but it does not look like the `junction:ref`
>> tagging scheme is very common. Till there is widespread usage by the
>> community we will continue to follow the conventional tagging of the
>> reference numbers on the motorway_junction node [1].
>>
>> Curious to know what the others think of the `junction:ref` tag.
>>
>> Cheers,
>> Jinal Foflia
>>
>>
>> [1] http://taginfo.openstreetmap.org/search?q=highway%3Dmotorway_junction
>>
>>
>> On Tue, May 3, 2016 at 3:49 PM, Paul Johnson  wrote:
>>
>>> I'm wondering why the push to tag a node with directional information
>>> when tagging the first segment of the diverging way would be more concise
>>> and already had support in some navigational data consumers?  This handles
>>> weird situations where ramps diverge to the left or from a lane other than
>>> the edge much more cleanly.
>>>
>>> For example, Exit 2 in West Tulsa on I 244. First segment could be
>>> tagged as...
>>>
>>> name=Okmulgee Beeline
>>> junction:ref=2
>>> destination=Okmulgee
>>> destination:ref=US 75 South
>>> ref=US 75
>>> highway=motorway
>>>
>>> Or, the number 3 lane exit westbound US 26 north of Beaverton at exit
>>> 71A (lanes 1, 2 and 4 remain on US 26, oddly enough).
>>>
>>> name=Canyon Road
>>> highway=motorway_link
>>> ref=OR 8
>>> junction:ref=71A
>>> destination=Beaverton
>>> destination:ref=OR 8 West
>>>
>>> This along with the departure angle, gives navigation systems ample
>>> information to accurately describe the ramp that point data just leaves out.
>>>
>>>
>>> On Tue, May 3, 2016 at 4:46 AM, Jinal Foflia 
>>> wrote:
>>>
 There has been a recent push to improve the coverage of exit numbers
 and destination signs on the motorways in the US by the data team at
 Mapbox. Some context here [1][2][3][4]. The primary sources of data were
 DoT documents and Mapillary images. The secondary source was Wikipedia, but
 as per the conversation with the local mappers, it is not a good idea to
 completely trust wikipedia documents for mapping the exit numbers and
 destinations. There are certain highways which do not have Mapillary
 coverage and it is difficult to validate/identify the missing exit numbers
 and destination. It will be a great help if local mappers can help share
 reliable sources and validate the existing data that will help improve the
 coverage of this data on the map

 We been working on this from the beginning of April and reviewed more
 than 220 highways in 9 states. The goal would be to authenticate all
 the existing data and fill in the gaps using verifiable sources wherever
 possible.

 Here is the Overpass query to get a better sense of the stats:

 * Total motorway_junction edited by team in last two weeks: 179 [5]

 This is the detailed workflow for *Exit mapping* [6] and *Destination
 mapping* [7] that was used for this mapping activity. Would be great
 to hear your feedback on how it can be improved for further such tasks,
 please drop a comment on the *project tracker* [3] .

 I want to thank all of you in the community for giving feedback,
 calling us out on the occasional errors, and working with us to improve
 signpost mapping conventions. I feel proud to be a member of such a great
 mapping community!
 Cheers,

 Jinal Foflia

 [1] https://www.openstreetmap.org/user/jinalfoflia/diary/38501

 [2] https://www.openstreetmap.org/user/jinalfoflia/diary/38342

 [3] https://github.com/mapbox/mapping/issues/178

 [4] https://github.com/mapbox/mapping/issues/169

 [5] http://overpass-turbo.eu/s/fzA

 [6]
 https://gist.github.com/poornibadrinath/a8f3652deb566d95b848c5e9cd68011f

 [7]
 https://gist.github.com/poornibadrinath/f982a947c6a063ed1a9016a2d3246d4a




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


>>>
>>> ___
>>> Talk-us mailing list
>>> 

Re: [OSM-talk-fr] relation avec plusieurs types (foot, bicycle) ?

[David Crochet]

Bonjour

Le 04/05/2016 10:21, Benoit FOURNIER a écrit :
> foot <-> network = lwn
> bicycle <-> network = lcn
> et autres tags name/distance

C'est pour cela que j'étais parti sur le principe d'une relation par 
type de transport


Cordialement
--
David Crochet

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

Re: [Talk-us] Improving coverage of exit numbers and destinations on motorways

[Mike N]

On 5/4/2016 4:18 AM, Greg Morgan wrote:

 At one time there was a discussion on the list about moving exit_to
tags as destination tags on the ramp.  I moved most of the exit_to tags
that I mapped to the ramps.  Here you are proposing something different
by leaving some exit_to tags and adding destination tags occasionally.


Just to add to this - someone has added ref:left and ref:right to split 
exits near me, but it appears that this is an abandoned proposal.


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

Re: [Talk-br] Votação: uso de boundary=administrative para meso/micro-regiões do IBGE

[Leonardo Brondani Schenkel]

On 04/05/2016 03:20, Flavio Bello Fialho wrote:
> Discordo: Primeiro, o tema é polêmico e acho a votação precipitada.

Que é polêmico acho que nem tem como discutir. Ou o fato de ser polêmico
também é polêmico? :-)

Sobre a precipitação da votação, poderia explicar em mais detalhes o que
há de precipitado (ou: o que deveria ter acontecido antes, na sua opinião)?

Note que não há nenhuma proposta concreta em votação aqui, este é um
tópico sobre um assunto específico onde a discussão está aberta e onde
eu formalizei a forma de expressar a opinião, assim é possível totalizar
as opiniões a título de sondagem. Daqui a pelo menos 90 dias podemos
ver, de acordo com a votação, se a discussão continua para algo mais
concreto que envolve alterações ou se o status quo permanece e a
discussão simplesmente acaba, o que também vai ser bom para todos — eu
imagino.

Abraço,
Leonardo.


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

Re: [Talk-br] Votação: uso de boundary=administrative para meso/micro-regiões do IBGE

[Leonardo Brondani Schenkel]

Caro Gerald,

On 03/05/2016 00:50, Gerald Weber wrote:
> Tenho objeção a conduzir a votação desta maneira, isto é uma votação
> induzida.

Me proponho a criar um terceiro tipo de voto, de "Objeção", que funciona
exatamente como os outros. Caso responda a este e-mail votando desta
forma vou interpretar como tal e registrar seu voto e totalizá-lo. Como
vai existir um link para sua objeção, tem a liberdade para argumentar de
forma que quiser no seu voto como esta votação não tem fundamento. Daí
vou colocar um aviso em negrito no topo do texto da votação no wiki
dizendo que existem objeções à votação e que os links dos votos
"Objeção" vão ter os detalhes das objeções.

Sobre conduzir a votação, o que eu fiz foi criar um tópico específico
para discutir o assunto da votação (e não os 20 outros relacionados) por
questão de objetividade, expliquei o escopo da votação, deixei claro na
primeira frase do texto da votação que sou eu que escrevi o texto da
votação e qual minha posição sobre o assunto, coloquei o link para os
arquivos da talk-br para permitir que as pessoas leiam a discussão
prévia por elas mesmas e estou apenas totalizando os votos que estão
sendo feitos usando publicamente — toda a informação é pública, o wiki
registra histórico e qualquer um pode inspecionar o que estou fazendo. O
tópico está em aberto, e respondi neste tópico para fazer alguns outros
pontos adicionais.

Isso ainda é uma lista de discussão, eu não encerrei o assunto. O tópico
está aí aberto para ser discutido. Qualquer argumento ou fato pode ser
apresentado, opiniões podem ser mudadas, e votos podem ser modificados.
Os votos são só a sondagem.

> Nenhuma das duas alternativas que foram propostas refletem o meu
> entendimento sobre o assunto.

Sinto ser grosso e direto, mas não é realmente problema meu. Você nem se
interessa muito em realmente explicar seu entendimento do assunto. A
iniciativa foi minha, tudo o que você fez foi criticar o tópico em si
(não os argumentos, mas o tópico) desde o início.

Faça o dever de casa e escreva um texto e proponha uma outra votação e
totalize os votos. Mas sei que não fará: se você _realmente_ estivesse
interessado em algo construtivo, teria explicado o que é realmente seu
entendimento ou sugerido como melhorar a votação. Mas criticar é fácil.

> Primeiro temos que definir cenários que resumem o entendimento do grupo
> e as suas consequências. Não cabe votar uma pergunta específica fora de
> contexto.

Se tivesse lido e prestado atenção no texto da votação teria visto que a
votação não está propondo nada, apenas sondando a posição da comunidade
sobre o assunto. Apenas formalizei a forma de expressar a posição e me
voluntariei a contar e totalizar.

De novo: faça o dever de casa e então faça tudo isso que você propõe.
Até uns dias atrás você questionou a própria importância de discutir
isso, que existiam outras coisas muito mais importantes a serem feitas —
mas ainda está postando por aqui e agora temos que definir cenários e
conseqüências, que curioso isso.

De novo mais uma vez: se tivesse lido e prestado atenção no texto da
votação teria visto que __eu estou me propondo a fazer uma proposta
formal com exatamente o que você está dizendo__, a votação é só uma
discussão/sondagem para ver se existe ou não um consenso sobre o
problema em si (e deixando amplo tempo de no mínimo 90 dias para
qualquer discussão sobre o assunto). Se todo mundo compartilha de sua
opinião, e eu sou o maluco aqui, não adianta eu perder tempo em fazer a
proposta. Assim eu salvo até o seu tempo para gastar nas outras coisas
mais importantes que estão aí implorando por atenção e eu não deixo você
fazer.

// Leonardo.



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

Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz

[jzvc]

Cus,


Dne 4.5.2016 v 11:56 Hynek Řehoř napsal(a):

Ahoj,

ještě dotaz - při updatu ref
rozcestníků dostávám warning:

Inline image 3

Mám hlášku ignorovat nebo opravit? Pokud opravit, jak?

Díky, H.



To varovani vychazi nejspis z predpokladu, ze rozcestnik neni soucasti 
cesty jako takovy, ale stoji nekde vedle ni. Tzn, pokud znas presnou 
polohu sloupku/stromu/... tak z toho udelej samostatne existujici node 
(a pridej ho do prislusnych relaci) pokud neznas, tak to neres.


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

Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz

[Miroslav Suchy]

Dne 4.5.2016 v 11:56 Hynek Řehoř napsal(a):
> ještě dotaz - při updatu ref
> rozcestníků dostávám warning:
> 
> Inline image 3
> 
> Mám hlášku ignorovat nebo opravit? Pokud opravit, jak?

Rozcestníky nedáváme na silnici, ale na to místo kde opravdu jsou - obvykle 
sloup vedle silnice.
(proč? viz diskuse v archívu z minulého roku).
Takže neignorovat ale přesunout nalevo nebo napravo od silnice.

Mirek

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

Re: [Talk-dk] Hvad hedder Geodatastyrelsen?

[Kurt Forbech Toft]

Hej Asger

Den officielle forkortelse er SDFE

Venlig Hilsen
Kurt Toft

Fra: Asger Frank [mailto:asg...@gmail.com]
Sendt: 4. maj 2016 12:23
Til: OpenStreetMap Denmark
Emne: [Talk-dk] Hvad hedder Geodatastyrelsen?

Jeg angiver troligt source som Geodatastyrelsen, selvom jeg godt ved, at det 
hedder den ikke mere, den afdeling der er relevant for OSM.

Men det var sådan et godt navn, og jeg er fristet til at fremover angive source 
som “Styrelsen tidligere kendt som Geodatastyrelsen”, i analogi til afdøde 
Prince, der en overgang af rettighedsproblemer kaldte sig “The Artist Formerly 
Known as Prince”.

Geodætisk Institut, Kort- & Matrikelstyrelsen, Geodatastyrelsen, og nu 
Styrelsen for Dataforsyning og Effektivisering.

Korte af lange, hvad skriver vi (fx ved kreditering af FOT ortofoto):
Fortsætter med “Geodatastyrelsen" resp. GST?
"Styrelsen for Dataforsyning og Effektivisering" resp. SDE?


Mvh. Asger Frank
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-it] palestra di roccia

[demon.box]

dieterdreist wrote
> In che senso sono "palestre"? C'è una recinzione? Si paga per l'utlizzo?
> Ci
> sono servizi offerti?

per spiegare: non c'è nessuna recinzione, ne ovviamente si paga e nemmeno è
offerto nessun servizio, trovi soltanto i chiodi già piantati...

però la parete ha un nome bene specifico e spesso l'unica cosa che trovi
oltre ai chiodi è proprio un cartello con scritto "Palestra di roccia XY".





--
View this message in context: 
http://gis.19327.n5.nabble.com/palestra-di-roccia-tp5872925p5872973.html
Sent from the Italy General mailing list archive at Nabble.com.

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

[Talk-dk] Hvad hedder Geodatastyrelsen?

[Asger Frank]

Jeg angiver troligt source som Geodatastyrelsen, selvom jeg godt ved, at det 
hedder den ikke mere, den afdeling der er relevant for OSM.

Men det var sådan et godt navn, og jeg er fristet til at fremover angive source 
som “Styrelsen tidligere kendt som Geodatastyrelsen”, i analogi til afdøde 
Prince, der en overgang af rettighedsproblemer kaldte sig “The Artist Formerly 
Known as Prince”.

Geodætisk Institut, Kort- & Matrikelstyrelsen, Geodatastyrelsen, og nu 
Styrelsen for Dataforsyning og Effektivisering.

Korte af lange, hvad skriver vi (fx ved kreditering af FOT ortofoto):
Fortsætter med “Geodatastyrelsen" resp. GST?
"Styrelsen for Dataforsyning og Effektivisering" resp. SDE? 


Mvh. Asger Frank___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-it] Relation Internazionali d'Italia #2 MTB al Monte Stella

[Volker Schmidt]

Ecco il sito web:
http://www.mtb-mag.com/2-internazionali-ditalia-series-la-montagnetta-di-san-siro-milano/

2016-05-04 11:52 GMT+02:00 Stefano :

> Google suggerisce fosse una tappa del campionato italiano di cross country
> http://www.montagnettamilanomtb.it/programma/
> http://www.internazionaliditaliaseries.it/
>
>
>
> Il giorno 4 maggio 2016 11:34, emmexx  ha scritto:
>
>> Ho notato che all'interno della montagnetta del Monte Stella a Milano e'
>> apparso un percorso che corrisponde ad una relation di tipo route, mtb
>> http://www.openstreetmap.org/relation/6171502
>>
>> Mi pare si tratti non di un percorso definitivo ma di una qualche
>> manifestazione sportiva.
>>
>> Ne sapete qualcosa? Va bene cosi'?
>>
>> grazie
>> maxx
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz

[Hynek Řehoř]

Ahoj,

ještě dotaz - při updatu ref
rozcestníků dostávám warning:

[image: Inline image 3]

Mám hlášku ignorovat nebo opravit? Pokud opravit, jak?

Díky, H.

2016-05-04 11:22 GMT+02:00 Marián Kyral :

> :-D
>
> Tak updaty POI v OSM jsou v plánu. Ale není to tak jednoduché a ještě to
> nikdo nenapsal. A v dohledné době to určitě nebude.
>
> Marián
>
> -- Původní zpráva --
> Od: Hynek Řehoř 
> Komu: OpenStreetMap Czech Republic 
> Datum: 4. 5. 2016 11:19:27
>
> Předmět: Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz
>
>
> Ahoj,
>
> aha, myslel jsem, že je to více "user friendly" -  pokud existuje
> rozcestník bez ref. id a nahraji fotku s ref id, která vzdálená do x metrů
> od rozcestníku, tak se automaticky updatne i OSM.
>
> Doplním tedy přímo do OSM, no problem ;-).
>
> Díky,
> Hynek
>
> 2016-05-04 10:51 GMT+02:00 Marián Kyral :
>
> Ahoj. Jestli to nebude tím, že to ref je potřeba doplnit do OSM.
>
> Marián
>
> -- Původní zpráva --
> Od: Hynek Řehoř 
> Komu: OpenStreetMap Czech Republic 
> Datum: 4. 5. 2016 10:28:20
>
> Předmět: Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz
>
>
> Ahoj,
>
> jak často se "párují" fotky nahrané přes
> http://map.openstreetmap.cz/work2/ s rozcestníky? O víkendu jsem nafotil
> 3 rozcestníky v Jindřichovicích pod Smrkem, v pondělí uploadoval ,a stále
> se zobrazují jako bez ref a fota. Fotky jsou v pořádku nahraná, kontroloval
> jsem.
>
> Dík, Hynek
>
> 2016-04-27 14:33 GMT+02:00 Petr Vozdecký :
>
> Ahoj,
>
> ref rozcestníku prosím v tomto případě jen HK043. Písmeno na konci je
> identifikační písmeno směrníku (konkrétní tabulky). Písmeno "m" definuje
> tabulku se jménem místa (název TIM).
>
> vop
>
> -- Původní zpráva --
> Od: Lukas Novotny 
> Komu: OpenStreetMap Czech Republic 
> Datum: 27. 4. 2016 9:36:18
> Předmět: Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz
>
>
> Dne 27. dubna 2016 8:24 Marián Kyral  napsal(a):
>
> Souřadnice a ref jsou předvyplněny z OSM (ref jen pokud je).
>
>
> Tak mě se ref nepředvyplnilo, že by mu vadilo písmeno na konci? *ref* =
> HK043m
> Viz screenshoty. Rozcestník jsem prozatím do systému nenahrál.
>
> Díky za vaší skvělou práci.
> Lukáš
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] Relation Internazionali d'Italia #2 MTB al Monte Stella

[Stefano]

Google suggerisce fosse una tappa del campionato italiano di cross country
http://www.montagnettamilanomtb.it/programma/
http://www.internazionaliditaliaseries.it/



Il giorno 4 maggio 2016 11:34, emmexx  ha scritto:

> Ho notato che all'interno della montagnetta del Monte Stella a Milano e'
> apparso un percorso che corrisponde ad una relation di tipo route, mtb
> http://www.openstreetmap.org/relation/6171502
>
> Mi pare si tratti non di un percorso definitivo ma di una qualche
> manifestazione sportiva.
>
> Ne sapete qualcosa? Va bene cosi'?
>
> grazie
> maxx
>
> ___
> 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: [Talk-us] Improving coverage of exit numbers and destinations on motorways

[Paul Johnson]

On Wed, May 4, 2016 at 3:18 AM, Greg Morgan  wrote:

>
>
> The work flow that you mention drive me batty.[0]  At one time there was a
> discussion on the list about moving exit_to tags as destination tags on the
> ramp.  I moved most of the exit_to tags that I mapped to the ramps.  Here
> you are proposing something different by leaving some exit_to tags and
> adding destination tags occasionally.  The batty part, is that the original
> way I mapped these without exit_to was what I found in Europe. It looks
> like Paul has a point because junction:ref is in the wiki page
> that Duane cites. I don't know that you can use "does not look like the x 
> tagging
> scheme is very common" or "we will continue to follow the conventional
> tagging" when the wiki page has changes as recent as 9/2015.
>
>
Plus Osmand consumes the ramp tagging, not the node tagging (and in no
small part because it's not obvious which direction the node means if
you're a machine).  Most of the interstates (soon, all) will have both.
Though Osmand doesn't use motorway junction refs or the way's junction:ref
(yet).

That said, yes, destination has legs.
http://taginfo.openstreetmap.org/keys/destination#map  Junction:ref=* is
getting there.  http://taginfo.openstreetmap.org/keys/junction%3Aref#map
 And here's a control with highway=motorway_link
http://taginfo.openstreetmap.org/tags/highway=motorway_link#map

Seems with the more flexible tagging (junction:ref=* and destination=*)
there's a strong correlation between regions with the strongest car culture
(Route 66, New England and Germany) and where it's being tagged.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Relation Internazionali d'Italia #2 MTB al Monte Stella

[Volker Schmidt]

.

>
> Va bene cosi'?
>
> Molto probabilmente no, perché non si tratta di un percorso permanente e
con segnaletica.
Hai contattato l'utente http://www.openstreetmap.org/user/Constable ?
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-it] Relation Internazionali d'Italia #2 MTB al Monte Stella

[emmexx]

Ho notato che all'interno della montagnetta del Monte Stella a Milano e'
apparso un percorso che corrisponde ad una relation di tipo route, mtb
http://www.openstreetmap.org/relation/6171502

Mi pare si tratti non di un percorso definitivo ma di una qualche
manifestazione sportiva.

Ne sapete qualcosa? Va bene cosi'?

grazie
maxx

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

Re: [OSM-talk-fr] Covoiturage pour Clermont-Ferrand (State of the Map)

[Vincent de Château-Thierry]

> De: "JB" 
> 
> Pour les hésitants entre covoiturage et train, y a-t-il des
> possibilités de stationnement facile proches de l'événement ?

On n'aura pas de parking attitré mais de l'avis des Clermontois, la pression 
est faible sur le stationnement aux alentours.

vincent

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

Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz

[Marián Kyral]

:-D

Tak updaty POI v OSM jsou v plánu. Ale není to tak jednoduché a ještě to 
nikdo nenapsal. A v dohledné době to určitě nebude.

Marián


-- Původní zpráva --
Od: Hynek Řehoř 
Komu: OpenStreetMap Czech Republic 
Datum: 4. 5. 2016 11:19:27
Předmět: Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz

"

Ahoj,



aha, myslel jsem, že je to více "user friendly" -  pokud existuje rozcestník
bez ref. id a nahraji fotku s ref id, která vzdálená do x metrů od 
rozcestníku, tak se automaticky updatne i OSM.



Doplním tedy přímo do OSM, no problem ;-).




Díky,

Hynek 





2016-05-04 10:51 GMT+02:00 Marián Kyral :
"
Ahoj. Jestli to nebude tím, že to ref je potřeba doplnit do OSM.

Marián


-- Původní zpráva --
Od: Hynek Řehoř 
Komu: OpenStreetMap Czech Republic 
Datum: 4. 5. 2016 10:28:20



Předmět: Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz
(http://osmap.cz)






"

Ahoj,



jak často se "párují" fotky nahrané přes http://map.openstreetmap.cz/work2/
(http://map.openstreetmap.cz/work2/) s rozcestníky? O víkendu jsem nafotil 3
rozcestníky v Jindřichovicích pod Smrkem, v pondělí uploadoval ,a stále se 
zobrazují jako bez ref a fota. Fotky jsou v pořádku nahraná, kontroloval 
jsem.




Dík, Hynek




2016-04-27 14:33 GMT+02:00 Petr Vozdecký :
"
Ahoj,

ref rozcestníku prosím v tomto případě jen HK043. Písmeno na konci je 
identifikační písmeno směrníku (konkrétní tabulky). Písmeno "m" definuje 
tabulku se jménem místa (název TIM).

vop


-- Původní zpráva --
Od: Lukas Novotny 
Komu: OpenStreetMap Czech Republic 
Datum: 27. 4. 2016 9:36:18
Předmět: Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz
(http://osmap.cz)

"






Dne 27. dubna 2016 8:24 Marián Kyral  napsal(a):
"Souřadnice a ref jsou předvyplněny z OSM (ref jen pokud je)."







Tak mě se ref nepředvyplnilo, že by mu vadilo písmeno na konci? ref = HK043m


Viz screenshoty. Rozcestník jsem prozatím do systému nenahrál.



Díky za vaší skvělou práci.


Lukáš





___
Talk-cz mailing list
Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)"

___
Talk-cz mailing list
Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)

"



___
Talk-cz mailing list
Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)"



___
Talk-cz mailing list
Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)

"



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

Re: [OSM-talk-fr] relation avec plusieurs types (foot, bicycle) ?

[Jo]

Malheureusement, ça ne fonctionnnera pas de cette façon-la. La difference
entre la solution qui en principe est la bonne et la solution qui
fonctionnera effecticement dans la pratique, disons.

Jo
Op 4-mei-2016 8:43 AM schreef "adrien" :

> Bonjour,
>
> Je n'avais pas pensé à mettre les valeurs avec des points-virgules.
> J'avais essayé de mettre plusieurs balise « root ».
>
> Il faudrait donc que je taggue plutôt comme ceci selon vous :
>
> type = root
> root  = foot; bicycle; horse
> network = lwn; lcn
> name = blabla
> distance = XX km
>
> au lieu de trois relations :
>
> type = root
> root = foot
> network = lwn
> name = blabla
> distance = XX km
> -
> type = root
> root = bicycle
> network = lcn
> name = blabla
> distance = XX km
> -
> type = root
> root = horse
> name = blabla
> distance = XX km
>
>
> Étant tout débutant dans les relations, j'apprends par vos commentaires !
>
> Bonne journée
>
> Adrien
>
> Le 04/05/2016 04:25, Philippe Verdy a écrit :
>
> JOSM ne sait pas voir qu'une relation a des tags différents. Il croit que
> ces relations pourraient n'en faire qu'une alors qu'il y a des tags en
> conflit, en supposant qu'on puisse fusionner ces tags en un seul avec les
> valeurs dans un ordre quelconque mais séparées par des points-virgules.
> Pourtant si c'est possible quand il y a un seul tel tag, il y a aussi
> d'autres tags uniques spécifiques pour une valeur précise du tag en conflit
> mais pas un autre.
> La fusion n'est donc pas toujours possible.
> En revanche JOSM a raison de râler si entre ces relations tous les tags
> (hormi les tags à ignorer comme source=* ou les tags rendus invisibles par
> défaut comme created_by=* qui doivent migrer maintenant en tags non plus
> sur les objets mais sur les changesets) sont identiques car c'est alors un
> doublon.
> Je trouve dommage que JOSM au moins ne fasse pas cette vérification pour
> savoir si c'est un vrai doublon pour modifier la sévérité du texte de
> l'avertissement.
> Comme il ne sait pas faire, en attendant il ne déclare pas que ce sont des
> erreurs, mais juste des avertissements: c'est à l'utilisateur de voir si
> c'est un vrai doublon ou pas et de décider s'il doit fusionner ou pas.
>
> Mais si on prend l'exemple d'une relation route qui est indifféremment
> pour piétons, cyclistes ou chevaux, je ne vois pas bien ce qui empêche de
> fusionner les relations avec un tag énumérant les valeurs possibles entre
> point-virgule. L'autre solution ce serait de taguer "foot", "bicycle" et
> "horse" non pas en valeur d'un attribut mais dans un nom d'attribut (comme
> on le fait pour "access=foot;bicycle" transformé en
> "access:foot=yes"+"access:bicycle=yes"
>
> Cela reviendrait alors à ne plus utiliser "type=route" + route=foot" dans
> une relation, et "type=route" + route=bicyle" dans une autre;
> mais d'utiliser "type="route" dans une seule relation avec deux tags
> "route:foot=yes" + "route:bicycle=yes" (et non pas un seul
> "route=foot;bicyle").
>
> On a des exemples similaires avec "shop=*".
>
> On a pourtant le cas ou la défusion du tag à valeurs multiples en deux
> tags séparés (tout en gardant une relation unique) n'a pas été fait:
> "landuse=commercial;industrial" qui pourait aussi devenir
> "landuse:commercial=yes"+"landuse:industrial=yes".
>
> On n'est pas toujours très cohérent dans OSM...
>
>
> Le 3 mai 2016 à 20:21, Jo  a écrit :
>
>> Ça choquera JOSM aussi. Le validateur viendra dire qu'il y 3 relations
>> avec les mêmes membres.
>> Néanmoins, pour moi, ça me semble la bonne solution. Il y a des doublons
>> dans les itinéraires des bus pour lesquelles je dois créer de telles
>> relations qui ne diffèrent que par leur tags.
>>
>> Polyglot
>>
>> 2016-05-03 19:05 GMT+02:00 Stéphane Péneau :
>>
>>> Heu... il n'y a que moi que ça choque ?
>>> Quelle est la logique derrière ça ?
>>> Ce ne serait pas plutôt à waymarkedtrails.org
>>>  de gérer ce genre de cas ?
>>>
>>> Stf
>>>
>>>
>>> Le 03/05/2016 à 18:45, adrien a écrit :
>>>
>>> OK merci pour la réponse, y-a-plus-qu'à !
>>>
>>> Adrien
>>>
>>> Le 02/05/2016 18:08, David Crochet a écrit :
>>>
>>> Bonjour
>>>
>>> Le 02/05/2016 17:39, adrien a écrit :
>>>
>>>   faut-il que j'ajoute une relation par type de
>>> déplacement, sachant que c'est le même circuit ?
>>>
>>> oui
>>>
>>> Cordialement
>>>
>>>
>>> ___
>>> Talk-fr mailing 
>>> listTalk-fr@openstreetmap.orghttps://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
>>
>>
>
>
> ___
> Talk-fr mailing 
> 

Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz

[Marián Kyral]

Ahoj. Jestli to nebude tím, že to ref je potřeba doplnit do OSM.

Marián


-- Původní zpráva --
Od: Hynek Řehoř 
Komu: OpenStreetMap Czech Republic 
Datum: 4. 5. 2016 10:28:20
Předmět: Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz

"

Ahoj,



jak často se "párují" fotky nahrané přes http://map.openstreetmap.cz/work2/
(http://map.openstreetmap.cz/work2/) s rozcestníky? O víkendu jsem nafotil 3
rozcestníky v Jindřichovicích pod Smrkem, v pondělí uploadoval ,a stále se 
zobrazují jako bez ref a fota. Fotky jsou v pořádku nahraná, kontroloval 
jsem.




Dík, Hynek




2016-04-27 14:33 GMT+02:00 Petr Vozdecký :
"
Ahoj,

ref rozcestníku prosím v tomto případě jen HK043. Písmeno na konci je 
identifikační písmeno směrníku (konkrétní tabulky). Písmeno "m" definuje 
tabulku se jménem místa (název TIM).

vop


-- Původní zpráva --
Od: Lukas Novotny 
Komu: OpenStreetMap Czech Republic 
Datum: 27. 4. 2016 9:36:18
Předmět: Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz
(http://osmap.cz)

"






Dne 27. dubna 2016 8:24 Marián Kyral  napsal(a):
"Souřadnice a ref jsou předvyplněny z OSM (ref jen pokud je)."







Tak mě se ref nepředvyplnilo, že by mu vadilo písmeno na konci? ref = HK043m


Viz screenshoty. Rozcestník jsem prozatím do systému nenahrál.



Díky za vaší skvělou práci.


Lukáš





___
Talk-cz mailing list
Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)"

___
Talk-cz mailing list
Talk-cz@openstreetmap.org(mailto:Talk-cz@openstreetmap.org)
https://lists.openstreetmap.org/listinfo/talk-cz
(https://lists.openstreetmap.org/listinfo/talk-cz)

"



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

Re: [OSM-talk-fr] Covoiturage pour Clermont-Ferrand (State of the Map)

[JB]

Pour les hésitants entre covoiturage et train, y a-t-il des possibilités 
de stationnement facile proches de l'événement ?


JB.


Le 04/05/2016 à 10:03, Vincent de Château-Thierry a écrit :

Bonjour,
en prévision du State of the Map à Clermont-Ferrand dans 2 grandes semaines, 
pour ceux qui cherchent une place ou ont des places à proposer dans un 
véhicule, nous avons mis en place ce tableau : 
https://framacalc.org/Covoiturage%20SOTM-FR-2016

Bonne journée,
vincent

ps. en amuse-bouche : 
http://www.dailymotion.com/video/x474g5w_sotm-fr2016-bande-annonce-state-of-the-map-france-2016-clermont-ferrand_tech
 :)

___
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] relation avec plusieurs types (foot, bicycle) ?

[Benoit FOURNIER]

Est-ce qu'on ne perd pas de l'information, avec les liens :

foot <-> network = lwn
bicycle <-> network = lcn
et autres tags name/distance

qui sont noyés dans la description avec une seule relation et liste à
point-virgule ?



2016-05-04 8:42 GMT+02:00 adrien :

> Bonjour,
>
> Je n'avais pas pensé à mettre les valeurs avec des points-virgules.
> J'avais essayé de mettre plusieurs balise « root ».
>
> Il faudrait donc que je taggue plutôt comme ceci selon vous :
>
> type = root
> root  = foot; bicycle; horse
> network = lwn; lcn
> name = blabla
> distance = XX km
>
> au lieu de trois relations :
>
> type = root
> root = foot
> network = lwn
> name = blabla
> distance = XX km
> -
> type = root
> root = bicycle
> network = lcn
> name = blabla
> distance = XX km
> -
> type = root
> root = horse
> name = blabla
> distance = XX km
>
>
> Étant tout débutant dans les relations, j'apprends par vos commentaires !
>
> Bonne journée
>
> Adrien
>
>
> Le 04/05/2016 04:25, Philippe Verdy a écrit :
>
> JOSM ne sait pas voir qu'une relation a des tags différents. Il croit que
> ces relations pourraient n'en faire qu'une alors qu'il y a des tags en
> conflit, en supposant qu'on puisse fusionner ces tags en un seul avec les
> valeurs dans un ordre quelconque mais séparées par des points-virgules.
> Pourtant si c'est possible quand il y a un seul tel tag, il y a aussi
> d'autres tags uniques spécifiques pour une valeur précise du tag en conflit
> mais pas un autre.
> La fusion n'est donc pas toujours possible.
> En revanche JOSM a raison de râler si entre ces relations tous les tags
> (hormi les tags à ignorer comme source=* ou les tags rendus invisibles par
> défaut comme created_by=* qui doivent migrer maintenant en tags non plus
> sur les objets mais sur les changesets) sont identiques car c'est alors un
> doublon.
> Je trouve dommage que JOSM au moins ne fasse pas cette vérification pour
> savoir si c'est un vrai doublon pour modifier la sévérité du texte de
> l'avertissement.
> Comme il ne sait pas faire, en attendant il ne déclare pas que ce sont des
> erreurs, mais juste des avertissements: c'est à l'utilisateur de voir si
> c'est un vrai doublon ou pas et de décider s'il doit fusionner ou pas.
>
> Mais si on prend l'exemple d'une relation route qui est indifféremment
> pour piétons, cyclistes ou chevaux, je ne vois pas bien ce qui empêche de
> fusionner les relations avec un tag énumérant les valeurs possibles entre
> point-virgule. L'autre solution ce serait de taguer "foot", "bicycle" et
> "horse" non pas en valeur d'un attribut mais dans un nom d'attribut (comme
> on le fait pour "access=foot;bicycle" transformé en
> "access:foot=yes"+"access:bicycle=yes"
>
> Cela reviendrait alors à ne plus utiliser "type=route" + route=foot" dans
> une relation, et "type=route" + route=bicyle" dans une autre;
> mais d'utiliser "type="route" dans une seule relation avec deux tags
> "route:foot=yes" + "route:bicycle=yes" (et non pas un seul
> "route=foot;bicyle").
>
> On a des exemples similaires avec "shop=*".
>
> On a pourtant le cas ou la défusion du tag à valeurs multiples en deux
> tags séparés (tout en gardant une relation unique) n'a pas été fait:
> "landuse=commercial;industrial" qui pourait aussi devenir
> "landuse:commercial=yes"+"landuse:industrial=yes".
>
> On n'est pas toujours très cohérent dans OSM...
>
>
> Le 3 mai 2016 à 20:21, Jo  a écrit :
>
>> Ça choquera JOSM aussi. Le validateur viendra dire qu'il y 3 relations
>> avec les mêmes membres.
>> Néanmoins, pour moi, ça me semble la bonne solution. Il y a des doublons
>> dans les itinéraires des bus pour lesquelles je dois créer de telles
>> relations qui ne diffèrent que par leur tags.
>>
>> Polyglot
>>
>> 2016-05-03 19:05 GMT+02:00 Stéphane Péneau < 
>> stephane.pen...@wanadoo.fr>:
>>
>>> Heu... il n'y a que moi que ça choque ?
>>> Quelle est la logique derrière ça ?
>>> Ce ne serait pas plutôt à waymarkedtrails.org
>>>  de gérer ce genre de cas ?
>>>
>>> Stf
>>>
>>>
>>> Le 03/05/2016 à 18:45, adrien a écrit :
>>>
>>> OK merci pour la réponse, y-a-plus-qu'à !
>>>
>>> Adrien
>>>
>>> Le 02/05/2016 18:08, David Crochet a écrit :
>>>
>>> Bonjour
>>>
>>> Le 02/05/2016 17:39, adrien a écrit :
>>>
>>>   faut-il que j'ajoute une relation par type de
>>> déplacement, sachant que c'est le même circuit ?
>>>
>>> oui
>>>
>>> Cordialement
>>>
>>>
>>> ___
>>> Talk-fr mailing 
>>> listTalk-fr@openstreetmap.orghttps://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] Improving coverage of exit numbers and destinations on motorways

[Greg Morgan]

On Tue, May 3, 2016 at 2:46 AM, Jinal Foflia  wrote:

> There has been a recent push to improve the coverage of exit numbers and
> destination signs on the motorways in the US by the data team at Mapbox.
> Some context here [1][2][3][4]. The primary sources of data were DoT
> documents and Mapillary images.
>
One of the first things that I mapped was exit numbers.  At least that
would provide some clue about the distance you have left or what not.  That
is a great first step but the focus is on urban mapping.  More important
for long distance driving or even navigation are mile markers.  The exit
numbers are tied to the mile markers.  The traffic engineer makes a
decision on an exit number based on the proximity of a mile marker. I have
added part of a press release[2] from Arizona DOT. Milepost/mile maker 346
is referenced.  Milepost/mile markers are far more valuable[1] but are not
rendered and thus have little value to an urban mapper or little reward for
the effort involved.  Also note that the exit numbers/mile makers for a
motorway will reset at state borders.  As I recall I-15 ends around 411 as
you enter Idaho.  Finally, expect gaps in the the exit numbers. Two or more
routes may share a section of the road for awhile until they diverge in
other directions.  Another case, is when the route is split by a city.  In
this case, a route might have run through a city at one time.

The work flow that you mention drive me batty.[0]  At one time there was a
discussion on the list about moving exit_to tags as destination tags on the
ramp.  I moved most of the exit_to tags that I mapped to the ramps.  Here
you are proposing something different by leaving some exit_to tags and
adding destination tags occasionally.  The batty part, is that the original
way I mapped these without exit_to was what I found in Europe. It looks
like Paul has a point because junction:ref is in the wiki page
that Duane cites. I don't know that you can use "does not look like
the x tagging
scheme is very common" or "we will continue to follow the conventional
tagging" when the wiki page has changes as recent as 9/2015.

I don't mind adding these features but there has to be something presented
on the main OSM maps other than another art project.  If you are looking
for mapper participation or encouraging passive users to become mappers,
then there has to be a reward on the main OSM site.  Otherwise, OSM has
developed the most boring video game that shows no lights nor rings any
bells.  It is the cartographers and not the importers that are killing off
mappers!

Regards,
Greg


[0] https://gist.github.com/poornibadrinath/f982a947c6a063ed1a9016a2d3246d4a
Look out for red outer circle for missing destination. Use open in JOSM
button to open the node in JOSM. Orange outer circle represents exit_to tag
and we don't need to add destination tags in the way. Green outer circle
represent that the concern way already has destination tag.

[1] http://www.openstreetmap.org/node/3910143420

[2] Bridge work to close State Route 89 for four hours late Friday
Those traveling between Prescott and I-40 should consider alternate routes

PHOENIX ‒ State Route 89 will close for four hours approximately 13 miles
north of Chino Valley starting at 9 p.m. Friday, May 6, so crews can pour a
concrete bridge deck at Hell Canyon __(milepost 346).__ It’s one of the
final steps in readying a $14.4 million bridge scheduled to open to traffic
in mid-June.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[OSM-talk-fr] Covoiturage pour Clermont-Ferrand (State of the Map)

[Vincent de Château-Thierry]

Bonjour,
en prévision du State of the Map à Clermont-Ferrand dans 2 grandes semaines, 
pour ceux qui cherchent une place ou ont des places à proposer dans un 
véhicule, nous avons mis en place ce tableau : 
https://framacalc.org/Covoiturage%20SOTM-FR-2016

Bonne journée,
vincent

ps. en amuse-bouche : 
http://www.dailymotion.com/video/x474g5w_sotm-fr2016-bande-annonce-state-of-the-map-france-2016-clermont-ferrand_tech
 :)

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

Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz

[Hynek Řehoř]

Ahoj,

jak často se "párují" fotky nahrané přes http://map.openstreetmap.cz/work2/
s rozcestníky? O víkendu jsem nafotil 3 rozcestníky v Jindřichovicích pod
Smrkem, v pondělí uploadoval ,a stále se zobrazují jako bez ref a fota.
Fotky jsou v pořádku nahraná, kontroloval jsem.

Dík, Hynek

2016-04-27 14:33 GMT+02:00 Petr Vozdecký :

> Ahoj,
>
> ref rozcestníku prosím v tomto případě jen HK043. Písmeno na konci je
> identifikační písmeno směrníku (konkrétní tabulky). Písmeno "m" definuje
> tabulku se jménem místa (název TIM).
>
> vop
>
> -- Původní zpráva --
> Od: Lukas Novotny 
> Komu: OpenStreetMap Czech Republic 
> Datum: 27. 4. 2016 9:36:18
> Předmět: Re: [Talk-cz] OsmHiCheck chybejici rozcestniky do osmap.cz
>
>
> Dne 27. dubna 2016 8:24 Marián Kyral  napsal(a):
>
> Souřadnice a ref jsou předvyplněny z OSM (ref jen pokud je).
>
>
> Tak mě se ref nepředvyplnilo, že by mu vadilo písmeno na konci? *ref* =
> HK043m
> Viz screenshoty. Rozcestník jsem prozatím do systému nenahrál.
>
> Díky za vaší skvělou práci.
> Lukáš
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk-fr] relation avec plusieurs types (foot, bicycle) ?

[Florian LAINEZ]

Le 4 mai 2016 à 08:42, adrien  a écrit :

> Il faudrait donc que je taggue plutôt comme ceci selon vous :
>
> type = root
> root  = foot; bicycle; horse
> network = lwn; lcn
> name = blabla
> distance = XX km
>

Bonjour, c'est en effet ce qui me parait le plus logique


-- 

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

Re: [Talk-es] 10as Jornadas de SIG Libre y 2a Conferencia QGIS: Yaqueda menos!

[Lluís Vicens]

On 04/05/16 05:47, Jose Alberto Gonzalez von Schmeling wrote:

Yo vivo en Paraguay, y me interesa mucho que haya streaming.

Buenos días José Alberto,

Por el momento, y lamentándolo  mucho, no está previsto programar un 
/streaming/ por cuestiones de coste y logísticas. Lo que sí hacemos es 
grabar tantas sesiones como podamos y colgar los vídeos, posteriormente, 
en nuestro canal de Vimeo [1]. No están todas las charlas, pero si buena 
parte de ellas.


Saludos,
Lluís

[1] http://bit.ly/24x7gDH



El 3 de mayo de 2016, 04:10, pcvalverde> escribió:


Me gustaría mucho ir pero son muchos los gastos estancia, comida,
entradas.
¿se verá por streaming?
Saludos.
Pepe

- Original Message -
*From:* Jornadas de SIG Libre 
*To:* talk-es@openstreetmap.org

*Sent:* Thursday, April 28, 2016 3:54 PM
*Subject:* [Talk-es] 10as Jornadas de SIG Libre y 2a
Conferencia QGIS: Yaqueda menos!

Saludos,

Quedan menos de 30 días para la celebración de las 10as
Jornadas de SIG Libre y la 2a Conferencia Internacional de
QGIS, patrocinadas por GeoCat [1] y Boundless [2], y que
tendrán lugar en Girona los próximos 24,25 y 26 de Mayo[3].
Ven a celebrar con nosotros, nuestro décimo aniversario!

En el sitio webdel evento, encontrarás toda la información
actualizada con respecto al programa de ponencias plenarias
[4], el programa de presentaciones de las Jornadasde SIG Libre
[5], el programa de Talleres de las Jornadas de SIG Libre [6]
así como los Workshops de QGIS [7], además del programa de
presentaciones de QGIS [8].

Si aun no estás inscrito al evento, anímate y regístrate en
alguna de las modalidades (individual, profesional o empresa)
que mejor se ajuste a tus necesidades y posibilidades[9], y
acude a las Jornadas de SIG Libre y/o a la 2a Conferencia
Internacional de QGIS. Será una ocasión única para compartir
conocimientos y experiencias.

Ya por último, desde la organización del evento, no podemos
dejar de agradecer a Patrocinadores, Colaboradores y Medios
asociados, así como a asistentes y presentadores, el apoyo a
las Jornadasde SIG y a la Conferencia de QGIS, haciendo
posible esta edición especial.

Contamos con tu presencia en Girona, este próximo mes de Mayo.


-- 
*Local Organizing Committee*

10as Jornadas de SIG Libre
2nd International QGIS User and Developer Conference
-
Pl. Ferrater Mora 1
17071 Girona
infojorna...@sigte.org 

Web site: http://www.sigte.udg.edu/jornadassiglibre/en/
Twitter: http://twitter.com/SIGLibreGirona


[1] https://www.geocat.net/
[2] http://boundlessgeo.com/
[3] http://www.sigte.udg.edu/jornadassiglibre/
[4] http://www.sigte.udg.edu/jornadassiglibre/ponentes/
[5]
http://www.sigte.udg.edu/jornadassiglibre/jornadas-sig-libre/programa/
[6]
http://www.sigte.udg.edu/jornadassiglibre/jornadas-sig-libre/talleres/
[7]

http://www.sigte.udg.edu/jornadassiglibre/international-qgis-user-and-developer-conference/workshops-qgis/
[8]

http://www.sigte.udg.edu/jornadassiglibre/international-qgis-user-and-developer-conference/conferencia-qgis/
[9] http://www.sigte.udg.edu/jornadassiglibre/inscripcion/




___
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




--
Podes encontrarme o comunicarte conmigo en:

  * *Mi blog*: http://proyectosbeta.net/
  * *Facebook*:
http://www.facebook.com/pages/Proyectos-Beta/113277785412256

  * *Twitter*: @proyectosbeta 



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



--
*Lluís Vicens*
Servei de Sistemes d'Informació Geogràfica
-
Universitat de Girona
*SIGTE*
-
Pl. Ferrater Mora 1
17071 Girona
Tel +34 972 418 039 (7025 intern)
ll...@sigte.udg.edu 

http://www.sigte.udg.edu
Twitter http://twitter.com/SIGTE_UDG

___
Talk-es mailing list
Talk-es@openstreetmap.org

Re: [OSM-talk-be] State of the Map Brussels taking shape

[joost schouppe]

> Will there be recordings of sessions and thus need to monitor those
> recordings?
>
> Jo
>

There will definitely be live streaming, and we have our eyes on high
quality recording material also used at FOSDEM and SOTM-EU. But we haven't
found anyone available who has the necessary experience with that
equipment. Plan B is to contract a commercial player or check if the VUB
itself has experience doing this.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] relation avec plusieurs types (foot, bicycle) ?

[Romain MEHUT]

Oui "route".

Le 4 mai 2016 à 09:02, Stéphane Péneau  a écrit
:

> Je suppose que tu voulais dire
> "route" au lieu de "root"  :-)
>
> Je viens de vérifier sur le site waymarkedtrails.org, et c'est supporté :
> "Une balise route avec des valeurs multiples est supportée quand
> celles-ci sont séparées par des points-virgules sans espace autour. La
> classification (et donc la couleur du trajet sur la carte) est déterminée
> par la balise network."
> http://hiking.waymarkedtrails.org/help/rendering
>
> Donc inutile de multiplier le nbr de relation.
>
> Stf
>
>
> Le 04/05/2016 à 08:42, adrien a écrit :
>
> Bonjour,
>
> Je n'avais pas pensé à mettre les valeurs avec des points-virgules.
> J'avais essayé de mettre plusieurs balise « root ».
>
> Il faudrait donc que je taggue plutôt comme ceci selon vous :
>
> type = root
> root  = foot; bicycle; horse
> network = lwn; lcn
> name = blabla
> distance = XX km
>
> au lieu de trois relations :
>
> type = root
> root = foot
> network = lwn
> name = blabla
> distance = XX km
> -
> type = root
> root = bicycle
> network = lcn
> name = blabla
> distance = XX km
> -
> type = root
> root = horse
> name = blabla
> distance = XX km
>
>
> Étant tout débutant dans les relations, j'apprends par vos commentaires !
>
> Bonne journée
>
> Adrien
>
> Le 04/05/2016 04:25, Philippe Verdy a écrit :
>
> JOSM ne sait pas voir qu'une relation a des tags différents. Il croit que
> ces relations pourraient n'en faire qu'une alors qu'il y a des tags en
> conflit, en supposant qu'on puisse fusionner ces tags en un seul avec les
> valeurs dans un ordre quelconque mais séparées par des points-virgules.
> Pourtant si c'est possible quand il y a un seul tel tag, il y a aussi
> d'autres tags uniques spécifiques pour une valeur précise du tag en conflit
> mais pas un autre.
> La fusion n'est donc pas toujours possible.
> En revanche JOSM a raison de râler si entre ces relations tous les tags
> (hormi les tags à ignorer comme source=* ou les tags rendus invisibles par
> défaut comme created_by=* qui doivent migrer maintenant en tags non plus
> sur les objets mais sur les changesets) sont identiques car c'est alors un
> doublon.
> Je trouve dommage que JOSM au moins ne fasse pas cette vérification pour
> savoir si c'est un vrai doublon pour modifier la sévérité du texte de
> l'avertissement.
> Comme il ne sait pas faire, en attendant il ne déclare pas que ce sont des
> erreurs, mais juste des avertissements: c'est à l'utilisateur de voir si
> c'est un vrai doublon ou pas et de décider s'il doit fusionner ou pas.
>
> Mais si on prend l'exemple d'une relation route qui est indifféremment
> pour piétons, cyclistes ou chevaux, je ne vois pas bien ce qui empêche de
> fusionner les relations avec un tag énumérant les valeurs possibles entre
> point-virgule. L'autre solution ce serait de taguer "foot", "bicycle" et
> "horse" non pas en valeur d'un attribut mais dans un nom d'attribut (comme
> on le fait pour "access=foot;bicycle" transformé en
> "access:foot=yes"+"access:bicycle=yes"
>
> Cela reviendrait alors à ne plus utiliser "type=route" + route=foot" dans
> une relation, et "type=route" + route=bicyle" dans une autre;
> mais d'utiliser "type="route" dans une seule relation avec deux tags
> "route:foot=yes" + "route:bicycle=yes" (et non pas un seul
> "route=foot;bicyle").
>
> On a des exemples similaires avec "shop=*".
>
> On a pourtant le cas ou la défusion du tag à valeurs multiples en deux
> tags séparés (tout en gardant une relation unique) n'a pas été fait:
> "landuse=commercial;industrial" qui pourait aussi devenir
> "landuse:commercial=yes"+"landuse:industrial=yes".
>
> On n'est pas toujours très cohérent dans OSM...
>
>
> Le 3 mai 2016 à 20:21, Jo  a écrit :
>
>> Ça choquera JOSM aussi. Le validateur viendra dire qu'il y 3 relations
>> avec les mêmes membres.
>> Néanmoins, pour moi, ça me semble la bonne solution. Il y a des doublons
>> dans les itinéraires des bus pour lesquelles je dois créer de telles
>> relations qui ne diffèrent que par leur tags.
>>
>> Polyglot
>>
>> 2016-05-03 19:05 GMT+02:00 Stéphane Péneau < 
>> stephane.pen...@wanadoo.fr>:
>>
>>> Heu... il n'y a que moi que ça choque ?
>>> Quelle est la logique derrière ça ?
>>> Ce ne serait pas plutôt à waymarkedtrails.org
>>>  de gérer ce genre de cas ?
>>>
>>> Stf
>>>
>>>
>>> Le 03/05/2016 à 18:45, adrien a écrit :
>>>
>>> OK merci pour la réponse, y-a-plus-qu'à !
>>>
>>> Adrien
>>>
>>> Le 02/05/2016 18:08, David Crochet a écrit :
>>>
>>> Bonjour
>>>
>>> Le 02/05/2016 17:39, adrien a écrit :
>>>
>>>   faut-il que j'ajoute une relation par type de
>>> déplacement, sachant que c'est le même circuit ?
>>>
>>> oui
>>>
>>> Cordialement
>>>
>>>
>>> ___
>>> Talk-fr mailing 
>>> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>>
>>> 

Re: [OSM-talk-fr] relation avec plusieurs types (foot, bicycle) ?

[Romain MEHUT]

Bonjour,

Juste un commentaire sur les points virgules, il ne faut pas d'espace donc
cela ferait root=foot;bicycle;horse

Romain

Le 4 mai 2016 à 08:42, adrien  a écrit :

> Bonjour,
>
> Je n'avais pas pensé à mettre les valeurs avec des points-virgules.
> J'avais essayé de mettre plusieurs balise « root ».
>
> Il faudrait donc que je taggue plutôt comme ceci selon vous :
>
> type = root
> root  = foot; bicycle; horse
> network = lwn; lcn
> name = blabla
> distance = XX km
>
> au lieu de trois relations :
>
> type = root
> root = foot
> network = lwn
> name = blabla
> distance = XX km
> -
> type = root
> root = bicycle
> network = lcn
> name = blabla
> distance = XX km
> -
> type = root
> root = horse
> name = blabla
> distance = XX km
>
>
> Étant tout débutant dans les relations, j'apprends par vos commentaires !
>
> Bonne journée
>
> Adrien
>
> Le 04/05/2016 04:25, Philippe Verdy a écrit :
>
> JOSM ne sait pas voir qu'une relation a des tags différents. Il croit que
> ces relations pourraient n'en faire qu'une alors qu'il y a des tags en
> conflit, en supposant qu'on puisse fusionner ces tags en un seul avec les
> valeurs dans un ordre quelconque mais séparées par des points-virgules.
> Pourtant si c'est possible quand il y a un seul tel tag, il y a aussi
> d'autres tags uniques spécifiques pour une valeur précise du tag en conflit
> mais pas un autre.
> La fusion n'est donc pas toujours possible.
> En revanche JOSM a raison de râler si entre ces relations tous les tags
> (hormi les tags à ignorer comme source=* ou les tags rendus invisibles par
> défaut comme created_by=* qui doivent migrer maintenant en tags non plus
> sur les objets mais sur les changesets) sont identiques car c'est alors un
> doublon.
> Je trouve dommage que JOSM au moins ne fasse pas cette vérification pour
> savoir si c'est un vrai doublon pour modifier la sévérité du texte de
> l'avertissement.
> Comme il ne sait pas faire, en attendant il ne déclare pas que ce sont des
> erreurs, mais juste des avertissements: c'est à l'utilisateur de voir si
> c'est un vrai doublon ou pas et de décider s'il doit fusionner ou pas.
>
> Mais si on prend l'exemple d'une relation route qui est indifféremment
> pour piétons, cyclistes ou chevaux, je ne vois pas bien ce qui empêche de
> fusionner les relations avec un tag énumérant les valeurs possibles entre
> point-virgule. L'autre solution ce serait de taguer "foot", "bicycle" et
> "horse" non pas en valeur d'un attribut mais dans un nom d'attribut (comme
> on le fait pour "access=foot;bicycle" transformé en
> "access:foot=yes"+"access:bicycle=yes"
>
> Cela reviendrait alors à ne plus utiliser "type=route" + route=foot" dans
> une relation, et "type=route" + route=bicyle" dans une autre;
> mais d'utiliser "type="route" dans une seule relation avec deux tags
> "route:foot=yes" + "route:bicycle=yes" (et non pas un seul
> "route=foot;bicyle").
>
> On a des exemples similaires avec "shop=*".
>
> On a pourtant le cas ou la défusion du tag à valeurs multiples en deux
> tags séparés (tout en gardant une relation unique) n'a pas été fait:
> "landuse=commercial;industrial" qui pourait aussi devenir
> "landuse:commercial=yes"+"landuse:industrial=yes".
>
> On n'est pas toujours très cohérent dans OSM...
>
>
> Le 3 mai 2016 à 20:21, Jo  a écrit :
>
>> Ça choquera JOSM aussi. Le validateur viendra dire qu'il y 3 relations
>> avec les mêmes membres.
>> Néanmoins, pour moi, ça me semble la bonne solution. Il y a des doublons
>> dans les itinéraires des bus pour lesquelles je dois créer de telles
>> relations qui ne diffèrent que par leur tags.
>>
>> Polyglot
>>
>> 2016-05-03 19:05 GMT+02:00 Stéphane Péneau < 
>> stephane.pen...@wanadoo.fr>:
>>
>>> Heu... il n'y a que moi que ça choque ?
>>> Quelle est la logique derrière ça ?
>>> Ce ne serait pas plutôt à waymarkedtrails.org
>>>  de gérer ce genre de cas ?
>>>
>>> Stf
>>>
>>>
>>> Le 03/05/2016 à 18:45, adrien a écrit :
>>>
>>> OK merci pour la réponse, y-a-plus-qu'à !
>>>
>>> Adrien
>>>
>>> Le 02/05/2016 18:08, David Crochet a écrit :
>>>
>>> Bonjour
>>>
>>> Le 02/05/2016 17:39, adrien a écrit :
>>>
>>>   faut-il que j'ajoute une relation par type de
>>> déplacement, sachant que c'est le même circuit ?
>>>
>>> oui
>>>
>>> Cordialement
>>>
>>>
>>> ___
>>> Talk-fr mailing 
>>> listTalk-fr@openstreetmap.orghttps://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
>>
>>
>
>
> ___
> Talk-fr mailing 
> 

Re: [OSM-talk-fr] relation avec plusieurs types (foot, bicycle) ?

[Stéphane Péneau]

Je suppose que tu voulais dire
"route" au lieu de "root"  :-)

Je viens de vérifier sur le site waymarkedtrails.org, et c'est supporté :
"Une balise |route| avec des valeurs multiples est supportée quand 
celles-ci sont séparées par des points-virgules sans espace autour. La 
classification (et donc la couleur du trajet sur la carte) est 
déterminée par la balise |network|."

http://hiking.waymarkedtrails.org/help/rendering

Donc inutile de multiplier le nbr de relation.

Stf

Le 04/05/2016 à 08:42, adrien a écrit :

Bonjour,

Je n'avais pas pensé à mettre les valeurs avec des points-virgules. 
J'avais essayé de mettre plusieurs balise « root ».


Il faudrait donc que je taggue plutôt comme ceci selon vous :

type = root
root  = foot; bicycle; horse
network = lwn; lcn
name = blabla
distance = XX km

au lieu de trois relations :

type = root
root = foot
network = lwn
name = blabla
distance = XX km
-
type = root
root = bicycle
network = lcn
name = blabla
distance = XX km
-
type = root
root = horse
name = blabla
distance = XX km


Étant tout débutant dans les relations, j'apprends par vos commentaires !

Bonne journée

Adrien

Le 04/05/2016 04:25, Philippe Verdy a écrit :
JOSM ne sait pas voir qu'une relation a des tags différents. Il croit 
que ces relations pourraient n'en faire qu'une alors qu'il y a des 
tags en conflit, en supposant qu'on puisse fusionner ces tags en un 
seul avec les valeurs dans un ordre quelconque mais séparées par des 
points-virgules.
Pourtant si c'est possible quand il y a un seul tel tag, il y a aussi 
d'autres tags uniques spécifiques pour une valeur précise du tag en 
conflit mais pas un autre.

La fusion n'est donc pas toujours possible.
En revanche JOSM a raison de râler si entre ces relations tous les 
tags (hormi les tags à ignorer comme source=* ou les tags rendus 
invisibles par défaut comme created_by=* qui doivent migrer 
maintenant en tags non plus sur les objets mais sur les changesets) 
sont identiques car c'est alors un doublon.
Je trouve dommage que JOSM au moins ne fasse pas cette vérification 
pour savoir si c'est un vrai doublon pour modifier la sévérité du 
texte de l'avertissement.
Comme il ne sait pas faire, en attendant il ne déclare pas que ce 
sont des erreurs, mais juste des avertissements: c'est à 
l'utilisateur de voir si c'est un vrai doublon ou pas et de décider 
s'il doit fusionner ou pas.


Mais si on prend l'exemple d'une relation route qui est 
indifféremment pour piétons, cyclistes ou chevaux, je ne vois pas 
bien ce qui empêche de fusionner les relations avec un tag énumérant 
les valeurs possibles entre point-virgule. L'autre solution ce serait 
de taguer "foot", "bicycle" et "horse" non pas en valeur d'un 
attribut mais dans un nom d'attribut (comme on le fait pour 
"access=foot;bicycle" transformé en 
"access:foot=yes"+"access:bicycle=yes"


Cela reviendrait alors à ne plus utiliser "type=route" + route=foot" 
dans une relation, et "type=route" + route=bicyle" dans une autre;
mais d'utiliser "type="route" dans une seule relation avec deux tags 
"route:foot=yes" + "route:bicycle=yes" (et non pas un seul 
"route=foot;bicyle").


On a des exemples similaires avec "shop=*".

On a pourtant le cas ou la défusion du tag à valeurs multiples en 
deux tags séparés (tout en gardant une relation unique) n'a pas été 
fait: "landuse=commercial;industrial" qui pourait aussi devenir 
"landuse:commercial=yes"+"landuse:industrial=yes".


On n'est pas toujours très cohérent dans OSM...


Le 3 mai 2016 à 20:21, Jo > a écrit :


Ça choquera JOSM aussi. Le validateur viendra dire qu'il y 3
relations avec les mêmes membres.
Néanmoins, pour moi, ça me semble la bonne solution. Il y a des
doublons dans les itinéraires des bus pour lesquelles je dois
créer de telles relations qui ne diffèrent que par leur tags.

Polyglot

2016-05-03 19:05 GMT+02:00 Stéphane Péneau
:

Heu... il n'y a que moi que ça choque ?
Quelle est la logique derrière ça ?
Ce ne serait pas plutôt àwaymarkedtrails.org
 de gérer ce genre de cas ?

Stf


Le 03/05/2016 à 18:45, adrien a écrit :

OK merci pour la réponse, y-a-plus-qu'à !

Adrien

Le 02/05/2016 18:08, David Crochet a écrit :

Bonjour

Le 02/05/2016 17:39, adrien a écrit :

   faut-il que j'ajoute une relation par type de
déplacement, sachant que c'est le même circuit ?

oui

Cordialement


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




___
Talk-fr mailing list
Talk-fr@openstreetmap.org 

Re: [OSM-talk-fr] relation avec plusieurs types (foot, bicycle) ?

[adrien]

Bonjour,

Je n'avais pas pensé à mettre les valeurs avec des points-virgules.
J'avais essayé de mettre plusieurs balise « root ».

Il faudrait donc que je taggue plutôt comme ceci selon vous :

type = root
root  = foot; bicycle; horse
network = lwn; lcn
name = blabla
distance = XX km

au lieu de trois relations :

type = root
root = foot
network = lwn
name = blabla
distance = XX km
-
type = root
root = bicycle
network = lcn
name = blabla
distance = XX km
-
type = root
root = horse
name = blabla
distance = XX km


Étant tout débutant dans les relations, j'apprends par vos commentaires !

Bonne journée

Adrien

Le 04/05/2016 04:25, Philippe Verdy a écrit :
> JOSM ne sait pas voir qu'une relation a des tags différents. Il croit
> que ces relations pourraient n'en faire qu'une alors qu'il y a des
> tags en conflit, en supposant qu'on puisse fusionner ces tags en un
> seul avec les valeurs dans un ordre quelconque mais séparées par des
> points-virgules.
> Pourtant si c'est possible quand il y a un seul tel tag, il y a aussi
> d'autres tags uniques spécifiques pour une valeur précise du tag en
> conflit mais pas un autre.
> La fusion n'est donc pas toujours possible.
> En revanche JOSM a raison de râler si entre ces relations tous les
> tags (hormi les tags à ignorer comme source=* ou les tags rendus
> invisibles par défaut comme created_by=* qui doivent migrer maintenant
> en tags non plus sur les objets mais sur les changesets) sont
> identiques car c'est alors un doublon.
> Je trouve dommage que JOSM au moins ne fasse pas cette vérification
> pour savoir si c'est un vrai doublon pour modifier la sévérité du
> texte de l'avertissement.
> Comme il ne sait pas faire, en attendant il ne déclare pas que ce sont
> des erreurs, mais juste des avertissements: c'est à l'utilisateur de
> voir si c'est un vrai doublon ou pas et de décider s'il doit fusionner
> ou pas.
>
> Mais si on prend l'exemple d'une relation route qui est indifféremment
> pour piétons, cyclistes ou chevaux, je ne vois pas bien ce qui empêche
> de fusionner les relations avec un tag énumérant les valeurs possibles
> entre point-virgule. L'autre solution ce serait de taguer "foot",
> "bicycle" et "horse" non pas en valeur d'un attribut mais dans un nom
> d'attribut (comme on le fait pour "access=foot;bicycle" transformé en
> "access:foot=yes"+"access:bicycle=yes"
>
> Cela reviendrait alors à ne plus utiliser "type=route" + route=foot"
> dans une relation, et "type=route" + route=bicyle" dans une autre;
> mais d'utiliser "type="route" dans une seule relation avec deux tags
> "route:foot=yes" + "route:bicycle=yes" (et non pas un seul
> "route=foot;bicyle").
>
> On a des exemples similaires avec "shop=*".
>
> On a pourtant le cas ou la défusion du tag à valeurs multiples en deux
> tags séparés (tout en gardant une relation unique) n'a pas été fait:
> "landuse=commercial;industrial" qui pourait aussi devenir
> "landuse:commercial=yes"+"landuse:industrial=yes".
>
> On n'est pas toujours très cohérent dans OSM...
>
>
> Le 3 mai 2016 à 20:21, Jo  > a écrit :
>
> Ça choquera JOSM aussi. Le validateur viendra dire qu'il y 3
> relations avec les mêmes membres.
> Néanmoins, pour moi, ça me semble la bonne solution. Il y a des
> doublons dans les itinéraires des bus pour lesquelles je dois
> créer de telles relations qui ne diffèrent que par leur tags.
>
> Polyglot
>
> 2016-05-03 19:05 GMT+02:00 Stéphane Péneau
> >:
>
> Heu... il n'y a que moi que ça choque ?
> Quelle est la logique derrière ça ?
> Ce ne serait pas plutôt àwaymarkedtrails.org
>  de gérer ce genre de cas ?
>
> Stf
>
>
> Le 03/05/2016 à 18:45, adrien a écrit :
>> OK merci pour la réponse, y-a-plus-qu'à !
>>
>> Adrien
>>
>> Le 02/05/2016 18:08, David Crochet a écrit :
>>> Bonjour
>>>
>>> Le 02/05/2016 17:39, adrien a écrit :
   faut-il que j'ajoute une relation par type de
 déplacement, sachant que c'est le même circuit ?
>>> oui
>>>
>>> Cordialement
>>>
>> ___
>> 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
>
>
>
>
> ___
> Talk-fr mailing list
>