Re: [OSM-talk] Cease use of OpenStreetMap/Antifa logo

[Sebastian Martin Dicke via talk]

Hi,

I do not know the situation in other countries, but in Germany trademarks are 
only protected for commercial usage. It is their purpose.

Regards

Sebastian

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

Re: [OSM-talk-fr] Nouvelles communes françaises issues de fusion et OSM

[Philippe Verdy]

Il faut noter aussi que mars 2020 est la date de fusion d'un certain nombre
d'EPCI, dont on connait déjà les contours (par exemple la prochaine
extension de la métropole lilloise ou MEL) car c'est déjà arrêté et on sait
combien d'élus municipaux siègeront dans l'intercommunalité.

Comme c'est déjà connu et qu'on est à moins d'un mois, déjà dans la période
de campagne électorale, on pourrait déjà mettre un "end_date" sur les EPCI
qui vont disparaitre.

Mais peut-on déjà changer les EPCI qui vont changer de périmètre sans
changer d'identité ? Là je parle par exemple de la MEL, avec deux solutions
:
- 1. conserver la relation historique existante avec "end_date=2020-03"
aussi, mais ajouter une autre relation homonyme avec le périmètre étendu et
"start_date=2020-03", éventuellement avec un préfixe "planned:" pour la clé
de "boundary=local_autority", puis après mars passer l'ancienne relation
avec un préfixe "disused:".
- 2. modifier la relation existante (mais alors perdre l'info historique,
et pas facile de déterminer quand le faire de façon pertinente, ni moyen
d'anticiper le changement).

J'aurais tendance à privilégier la solution 1 qui permet la transition en
douceur et pas dans l'urgence (sans compter aussi des références subsistant
encore à l'ancien périmètre pendant les opérations de transfert de
compétence vers les communes ou les nouveaux EPCI, et des recours
administratifs et judiciaires suite aux litiges qui seront liés à ces
transferts), la solution 1 permettant de conserver les liens valides
existants à une date donnée, et savoir ensuite comment et quand faire la
transition pour les références nouvelles.

Ensuite combien de temps garder l'ancienne relation? J'aurais tendance à
dire qu'il faut au moins 2 exercices comptables complets, ou comme l'INSEE
conserver pour au moins 10 ans après la date de dernier recours judiciaire
(davantage si des recours sont déjà amorcés), ce qui permet aussi une
continuité pour l'analyse statistique et la détection d'anomalies ou
d'irrégularités pouvant entraîner des recours judiciaires pour des
transferts pas correctement réalisés ou des "trous" dans les opérations de
contrôle (pas seulement par les organismes publics mais aussi la société
civile qui voudra pouvoir juger de la pertinence de tels changements en
comparant la situation avant/après et pas seulement sur des simulations
estimées).


Le mar. 11 févr. 2020 à 15:17, Rpnpif via Talk-fr 
a écrit :

> Je voudrais proposer de modifier la façon de traiter les communes
> nouvelles françaises dans OSM.
>
> Je considère qu'une nouvelle commune devrait être enregistrée de la même
> façon qu'une ancienne commune issue de fusion de plusieurs communes.
>
> La possibilité de fusion des communes en France est très ancienne, elle
> a plus de 50 ans. Par exemple, certaines communes sont issues d'une
> campagne de fusion des années 1970. Ces dernières portent souvent le nom
> des deux communes séparées d'un trait d'union. Dans OSM, elles ne sont
> pas distinguées des communes non issues de fusion (ou plutôt, celles
> dont on se souvient qu'elles ne sont pas issues de fusion ; si on
> remonte très loin, au Moyen-Âge, ces communes non issues de fusion
> doivent être assez rares).
>
> De façon que je considère arbitraire, les communes issues de fusion
> d'après 2010 (pourquoi ne pas prendre celles avant 2010 ?) , il a été
> décidé ici même de traiter à part les communes nouvelles en ne les
> enregistrant que par leur frontière et sous forme de relation avec leurs
> anciennes communes membres et leur admin_centre. Il a aussi été décidé
> de ne pas les repérer par un nœud place=* contrairement aux communes
> d'avant 2010 même issues de fusion (donc beaucoup comme on l'a vu).
>
> La conséquence la plus visible est que ces communes sont totalement
> invisibles dans le rendu officiel osm.org qui n'affiche pas le nom des
> zones englobées par une frontière sans place=*.  Il y a pourtant
> d'autres limites dont le nom est affiché comme les forêts, etc.
> Geoportail de l'IGN affiche bien, lui, ces nouvelles communes.
>
> On répond que les nouvelles communes ne sont que des délimitations
> administratives qui n'ont pas vocation à être des lieux-dits. Cette
> opinion est contestable car c'est pourtant comme cela que l'on note les
> anciennes communes issues ou non de fusion. De plus dans l'esprit du
> législateur, les nouvelles communes issues de fusions récentes ont
> vocation à fonctionner comme les autres communes en intégrant
> complètement les anciennes qui ne deviennent que des sortes de quartiers
> ou arrondissements. Ces anciennes communes peuvent être des villages et
> parfois des petites villes (plus de 1 habitants aux abords d'une
> grande agglomération).
>
> Par exemple, une commune classique non issue de fusion récente comporte
> souvent un bourg qui est appelé Le Bourg par les habitants et est
> rarement repéré par ce nom dans Osm.org (alors que BANO peut le
> marquer). En général, la mairie décide de noter sur les 

Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

[Philippe Verdy]

Il y a bien une solution aussi pour créer des points de calage: rester sur
le lieu pour faire des mesures à différentes heures pour pouvoir capter
plus de satellites dans des directions différentes. Même avec un capteur de
mauvaise qualité (immédiate) on doit pouvoir obtenir un moyennage correct.
Bref, se fixer un point précis où on pourra caler un appareil précisément,
offrant un dégagement suffisant dans plein de directions, et y revenir.
Certes la mesure ne sera pas faite en 3 minutes mais à plusieurs heures de
la journée (et éventuellement aussi avec plusieurs appareils différents
pour que leurs propres erreurs internes se compensent), on doit pouvoir
faire ça à pas cher, et se former une grille géodésique "maison" qui pourra
servir de référence et qui pourra ensuite être maintenue).

Mettre ensuite cela en ligne en formant une base géodésique avec des fiches
d'observation et de calage. Progressivement augmenter la résolution de
cette grille de triangulation.

Reste alors à bien choisir les points, qui doivent être facilement
observables sur l'imagerie et assez stables sur le terrain: emplacement
d'un puits, pylône électrique, borne kilométrique sur une route, coin de
terrasse sur un toit de bâtiment construit en dur, statue, pilier d'un pont
sur un fleuve, etc. (on évitera les arbres, même isolés, car pas faciles à
caler et n'offrant pas assez de visibilité en différentes saisons, pour que
le point soit aussi observable avec des mois de décalage dans les prises de
vue). Choisir ces points devrait être possible en utilisant l'imagerie
existante pour trouver les points remarquables, facilement calables
visuellement et persistants et faciles aussi d'accès en sécurité (pas au
milieu d'une route, mais pourquoi pas au centre d'une place piétonne à
condition de trouver un emplacement bien marqué).

C'est plus difficile en milieu très rural ou forestier, savane ou désert
car les éléments naturels dominent et n'ont pas de point facilement
remarquables et clairement identifiables une fois sur le terrain, et ce
n'est pas évident non plus d'y rester longtemps pour faire des observations
longues et d'y revenir précisément sans ambiguïté, mais on doit pouvoir y
trouver quand même des constructions stables. Si on ne trouve rien, on peut
se caler sur le marquage au sol des routes, sur un pied de panneau de
signalisation ou publicitaire, et sinon sur un rocher remarquable en
bordure de fleuve, où on pourra aussi matérialiser un point de calage pour
la marquer et la retrouver plus tard sans la confondre avec une autre. Une
photo ajoutée à la fiche devrait aussi aider et plus facile à utiliser
qu'une description (surtout dans un contexte multilingue).



Le ven. 14 févr. 2020 à 11:22, Martin Noblecourt 
a écrit :

> Bonjour,
>
> Merci Séverin de (re)lancer ce sujet toujours aussi problématique.
>
> Côté CartONG on a plutôt appliqué jusqu'à présent la politique soit de
> tracer sur le calage de l'image utilisée si pas de données pré-existantes,
> soit de recaler l'imagerie sur Bing dans le cas de données existantes, pour
> être cohérents avec ces dernières.
>
> L'idéal est bien entendu d'avoir des points de référencement pris sur le
> terrain. En dehors de l'hypothèse de l'achat d'un GPS submétrique, qui
> demanderait une organisation spécifique comme tu l'as mentionné, il reste
> l'option 1) d'essayer d'améliorer la précision des GPS de téléphones (nous
> avons publié un tutoriel, en anglais, contenant quelques techniques pour
> cela
> ),
> et de choisir un smartphone avec un bon capteur GPS (nous avons également fait
> une étude sur le sujet
> ,
> qui a mis en avant des précisions médianes allant de 2m à 5m selon les
> modèles, sachant que la précision est souvent encore plus mauvaise pour les
> marques chinoises "pas chères"... il  y a donc aussi une marge importante
> de ce côté).
>
> Bonne journée,
>
> Martin
> On 14/02/2020 10:51, talk-fr-requ...@openstreetmap.org wrote:
>
> Subject:
> [OSM-talk-fr] Création de points de référence pour calage des imageries
> satellites - quelle approche et quel matériel ?
>
> From:
> "severin.menard" 
> 
>
> Date:
> 14/02/2020, 03:00
>
> To:
> Discussions sur OSM en français 
> 
> Bonjour à tou-te-s,
>
> J'ai eu l'occasion d'en parler de manière informelle à quelques personnes
> et peut-être ce sujet a-t-il déjà été discuté en long et en travers sur un
> fil de cette liste ou sur le forum, mais je ne l'ai pas trouvé. Désolé si
> c'est le cas !
>
> Après une assez longue période (en gros entre 2012 et mi 2017) pendant
> laquelle la communauté OSM s'est appuyée sur l'imagerie Bing pour
> digitaliser, l'arrivée d'autres ressources (Digital Globe en mai 2017, Esri
> puis Maxar remplaçant Digital Globe avec une imagerie différente, qui n'est
> plus disponible actuellement) a permis de bénéficier d’imageries
> 

Re: [Talk-it] Senso unico ad orari prefissati

[Martin Koppenhoefer]

Am Sa., 15. Feb. 2020 um 01:51 Uhr schrieb griphon :

> Considerando quindi che i due segmenti sono già tracciati per il verso del
> senso unico, se non erro quindi la sintassi dovrebbe essere la seguente:
>
> tag:
> oneway
>
> valore + condizione:
> yes:conditional=(Mo-Sa 07:45-08:15; Mo-Sa 15:45-16:15)
>
> Potrebbe essere corretto così?
>


io farei così

oneway=no
oneway:conditional = yes @ (Mo-Sa 07:45-08:15, Mo-Sa 15:45-16:15)

oppure forse al contrario (come fallback per sicurezza potrebbe essere
meglio avere la restrizione più limitante come default)
oneway=yes
oneway:conditional = no @

però in questo caso è solo 1 ora in 6 giorni della settimana, mentre per il
resto è normale, quindi direi la prima va meglio.

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

[talk-au] South Australian bushfire imagery

[Ewen Hill]

A big thank you to Andrew Harvey and ARA Airborne Research Australia for
their bushfire imagery of the Adelaide hills and Kangaroo Island.

Will the Geotiffs be updated overtime Andrew as the detail is
extremely impressive?


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

Re: [Talk-it] Senso unico ad orari prefissati

[griphon]

Considerando quindi che i due segmenti sono già tracciati per il verso del
senso unico, se non erro quindi la sintassi dovrebbe essere la seguente:

tag:
oneway

valore + condizione:
yes:conditional=(Mo-Sa 07:45-08:15; Mo-Sa 15:45-16:15)

Potrebbe essere corretto così?




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

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

Re: [Talk-br] Nova proposta de classificação viária

[santamariense]

> Por outro lado o algorítmo falhou em "capturar" a BR-262 entre Betim e
> Uberaba, que eu conheço bem, é uma estrada pedagiada e claramente exerce
> papel de trunk, parte dela é motorway inclusive.

O algorítimo detecta cidade interconectáveis, não as rotas. O Linhares
deu o parecer dele sobre as rotas entre as cidades. Outros usuários
podem divergir um pouco do resultado, como tu está  fazendo com base
em seus conhecimentos e pareceres da região. O importante é que o
resultado final convirja ao máximo a um consenso ao menos da maioria.

Vamos construir o mapa em conjunto com a comunidade. O problema que
vejo nos teus contrapontos e visão de classificação é que ela tende a
ter descontinuidades topológicas, quando para mapear se olha
estritamente para um trecho de via observando exclusivamente suas
características físicas. A nossa proposta também considera que se
possível, as maiores classificações terão as melhores características
físicas, mas na falta dela em alguns trechos, não afeta a
continuidade.

> Eu também entendo que o "algoritmo" proposto (que eu sempre chamei de
> "metodologia") não deve ser levado sempre ao pé da letra sempre, alguma
> dose de ponderação e interpretação deve ser permitida para tratar de casos
> limítrofes pelo consenso. A "metodologia" é pra ajudar a orientar o
> trabalho de classificação e eliminar da discussão a grande maioria dos
> casos principais.

Isso. O algorítimo é norteador, mas se houver consenso sobre alguns
pontos divergentes do algorítimo, a gente discute e documenta as
exceções.

> No RS, a única restrição aplicada à malha primária é que elas deveriam ser 
> pavimentadas.

Em contato com o DEER MG, fui informado que apenas duas cidades não
tem acesso asfáltico. Elas tem menos de 6 mil habitantes, logo não
parece haver também neste estado a necessidade de primary ou trunk sem
pavimentação.

Sou da mesma opinião de "uma dor de cabeça por vez". Vamos discutir
cada "rota ideal" entre par de cidades por vez.

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

Re: [Talk-br] Nova proposta de classificação viária

[Fernando Trebien]

On Fri, Feb 14, 2020 at 7:14 PM Gerald Weber  wrote:
>
> Oi Fernando
>
> On Fri, 14 Feb 2020 at 14:34, Fernando Trebien  
> wrote:
>>
>> On Thu, Feb 13, 2020 at 10:41 PM Gerald Weber  wrote:
>>>
>>> Enfim, se eu já achava que a proposta era uma má ideia, agora estou 
>>> convencido que se trata de um grande desastre.
>>
>>
>> Para quem?
>
> Para quem precisa confiar que os dados são reflexo da realidade e não reflexo 
> de um algorítmo.

Por que o algoritmo não seria um reflexo da realidade? O fluxograma de
2013 também é um algoritmo, só que mais simples.

>>> Daqui a duas semanas participo de uma banca de mestrado onde se fez 
>>> precisamente isto, extrairam os dados do OSM e fizeram uma análise de 
>>> conectividade. Eu já vi que tiveram problemas com as classificações das 
>>> rodovias. A atual proposta vai agravar a situação e tornar o OSM inútil 
>>> para estudos científicos deste tipo.
>>
>>
>> Pode dar mais detalhes? Eu acredito fortemente que a nova proposta resolverá 
>> problemas de classificação ao invés de prejudicar. Para poder ajudar e poder 
>> dizer se a nova proposta realmente prejudica alguém, gostaria de saber: que 
>> trabalho foi esse, o que estavam tentando fazer, que problemas tiveram, que 
>> estudos científicos estão sendo feitos usando o OSM, etc.
>
>
> Eu vou terminar de ler a dissertação e te falo com mais propriedade. Penso 
> que o texto, após as correções deva ficar disponível on-line, quando isto 
> acontecer eu aviso aqui.
>
> Mas para ficar em exemplos de trabalhos científicos, vamos considerar este 
> artigo:
> https://www.sciencedirect.com/science/article/pii/S2226585615000199
>
> Eu não sei como os mapeadores chineses classificaram suas vias e que regras 
> usaram.

Para alguém com uma opinião forte, soa meio preocupante. E se os
chineses tiverem usado um algoritmo? E se estiverem copiando uma
classificação oficial que dependeu de um algoritmo? O que consta na
página chinesa do artigo key:highway [1] é uma tradução quase ipsis
literis do original em inglês. Já no fórum chinês do OSM só há 44
postagens - o Brasil tem 3808. Para mim, parece que a classificação
atual é resultado da importação de dados de uma fonte de dados
oficial, e a qualidade da classificação portanto reflete a qualidade
dessa fonte de dados. Além disso, a China está cheia de motorways e
trunks, para mim seria interessante saber se a análise da qualidade da
classificação contemplou todos os níveis ou se ateve ao mais altos, o
que pode significar que é apenas efeito colateral da enorme população
desse país.

> dentre elas que o OSM se aproxima mais da realidade que mapas comerciais.

Qual aspecto da realidade?

> mas eu prefiro uma metodologia ancorada na verificação (survey) ou, na 
> impossibilidade desta, na consulta de uma autoridade que realiza este tipo de 
> verificação como o DEER.

Veja bem, a classificação do DEER não tem uma relação 1:1 com qualquer
regra definida por atributos físicos, que é exatamente o que a
proposta de 2013 é. Ou você defende um "algoritmo" baseado em
atributos físicos, ou defende a cópia da classificação funcional
"arbitrária" do DEER. Defender as duas coisas é uma contradição.

> Por exemplo, no caso de MG, o seu algoritmo considerou algumas rodovias ao 
> redor de Diamantina deviam ser trunk. Já pelo DEER-MG ali tem um grande 
> vazio, não há qualquer rodovia trunk (e eu concordo com o DEER neste caso). O 
> que aconteceu? É o Vale do Jequitinhonha, umas das regiões mais pobres de 
> Minas. Tem população que satisfaz o seu critério, mas não tem renda, não tem 
> PIB. Tem gente, mas não tem produtos para transportar que justifiquem uma 
> malha tipo trunk. O grande contraste aqui é o Triângulo Mineiro que é uma 
> região rica permeada por trunks.

Disso eu concluo que esse algoritmo então é, pelo menos do ponto de
vista social, provavelmente mais ético, por não diminuir a importância
das malhas que atendem populações pobres simplesmente por serem
pobres. O efeito de outros métodos é apagar essas malhas do mapa, como
se nessas regiões não houvese nada importante. Essa também é uma das
minhas preocupações, sobretudo nas regiões menos densas (e que também
são mais pobres) do Norte e do Centro-Oeste. Não havendo vias de
classificação alta lá, perde-se discernibilidade, para quem mora e
transita na região, entre as vias que são melhores e as que não são no
contexto regional.

Eu acho importante notar que é muito raro alguém fazer uma viagem
terrestre muito longa, e que a maioria das viagens terrestres está
limitada àquilo que se pode fazer em 1 ou no máximo 2 dias de viagem.
Quando você aplica essa janela à classificação das vias e faz a
classificação de forma comparativa dentro da área correspondente a
esse contexto, você acaba produzindo um mapa mais útil pra mais gente.
Só é menos útil pra quem quer ter um termômetro de qualidade/segurança
viária que seja rigidamente válido em todas as partes do mundo,
ignorando suas disparidades. Talvez por isso os mapas comerciais não

Re: [Diversity-talk] [Osmf-talk] First Meeting of Diversity and Inclusion Special Committee

[Mikel Maron]

Thanks everyone for the follow on discussion. Please keep it going!

I had promised a next action myself to digest and post to OSMF wiki, including 
some next steps that others can take up. But I ran out of time, and that's not 
going to happen for another 1.5 weeks, I'm going offline for the kids' school 
break. 

In the mean time, if someone wanted to step in and start organizing my notes 
into more tangible discrete tasks, please do. 

Something else I intend to do is more direct outreach to folks to join this 
group. We need more diversity in the diversity committee! I think there's a lot 
OSMF can learn from what other folks have already done in our community, and I 
hope to develop relationships to explore this more.

-Mikel


On Wednesday, February 12, 2020, 01:15:48 PM EST, Mikel Maron 
 wrote: 





We just concluded second of two meetings today. Lots to digest, thanks to those 
who were able to make it. Raw notes are at 
https://hackmd.io/3cy5P9fhSvSVI8gkIHIX6w?view. My next action is to digest a 
bit, and create a page on the OSMF wiki with some things that came out of the 
meeting.

Other next steps. Maggie is going to start a OSM wiki page to gather previous 
research, Rory is looking at tweaks to the Diversity Statement, and Jinal is 
putting together a short form to gather details on interest from people who 
didn't make this meeting.

-Mikel

* Mikel Maron * +14152835207 @mikel s:mikelmaron






On Thursday, February 6, 2020, 01:41:45 PM EST, Mikel Maron 
 wrote: 






Last month, the OSMF adopted this Diversity Statement [1] and appointed a 
committee [2] to compile research and undertake new research on our diversity, 
identify root causes that contribute to any shortfalls, and make 
recommendations to help resolve issues and improve. 

If you're interested to take part, join an upcoming initial meeting of the 
committee. We're holding a first meeting on Wednesday February 12 at 1400 UTC 
[3] on Mumble [4] (in the public OSMF Board of Directors room). Please join if 
you'd like to contribute. If you're unavailable at that time, let us know other 
times that might work, and we can schedule another kickoff meeting in addition.

[1] https://wiki.osmfoundation.org/wiki/Diversity_Statement
[2] https://hackmd.io/ZG8x44H4Skq0CPkcrMTB6A?view
[3] Timezone converter: 
https://www.timeanddate.com/worldclock/fixedtime.html?msg=DISC+Meeting=20200212T14=1440
[4] How to use Mumble: https://wiki.openstreetmap.org/wiki/Mumble

-Mikel




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

___
Diversity-talk mailing list
Code of Conduct: 
https://wiki.openstreetmap.org/wiki/Diversity/MailingList/CodeOfConduct
Contact the mods (private): diversity-talk-ow...@openstreetmap.org

Re: [OSM-talk] copying numbering (ref)

[stevea]

Or, using unsigned_ref=* is an option.
SteveA

> On Feb 14, 2020, at 1:08 PM, Joseph Eisenberg  
> wrote:
> 
> > “ they don't really use numbers for roads except internally”
> 
> If they do not post signs, and locals do not usually know the numbers, then 
> there should not be a ref for those provincial roads in Openstreetmap.
> 
> -Joseph Eisenberg
> ___
> 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-br] Nova proposta de classificação viária

[Gerald Weber]

Oi Fernando

On Fri, 14 Feb 2020 at 14:34, Fernando Trebien 
wrote:

> On Thu, Feb 13, 2020 at 10:41 PM Gerald Weber  wrote:
>
>> Enfim, se eu já achava que a proposta era uma má ideia, agora estou
>> convencido que se trata de um grande desastre.
>>
>
> Para quem?
>

Para quem precisa confiar que os dados são reflexo da realidade e não
reflexo de um algorítmo.


>
>
>> Daqui a duas semanas participo de uma banca de mestrado onde se fez
>> precisamente isto, extrairam os dados do OSM e fizeram uma análise de
>> conectividade. Eu já vi que tiveram problemas com as classificações das
>> rodovias. A atual proposta vai agravar a situação e tornar o OSM inútil
>> para estudos científicos deste tipo.
>>
>
> Pode dar mais detalhes? Eu acredito fortemente que a nova proposta
> resolverá problemas de classificação ao invés de prejudicar. Para poder
> ajudar e poder dizer se a nova proposta realmente prejudica alguém,
> gostaria de saber: que trabalho foi esse, o que estavam tentando fazer, que
> problemas tiveram, que estudos científicos estão sendo feitos usando o OSM,
> etc.
>

Eu vou terminar de ler a dissertação e te falo com mais propriedade. Penso
que o texto, após as correções deva ficar disponível on-line, quando isto
acontecer eu aviso aqui.

Mas para ficar em exemplos de trabalhos científicos, vamos considerar este
artigo:
https://www.sciencedirect.com/science/article/pii/S2226585615000199

Na Eq (2) ele calcula uma diversidade de rodovias, H', na China referente
ao OSM de 2014. Eu não sei como os mapeadores chineses classificaram suas
vias e que regras usaram. Mas note que o trabalho tira várias conclusões
importantes, e fica claro que neste trabalho os autores tem a consciência
que essas classificações dependem fortemente da decisão do mapeador. Os
autores comparam densidade de rodovias com diversidade de classificação e
tiram várias conclusões, dentre elas que o OSM se aproxima mais da
realidade que mapas comerciais.

Imagina agora que você introduz um viés algorítmico na classificação das
vias, o que pode acontecer é que estudos similares no futuro vão gerar
resultados que vão estar "contaminados" por isto.  Por exemplo alguém
poderia analisar a diversidade de rodovias do Brasil e ficar espantado em
concluir que ela segue uma lei perfeita que depende da raíz quadrada das
populaçoes que conectam as vias. Ou seja, em vez de capturar a realidade,
capturou o modo de funcionamento do algorítmo.


> Eu também entendo que o "algoritmo" proposto (que eu sempre chamei de
> "metodologia") não deve ser levado sempre ao pé da letra sempre, alguma
> dose de ponderação e interpretação deve ser permitida para tratar de casos
> limítrofes pelo consenso. A "metodologia" é pra ajudar a orientar o
> trabalho de classificação e eliminar da discussão a grande maioria dos
> casos principais.
>

O ponto central da sua metodologia é uma abordagem algorítmica. Eu entendo
a sua preocupação e respeito o seu esforço, mas eu prefiro uma metodologia
ancorada na verificação (survey) ou, na impossibilidade desta, na consulta
de uma autoridade que realiza este tipo de verificação como o DEER.

Agora eu acho que tem muito mérito esse seu trabalho. Ele reflete a
disparidade da conectividade de rodovias no Brasil. Isto está muito claro.
Por exemplo, no caso de MG, o seu algoritmo considerou algumas rodovias ao
redor de Diamantina deviam ser trunk. Já pelo DEER-MG ali tem um grande
vazio, não há qualquer rodovia trunk (e eu concordo com o DEER neste caso).
O que aconteceu? É o Vale do Jequitinhonha, umas das regiões mais pobres de
Minas. Tem população que satisfaz o seu critério, mas não tem renda, não
tem PIB. Tem gente, mas não tem produtos para transportar que justifiquem
uma malha tipo trunk. O grande contraste aqui é o Triângulo Mineiro que é
uma região rica permeada por trunks.

Olhando a lista de rodovias que você mostrou no seu email anterior, aquilo
basicamente esgota o que pode ser trunk em MG, a maioria são rodovias
pedagiadas, isso é de fácil verificação. Agora como a proposta também cobre
classificação de primary, eu temo que a situação possa ficar mais
intratável. Quando chegar o momento de classificar as vias primárias pelo
algorítmo aí eu penso que distorções bem maiores podem acontecer sem nenhum
claro benefício para o usuário do mapa.

De todo modo agradeço por este trabalho e pela proposta, mas acho
desaconselhável substituir o atual esquema de rodovias por algo assim.

um abraço e bom final de semana

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

Re: [OSM-talk] copying numbering (ref)

[Joseph Eisenberg]

> “ they don't really use numbers for roads except internally”

If they do not post signs, and locals do not usually know the numbers, then
there should not be a ref for those provincial roads in Openstreetmap.

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

Re: [OSM-talk] copying numbering (ref)

[Martin Koppenhoefer]

sent from a phone

> Il giorno 14 feb 2020, alle ore 16:40, Mario Frasca  ha 
> scritto:
> 
> what would you do?


what’s posted on the ground?

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

Re: [Talk-it] Senso unico ad orari prefissati

[Martin Koppenhoefer]

sent from a phone

> Il giorno 14 feb 2020, alle ore 18:44, Andrea Albani  ha 
> scritto:
> 
> In questo caso si applica oneway:conditional


+1, perché è la soluzione più semplice, anche se
oneway:forward:conditional e oneway:backward:conditional non sarebbero 
sbagliati.


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

Re: [Talk-it] centro riparazione elettrodomestici

[Francesco Ansanelli]

Il ven 14 feb 2020, 10:24 Martin Koppenhoefer  ha
scritto:

>
> Am Do., 13. Feb. 2020 um 09:22 Uhr schrieb demon_box <
> e.rossini7...@gmail.com>:
>
>>
>> appunto, io per ora utilizzo
>>
>> craft=appliances_repair
>>
>> grazie
>>
>
>
> mi sembra adatto come tag.
> Purtroppo usato pochino,
>
> 6x craft=appliance_repair
> 3x craft=appliances_repair
>
> Lo vogliamo documentare? Meglio singolare o plurale?
>

Direi singolare... Per me ok documentarlo, magari anche andando a sistemare
i casi al plurale.
Francesco

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

Re: [OSM-talk-fr] ref et ref:FR

[deuzeffe]

Beau boulot !

Effectivement, c'est vaguement le bazar dans les ref* et dans leur 
classement sur la page en cours sur le wiki :/


Le 14/02/2020 à 19:20, leni a écrit :


Le 11/02/2020 à 23:47, François Lacombe a écrit :

Bonsoir à vous

+1 avec vous, bonne idée de séparer le tableau, pourquoi pas par 
thèmes, comme nous le faisons pour les Map Features ?
Sur le caractère national/local, pourquoi pas ajouter une colonne dans 
les tables pour le préciser ?



Comme j'ai du mal à définir les thèmes (et à savoir à quoi tout 
correspond), j'ai récupéré le tableau du wiki que j'ai mis en libre 
accès sur https://lite.framacalc.org/9f0b-osm_ref_fr


J'ai ajouté une colonne thème et une national/local et j'ai séparé les 
ref France existants :


- ceux qui n'ont pas de FR: (8)
- ceux qui sont avec fr_ (2)
- ceux qui sont en FR: (38)
- ceux qui sont dans osm et qui ne sont pas dans le wiki : les plus 
nombreux (96)


J'en ai certainement loupé ...

bonne soirée

leni


___
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] Tagger correctement les panneaux entrées de villes & villages

[Sébastien Hinderer]

Bravo pour ce travail c'est hyper enthousiasmant!
Et merci pour le petit exemple OverPass, c'est instructif à lire!

Sébastien.

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

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[Jérôme Seigneuret]

Bien joué 


Le ven. 14 févr. 2020 à 19:48,  a écrit :

> Bonsoir,
>
> ça y est, nous avons fini la journée de Cartopartie à tagger les panneaux
> d'entrée et de sorties de villes du Gers.
> 966 panneaux ont été créés.
>
> Voici la requette Overpass Turbo pour consulter les données:
>
> [out:json][timeout:25];
> // Définir la zone de recherche:
> {{geocodeArea:"Gers"}}->.dept;
> ( // Prospecter pour les noeuds, chemins et relation
> node["traffic_sign:forward"="city_limit"](area.dept);
> node["traffic_sign:backward"="city_limit"](area.dept);
> node["traffic_sign"="city_limit"](area.dept);
> node["traffic_sign"="city_limit,FR:EB10"](area.dept);
> node["traffic_sign"="city_limit,FR:EB20"](area.dept);
> );
> // Afficher les résultats:
> out body;
> >;
> out skel qt;
>
>
> Je dois encore vérifier et corriger quelques petites choses pour voir s'il
> n'y a pas d'erreurs.
> Je compléterais également la doc OSM.
>
> Nous n'avons pas tant utilisés le tag traffic_sign:forward car certains
> étudiants n'étaient pas forcément à l'aise avec le sens du tracet, etc.
>
> Merci à tous ceux qui m'ont aidé à préparé et débrousailler ce travail!
>
> Bonne soirée,
>
> Onésime.
>
> --
> *De: *onesim...@free.fr
> *À: *"Discussions sur OSM en français" 
> *Envoyé: *Jeudi 13 Février 2020 23:26:01
> *Objet: *Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
> villes & villages
>
> Bonsoir,
>
> Ok, merci pour cette précisions.
> Je vais voir comment ça se passe.
> Et si jamais c'est trop compliqué de tagger directement dans OSM, est ce
> qu'on peut transmettre le fichier shapefile avec les données, et les
> métadonnées pour que quelqu'un puisse les charger directement dans OSM? Si
> oui, comment ça se passe, il y a un lieu fait pour ça, ou c'est sur ce
> genre de liste?
> Avant, on utilisait le plugin OSM de QGis, mais maintenant il n'y ai
> plus... et l'utilisation de Josm est un peu compliquée à employer dans le
> cadre d'une cartopartie avec des personnes qui ne sont pas familières.
>
> Merci à vous,
>
> Onésime.
>
> --
> *De: *"Florimond Berthoux" 
> *À: *"Discussions sur OSM en français" 
> *Envoyé: *Mercredi 12 Février 2020 22:13:39
> *Objet: *Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
> villes & villages
>
>
> Sur le wiki en créant une page, par exemple en anglais tu suis un des
> liens et tu appuies sur "créer"
> https://wiki.openstreetmap.org/wiki/Key:pole:sealed
> ou https://wiki.openstreetmap.org/wiki/Key:support:sealed
>
> Le mar. 11 févr. 2020 à 21:30,  a écrit :
>
>> Ok, je vais tenter avec cela.
>> Pour le documenter, comment ça se passe?
>>
>> Merci!
>>
>> --
>> *De: *"Florimond Berthoux" 
>> *À: *"Discussions sur OSM en français" 
>> *Envoyé: *Mardi 11 Février 2020 19:38:44
>> *Objet: *Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de
>> villes & villages
>>
>> Tout bien réfléchi je pense que c'est une erreur de considérer le sol ou
>> le béton comme étant le support du poteau (c'est pas faux, mais pas top non
>> plus).
>> Je verrais plutôt un tag pour préciser si le poteau est scellé ou non
>> dans du béton.
>>
>> propositions :
>> support:sealed=yes|concrete
>> ou
>> pole:sealed=yes|concrete
>>
>> (sealed ou embedded ?)
>>
>> @Onésime oui il n'y a pas de tag documenté pour différencier les poteaux
>> scellé des non scellé.
>> Dans l'absolue vaut mieux inventer inventer un nouveau tag, le
>> documenter, et s'il faut le changer un peu plus tard on pourra le faire de
>> façon presque automatique.
>>
>> Le mar. 11 févr. 2020 à 14:34, marc marc  a
>> écrit :
>>
>>> Le 11.02.20 à 14:05, Florimond Berthoux a écrit :
>>> > support=pole
>>> > support:pole:support=ground
>>> >
>>> > plutôt parce que s’il y a plusieurs support (support=pole;wall) on
>>> > pourra pas préciser le support de quel support.
>>>
>>> une photo d'un panneau supporté à la fois par un poteau et un mur ?
>>> j'ai l'impression qu'on est une fois de +  entrain de faire une usine à
>>> gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus
>>> complexe que le cas par défaut. et le contributeur lambda est largé
>>> depuis longtemps par la marche toujours plus grande à entrée...
>>>
>>> > Le mar. 11 févr. 2020 à 00:15, marc marc a écrit :
>>> >
>>> > support=pole : le panneau est porté par un poteau
>>> > support:support=ground : le poteau est directement mis dans le sol
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> --
>> Florimond Berthoux
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Florimond 

Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & villages

[onesime31]

Bonsoir, 


ça y est, nous avons fini la journée de Cartopartie à tagger les panneaux 
d'entrée et de sorties de villes du Gers. 
966 panneaux ont été créés. 


Voici la requette Overpass Turbo pour consulter les données: 


[out:json][timeout:25]; 
// Définir la zone de recherche: 
{{geocodeArea:"Gers"}}->.dept; 
( // Prospecter pour les noeuds, chemins et relation 
node["traffic_sign:forward"="city_limit"](area.dept); 
node["traffic_sign:backward"="city_limit"](area.dept); 
node["traffic_sign"="city_limit"](area.dept); 
node["traffic_sign"="city_limit,FR:EB10"](area.dept); 
node["traffic_sign"="city_limit,FR:EB20"](area.dept); 
); 
// Afficher les résultats: 
out body; 
>; 
out skel qt; 




Je dois encore vérifier et corriger quelques petites choses pour voir s'il n'y 
a pas d'erreurs. 
Je compléterais également la doc OSM. 


Nous n'avons pas tant utilisés le tag traffic_sign:forward car certains 
étudiants n'étaient pas forcément à l'aise avec le sens du tracet, etc. 


Merci à tous ceux qui m'ont aidé à préparé et débrousailler ce travail! 


Bonne soirée, 



Onésime. 

- Mail original -

De: onesim...@free.fr 
À: "Discussions sur OSM en français"  
Envoyé: Jeudi 13 Février 2020 23:26:01 
Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & 
villages 



Bonsoir, 


Ok, merci pour cette précisions. 

Je vais voir comment ça se passe. 
Et si jamais c'est trop compliqué de tagger directement dans OSM, est ce qu'on 
peut transmettre le fichier shapefile avec les données, et les métadonnées pour 
que quelqu'un puisse les charger directement dans OSM? Si oui, comment ça se 
passe, il y a un lieu fait pour ça, ou c'est sur ce genre de liste? 
Avant, on utilisait le plugin OSM de QGis, mais maintenant il n'y ai plus... et 
l'utilisation de Josm est un peu compliquée à employer dans le cadre d'une 
cartopartie avec des personnes qui ne sont pas familières. 


Merci à vous, 


Onésime. 

- Mail original -

De: "Florimond Berthoux"  
À: "Discussions sur OSM en français"  
Envoyé: Mercredi 12 Février 2020 22:13:39 
Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & 
villages 





Sur le wiki en créant une page, par exemple en anglais tu suis un des liens et 
tu appuies sur "créer" 

https://wiki.openstreetmap.org/wiki/Key:pole:sealed 
ou https://wiki.openstreetmap.org/wiki/Key:support:sealed 


Le mar. 11 févr. 2020 à 21:30, < onesim...@free.fr > a écrit : 





Ok, je vais tenter avec cela. 
Pour le documenter, comment ça se passe? 


Merci! 



De: "Florimond Berthoux" < florimond.berth...@gmail.com > 
À: "Discussions sur OSM en français" < talk-fr@openstreetmap.org > 
Envoyé: Mardi 11 Février 2020 19:38:44 
Objet: Re: [OSM-talk-fr] Tagger correctement les panneaux entrées de villes & 
villages 



Tout bien réfléchi je pense que c'est une erreur de considérer le sol ou le 
béton comme étant le support du poteau (c'est pas faux, mais pas top non plus). 
Je verrais plutôt un tag pour préciser si le poteau est scellé ou non dans du 
béton. 


propositions : 
support:sealed=yes|concrete 
ou 

pole:sealed=yes|concrete 


(sealed ou embedded ?) 



@Onésime oui il n'y a pas de tag documenté pour différencier les poteaux scellé 
des non scellé. 
Dans l'absolue vaut mieux inventer inventer un nouveau tag, le documenter, et 
s'il faut le changer un peu plus tard on pourra le faire de façon presque 
automatique. 




Le mar. 11 févr. 2020 à 14:34, marc marc < marc_marc_...@hotmail.com > a écrit 
: 


Le 11.02.20 à 14:05, Florimond Berthoux a écrit : 
> support=pole 
> support:pole:support=ground 
> 
> plutôt parce que s’il y a plusieurs support (support=pole;wall) on 
> pourra pas préciser le support de quel support. 

une photo d'un panneau supporté à la fois par un poteau et un mur ? 
j'ai l'impression qu'on est une fois de + entrain de faire une usine à 
gaz "par défaut" pour au cas oü il y a besoin de traiter un cas plus 
complexe que le cas par défaut. et le contributeur lambda est largé 
depuis longtemps par la marche toujours plus grande à entrée... 

> Le mar. 11 févr. 2020 à 00:15, marc marc a écrit : 
> 
> support=pole : le panneau est porté par un poteau 
> support:support=ground : le poteau est directement mis dans le sol 

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




-- 

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

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




-- 

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


___ 
Talk-fr mailing list 

Re: [OSM-talk-fr] ref et ref:FR

[leni]

Le 11/02/2020 à 23:47, François Lacombe a écrit :

Bonsoir à vous

+1 avec vous, bonne idée de séparer le tableau, pourquoi pas par 
thèmes, comme nous le faisons pour les Map Features ?
Sur le caractère national/local, pourquoi pas ajouter une colonne dans 
les tables pour le préciser ?



Comme j'ai du mal à définir les thèmes (et à savoir à quoi tout 
correspond), j'ai récupéré le tableau du wiki que j'ai mis en libre 
accès sur https://lite.framacalc.org/9f0b-osm_ref_fr


J'ai ajouté une colonne thème et une national/local et j'ai séparé les 
ref France existants :


- ceux qui n'ont pas de FR: (8)
- ceux qui sont avec fr_ (2)
- ceux qui sont en FR: (38)
- ceux qui sont dans osm et qui ne sont pas dans le wiki : les plus 
nombreux (96)


J'en ai certainement loupé ...

bonne soirée

leni


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

Re: [Talk-it] Senso unico ad orari prefissati

[Andrea Albani]

Il ven 14 feb 2020, 18:36 Mannivu  ha scritto:

> Usando il tag "oneway=reversible" con "oneway:backward/forward:conditional=*"
> (vedi anche [1])
>
> Manuel
>
Oneway=reversible si usa solo quando il senso del senso unico cambia.

In questo caso si applica oneway:conditional

> 
>

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

Re: [Talk-it] Senso unico ad orari prefissati

[Mannivu]

Pardon, devi usare "oneway=no" con "oneway:backward/forward:conditional=*"

Manuel

Il 14/02/2020 18:15, griphon ha scritto:

Come taggare una strada che, normalmente a doppio senso di circolazione, nei
giorni feriali in due determinati intervalli orari della giornata diventa a
senso unico?




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

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


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

Re: [Talk-it] Senso unico ad orari prefissati

[Mannivu]

Usando il tag "oneway=reversible" con 
"oneway:backward/forward:conditional=*" (vedi anche [1])


Manuel

https://wiki.openstreetmap.org/wiki/Conditional_restrictions

Il 14/02/2020 18:15, griphon ha scritto:

Come taggare una strada che, normalmente a doppio senso di circolazione, nei
giorni feriali in due determinati intervalli orari della giornata diventa a
senso unico?




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

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

Re: [Talk-br] Nova proposta de classificação viária

[Fernando Trebien]

On Thu, Feb 13, 2020 at 10:41 PM Gerald Weber  wrote:

> Enfim, se eu já achava que a proposta era uma má ideia, agora estou
> convencido que se trata de um grande desastre.
>

Para quem?


> Daqui a duas semanas participo de uma banca de mestrado onde se fez
> precisamente isto, extrairam os dados do OSM e fizeram uma análise de
> conectividade. Eu já vi que tiveram problemas com as classificações das
> rodovias. A atual proposta vai agravar a situação e tornar o OSM inútil
> para estudos científicos deste tipo.
>

Pode dar mais detalhes? Eu acredito fortemente que a nova proposta
resolverá problemas de classificação ao invés de prejudicar. Para poder
ajudar e poder dizer se a nova proposta realmente prejudica alguém,
gostaria de saber: que trabalho foi esse, o que estavam tentando fazer, que
problemas tiveram, que estudos científicos estão sendo feitos usando o OSM,
etc.

Eu também entendo que o "algoritmo" proposto (que eu sempre chamei de
"metodologia") não deve ser levado sempre ao pé da letra sempre, alguma
dose de ponderação e interpretação deve ser permitida para tratar de casos
limítrofes pelo consenso. A "metodologia" é pra ajudar a orientar o
trabalho de classificação e eliminar da discussão a grande maioria dos
casos principais.

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

[Talk-it] Senso unico ad orari prefissati

[griphon]

Come taggare una strada che, normalmente a doppio senso di circolazione, nei
giorni feriali in due determinati intervalli orari della giornata diventa a
senso unico?




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

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

Re: [Talk-it] Il Cammino di Sant'Antonio

[Gabriele Sani via Talk-it]

Si, il sito ufficiale e' un po' vetusto [0] ma ci sono vari contatti (attivi), 
ci son odiverse strutture convenzionate e la segnalitca e' ben presente sul 
territorio

[0] http://www.ilcamminodisantantonio.org




Gabriele Sani

Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Friday 14 February 2020 17:34, liste DOT girarsi AT posteo DOT eu 
 wrote:

> Il 14/02/20 15:21, Gabriele Sani via Talk-it ha scritto:
>
> > Buongiorno,
> > oggi ho cercato di mettere un po' di ordine al Cammino di Sant'Antonio. La 
> > situazione attuale penso sia buona, ma avrei una domanda (non so se e' il 
> > posto giusto in cui chiedere): al momento c'e' un network [0] che contiene 
> > il cammino "ufficiale" [1] (che e' quello su cui ho cercato di fare un po' 
> > d'ordine), un'altra route [2] che contiene una parte che pare sia in fase 
> > di ideazione, un'altra route [3] chiamata "Ultimo Cammino" che non so cosa 
> > sia e non ho toccato ed, infine, una route [4] che sarei propenso a 
> > cancellare, dato che riguarda un tratto del Cammino (Padova - Bologna) che 
> > non capisco a cosa faccia riferimento: nel sito del Cammino infatti non si 
> > parla mai di Bologna come punto opzionale di partenza/arrivo. La mia 
> > domanda e': posso eliminare suddetta relazione, dato che tutti i tratti 
> > sono GIA' compresi nella relazione che ho sistemato oggi?
> > Grazie
>
> Non conosco il cammino di questo santo, è documentato e vi sono
> segnaletiche in zona?
>
> Sant'antonio dalle mie parti è onorato con molti capitelli e dediche, ma
> di cammino non mi risulta, erò se è documentato e con segnaletica sul
> posto, per me va bene se si mette ordine.
>
>
> ---
>
> |
> |||
> Simone Girardelli
>
> 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-it] Il Cammino di Sant'Antonio

[liste DOT girarsi AT posteo DOT eu]

Il 14/02/20 15:21, Gabriele Sani via Talk-it ha scritto:
> Buongiorno,
> oggi ho cercato di mettere un po' di ordine al Cammino di Sant'Antonio. La 
> situazione attuale penso sia buona, ma avrei una domanda (non so se e' il 
> posto giusto in cui chiedere): al momento c'e' un network [0] che contiene il 
> cammino "ufficiale" [1] (che e' quello su cui ho cercato di fare un po' 
> d'ordine), un'altra route [2] che contiene una parte che pare sia in fase di 
> ideazione, un'altra route [3] chiamata "Ultimo Cammino" che non so cosa sia e 
> non ho toccato ed, infine, una route [4] che sarei propenso a cancellare, 
> dato che riguarda un tratto del Cammino (Padova - Bologna) che non capisco a 
> cosa faccia riferimento: nel sito del Cammino infatti non si parla mai di 
> Bologna come punto opzionale di partenza/arrivo. La mia domanda e': posso 
> eliminare suddetta relazione, dato che tutti i tratti sono GIA' compresi 
> nella relazione che ho sistemato oggi?
> 
> Grazie
> 

Non conosco il cammino di questo santo, è documentato e vi sono
segnaletiche in zona?

Sant'antonio dalle mie parti è onorato con molti capitelli e dediche, ma
di cammino non mi risulta, erò se è documentato e con segnaletica sul
posto, per me va bene se si mette ordine.



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

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

Re: [OSM-talk] Cease use of OpenStreetMap/Antifa logo

[dcapillae]

Hi,

Thank you for your comment, Rory. You seem like a reasonable person. Thank
you for talking about the subject in a casual way and without the fanaticism
that others often show when their ideas are criticized.

I was censored on an informal communication channel of the OSM community in
Spain. I can speak as a person affected by the decision of those who do not
know how to disassociate their personal (or group) ideology from OSM
affairs. I was accused of using their contact channel to share messages with
"political and ideological" content. It is false, absolutely false,
ridiculously false, an infamous lie. I have never had any discussion of
political content on any OSM communication channel, formal or informal. I
never talk about politics, not even with my friends. On the other hand, I am
usually very respectful of the rules of the community, so I will hardly make
improper use of OSM communication channels.

I have my own opinions about anti-fascist symbols. I will not share my
opinions with you because, as always, I never discuss politics in OSM
communication channels. I don't think we should bring political discussions
to these forums. They do not benefit us. Let's the OSM Foundation or their
legal group decide on the appropriate use of their logos. The Foundation is
the owner of the rights, so let's them decide.

There are some points in your message that I don't agree with. Or at least,
not how they're posed. But whatever, it's the same. I don't care what
everyone individually thinks of the project or  whatever everyone thinks is
its inherent ideology. I am only interested in the fact that all these
ideas, prejudices or beliefs do not interfere with our work and
collaboration.

The proper use of the OSM marks is best left to the Foundation to decide.

Greetings from Spain.

Regards,
Daniel



--
Sent from: http://gis.19327.n8.nabble.com/General-Discussion-f5171242.html

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

[OSM-talk] copying numbering (ref)

[Mario Frasca]

Hi everybody

in Panama I've been looking for official sources of information about 
road numbering, and could only find out that the 'Panamericana' is road 
#1.  (road signs all over the place tell you this).  for the rest, I've 
interviewed an employee of the MOP (Ministerio Obras Públicas), who 
alleged that they don't really use numbers for roads except internally, 
and that in this case the road number starts with a leading digit 
identifying the province, luckily it's 9 provinces in Panama.


now a couple of concrete examples of data in our database.

road #33, in Veraguas.  that's province #9.

roads #12, 18, 47, 48, 110, all in Chiriquí, that's province #4 ('Ch' 
goes as one letter, so it follow Coclé and Colón).  (the ones with the 
leading 4 agree with my MOP source).


so far so good.  the curious part is that all these numbers are also in 
Google Maps, included the suspicious ones.


I've placed questions in the corresponding changesets, and I have 
received replies, but quite non factual. 
(http://resultmaps.neis-one.org/osm-discussion-comments?uid=248722)


road #28 (according to Google) is road #91 according to us.  it's 
Veraguas, so the leading 9 might be correct.  here it's curious that it 
was created as #28 also in OSM 
(https://www.openstreetmap.org/changeset/35351526) then changed to 91 
(https://www.openstreetmap.org/changeset/63256732).


what would you do?

MF


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

Re: [Talk-br] Nova proposta de classificação viária

[Roberto Carlos Caleffi]

Quanto a BR 174 - Boa Vista para Manaus ela é primária ou pode ser
considerada como trunk?
Não é pedagiada mas em muitos trechos ela tem o acostamento asfaltado, é
larga, bem sinalizada. Com exceção do trecho da reserva dos Waimiri Atroari.
Outra dúvida, viajei recentemente para o Paraná, e algumas rodovias tanto
Federais quanto Estaduais por lá o limite de velocidade é 100 e 110 por
hora. 100 quando é pista simples e 110 dupla.
A 174 é bem mais larga e menos sinuosa que as estradas do Paraná e aqui é
só 80 km/h. Alguém sabe dizer quem define isso?

Em sex., 14 de fev. de 2020 às 10:57, Gerald Weber 
escreveu:

> Oi Linhares
>
> obrigado pelas considerações.
>
> Só não entendi essa frase aqui:
>
>> Sei que o OSM é muito mais que um mapa, mas quando ele não serve nem para
>> fazer um mapa é porque algo está errado! 
>>
>
> Não vi nada que impeça o OSM de servir como mapa da maneira como está.
> Claro que ajustes são importantes e sempre vão acontecer, e não há dúvida
> que existe um conjunto de rodovias que deveria ser classificado como trunk.
> Uma regra simples que poderia ser aplicada é se a rodovia é pedagiada.
>
> Penso que a análise que foi feita não deixa de ser interessante como
> ferramenta auxiliar na discussão das rodovias, ou para localizar rodovias
> que de fato poderiam ser promovidas. Mas não acho aconselhável que
> substitua por completo as regras de mapeamento.
>
> O problema que eu vejo é que "o que os olhos não veem o coração não
> sente". Lembra de velhas discussões sobre "poluição visual" sobre excesso
> de tertiary em Porto Alegre? Pois foi o Carto mudar a renderização de
> amarelo para branco que súbitamente cessaram todas as discussões sobre
> isto.
>
> E tem a síndrome do "ninho vazio". Quando deixaram de renderizar primary
> em zoom=7 todo mundo ficou nervoso porque de repente o mapa ficou "vazio",
> e começou a corrida para promover tudo que é primary para trunk.
>
> Então a gente tem que ter um pouco de sangue frio e entender que a gente
> não pode se render ao renderizador (ai, essa foi podre, eu sei).
>
> abraço
>
> Gerald
>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Nova proposta de classificação viária

[Gerald Weber]

Oi Linhares

obrigado pelas considerações.

Só não entendi essa frase aqui:

> Sei que o OSM é muito mais que um mapa, mas quando ele não serve nem para
> fazer um mapa é porque algo está errado! 
>

Não vi nada que impeça o OSM de servir como mapa da maneira como está.
Claro que ajustes são importantes e sempre vão acontecer, e não há dúvida
que existe um conjunto de rodovias que deveria ser classificado como trunk.
Uma regra simples que poderia ser aplicada é se a rodovia é pedagiada.

Penso que a análise que foi feita não deixa de ser interessante como
ferramenta auxiliar na discussão das rodovias, ou para localizar rodovias
que de fato poderiam ser promovidas. Mas não acho aconselhável que
substitua por completo as regras de mapeamento.

O problema que eu vejo é que "o que os olhos não veem o coração não sente".
Lembra de velhas discussões sobre "poluição visual" sobre excesso de
tertiary em Porto Alegre? Pois foi o Carto mudar a renderização de amarelo
para branco que súbitamente cessaram todas as discussões sobre isto.

E tem a síndrome do "ninho vazio". Quando deixaram de renderizar primary em
zoom=7 todo mundo ficou nervoso porque de repente o mapa ficou "vazio", e
começou a corrida para promover tudo que é primary para trunk.

Então a gente tem que ter um pouco de sangue frio e entender que a gente
não pode se render ao renderizador (ai, essa foi podre, eu sei).

abraço

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

Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

[Stéphane Péneau]

Une partie des bouches portent des indications différentes selon si on 
entre ou sort du métro.
Pour se conformer à cette situation, tout en cartographiant les zones 
intérieures en surfacique, on avait utilisé les relations destination_sign.

Exemple à la gare de lyon :
https://www.openstreetmap.org/node/4086374120
Cette bouche porte le nom "Gare de Lyon" lorsqu'on vient de l'extérieur, 
et "Sortie Rue Van Gogh" lorsqu'on sort.

Et sa relation destination_sign :
https://www.openstreetmap.org/relation/10054778

Stf

Le 14/02/2020 à 15:26, Francois Gouget a écrit :

On Fri, 14 Feb 2020, osm.sanspourr...@spamgourmet.com wrote:
[...]

https://www.sortiesdumetro.fr
 n'a pas des
données libres, mais ça peut permettre de voir la complétude. Après rien
n'empêche de demander s'ils acceptent une exception.

Ce site indique aussi quelles sorties disposent d'un ascenseur. Je ne
sais pas si la présence d'un ascenseur doit être représentée dans
OpenStreetMap mais ça serait sans doute une bonne idée d'indiquer quelle
sorties sont accessibles en fauteuil roulant.

Parfois les deux se combinent. Par exemple à Cachan deux des sorties ont
un ascenseur et sont donc accessibles en fauteuil roulant (+poussettes &
valises lourdes), tandis que deux autres nécessitent d'emprunter un
escalier.

Pour une sortie je suppose que la géométrie pourrait suffir à expliciter
l'accessibilité en chaise roulante, quoiqu'il n'y ait pas le moindre tag
wheelchair à l'horizon.

https://www.openstreetmap.org/node/6769102196

Mais pour l'autre sortie je ne vois pas trop comment une application
pourrait rattacher l'ascenseur à la sortie correspondante et traiter les
aspects chaise roulante :

https://www.openstreetmap.org/node/3823552596

Bon, et le champ name contient le nom de la station dans les deux cas
ce qui serait faux selon Noémie (et je suis d'accord). Par contre,
faut-il vraiment mettre le numéro dans le nom ou devrait-il être dans
le champ ref ? (pas exit_number apparemment) Ou les deux ?


[...]

266 noeuds sans tag ref. Est-ce que l'absence de ce tag a aussi une
sémantique (par exemple il n'y a qu'une sortie), ou est-ce que ce sont
des données manquantes?

ref est-il sensé être unique globalement ? (comme pour les
identifiants de boîtes aux lettres ou de transformateur) Parce que si
l'on met le numéro de sortie il y aura beaucoup de doublons 1, 2, 3...



1070 noeuds ont un attribut name, seulement 57 ont un attribut
destination. Est-ce que du coup on pourrait faire disparaître l'attribut
destination?

Non, destination est bon. C'est plutôt "name" qui est à vérifier et à
remplacer par destination le cas échéant.

Si je reprends la gare de Cachan, destination contient le nom des lignes
de bus en correspondance. Ça ne me semble pas devoir aller dans name.
Mais destination devrait-il indiquer les lignes de bus plutôt que les
noms de rues ?

Ce qui est bizarre aussi c'est qu'il a deux sorties côte à côte, une
pour le quai des RERs en provenance de Paris et l'autre pour ceux venant
de la banlieue ; et l'une indique "162;187;193;v3" et l'autre
"162;187;193". Pourtant venant de province c'est bien la sortie à
prendre pour attraper la Valouette (v3). C'est peut-être une bizarrerie
de l'affichage RATP. Il faudra que je vérifie.



Et qu'en est-il de découper le contenu de name, ou au moins d'en avoir
une version alternative découpée en plusieurs morceaux?

destination, ref et le nom de la station portée par la relation
public_transport=stop_area, oui c'est mieux (et au final on vire name,

Si à Cachan le champ destination contient bien les noms des lignes de
bus, alors il ne permettrait pas de reconstruire le nom des sorties qui,
il me semble, contiennent le nom de la rue où elles sont.




___
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] Données sur les bouches de métro franciliennes

[Christian Quest]

Le 14/02/2020 à 15:26, Francois Gouget a écrit :

On Fri, 14 Feb 2020, osm.sanspourr...@spamgourmet.com wrote:
[...]

https://www.sortiesdumetro.fr
 n'a pas des
données libres, mais ça peut permettre de voir la complétude. Après rien
n'empêche de demander s'ils acceptent une exception.

Ce site indique aussi quelles sorties disposent d'un ascenseur. Je ne
sais pas si la présence d'un ascenseur doit être représentée dans
OpenStreetMap mais ça serait sans doute une bonne idée d'indiquer quelle
sorties sont accessibles en fauteuil roulant.

Parfois les deux se combinent. Par exemple à Cachan deux des sorties ont
un ascenseur et sont donc accessibles en fauteuil roulant (+poussettes &
valises lourdes), tandis que deux autres nécessitent d'emprunter un
escalier.

Pour une sortie je suppose que la géométrie pourrait suffir à expliciter
l'accessibilité en chaise roulante, quoiqu'il n'y ait pas le moindre tag
wheelchair à l'horizon.

https://www.openstreetmap.org/node/6769102196

Mais pour l'autre sortie je ne vois pas trop comment une application
pourrait rattacher l'ascenseur à la sortie correspondante et traiter les
aspects chaise roulante :

https://www.openstreetmap.org/node/3823552596

Bon, et le champ name contient le nom de la station dans les deux cas
ce qui serait faux selon Noémie (et je suis d'accord). Par contre,
faut-il vraiment mettre le numéro dans le nom ou devrait-il être dans
le champ ref ? (pas exit_number apparemment) Ou les deux ?



C'est toute la différence entre des données relationnelles avec des 
liens explicites et des données géographiques, avec des liens 
implicites. Dans le premier cas, il n'y a pas ambiguïté, dans le second, 
il faut faire un calcul géométrique et on n'est pas toujours sûr du 
résultat.


La modélisation sert justement à rester autant que possible dans 
l'explicite non ambigu.





[...]

266 noeuds sans tag ref. Est-ce que l'absence de ce tag a aussi une
sémantique (par exemple il n'y a qu'une sortie), ou est-ce que ce sont
des données manquantes?

ref est-il sensé être unique globalement ? (comme pour les
identifiants de boîtes aux lettres ou de transformateur) Parce que si
l'on met le numéro de sortie il y aura beaucoup de doublons 1, 2, 3...


Non ref n'a pas vocation a être unique... les numéros de routes sont un 
bon exemple !






1070 noeuds ont un attribut name, seulement 57 ont un attribut
destination. Est-ce que du coup on pourrait faire disparaître l'attribut
destination?

Non, destination est bon. C'est plutôt "name" qui est à vérifier et à
remplacer par destination le cas échéant.

Si je reprends la gare de Cachan, destination contient le nom des lignes
de bus en correspondance. Ça ne me semble pas devoir aller dans name.
Mais destination devrait-il indiquer les lignes de bus plutôt que les
noms de rues ?


Qu'y a-t-il sur le terrain, c'est à dire sur les panneaux qui signalent 
les sorties ?


Une sortie débouche le plus souvent sur plein de choses... et la 
signalétique n'est pas homogène. Parfois on aura un nom de rue, des N° 
de lignes de bus, voire le nom d'un monument !


Là, je pense qu'il faut repasser en géo implicite et pas en description 
explicite.




Ce qui est bizarre aussi c'est qu'il a deux sorties côte à côte, une
pour le quai des RERs en provenance de Paris et l'autre pour ceux venant
de la banlieue ; et l'une indique "162;187;193;v3" et l'autre
"162;187;193". Pourtant venant de province c'est bien la sortie à
prendre pour attraper la Valouette (v3). C'est peut-être une bizarrerie
de l'affichage RATP. Il faudra que je vérifie.



Et qu'en est-il de découper le contenu de name, ou au moins d'en avoir
une version alternative découpée en plusieurs morceaux?

destination, ref et le nom de la station portée par la relation
public_transport=stop_area, oui c'est mieux (et au final on vire name,

Si à Cachan le champ destination contient bien les noms des lignes de
bus, alors il ne permettrait pas de reconstruire le nom des sorties qui,
il me semble, contiennent le nom de la rue où elles sont.



Les "noms" sont ici plutôt un repère pour les différencier et plus 
compréhensibles que des numéros complètement arbitraires.



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

[Francois Gouget]

On Fri, 14 Feb 2020, osm.sanspourr...@spamgourmet.com wrote:
[...]
> https://www.sortiesdumetro.fr
>  n'a pas des
> données libres, mais ça peut permettre de voir la complétude. Après rien
> n'empêche de demander s'ils acceptent une exception.

Ce site indique aussi quelles sorties disposent d'un ascenseur. Je ne 
sais pas si la présence d'un ascenseur doit être représentée dans 
OpenStreetMap mais ça serait sans doute une bonne idée d'indiquer quelle 
sorties sont accessibles en fauteuil roulant.

Parfois les deux se combinent. Par exemple à Cachan deux des sorties ont 
un ascenseur et sont donc accessibles en fauteuil roulant (+poussettes & 
valises lourdes), tandis que deux autres nécessitent d'emprunter un 
escalier.

Pour une sortie je suppose que la géométrie pourrait suffir à expliciter 
l'accessibilité en chaise roulante, quoiqu'il n'y ait pas le moindre tag 
wheelchair à l'horizon.

https://www.openstreetmap.org/node/6769102196

Mais pour l'autre sortie je ne vois pas trop comment une application 
pourrait rattacher l'ascenseur à la sortie correspondante et traiter les 
aspects chaise roulante :

https://www.openstreetmap.org/node/3823552596

Bon, et le champ name contient le nom de la station dans les deux cas 
ce qui serait faux selon Noémie (et je suis d'accord). Par contre, 
faut-il vraiment mettre le numéro dans le nom ou devrait-il être dans 
le champ ref ? (pas exit_number apparemment) Ou les deux ?


[...]
> > 266 noeuds sans tag ref. Est-ce que l'absence de ce tag a aussi une
> > sémantique (par exemple il n'y a qu'une sortie), ou est-ce que ce sont
> > des données manquantes?

ref est-il sensé être unique globalement ? (comme pour les 
identifiants de boîtes aux lettres ou de transformateur) Parce que si 
l'on met le numéro de sortie il y aura beaucoup de doublons 1, 2, 3...


> > 1070 noeuds ont un attribut name, seulement 57 ont un attribut
> > destination. Est-ce que du coup on pourrait faire disparaître l'attribut
> > destination?
> 
> Non, destination est bon. C'est plutôt "name" qui est à vérifier et à
> remplacer par destination le cas échéant.

Si je reprends la gare de Cachan, destination contient le nom des lignes 
de bus en correspondance. Ça ne me semble pas devoir aller dans name. 
Mais destination devrait-il indiquer les lignes de bus plutôt que les 
noms de rues ?

Ce qui est bizarre aussi c'est qu'il a deux sorties côte à côte, une 
pour le quai des RERs en provenance de Paris et l'autre pour ceux venant 
de la banlieue ; et l'une indique "162;187;193;v3" et l'autre 
"162;187;193". Pourtant venant de province c'est bien la sortie à 
prendre pour attraper la Valouette (v3). C'est peut-être une bizarrerie 
de l'affichage RATP. Il faudra que je vérifie.


> > Et qu'en est-il de découper le contenu de name, ou au moins d'en avoir
> > une version alternative découpée en plusieurs morceaux?
> 
> destination, ref et le nom de la station portée par la relation
> public_transport=stop_area, oui c'est mieux (et au final on vire name,

Si à Cachan le champ destination contient bien les noms des lignes de 
bus, alors il ne permettrait pas de reconstruire le nom des sorties qui, 
il me semble, contiennent le nom de la rue où elles sont.



-- 
Francois Gouget   http://fgouget.free.fr/
 "Utilisateur" (nom commun) :
Mot utilisé par les informaticiens en lieu et place d'"idiot".___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-it] Il Cammino di Sant'Antonio

[Gabriele Sani via Talk-it]

Buongiorno,
oggi ho cercato di mettere un po' di ordine al Cammino di Sant'Antonio. La 
situazione attuale penso sia buona, ma avrei una domanda (non so se e' il posto 
giusto in cui chiedere): al momento c'e' un network [0] che contiene il cammino 
"ufficiale" [1] (che e' quello su cui ho cercato di fare un po' d'ordine), 
un'altra route [2] che contiene una parte che pare sia in fase di ideazione, 
un'altra route [3] chiamata "Ultimo Cammino" che non so cosa sia e non ho 
toccato ed, infine, una route [4] che sarei propenso a cancellare, dato che 
riguarda un tratto del Cammino (Padova - Bologna) che non capisco a cosa faccia 
riferimento: nel sito del Cammino infatti non si parla mai di Bologna come 
punto opzionale di partenza/arrivo. La mia domanda e': posso eliminare suddetta 
relazione, dato che tutti i tratti sono GIA' compresi nella relazione che ho 
sistemato oggi?

Grazie

Gabriele Sani

P.S. per chi fosse interessato esiste anche UN'ALTRA relazione [5] con le 
frecce direzionali: la mia idea e' di "smantellarla" pian piano e spostare le 
frecce nelle tappe a loro relative

[0] https://www.openstreetmap.org/relation/5562005
[1] https://www.openstreetmap.org/relation/3446664
[2] https://www.openstreetmap.org/relation/10275750
[3] https://www.openstreetmap.org/relation/4742006
[4]https://www.openstreetmap.org/relation/5559967
[5] https://www.openstreetmap.org/relation/7857036

Sent with [ProtonMail](https://protonmail.com) Secure Email.___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk] 1e7 | Re: OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Rory McCann]

On 13/02/2020 00:15, Martin Koppenhoefer wrote:

Il giorno 13 feb 2020, alle ore 00:05, Colin Smale  ha 
scritto:

Locations are stored in OSM as pairs of {lat,lon} and I assume these are both 
64-bit floats in the database.



AFAIK they are stored as integers (shifting the decimals)


They are stored with 7 places of decimals (i.e. multiple by 1e7).

https://wiki.openstreetmap.org/wiki/Node

Do not use IEEE 32-bit floating point data type since it is limited
to about 5 decimal places for the highest longitude.

>

A 32-bit method used by the Rails port is to use an integer (by
multiplying each coordinate in degrees by 1E7 and rounding it: this
allows to cover all absolute signed coordinates in ±214.7483647
degrees, or a maximum difference of 429.4967295 degrees, a bit more
than what is needed).

For computing projections, IEEE 64 bit floating points are needed for
intermediate results.

>

The 7 rounded decimal places for coordinates in degrees define the
worst error of longitude to a maximum of ±5.56595 millimeters on the
Earth equator, i.e. it allows building maps with centimetric
precision. With only 5 decimal places, the precision of map data
would be only metric, causing severe changes of shapes for important
objects like buildings, or many zigzags or angular artefacts on
roads.


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

[Talk-cat] dolmens de Catalunya

[Joan Quintana]

Bé, no havia vist el següent enllaç que és important:
https://wiki.openstreetmap.org/wiki/Key:megalith_type

grosssteingrab s'ha de canviar per dolmen.
burial_stone i passage_grave són les etiquetes correctes a utilitzar

Joan Q
___
Talk-cat mailing list
Talk-cat@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cat

[Talk-cat] dolmens de Catalunya

[Joan Quintana]

Volia completar la informació dels dolmens de Catalunya.
Tinc vàries pregunets. La informació està bastant dispersa, diguem que el
punt de partida seria:
*https://ca.wikipedia.org/wiki/Categoria:D%C3%B2lmens_de_Catalunya
que conté vàries subcategories. Seguint el fil, es pot constatar que hi ha
bastanta informació introduïda, però encara queda bastanta feina per fer.
Entenc que posar la informació que falta és una bona cosa, però no es pot
parlar d'importació oficial perquè no  hi ha una font única.

D'altra banda, entenc que la informació que hi ha s'ha de preservar
(bàsicament per respectar la feina que ha fet d'altra gent), però un pot
estar en desacord amb els tags. Vaig a posar un exemple.

Bàsicament els tags involucrats són:
*historic=archaeological_site
*site_type=megalith

*megalith_type= podria ser un d'aquests
grosssteingrab
passage_grave
dolmen
menhir
burial_stone
cista

hi ha bastants dòlmens que estan etiquetats com a grosssteingrab. Entenc
que això ho ha fet una persona de la comunitat científica alemanya, i jo no
voldria malmetre la feina que ha fet. La meva opinió és que s'hauria de
canviar:


per



Ara imaginem que aquesta persona s'ha currat una pàgina web amb els dòlmens
de la península ibèrica. Després de fer aquest canvi la web deixaria de
funcionar. Aleshores què s'ha de fer. Potser s'ha de contactar prèviament
amb la persona?

El mateix podem dir per passage_grave i burial_stone, que la persona que ho
ha etiquetat ho ha fet en el context de tot Europa (tot i que a ni només
m'interessa Catalunya)

Es podria fer:

per



(d'altra banda, passage_grave no sé com es tradueix).

Encara no he fet cap canvi, volia anar amb peus de plom. El que em preocupa
és veure les implicacions que pot tenir editar la feina que ha fet d'altra
gent. Ho documentaré a:

*
http://wiki.joanillo.org/index.php/Importaci%C3%B3_dels_d%C3%B2lmens_de_Catalunya
i quan hagi acabat ja ho posaré a la wiki de osm Cat.

Joan Quintana
___
Talk-cat mailing list
Talk-cat@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cat

Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

[Stéphane Péneau]

Bonjour Séverin,

Je ne vais pas discuter du SX Blue, d'autres l'ont fait, mais un peu 
plus des autres options disponibles, principalement à base de puce Ublox 
F9P.


- On va partir du principe qu'il n'y a pas de réseau de base gnss 
accessible comme le RGP en France [1].


Si on utilise un récepteur standard, ou même un récepteur plus évolué 
comme le F9P, mais en fonctionnement basique, alors on ne sera pas en 
submétrique.
Dans ce genre de cas, on peut utiliser le PPP pour "Precise Point 
Positionning". Ça ne peut se réaliser qu'avec un récepteur type F9P ou 
autre produit de la même gamme.
Pour ce faire, on place notre récepteur sur un point fixe, et on le 
laisse enregistrer sur plusieurs heures, l'idéal étant 24h. Ensuite, on 
peut récupérer les données et les traiter avec des services en lignes 
(gratuits) ou avec RTKLIB (logiciel libre), mais c'est un peu plus 
compliqué avec ce dernier. Là, on obtiendra une position sous les 10 cm, 
et encore mieux si on attend quelques semaines avant de faire le 
post-traitement (je t'épargne les détails techniques pour l'instant). Je 
pense que le Sirius qu'a mentionné Christian est adapté à ce genre de cas.
L'inconvénient de cette solution PPP, c'est qu'il faut pouvoir laisser 
le récepteur en place sur une longue durée.


Il y a une évolution du PPP qui utilise des corrections (SSR) et qui 
permet d'obtenir une très bonne précision bien plus rapidement, mais 
c'est encore assez expérimental[3].


L'étape suivante, c'est d'installer des bases fixes pour recréer un 
réseau comme celui du RGP, comme Centipede [2]. Ensuite, le récepteur 
qui pourra être basé lui aussi sur une puce F9P, utilisera la position 
de la base pour calculer la sienne avec plus de précision (toujours - de 
10cm si on reste dans un rayon de 30 à 60 km de la base). Cette position 
pourra être obtenue en général en moins d'1mn si on peut recevoir les 
données de la base en direct (connexion internet), ou alors on 
enregistre les données séparément, et on post traite ça une fois qu'on 
retrouve un ordi et une connexion, c'est en général ce que je fais et 
j'obtiens ce genre de chose : http://www.stemani.fr/public/Osm/anim_rtk.gif
On appelle ça du RTK, ou Post-RTK si on n'est pas en temps réel (parfois 
abrégé en PPK).


J'ai construit ma propre base et j'en ai parlé au dernier Sotm, mais 
malheureusement ce n'était pas filmé. Les diapos sont là : 
http://www.stemani.fr/public/gnss/Fabrication_base_GNSS.pdf

Le code : https://github.com/Stefal/rtkbase
Depuis, d'autres ont été fabriquées sur le même concept et rejoindront 
le réseau centipede prochainement : 
https://twitter.com/complementterre/status/1204801663321726976


J'ai aussi un logger mobile qui enregistre sur une carte micro SD, mais 
je n'ai pas documenté pour le moment. Je récupère son signal via 
Bluetooth sur mon smartphone, mais c'est de la localisation standard 
puisque la plupart du temps je ne suis pas connecté à une base, je fais 
du post-traitement un fois rentré.



Pour ce qui est de récupérer ce signal Bluetooth via une appli libre, 
j'ai forké un fork de fork deBlueGPS. Il est loin d'être parfait, 
n'est pas 100% stable, mais il existe : 
https://github.com/Stefal/bluegnss4droid/releases
Mes compétences en Java étant proches du néant, j'ai du mal à 
l'améliorer


[1]http://rgp.ign.fr/DONNEES/diffusion/
[2]https://centipede.fr/
[3]https://rtklibexplorer.wordpress.com/2018/05/08/using-ssr-corrections-with-rtklib-for-ppp-solutions/

A+

Stéphane


Le 14/02/2020 à 03:00, severin.menard via Talk-fr a écrit :

Bonjour à tou-te-s,

J'ai eu l'occasion d'en parler de manière informelle à quelques 
personnes et peut-être ce sujet a-t-il déjà été discuté en long et en 
travers sur un fil de cette liste ou sur le forum, mais je ne l'ai pas 
trouvé. Désolé si c'est le cas !


Après une assez longue période (en gros entre 2012 et mi 2017) pendant 
laquelle la communauté OSM s'est appuyée sur l'imagerie Bing pour 
digitaliser, l'arrivée d'autres ressources (Digital Globe en mai 2017, 
Esri puis Maxar remplaçant Digital Globe avec une imagerie différente, 
qui n'est plus disponible actuellement) a permis de bénéficier 
d’imageries généralement plus récentes que Bing et parfois sans nuages 
sur des zones qui restaient encore à digitaliser complètement. 
Cependant, chacune de ces images possède un géo-référencement 
légèrement différent, à quelques mètres pràs, sans qu'il soit souvent 
possible de déterminer lequel serait le meilleur à partir des traces 
de terminaux GPS grand public à 2-5 m de précision. En France, la 
convention passée entre OSM France et l'IGN permet de s'appuyer sur 
son imagerie dont le géo-référencement, j'imagine, peut être considéré 
comme faisant référence. Sur d'autres territoires francophones, 
l'usage d'autres sources que Bing rend la carte OSM certes  
globalement plus à jour, mais avec une diminution de l’homogénéité du 
géo-référencement des objets dans la base, tous les contributeurs ne 

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Martin Koppenhoefer]

Am Fr., 14. Feb. 2020 um 11:18 Uhr schrieb Colin Smale <
colin.sm...@xs4all.nl>:

> Yes I realise that but attention must be paid to all possible sources of
> precision leakage.
>
> What use would proprietary parameters be? If they were used, are relevant
> and kept private, this would impede the consumption of the data by any
> clients. All GIS files must include, by value or by reference, the relevant
> CRS, otherwise the contents can not be interpreted properly, can they? Or
> are you thinking of the situation in China where they have a
> state-controlled/licenced transformation?
>
>


First, proprietary parameters does not mean you cannot have access to them,
but you might have to pay for it. Secondly, you do not need the parameters
for use of the data in a certain CRS but you need them for high precision
conversions into another CRS.

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

Re: [Talk-de] Dienstleister für OSM-Kartendruck im Großformat

[Martin Koppenhoefer]

Am Fr., 14. Feb. 2020 um 11:22 Uhr schrieb Michael Kugelmann via Talk-de <
talk-de@openstreetmap.org>:


> Hartmut bietet häufig auf Events (z.B. 36C3 oder SOTM@HD oder FOSSGIS)
> Kartendruck für Besucher. IIRC hat er auch schon dazu Vorträge gehalten.
> Aber da steht keine Firma dahinter und auch nicht irgendetwas von wegen
> "auf Kork" oder so.




wie schon oben geschrieben, was man eigentlich benötigt ist eine
Druckvorlage in geeigneter Auflösung und mit entsprechenden Textgrößen und
Icons (also das, was Hartmut völlig uneigennützig der Community schenkt).
Damit kann man zu jedem besseren Copyshop gehen und sich das auf das
gewünschte Papier drucken, und ggf. dieses dann auf andere Materialien
kaschieren.
Direkt auf Kork wird man nicht drucken, weil man ein Material braucht, das
die Farbe nicht aufsaugt.

Gruß
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

[osm . sanspourriel]

Le 13/02/2020 à 23:17, Sébastien Hinderer -
sebastien.hinde...@ens-lyon.org a écrit :


Bonsoir Marc,

Merci beaucoup pour ta réponse rapide!


D'accord avec les réponses de Marc.


Je suis aveugle et codeur. J'aimerais faire une petite appli web
permettant de saisir une adresse et donnant en retour les*bouches*  de
métro les plus proches de cette adresse.


Bonne idée et les bonnes compétences pour le faire.

https://www.sortiesdumetro.fr
 n'a pas des
données libres, mais ça peut permettre de voir la complétude. Après rien
n'empêche de demander s'ils acceptent une exception.


Si j'ai bien compris ça fait ce que je suggérais pour regrouper les
bouches par stations donc c'est bien, ça veut dire que
l'information est déjà présente! Ce que je me demande c'set si on peut
raisonnablement estimer que c'est exhaustif, ou est-ce qu'il manque des
choses? La question se pose pour les bouches elles-mêmes aussi,
d'ailleurs.


Oui tu as bien compris, non ce n'est probablement pas exhaustif.


266 noeuds sans tag ref. Est-ce que l'absence de ce tag a aussi une
sémantique (par exemple il n'y a qu'une sortie), ou est-ce que ce sont
des données manquantes?

Quid de exit_number alors? Faudrait-il l'enlever?


Non, à remplacer par ref (c'est sans doute ce que tu voulais dire).


1070 noeuds ont un attribut name, seulement 57 ont un attribut
destination. Est-ce que du coup on pourrait faire disparaître l'attribut
destination?


Non, destination est bon. C'est plutôt "name" qui est à vérifier et à
remplacer par destination le cas échéant.


Et qu'en est-il de découper le contenu de name, ou au moins d'en avoir
une version alternative découpée en plusieurs morceaux?


destination, ref et le nom de la station portée par la relation
public_transport=stop_area, oui c'est mieux (et au final on vire name,
et pour éviter que d'autres en inventent un on peut mettre noname
=yes).

Comme ça sur une carte on peut afficher proprement les noms des stations
d'un côté et les numéros de sortie de l'autre (éventuellement la
destination aussi).

Peut-être que la page du wiki doit être clarifiée.


Idéalement, ce serait bien me semble-t-il d'avoir des tags séparés pour
le nom de la station, le numéro de la sortie et le nom de la sortie.


+1


il semblerait qu'il y en a
aussi beaucoup qui utilisent l'attribut ref, sans que je sois sûr à 100%
que le numéro utilisé comme valeur pour ref soit toujours le numéro de
sortie véritable, au sens RATP.


Tu peux chercher les valeurs exotiques, ça devrait être un nombre
inférieur à 100.


Je voudrais échanger avec vous pour savoir s'il vous semblerait possible
d'aller vers plus d'uniformité et, si oui, comment on devrait s'y
prendre pour y arriver. Je ne sais pas trop si c'set une discussion
qu'on peut avoir ici ou s'il faudrait l'avoir à un niveau international
cependant, donc je sollicite aussi vos conseils là-dessus.


On peut discuter ici, regarder si c'est bien par rapport au wiki et si
on veut changer des choses, voir sur une liste internationale.


Il serati bien aussi de pouvoir indiquer lesquelles des stations
communiquent entre elles (Saint-Michel et Cluny, Opéra et Aubert,
etc.) parce que parfois quand on ne voit pas on préfère faire
certains trajets sous terre, parce qu'avec les couloirs c'est plus
simple
et plus balisé qu'en surface.


Je suppose qu'il y a une voie piétonne de tracée entre les
stations/sorties. Je ne sais s'il y a ou s'il faut des attributs
spécifiques. Peut-être une sortie avec pour destination l'autre station ?

Sinon il y a aussi une liste spécialisée sur les transports publics.

Jean-Yvon


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

Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

[Eric SIBERT via Talk-fr]

Mon expérience à Madagascar (36 15 My Life pour les plus anciens...)

Depuis quelques années, je travaille avec un Garmin etrex 30, captant 
les satellites GPS et Glonass. Des mesures répétées plusieurs jours de 
suite sur un point dégagé me donnent un écart type en X et Y de 1,60 m. 
Je pense qu'en France métropolitaine, avec les corrections Egnos, on 
doit être à moins d'un mètre. En tout cas, assez pour voir la différence 
entre WGS84 et RGF93 [1,2].


Il y a eu une période à Madagascar où je mesurais la position de points 
de repères sur le terrain. Ensuite, j'allais dans JOSM. Pour chaque 
point de repère, j'estimais le décalage. Je reportais des valeurs X et Y 
du décalage dans un tableur. Je faisais la moyenne des valeurs pour 
l'ensemble d'une ville (en faisant attention qu'il n'y ait pas 
juxtaposition de plusieurs vues aérienne). Enfin, dans JOSM, 
j'appliquais la correction moyenne. Un peu lourd puis il faut vérifier 
de temps à autre qu'ils n'ont pas changé l'image source avec un nouveau 
décalage. Maintenant, je me contente d'ouvrir la vue aérienne dans JOSM. 
Je fais afficher les traces GPS disponibles dans OSM. Visuellement, je 
recale la vue aérienne. Ça va pas mal aussi. Il faut avoir assez de 
traces GPS. Dans certains coins, mon problème est que j'ai trop de 
traces et que je ne vois plus rien ;-).


Ensuite, pour un récepteur plus précis, laisse tomber le récepteur à 2 
k€. Il ne fait pas grand chose de plus qu'un récepteur grand public et 
la précision métrique nécessite une correction comme EGNOS non 
disponible en Afrique.


À l'instigation de Stéphane Péneau, je suis en train de me monter un 
enregistreur de donnée GNSS brutes [3]. Quatre constellations, 
bi-fréquence. 400 € de pièces, y compris la TVA payée à l'import. Il 
faut calculer à postériori les corrections pour avoir la meilleure 
précision, idéalement, par rapport à une station de référence. Stéphane 
a aussi fait plusieurs forks [4] (dont support bluetooth? Je ne retrouve 
pas).


Ce n'est peut-être pas la meilleure solution pour avoir la meilleure 
précision possible en temps réel car il ne supporte pas les corrections 
SBAS (WAAS, EGNOS...). Il est vraiment fait pour travailler en 
différentiel, que ce soit en temps réel ou à postériori. Dans tous les 
cas je vais essayer d'évaluer la précision dans les différents cas de 
figure en France et à Madagascar.


Eric


[1] : 
https://lists.openstreetmap.org/pipermail/talk-fr/2019-September/094202.html

[2] : https://www.openstreetmap.org/user/StephaneP/diary/390290
[3] : https://github.com/PaulZC/F9P_RAWX_Logger
[4] : https://github.com/Stefal/F9P_RAWX_Logger



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

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Colin Smale]

On 2020-02-14 10:18, Martin Koppenhoefer wrote:

> Am Do., 13. Feb. 2020 um 08:41 Uhr schrieb Colin Smale 
> : 
> Locations are stored in OSM as pairs of {lat,lon} and I assume these are both 
> 64-bit floats in the database. 
> 
> AFAIK they are stored as integers (shifting the decimals)
> 
> If so then then my comments about preserving precision still apply to all 
> "client" software and I bet the majority uses float. Then an innocent update 
> to a tag on a node can end up unintentionally moving the location slightly, 
> losing precision.

My comment about precision lost through conversion was not about missing
floating point digits, but about conversions from one CRS to another,
where you may need additional (proprietary) grid parameters to do a high
precision conversion. 

Yes I realise that but attention must be paid to all possible sources of
precision leakage. 

What use would proprietary parameters be? If they were used, are
relevant and kept private, this would impede the consumption of the data
by any clients. All GIS files must include, by value or by reference,
the relevant CRS, otherwise the contents can not be interpreted
properly, can they? Or are you thinking of the situation in China where
they have a state-controlled/licenced transformation?___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

[Martin Noblecourt]

Bonjour,

Merci Séverin de (re)lancer ce sujet toujours aussi problématique.

Côté CartONG on a plutôt appliqué jusqu'à présent la politique soit de 
tracer sur le calage de l'image utilisée si pas de données 
pré-existantes, soit de recaler l'imagerie sur Bing dans le cas de 
données existantes, pour être cohérents avec ces dernières.


L'idéal est bien entendu d'avoir des points de référencement pris sur le 
terrain. En dehors de l'hypothèse de l'achat d'un GPS submétrique, qui 
demanderait une organisation spécifique comme tu l'as mentionné, il 
reste l'option 1) d'essayer d'améliorer la précision des GPS de 
téléphones (nous avons publié un tutoriel, en anglais, contenant 
quelques techniques pour cela 
), 
et de choisir un smartphone avec un bon capteur GPS (nous avons 
également fait une étude sur le sujet 
, 
qui a mis en avant des précisions médianes allant de 2m à 5m selon les 
modèles, sachant que la précision est souvent encore plus mauvaise pour 
les marques chinoises "pas chères"... il  y a donc aussi une marge 
importante de ce côté).


Bonne journée,

Martin

On 14/02/2020 10:51, talk-fr-requ...@openstreetmap.org wrote:

Subject:
[OSM-talk-fr] Création de points de référence pour calage des 
imageries satellites - quelle approche et quel matériel ?

From:
"severin.menard" 
Date:
14/02/2020, 03:00

To:
Discussions sur OSM en français 


Bonjour à tou-te-s,

J'ai eu l'occasion d'en parler de manière informelle à quelques 
personnes et peut-être ce sujet a-t-il déjà été discuté en long et en 
travers sur un fil de cette liste ou sur le forum, mais je ne l'ai pas 
trouvé. Désolé si c'est le cas !


Après une assez longue période (en gros entre 2012 et mi 2017) pendant 
laquelle la communauté OSM s'est appuyée sur l'imagerie Bing pour 
digitaliser, l'arrivée d'autres ressources (Digital Globe en mai 2017, 
Esri puis Maxar remplaçant Digital Globe avec une imagerie différente, 
qui n'est plus disponible actuellement) a permis de bénéficier 
d’imageries généralement plus récentes que Bing et parfois sans nuages 
sur des zones qui restaient encore à digitaliser complètement. 
Cependant, chacune de ces images possède un géo-référencement 
légèrement différent, à quelques mètres pràs, sans qu'il soit souvent 
possible de déterminer lequel serait le meilleur à partir des traces 
de terminaux GPS grand public à 2-5 m de précision. En France, la 
convention passée entre OSM France et l'IGN permet de s'appuyer sur 
son imagerie dont le géo-référencement, j'imagine, peut être considéré 
comme faisant référence. Sur d'autres territoires francophones, 
l'usage d'autres sources que Bing rend la carte OSM certes  
globalement plus à jour, mais avec une diminution de l’homogénéité du 
géo-référencement des objets dans la base, tous les contributeurs ne 
recalant pas l’imagerie qu'ils utilisent sur le vecteur existant.
La seule manière pour y remédier me semble être de constituer sur ces 
territoires des points de référence à l'aide de GPS sub-métriques (si 
d'autres approches seraient également envisageables, je suis preneur) 
et je cherche à identifier le matériel nécessaire et son coût pour 
tester un usage en Afrique Y en a-t-il parmi vous qui sont au fait 
côté besoins specs et matériels adaptés à ce besoin ? Un GPS 
submétrique me semble suffisant par rapport à un GPS centimétrique, un 
modèle de ce type 
(http://www.geo-boutique.com/product.php?id_product=11) semble faire 
l'affaire pour un coût qui reste encore envisageable (avec tous les 
accessoires nécessaires à prévoir en plus). Y a-t-il des modèles plus 
adaptés ? Ça fonctionne en bluetooth et est donc connectable à un 
Android (plutôt qu'un pocket PC qui va coûter une blinde) : y a-t-il 
une appli (libre de préférence) qui s'imposerait ?
Par ailleurs, pour les infos du relais terrestre, il semble qu'en 
Afrique le seul réseau disponible soit Omnistar, dont le prix 
s'obtient apparemment plutôt sur devis (ce qui n'est jamais bon signe 
quant au coût final, même si apparemment cela peut se faire via des 
abonnements courts d'un mois). Quelqu'un a-t-il déjà l'opportunité 
d'utiliser un GPS de ce type connecté au réseau Omnistar ?


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

Re: [Talk-de] Dienstleister für OSM-Kartendruck im Großformat

[Michael Kugelmann via Talk-de]

Am 13.02.2020 um 14:11 schrieb Mathias Schindler:

Auf https://wiki.openstreetmap.org/wiki/OSM_on_Paper habe ich bereits
einige Anregungen gesammelt, welche Anbieter es gibt. Da es schön aussehen
sollte, wäre ich sehr über Tipps oder Erfahrungsberichte dankbar.

Hartmut bietet häufig auf Events (z.B. 36C3 oder SOTM@HD oder FOSSGIS)
Kartendruck für Besucher. IIRC hat er auch schon dazu Vorträge gehalten.
Aber da steht keine Firma dahinter und auch nicht irgendetwas von wegen
"auf Kork" oder so.


BR,
Michael.


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

Re: [OSM-talk-fr] Création de points de référence pour calage des imageries satellites - quelle approche et quel matériel ?

[Christian Quest]

Le 14/02/2020 à 03:00, severin.menard via Talk-fr a écrit :

Bonjour à tou-te-s,

J'ai eu l'occasion d'en parler de manière informelle à quelques 
personnes et peut-être ce sujet a-t-il déjà été discuté en long et en 
travers sur un fil de cette liste ou sur le forum, mais je ne l'ai pas 
trouvé. Désolé si c'est le cas !


Après une assez longue période (en gros entre 2012 et mi 2017) pendant 
laquelle la communauté OSM s'est appuyée sur l'imagerie Bing pour 
digitaliser, l'arrivée d'autres ressources (Digital Globe en mai 2017, 
Esri puis Maxar remplaçant Digital Globe avec une imagerie différente, 
qui n'est plus disponible actuellement) a permis de bénéficier 
d’imageries généralement plus récentes que Bing et parfois sans nuages 
sur des zones qui restaient encore à digitaliser complètement. 
Cependant, chacune de ces images possède un géo-référencement 
légèrement différent, à quelques mètres pràs, sans qu'il soit souvent 
possible de déterminer lequel serait le meilleur à partir des traces 
de terminaux GPS grand public à 2-5 m de précision. En France, la 
convention passée entre OSM France et l'IGN permet de s'appuyer sur 
son imagerie dont le géo-référencement, j'imagine, peut être considéré 
comme faisant référence. Sur d'autres territoires francophones, 
l'usage d'autres sources que Bing rend la carte OSM certes  
globalement plus à jour, mais avec une diminution de l’homogénéité du 
géo-référencement des objets dans la base, tous les contributeurs ne 
recalant pas l’imagerie qu'ils utilisent sur le vecteur existant.
La seule manière pour y remédier me semble être de constituer sur ces 
territoires des points de référence à l'aide de GPS sub-métriques (si 
d'autres approches seraient également envisageables, je suis preneur) 
et je cherche à identifier le matériel nécessaire et son coût pour 
tester un usage en Afrique Y en a-t-il parmi vous qui sont au fait 
côté besoins specs et matériels adaptés à ce besoin ? Un GPS 
submétrique me semble suffisant par rapport à un GPS centimétrique, un 
modèle de ce type 
(http://www.geo-boutique.com/product.php?id_product=11) semble faire 
l'affaire pour un coût qui reste encore envisageable (avec tous les 
accessoires nécessaires à prévoir en plus). Y a-t-il des modèles plus 
adaptés ? Ça fonctionne en bluetooth et est donc connectable à un 
Android (plutôt qu'un pocket PC qui va coûter une blinde) : y a-t-il 
une appli (libre de préférence) qui s'imposerait ?
Par ailleurs, pour les infos du relais terrestre, il semble qu'en 
Afrique le seul réseau disponible soit Omnistar, dont le prix 
s'obtient apparemment plutôt sur devis (ce qui n'est jamais bon signe 
quant au coût final, même si apparemment cela peut se faire via des 
abonnements courts d'un mois). Quelqu'un a-t-il déjà l'opportunité 
d'utiliser un GPS de ce type connecté au réseau Omnistar ?


Séverin



Le SX Blue à 2000€ HT, ça fait quand même un beau budget et surtout 
c'est une techno un peu ancienne et pas forcément adaptée.


Pas sûr qu'il donne les résultats escomptés en Afrique car il dépend de 
signaux WAAS ou EGNOS qui ne sont pas forcément disponibles partout. 
Sans ces signaux de correction, il faut soit faire un moyennage sur une 
position fixe sur un temps long, soit passer en multi-bande (la majorité 
des GPS sont mono-bande, c'est à dire qu'ils n'utilisent qu'une seule 
fréquence de signal alors que les sat en émettent 2).


uBlox a sorti une nouvelle série de récepteurs qui gère le multi-bande, 
le F9 ...


Drotek propose un récepteur basé dessus: 
https://drotek.com/drotek-launches-f9p-sirius-base/


Le coût ? 400€ (TTC) https://store.drotek.com/sirius-rtk-gnss-base-f9p

200€ le chip seul, à intégrer... https://store.drotek.com/rtk-zed-f9p-gnss

--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

[Sébastien Hinderer]

Bonjour Christian,

Un grand merci pour ta réponse. Je comprends que beaucoup reste à faire
mais suis très motivé, le besoin étant réel. Et, bien que je n'aie pas
encore essayé l'API de contribution, ça ne m'effraie pas de faire le
travail de fourmi consistant à nourrir la base objet par objet, tag par
tag.

Simplement, je pense que j'aurais besoin d'aide, à plusieurs niveaux. Je
pense notamment à:

- M'aider pour regarder ce qui se fait ailleurs: je pense que d'une part
ça va faire beauoucp de donées à compulser (en braille tout prend plus de
temps) et que, d'autre part, ça demande une expertise OSM que je n'ai pas
(encore) de distinguer, dans tout ce qui exite, ce dont on peut
s'inspirer de ce qu'il vaut mieux éviter.

- Réfléchir avec moi à l'ordre dans lequel on fait les choses, une fois
qu'on a décidé vers où on voulait aller.

- Eventuellement, m'aider sur les premières contributions, ou au moins
les valider, pour être sûr que je ne fasse pas de bêtises.

S'il y a des personnes de la communauté qui sont disponibles pour
apporter de l'aide sur ces différents points, ce serait vraiment super.
Si en plus ces personnes sont basées à Paris, on pourrait peut-être même
envisager de se rencontrer, ça peut permettre d'avancer plus
efficacement.

D'avance merci beaucoup,

Sébastien.

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

Re: [OSM-talk-fr] Données sur les bouches de métro franciliennes

[Noémie Lehuby via Talk-fr]

Bonjour,

La page de wiki est normalement à jour avec les bonnes pratiques : 
https://wiki.openstreetmap.org/wiki/FR:Tag:railway%3Dsubway_entrance


Et effectivement, sur la région parisienne, il reste encore pas mal de 
boulot.

Quelques remarques :
- Toutes les relations des stations existent, mais il y a encore des 
bouches de métro qui ne sont pas dans ces relations
- Le nom de la bouche ne devrait pas répéter le nom de la station, mais 
plutôt être de la forme "Sortie 2 - Place de l'Église"
- Certaines bouches de métro n'ont pas de "destination", certaines 
bouches n'ont pas de numéro ... Aucune idée des règles qui déterminent 
ça (dans ce cas, name = Sortie)
- Les sorties de certaines gares de RER et Transilien ont le tag 
railway=train_station_entrance, avec les mêmes règles de fonctionnement
- Il y a des données sur les bouches de métro sur le portail open data 
d'IDFM donc on pourrait envisager une analyse Osmose pour compléter les 
noms et numéro de ces bouches de métro et sorties de gares déjà présents 
dans OSM et peut-être aussi en détecter d'éventuelles manquantes


--
Noémie Lehuby
Jungle Bus - http://junglebus.io

Le 13/02/2020 à 23:17, Sébastien Hinderer a écrit :

Bonsoir Marc,

Merci beaucoup pour ta réponse rapide!

marc marc (2020/02/13 21:51 +):

à chaud, sans avoir été chercher la précédente discussion sur le sujet :

le nom de la station n'est pas celui de la sortie, le wiki recommande
l'utilisation d'une relation public_transport=stop_area
pour les lier (et je partage cet avis)

OK. Si j'ai bien compris ça fait ce que je suggérais pour regrouper les
bouches par stations donc c'est bien, ça veut dire que
l'information est déjà présente! Ce que je me demande c'set si on peut
raisonnablement estimer que c'est exhaustif, ou est-ce qu'il manque des
choses? La question se pose pour les bouches elles-mêmes aussi,
d'ailleurs.

J'essaierai de voir bientôt s'ily a des bouches qui ne sont dans aucune
relation par exemple, des choses comme ça.


les sorties devraient avoir leur no dans ref=*, j'espère que tout le
monde était d'accord :)

266 noeuds sans tag ref. Est-ce que l'absence de ce tag a aussi une
sémantique (par exemple il n'y a qu'une sortie), ou est-ce que ce sont
des données manquantes?

Quid de exit_number alors? Faudrait-il l'enlever?


de mémoire (mais je peux me tromper) nous avions surtout discuté du tag
name qui souvent n'est pas vraiment un nom propre à la sortie mais une
destination (pour lequel il existe le tag destination, par exemple
utilisé pour les sorties routières). bien que pertinent comme argument,
je m'en tiens pour l'instant à l'usage documenté (le tag name).

1070 noeuds ont un attribut name, seulement 57 ont un attribut
destination. Est-ce que du coup on pourrait faire disparaître l'attribut
destination?

Et qu'en est-il de découper le contenu de name, ou au moins d'en avoir
une version alternative découpée en plusieurs morceaux?


j'avais testé une appli capable d'indiquer le no de sortie le plus court
vers la destination, je ne me souviens hélas plus de son nom.

Il y a "Métro sorties" que j'avais mais qui ne marche plus trop bien. Il
y en a d'autres aussi mais qui ofnt les choses de façon graphique, donc
inutilisable pour les déficients visuels.

Sébastien.

___
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] Données sur les bouches de métro franciliennes

[Christian Quest]

Bonjour Sébastien,

L'état des tags sur les bouches de métro n'a rien d'exceptionnel pour 
les données OSM qui, dans la majorité des cas, sont ajoutées petit à 
petit, objet par objet, tag par tag... sauf quand on a une source 
opendata sur laquelle s'appuyer. Il y a peut être une piste à creuser 
dans les données du plan de voirie de la Ville de Paris, mais côté RATP 
rien d'exploitable à ce jour.


Ceci vaut pour l'exhaustivité des objets et des tags.

Ensuite, second problème, la cohérence et l’homogénéité des tags 
utilisés. Pour les bouches de métro, il y a eu, historiquement, une 
première tentative de les relier aux stations à l'aide de relations qui 
semblent avoir toutes disparues aujourd'hui.


Il y a aussi eu un usage des relations "site", on en trouve encore 
(Pigalle, Gare d'Austerlitz, Cité Universitaire).


Puis, le schéma pour les transports publics a évolué et la notion de 
stop_area est arrivée qui permet de faire le lien bouche de métro/station.


Des bouches de métro membre d'aucune relation il y en a, sûrement 
beaucoup, exemple: https://www.openstreetmap.org/node/6462062885



Un travail d'harmonisation, documenté serait fort utile !

Pour commencer, j'irai regarder ce qui se fait ailleurs dans le monde... 
histoire de ne pas inventer un truc génial mais isolé.


Ce dont on a besoin, c'est:

- un nom et/ou un numéro pour la sortie (noms et numéros qu'on trouve 
sur les panneaux dans les stations)


- un lien vers la station (relation)


Le 13/02/2020 à 23:17, Sébastien Hinderer a écrit :

Bonsoir Marc,

Merci beaucoup pour ta réponse rapide!

marc marc (2020/02/13 21:51 +):

à chaud, sans avoir été chercher la précédente discussion sur le sujet :

le nom de la station n'est pas celui de la sortie, le wiki recommande
l'utilisation d'une relation public_transport=stop_area
pour les lier (et je partage cet avis)

OK. Si j'ai bien compris ça fait ce que je suggérais pour regrouper les
bouches par stations donc c'est bien, ça veut dire que
l'information est déjà présente! Ce que je me demande c'set si on peut
raisonnablement estimer que c'est exhaustif, ou est-ce qu'il manque des
choses? La question se pose pour les bouches elles-mêmes aussi,
d'ailleurs.

J'essaierai de voir bientôt s'ily a des bouches qui ne sont dans aucune
relation par exemple, des choses comme ça.


les sorties devraient avoir leur no dans ref=*, j'espère que tout le
monde était d'accord :)

266 noeuds sans tag ref. Est-ce que l'absence de ce tag a aussi une
sémantique (par exemple il n'y a qu'une sortie), ou est-ce que ce sont
des données manquantes?

Quid de exit_number alors? Faudrait-il l'enlever?


de mémoire (mais je peux me tromper) nous avions surtout discuté du tag
name qui souvent n'est pas vraiment un nom propre à la sortie mais une
destination (pour lequel il existe le tag destination, par exemple
utilisé pour les sorties routières). bien que pertinent comme argument,
je m'en tiens pour l'instant à l'usage documenté (le tag name).

1070 noeuds ont un attribut name, seulement 57 ont un attribut
destination. Est-ce que du coup on pourrait faire disparaître l'attribut
destination?

Et qu'en est-il de découper le contenu de name, ou au moins d'en avoir
une version alternative découpée en plusieurs morceaux?


j'avais testé une appli capable d'indiquer le no de sortie le plus court
vers la destination, je ne me souviens hélas plus de son nom.

Il y a "Métro sorties" que j'avais mais qui ne marche plus trop bien. Il
y en a d'autres aussi mais qui ofnt les choses de façon graphique, donc
inutilisable pour les déficients visuels.

Sébastien.

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


--
Christian Quest - OpenStreetMap France


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

Re: [Talk-it] centro riparazione elettrodomestici

[Martin Koppenhoefer]

Am Do., 13. Feb. 2020 um 09:22 Uhr schrieb demon_box <
e.rossini7...@gmail.com>:

>
> appunto, io per ora utilizzo
>
> craft=appliances_repair
>
> grazie
>


mi sembra adatto come tag.
Purtroppo usato pochino,

6x craft=appliance_repair
3x craft=appliances_repair

Lo vogliamo documentare? Meglio singolare o plurale?

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

Re: [OSM-talk] OTG rule, borders & mountains existing | Re: Crimea situation - on the ground

[Martin Koppenhoefer]

Am Do., 13. Feb. 2020 um 08:41 Uhr schrieb Colin Smale <
colin.sm...@xs4all.nl>:

> Locations are stored in OSM as pairs of {lat,lon} and I assume these are
> both 64-bit floats in the database.
>
>
> AFAIK they are stored as integers (shifting the decimals)
>
> If so then then my comments about preserving precision still apply to all
> "client" software and I bet the majority uses float. Then an innocent
> update to a tag on a node can end up unintentionally moving the location
> slightly, losing precision.
>
>



My comment about precision lost through conversion was not about missing
floating point digits, but about conversions from one CRS to another, where
you may need additional (proprietary) grid parameters to do a high
precision conversion.

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

Re: [Talk-it] mancate attribuzioni su immagini pubblicate

[Martin Koppenhoefer]

Am Do., 13. Feb. 2020 um 13:39 Uhr schrieb Marcello :

> Informo che ne sito http://www.osservatoriometeoesismicoperugia.it/ hanno
> provveduto ad aggiungere l'attribuzione, nella pagina Geolocalizzazione
> hanno messo anche il link al sito OSM.
>

grazie!

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

Re: [OSM-talk] Is OSM Anti-Fascist? (was: Cease use of OpenStreetMap/Antifa logo)

[Martin Koppenhoefer]

Am Do., 13. Feb. 2020 um 14:28 Uhr schrieb Frederik Ramm <
frede...@remote.org>:

> where governments propose or make laws that would
> make it harder for us to map, I think we should oppose that in a
> structured way, as an organisation - provided we have the time and
> energy for that.




+1, I agree, but ultimately this means we would act politically (as an
organization).

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

Re: [OSM-talk] Cease use of OpenStreetMap/Antifa logo

[Martin Koppenhoefer]

Am Do., 13. Feb. 2020 um 13:42 Uhr schrieb Maarten Deen :

>  From wikipedia (if that is an authority)
>


it isn't.

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

Re: [OSM-talk-fr] Nettoyage Enedis / GRDF

[PanierAvide]

Bonjour François,

Merci pour ce travail de documentation et d'animation de communauté ! Je 
viens de faire la bascule en Bretagne des operator=ERDF/EDF vers 
operator=Enedis sur le réseau de distribution. Je n'ai pas modifié les 
operator=EDF sur tout ce qui est production d'énergie (centrales 
électriques).


Cordialement,

Adrien P.

Le 14/02/2020 à 00:29, François Lacombe a écrit :

Salut à tous,

Il devenait nécessaire de créer une page wiki pour Enedis et GRDF, nos 
opérateurs de distribution préférés pour documenter les pratiques les 
concernant.

https://wiki.openstreetmap.org/wiki/FR:Tag:operator%3DGRDF

En particulier Enedis qui mérite un bon nettoyage puisque qu'il y a 
encore ~2500 operator=ERDF et quelques operator=EDF qui traînent (on a 
dépassé les 100 000 pour Enedis)


Un résumé des différentes valeurs est visible ici
https://wiki.openstreetmap.org/wiki/FR:Tag:operator%3DEnedis

Si certains objets concernés se trouvent dans votre zone de 
prédilection, cela sera utile de mettre la bonne valeur pour operator
Il est possible de vérifier si Enedis est bien le gestionnaire du 
réseau sur la commune ici

https://dataviz.agenceore.fr/distributeurs-energie-france/

Au passage, compléter les postes, *poteaux* et autres ouvrages avec 
ref:FR:gdo et name est apprécié

https://wiki.openstreetmap.org/wiki/FR:Key:ref:FR:gdo

A disposition en cas de questions sur le sujet

Bonne soirée

François

___
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