Re: [OSM-talk-fr] Aire de retournement

[Arnaud Champollion]

Le 24/01/2020 à 05:46, Philippe Verdy a écrit :
peut-être une voie de service, mais pas sûr que ce soit réservé 
seulement aux bus


Non il n'y a pas de signalétique la réservant aux bus.

, et dans ce cas c'est encore la fin de la rue résidentielle qui y 
arrive (et d'ailleurs ça se voit aux adresses FANTOIR, le Chemin du 
Marquis est en voie publique même si c'est une impasse avec un seul 
résident).


Donc ça devrait être en highway=residential avec surface=unpaved ? En 
fait pour l'instant il y a highway=track à cause du non-revêtement, mais 
c'est peut-être justement une erreur.


Au passage la boucle est mal alignée, elle passe un peu plus à l'ouest 
(on la voit bien à travers les branches de arbres dessus à l'extrémité 
de l'îlot, et le chmein du Marqui tombe bien sur cette boucle et non 
sur le sentier allant vers l'ouest).


OK j'ai corrigé cela.


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

Re: [OSM-talk-fr] Doublon Wikipédia

[Philippe Verdy]

Tu peux toujours créer une relation site pour lier ensemble le château
d'une commune et ses dépendances WP.
Ne donner le nom du Chateau que sur le bâtiment du château lui-même, lui
donner un attribut "castle/manor" approprié, et les attributs corrects ou
simplement "building" pour les dépendances ayant leur propre inscription
Mérimée dessus, même s'ils sont regroupés dans la relation site concernant
le château lui-même qui aura lui même son inscription Mérimée, mais pas la
relation site qui ne porte que le WP commun.

Autre solution: si l'article de Wikipédia a des sections séparées pour le
château et les dépendances, ajouter "#nom-de-section" au nom de la page en
valeur du tag pour indiquer la section des dépendances.

Dernière solution: une seule relation multipolygone de site classé
comprenant tout les batiments, avec un seul lien Wikipédia dessus mais sur
aucun bâtiment, mais le tag de référence Mérimée contenant les deux numéros
de classement avec un point-virgule. On peut laisser les noms en "doublon"
sur un bâtiment de chaque commune (pour montrer qu'il est classé dans les
deux communes et pas une seule), mais aucun lien WP sur eux.

Le seule problème que tu as en fait c'est unicité du lien WP et c'est là
qu'une relation site peut servir, même si la relation n'a elle-même pas de
référence Mérimée pour sa totalité mais seulement pour ses parties.

Il est difficile de parler aujourd'hui de "dépendances" quand l'ancien
domaine a été divisé administrativement et n'est sans doute même plus une
propriété unique, chaque batiment ayant son usage propre et ses propres
éléments de conservation qui ont été classés à des dates différentes et
pour d'autres raisons (qui peuvent aussi inclure parcs, jardins et bois,
anciens portails, et éléments de décor statuaire, fontaine, éléments
spécifiques de leur façade, leur toit ou à l'intérieur comme des plafonds
peints, des bas-reliefs, des panneaux et portes sculputées, des cheminées
ou anciennes cuisines, etc.). La présence de la piscine pour le batiment
nord et son jardin privé cloturé semble indiquer que ce sont plusieurs
propriétés dans des états différents, même s'il y a encore un chemin
préservé entre les deux pour les visiteurs des deux parties.

Le jeu. 23 janv. 2020 à 23:19, deuzeffe  a écrit :

> reBonsoir,
>
> Soit le château https://www.openstreetmap.org/way/235798481 en base
> Mérimée et sur wikipédia.
>
> Soient ses dépendances https://www.openstreetmap.org/node/5176892546 en
> base Mérimée aussi (mais notice différente) et aussi sur wikipédia
> (entrée identique, évidemment, sinon, c'est pas drôle).
>
> (on remarquera qua la limite communale passe entre les deux...)
>
> Osmose me signale à raison un doublon WP.
>
> Je supprime la un des tag WP (si oui, lequel ?) ?
>
> Et au passage, pas réussi à trouver un tag pour dépendances-du-chateau.
>
> Aide bienvenue, donc ^^
>
> Merci.
> --
> deuzeffe
>
>
> ___
> 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] Aire de retournement

[Philippe Verdy]

de plus cette boucle n'est pas que pour les bus puisqu'il y a un chemin
d'accès à un résidence qui tombe dessus. Bref peut-être une voie de
service, mais pas sûr que ce soit réservé seulement aux bus, et dans ce cas
c'est encore la fin de la rue résidentielle qui y arrive (et d'ailleurs ça
se voit aux adresses FANTOIR, le Chemin du Marquis est en voie publique
même si c'est une impasse avec un seul résident).

Au passage la boucle est mal alignée, elle passe un peu plus à l'ouest (on
la voit bien à travers les branches de arbres dessus à l'extrémité de
l'îlot, et le chmein du Marqui tombe bien sur cette boucle et non sur le
sentier allant vers l'ouest). Tant qu'à corriger, autant regagner un peu en
précision avec l'imagerie BDOrtho, y compris les bâtiments trop petits ou
manquants. Et aussi ajouter les portails au bout des impasses.

Le ven. 24 janv. 2020 à 05:39, Philippe Verdy  a écrit :

> Ca ne me parait pas être une "aire" s'il y a un îlot central, qui plus est
> gazonnée, et planté d'un arbre, donc pas empruntable par le bus qui doit
> tourner autour. La boucle semble appropriée...
>
> Le jeu. 23 janv. 2020 à 22:32, Arnaud Champollion <
> arnaud.champoll...@linux-alpes.org> a écrit :
>
>> Le 23/01/2020 à 22:28, Vincent de Château-Thierry a écrit :
>> > Si tu as un lien vers la zone ? C'est toujours plus simple pour se
>> > faire une idée.
>>
>> Ah oui désolé j'ai oublié le lien
>>
>>
>> https://www.openstreetmap.org/changeset/79996713#map=19/44.08023/6.20833
>>
>>
>>
>> ___
>> 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] Aire de retournement

[Philippe Verdy]

Ca ne me parait pas être une "aire" s'il y a un îlot central, qui plus est
gazonnée, et planté d'un arbre, donc pas empruntable par le bus qui doit
tourner autour. La boucle semble appropriée...

Le jeu. 23 janv. 2020 à 22:32, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> Le 23/01/2020 à 22:28, Vincent de Château-Thierry a écrit :
> > Si tu as un lien vers la zone ? C'est toujours plus simple pour se
> > faire une idée.
>
> Ah oui désolé j'ai oublié le lien
>
>
> https://www.openstreetmap.org/changeset/79996713#map=19/44.08023/6.20833
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

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

[Alexandre Oliveira]

Eu gostaria de sugerir que as classificações viárias para vias
"municipais" (de menor importância se comparadas a rodovias estaduais e
federais), pois ajudaria muito mapeadores iniciantes como eu.

Acredito que as páginas atuais para classificações viárias na Wiki estão
confusas. Outro dia fui reclassificar uma avenida que corta três bairros
em BH e não sabia qual página usar, me deparei com uma que possuía um
fluxograma, que considerava qualquer tipo de via mas era um pouco
confuso de compreender, e depois a própria página da tag `highway` em
português, que, apesar de descrever critérios para cada tipo de
classificação, me deixou mais confuso. Por exemplo, as definiçãos de
`secondary` e `tertiary` são bem semelhantes e no caso eu não sabia qual
escolher.

O problema mencionado acima é uma avenida que cruza três bairros, e no
meio do caminho sua classificação era rebaixada. Estou falando da Av.
Professor Mario Werneck, de BH. O próprio plano diretor mais recente da
cidade (2019) a considera como arterial, até ela mudar de nome para Av.
Aggeo Pio Sobrinho, onde passa a ser considerada coletora até cruzar com
a Rua Úrsula Paulino e finalmente chegar na Av. Teresa Cristina[1]
(arterial é laranja, coletora é amarela. Hierarquia viária mais
recente[2]). Contudo, passando quase que diariamente por estes trechos
mencionados, sei que a realidade é outra, apesar da troca de nome, a
avenida ao todo mantém sua importância ao atravessar os bairros,
portanto para mim esse rebaixamento de classificação é equivocado.

A sugestão proposta pelo santamariense no grupo de suporte foi seguir a
classificação da primeira avenida (Mário Werneck), que foi o que fiz.
Antes, a Av. Mário Werneck era uma `secondary`, e, ao trocar de nome
para Av. Aggeo Pio Sobrinho e mais pra frente para Av. Dom João VI, ela
era rebaixada para `tertiary`, porém, como disse, esse rebaixamento não
condiz com a importância dessas vias.



Outro ponto que gostaria de questionar é justamente o princípio de
continuidade. Tem uma via que eu considero problemática, a Av. Nossa
Senhora do Carmo. Até mais ou menos um pouco à frente do cruzamento e do
viaduto da avenida, ela muda de nome e torna-se uma rodovia federal, a
BR-356[3], com base no BHMap, portal de dados georreferenciados da
prefeitura. Já no plano diretor, a situação é outra e a avenida somente
torna-se uma rodovia federal após o trevo do BH Shopping[4], sendo
considerada uma via de ligação regional.

No caso, qual seria o certo para ser representado no mapa? Atualmente, o
que está mapeado é justamente o primeiro caso que mencionei[5].



Seguindo o plano diretor, a grande maioria das ruas do centro de Belo
Horizonte são arteriais[5], porém apenas umas três avenidas são
consideradas `primary`, as principais avenidas do centro são `secondary`
e nem todas as ruas, consideradas arteriais pelo plano diretor, são
`tertiary`[6]. Como ficaria o mapeamento neste caso, visto que o centro
é uma região de alto tráfego de veículos?



O Gerald mencionou o uso dos dados do DEER, mas eles não seriam
aplicados somente para as rodovias sob sua jurisdição, que seriam as
estaduais e federais? Quais dados deveríamos usar para as vias
municipais? E no caso, qual dado usar, o portal de dados
georreferenciados da prefeitura ou o plano diretor da cidade?



[1] https://i.imgur.com/3dxuh8u.png (grifo próprio)
[2]
http://cmbhsildownload.cmbh.mg.gov.br/silinternet/servico/download/documentoDaNorma?idDocDaNorma=2c907f766c440a9f016c76339e9d00ca
[3] https://www.openstreetmap.org/way/362639212#map=17/-19.95819/-43.94155
[4] https://i.imgur.com/mZ4eMMi.png
[5] https://i.imgur.com/MNR607q.png
[6] https://www.openstreetmap.org/#map=15/-19.9243/-43.9384



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

Re: [Talk-us] When is your doctor a clinic?

[Jmapb]

On 1/23/2020 8:14 PM, Shawn K. Quinn wrote:


On 1/23/20 17:29, Jmapb wrote:

However, truth be told, since the default map has ceased rendering
healthcare=*, I've found myself tagging anything smaller than a hospital
but larger than a doctor's office as amenity=clinic. For example, the
"freestanding emergency departments" that were discussed on the Tagging
list last April. This is one area where I'm not too shy about tagging
for the renderer.

Our tagging scheme needs to catch up to this and offer another option
between clinic and hospital. I must have missed the discussion about
this, or I'm not on that list; why is healthcare=* no longer being rendered?


There was an issue rendering polygons that had healthcare tags but
didn't have amenity tags, which was a lot of them, especially given the
variety of healthcare tags that don't have an amenity equivalent. If you
want to get into the nitty-gritty:

https://github.com/gravitystorm/openstreetmap-carto/pull/3731
https://github.com/gravitystorm/openstreetmap-carto/pull/3644

Even with established healthcare=* tags, though, the question of
"another option between clinic and hospital" isn't exactly settled. For
instance, some mappers seem to think healthcare=centre fits in that
slot, but others use it for a large healthcare campus that contains
several hospitals.

J


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

Re: [talk-ph] Follow-up on possible LGU-led mapping in Batangas

[maning sambale]

TagaSanPedroAko,

> and asked GOwin and maning on GitHub to contact directly any of the LGUs 
> involved, but there has been no response since then.

I'm not sure what else I can do here, you mentioned that you already
contacted 3 users and there was no response.
Secondly, these LGUs are likely swamped with work due to the Taal
response, asking about this issue at this time seems inappropriate.


On Fri, Jan 24, 2020 at 4:35 AM Jherome Miguel  wrote:
>
> It has been a month ago since I raised quality issues on map data added on a 
> possible local government-led mapping project in some municipalities in 
> Batangas near Taal Volcano. Last December, we have seen a spike in mapping 
> activity around the municipalities of Taal, Lemery, San Luis, San Nicolas, 
> and Santa Teresita in Batangas, and involves around 24+ users, many mapping 
> using accounts with their real names. I opened a papercut_fix ticket 
> (https://github.com/OSMPH/papercut_fix/issues/56), partially cleaned up the 
> questionable edits, sent private emails to some of the users involved, and 
> asked GOwin and maning on GitHub to contact directly any of the LGUs 
> involved, but there has been no response since then. Since the 2020 eruption 
> of Taal Volcano, I have thought of a possibility the organized mapping 
> project has something to do with disaster preparedness (taking in account the 
> location of those municipalities around Taal Volcano), though it also equally 
> possible the editing is also for land use planning (for Comprehensive Land 
> Use Plan maps) and other purposes. Can someone follow up attempts to contact 
> the LGUs, especially through their disaster risk reduction/management or 
> planning/development offices (though this may not be possible due to the 
> lockdown on the volcano danger zone), or bring up any previous attempts to 
> contact them?
>
>
> --TagaSanPedroAko
> ___
> talk-ph mailing list
> talk-ph@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ph



-- 
cheers,
maning
--
"Freedom is still the most radical idea of all" -N.Branden
https://github.com/maning
http://twitter.com/maningsambale
--

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

Re: [Talk-us] When is your doctor a clinic?

[Shawn K. Quinn]

On 1/23/20 17:29, Jmapb wrote:
> However, truth be told, since the default map has ceased rendering
> healthcare=*, I've found myself tagging anything smaller than a hospital
> but larger than a doctor's office as amenity=clinic. For example, the
> "freestanding emergency departments" that were discussed on the Tagging
> list last April. This is one area where I'm not too shy about tagging
> for the renderer.

Our tagging scheme needs to catch up to this and offer another option
between clinic and hospital. I must have missed the discussion about
this, or I'm not on that list; why is healthcare=* no longer being rendered?

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

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

Re: [Talk-at] Überregionale Wanderwege aus lokalen Wegen zusammensetzen?

[Robert Grübler]

Patrick Strasser-Mikhail [mailto:patr...@wirklich.priv.at] schrieb am 
Donnerstag, 23. Jänner 2020 23:35

 

> Ich kann das Argument der Attributszuordnung nicht nachvollziehen

> Die Attribute der Route beschreiben ja nichts physisches außer Distanz 

> und Höhenangaben …

 

Die Attribute operator, website, network usw können widersprüchlich sein.

 

> Im Konkreten frage ich mich, ob es nicht sehr viel Übersichtlicher 

> und der dokumentation der tatsächlichen Natur der Sache näher 

> wäre, solche "Sammelwege" auch so zu strukturieren.

 

Ja und nein. Eine gute Gegenüberstellung findest du hier: 

https://wiki.openstreetmap.org/wiki/Relation:route#Multiple_routes_sharing_the_same_ways
 

 

> Ich könnte mir vorstellen, dass die als eigene Relationen 

> zusammen gestellt werden, aber dann nicht type, route und 

> network so bekommen, dass sie als eigenständige Wege 

> erkannt werden (z.B. route=hiking_subroute). Name könnte 

> dann einen Beschreibung der Teilstrecke sein mit "Wanderweg xxx, Teil ...".

 

Ich sehe keinen Grund für einen neuen Relationstyp. Siehe den Lösungsansatz von 
Waymarked Trails: 

https://cycling.waymarkedtrails.org/help/rendering/hierarchies   

 

Ich würde keine Route teilen, nur weil eine andere Route einmündet, das wäre 
mir zu künstlich. Nur wenn sie über eine lange Strecke identisch verläuft und 
sich in einer Etappenteilung harmonisch einfügt, könnte ich mir das vorstellen.

 

Liebe Grüße

Robert (robhubi)

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

Re: [Talk-us] When is your doctor a clinic?

[Mike N]

On 1/23/2020 6:51 PM, Frederik Ramm wrote:

I'm not trying to apply my understanding of medical establishments to
the US - just asking what the general understanding is on your side of
the pond. Does Jmapb's distinction sound more or less ok for others too?


Jmapb's description matches my general understanding.

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

Re: [Talk-us] When is your doctor a clinic?

[Harald Kliems]

German native speaker who has lived in the US for a good while and works in
health research.  Jmapb's definition sounds pretty good to me. I think the
"accept walk-ins" may not be a great distinguisher. I can think of several
clinics here that don't accept walk-ins, and my small dentist practice does
accept walk-ins.

For the "usually named": I'd say a clinic would never not be named, but a
small doctor's office may still be named, as in your dentist example. Seems
less likely outside of dentistry.

In general, clinics are just more common in the US than in clinic because
of the structure of the healthcare system, which makes it quite difficult
to run a single-physician office (with the exception of certain
subspecialties or in certain locations).

 Harald.

On Thu, Jan 23, 2020 at 5:52 PM Frederik Ramm  wrote:

> Hi,
>
> On 1/23/20 22:42, Paul Johnson wrote:
> > There may be a disconnect with what the US (or that spammer) means.
> > Could I get a clarification on the difference between "doctors" and
> > "clinic" as you understand it?
>
> Personally (and in my country - Germany) there's precious little I would
> tag as a clinic; in everyday language we use the (german version of) the
> word clinic more or less synonymous with "hospital", with the possible
> exception that we'd also apply clinic to something that deals
> exclusively with non-illness-related things like e.g. a beauty clinic or
> a drug rehab clinic. In my language, a clinic would always be something
> where you can (and usually do) have a bed and stay for longer until the
> treatment is over. A building with a couple of different medical
> practitioners might be a "Gemeinschaftspraxis" ("shared practice") or
> perhaps an "Ärztehaus" (doctors' house) but not a "Klinik". Then again
> these would hardly ever be open 24/7...
>
> I'm not trying to apply my understanding of medical establishments to
> the US - just asking what the general understanding is on your side of
> the pond. Does Jmapb's distinction sound more or less ok for others too?
> He wrote:
>
> > amenity=doctors:
> > * are usually operated by (and even named for) a particular doctor (or a
> small partnership)
> > * are usually either a general practice or specialize in a small number
> of areas
> > * often require an appointment
> > * usually have typical daytime business hours
> >
> > amenity=clinic:
> > * are usually named like a business
> > * feature a larger medical staff, often rotating
> > * offer treatment for a wide variety of issues
> > * generally accept walk-in patients
> > * often have extended hours, including 24/7
>
> Is this "usually named ..." really a thing - I have a feeling that
> especially with dentists, even (what seems to me like) one-doctor
> practices will often be called some thing like "Bay Area Smiles Family
> Dentist" or something like that.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>


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

Re: [Talk-us] When is your doctor a clinic?

[Frederik Ramm]

Hi,

On 1/23/20 22:42, Paul Johnson wrote:
> There may be a disconnect with what the US (or that spammer) means. 
> Could I get a clarification on the difference between "doctors" and
> "clinic" as you understand it? 

Personally (and in my country - Germany) there's precious little I would
tag as a clinic; in everyday language we use the (german version of) the
word clinic more or less synonymous with "hospital", with the possible
exception that we'd also apply clinic to something that deals
exclusively with non-illness-related things like e.g. a beauty clinic or
a drug rehab clinic. In my language, a clinic would always be something
where you can (and usually do) have a bed and stay for longer until the
treatment is over. A building with a couple of different medical
practitioners might be a "Gemeinschaftspraxis" ("shared practice") or
perhaps an "Ärztehaus" (doctors' house) but not a "Klinik". Then again
these would hardly ever be open 24/7...

I'm not trying to apply my understanding of medical establishments to
the US - just asking what the general understanding is on your side of
the pond. Does Jmapb's distinction sound more or less ok for others too?
He wrote:

> amenity=doctors:
> * are usually operated by (and even named for) a particular doctor (or a 
> small partnership)
> * are usually either a general practice or specialize in a small number of 
> areas
> * often require an appointment
> * usually have typical daytime business hours
> 
> amenity=clinic:
> * are usually named like a business
> * feature a larger medical staff, often rotating
> * offer treatment for a wide variety of issues
> * generally accept walk-in patients
> * often have extended hours, including 24/7

Is this "usually named ..." really a thing - I have a feeling that
especially with dentists, even (what seems to me like) one-doctor
practices will often be called some thing like "Bay Area Smiles Family
Dentist" or something like that.

Bye
Frederik

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

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

Re: [Talk-us] When is your doctor a clinic?

[Jmapb]

On 1/23/2020 5:30 PM, Bill Ricker wrote:

My US doctor's office *is* a clinic, but that's because they were
previously an all in one HMO before merger/spinoff. On-site blood lab,
x-ray, specialities, pediatrics, coffee shop, PT/OT, optometry,
pharmacy, ... . Multiple docs and nurses in each practice for cover.
Larger clinics in chain have urgent care, can even apply a cast if you
break a limb early enough in the day (one shift only).  Can even do
light surgery e.g. drain an abscess.

It has a corporate name, not "Dr P Smith, MD PC".
Otoh the back country family-practice partnership that took care of my
family 50 years ago had a small surgery in the British sense en-suite,
in addition to consulting and examining rooms, and could be called a
clinic - they had an autoclave and a centrifuge.


As I tag them,

amenity=doctors:
* are usually operated by (and even named for) a particular doctor (or a
small partnership)
* are usually either a general practice or specialize in a small number
of areas
* often require an appointment
* usually have typical daytime business hours

amenity=clinic:
* are usually named like a business
* feature a larger medical staff, often rotating
* offer treatment for a wide variety of issues
* generally accept walk-in patients
* often have extended hours, including 24/7

However, truth be told, since the default map has ceased rendering
healthcare=*, I've found myself tagging anything smaller than a hospital
but larger than a doctor's office as amenity=clinic. For example, the
"freestanding emergency departments" that were discussed on the Tagging
list last April. This is one area where I'm not too shy about tagging
for the renderer.

Jason

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

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

[Fernando Trebien]

On Thu, Jan 23, 2020 at 7:50 PM Gerald Weber  wrote:
> dito tudo isto, na verdade realmente tanto faz, ninguém usa o OSM para quase 
> nada. Depois de 15 anos a maioria das pessoas nem nunca ouviu falar, tudo é 
> só Google Maps. Além disto o mapa não é confiável, e da maneira como opera, 
> nunca vai ser.

O OSM é usado por um monte de gente importante:
https://wiki.openstreetmap.org/wiki/Major_OpenStreetMap_Consumers#As_a_base_map

Infelizmente, o fato de os dados serem do OSM geralmente fica relegado
a uma tímida nota de rodapé, que poucos lêem, e os usuários acham que
tudo é obra do provedor do serviço - que também tem seu mérito, claro.

No fundo, as pessoas querem uma classificação que as ajude a encontrar
os seus caminhos e a entender a sua própria localização e a das coisas
ao redor. A falta de adoção do OSM me sugere que deveríamos nos
perguntar por que as pessoas estão preferindo os concorrentes que usam
uma classificação que não seja baseada na estrutura física. Eu
acredito que é porque o resultado fica simplesmente confuso.

Quanto ao mascaramento dos problemas, eu não entendo bem a sua
indignação (gostaria de entender melhor). Você pode mapear as
características das vias em detalhe, representando assim de forma bem
rica as deficiẽncias das vias, e os interessados podem produzir uma
renderização para isso, ou para propósitos mais específicos sempre é
possível baixar os dados usando o Overpass e aplicar uma estilização
customizada no JOSM. De fato, a camada Humanitária muda a
representação das vias não-pavimentadas de alta classe, aceitando
então que essa combinação é possível, justamente porque o HOT trabalha
nas regiões menos desenvolvidas do planeta onde essa combinação
costuma ocorrer.

Como exemplo, nós podemos buscar um pouco de inspiração num dos países
com mais mapeadores no OSM, vastas diferenças na sua densidade
populacional, e vários problemas de infraestrutura: a Rússia. Lá no
finalzinho da Sibéria tem uma trunk (a rota R504) que não é
pavimentada, cruzando uma distância enorme, levando até uma cidade com
um pouco menos de 100 mil habitantes (Magadan). Se mudamos de país e
de realidade econômica e cultural e vamos pro Canadá, na referência de
classificação oficial deles há uma menção de que as trunks não
precisam ser pavimentadas. [2] Então, não sei se se sustenta bem o
argumento de que a importância da via está intimamente atrelada à sua
estrutura física em todas as situações. Eu acho que pode estar
atrelada em situações extremas, tanto no extremo mais alto (motorway)
quanto no mais baixo (service=alley nas vias públicas que são muito
estreitas), mas no meio do caminho o wiki do OSM e o resultado dos
outros países parece sugerir uma certa flexibilidade em relação à
estrutura física.

Eu gostaria de discutir vários dos outros pontos que você colocou, mas
acho que seria melhor quebrá-los em tópicos para não poluir a lista. O
melhor pra isso seria o fórum. Em especial, sobre a sua última
observação do DEER, eu entendo que eles estavam medindo demanda, que
está atrelada ao VDM, que está atrelado à estrutura física, não
necessariamente definindo a importância das vias. Se possível, e com
tempo, eu queria que você desse uma olhada no material do DER/SC que
diferencia classificação funcional, volume de tráfego e estrutura
física. [1]

Sobre tempo, eu também entendo que essa proposta não vai ser aprovada
da noite pro dia e que precisaria de vários ajustes às realidades
locais. No RS, foram alguns meses de discussão, mais muitos meses de
validação, e depois mais um tempo de espera pra ver se haveria
questionamentos, daí implementação. Da minha parte, não quero
atropelar ninguém, e entendo que se faz proposta para para ouvir
opiniões, até porque novos consensos podem levar a alterações naquilo
que já foi aprovado no RS, etc.

[1] https://forum.openstreetmap.org/viewtopic.php?pid=688142#p688142
[2] https://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Trunk

-- 
Fernando Trebien

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

Re: [Talk-us] When is your doctor a clinic?

[Bill Ricker]

My US doctor's office *is* a clinic, but that's because they were
previously an all in one HMO before merger/spinoff. On-site blood lab,
x-ray, specialities, pediatrics, coffee shop, PT/OT, optometry, pharmacy,
... . Multiple docs and nurses in each practice for cover. Larger clinics
in chain have urgent care, can even apply a cast if you break a limb early
enough in the day (one shift only).  Can even do light surgery e.g. drain
an abscess.

It has a corporate name, not "Dr P Smith, MD PC".
Otoh the back country family-practice partnership that took care of my
family 50 years ago had a small surgery in the British sense en-suite, in
addition to consulting and examining rooms, and could be called a clinic -
they had an autoclave and a centrifuge.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [talk-cz] WeeklyOSM CZ 494

[majka]

Myšleno to bylo jinak:
Žiju v tom, že "nezmapovaná místa" hledají v obci alespoň jednu
"residential" cestu. Pokud nenajdou, označí to místo jako nezmapované.
U toho co jsem měla na mysli ty baráky zkrátka jen lemují silnici I. /
II. / III. třídy. Nic jiného než ten průjezd skrz tam není, i vjezd na
pole bývá mimo ves.

U toho Bingu:
Ty vjezdy co to po okolí našlo jsou všechny za plotem, resp. za zdí,
neviditelné jinak než z leteckých snímků, zkrátka umělé inteligenci
buď chyběl jen ten kus "za zdí", nebo celý ten vjezd do zahrady, pokud
tam fakticky nic jiného není (třeba hned u silnice je plot).

Mapovat někomu zahradu nebo dvůr preventivně (vč. označení jako
soukromé) jen proto, aby to tam někdo nenastřílel podle Bingu se mi
jako řešení nelíbí.
Jedna možnost by byla zakreslit ty bariéry jako takové, tedy ten plot
podél ulice a doufat, že to mapujícím bez místní znalosti dojde.
Fakticky taky jen práce pro práci.


On Thu, 23 Jan 2020 at 15:07, Marián Kyral  wrote:

>
> -- Původní e-mail --
> Od: Michal Fabík 
> Komu: talk-cz@openstreetmap.org
> Datum: 23. 1. 2020 13:58:51
> Předmět: Re: [talk-cz] WeeklyOSM CZ 494
>
> On 1/23/20 1:45 PM, majkaz wrote:
> > Namapovat tam nějaký vjezd jako residential jen proto, aby to přestalo
> vyskakovat, se mi opravdu nechce.
> >
> >
> Nebylo vhodnější highway=service + service=driveway, případně +
> access=private (pokud je to z nějakého zdroje poznat)? To by asi vyřešilo
> problém s false positives a navíc by to i odpovídalo skutečnosti.
>
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-ph] Follow-up on possible LGU-led mapping in Batangas

[Nick Brown]

Hi Jherome,
HOT Ph is in touch with the Batangas PDRRMO via OCHA as well as OCD, but am
not directly in touch with the municipalities. I'm unaware of any
coordinated mapping efforts underway in affected areas, but HOT Ph can
provide trainers to local LGUs upon request.

We have a virtual mapathon planned for Monday evening 7-10pm and hopefully
by then we will have permission from all data providers by then to validate
and release ~550 Evacuation Center locations.

As I understand it, the affected areas are as well mapped as possible via
satellite imagery and can only be improved by local knowledge, hence HOT Ph
has not activated a mapping response. If you're aware of any LGUs who'd
like to improve their local maps please connect them with me.

Best,
Nick

On Fri, Jan 24, 2020 at 4:35 AM Jherome Miguel 
wrote:

> It has been a month ago since I raised quality issues on map data added on
> a possible local government-led mapping project in some municipalities in
> Batangas near Taal Volcano. Last December, we have seen a spike in mapping
> activity around the municipalities of Taal, Lemery, San Luis, San Nicolas,
> and Santa Teresita in Batangas, and involves around 24+ users, many mapping
> using accounts with their real names. I opened a papercut_fix ticket (
> https://github.com/OSMPH/papercut_fix/issues/56), partially cleaned up
> the questionable edits, sent private emails to some of the users involved,
> and asked GOwin and maning on GitHub to contact directly any of the LGUs
> involved, but there has been no response since then. Since the 2020
> eruption of Taal Volcano, I have thought of a possibility the organized
> mapping project has something to do with disaster preparedness (taking in
> account the location of those municipalities around Taal Volcano), though
> it also equally possible the editing is also for land use planning (for
> Comprehensive Land Use Plan maps) and other purposes. Can someone follow up
> attempts to contact the LGUs, especially through their disaster risk
> reduction/management or planning/development offices (though this may not
> be possible due to the lockdown on the volcano danger zone), or bring up
> any previous attempts to contact them?
>
>
> --TagaSanPedroAko
> ___
> talk-ph mailing list
> talk-ph@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ph
>


-- 
*Nick Brown*
Country Manager for HOT Philippines
nick.br...@hotosm.org

*Humanitarian OpenStreetMap Team*
*Using OpenStreetMap for Disaster Risk Reduction, Response & Development*
web  | twitter  |
facebook 
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[OSM-talk-fr] Doublon Wikipédia

[deuzeffe]

reBonsoir,

Soit le château https://www.openstreetmap.org/way/235798481 en base 
Mérimée et sur wikipédia.


Soient ses dépendances https://www.openstreetmap.org/node/5176892546 en 
base Mérimée aussi (mais notice différente) et aussi sur wikipédia 
(entrée identique, évidemment, sinon, c'est pas drôle).


(on remarquera qua la limite communale passe entre les deux...)

Osmose me signale à raison un doublon WP.

Je supprime la un des tag WP (si oui, lequel ?) ?

Et au passage, pas réussi à trouver un tag pour dépendances-du-chateau.

Aide bienvenue, donc ^^

Merci.
--
deuzeffe


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

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

[Gerald Weber]

agradeço aos colegas por todos os detalhamentos e respostas

pensei bastante e no final volto exatamente à mesma pergunta crucial do
debate de 2013: afinal o que queremos representar no mapa? O país como ele
é ou como deveria ser?

A minha postura desde aquela época continua a mesma: quero um mapa que
represente a realidade das rodovias. Falo como usuário e como mapeador.

Gostei da descrição  "salada de frutas" de classificação viária, mas
francamente, não é essa a realidade das nossas rodovias? Porque mascarar?

Qual exatamente é o problema em olhar para o mapa do Brasil e ver pouca
densidade de rodovias tipo trunk? Não é essa a nossa realidade? A nossa
malha viária não é deficiente? Alguém aqui acha que é boa? Ou, devemos
fazer que nem na Argentina, mascarar a realidade e elevar qualquer coisa a
trunk só para ficar mais denso no mapa? Isto não é mapear para o
renderizador?

Voltando a proposta apresentada, agora que entendi melhor, eu fiquei
profundamente incomodado. Agora vamos mapear por "inferência"? Se tem duas
cidades com mais de 200 mil habitantes nós vamos "inferir" que as rodovias
são tipo trunk? E o que fazemos com a "realidade"? Deixa para lá porque não
fica tão bonito no mapa?

Da minha parte eu me oponho a esta proposta porque ela fere um princípio
fudamental do OSM: the truth is on the ground. A verdade não pode ser
inferida por regras arbitrárias e abstratas. É um fato que a hierarquia
rodoviária neste país é um caos, porque disfarçar?

Vamos fazer um pequeno exercício. Hoje, se eu olho o mapa e vejo uma
rodovia tipo trunk o que eu posso pensar? Pela proposta de 2013, eu deduzo
que se trata de uma rodovia de maior porte, melhor que uma primary. Esta é
uma informação útil, fácilmente acessível por qualquer usuário leigo do OSM.

Desde proposta do top+5, eu já não posso mais fazer esta afirmação
facilmente. Uma trunk pode ser uma rodovia bem estruturada ou uma completa
porcaria. Tá legal, posso olhar as tag acessórias, quantas lanes etc, mas
quem sabe fazer isto ou tem tempo para olhar? Quantas vezes você estava com
o aplicativo aberto e tendo de tomar uma decisão rápida? se você vê uma
rodovia tipo trunk, você vai por ela e pronto.

Agora, por esta proposta apresentada, todas as classificações passam as ser
"inferidas"? Então se eu vejo "trunk" significa que liga cidades de maior
porte. Tá, e daí? No que isso me ajuda? Eu já não estou vendo as cidades de
maior porte no mapa? Eu quero saber se é uma rodovia boa ou não,

Agora se for o contrário, essas duas cidades, onde pela lógica deveria
haver uma rodovia "trunk" mas eu vejo uma "secondary". Agora sim, isso é
útil. Agora eu sei que há uma infraestrutura deficiente. Por que mascarar
isto? Por que fazer de conta que é trunk?

Então, com todo respeito pelos esforços, me desculpem, mas acho que indo
pelo caminho errado. A  top+5 já foi uma proposta equivocada, mas foi uma
interferência pontual. Esta proposta é bem pior, pois todas as
classificações agora passariam a ser fictícias. Não tenho como concordar
com isto, não faz sentido.

Eu penso que o que foi apresentado não é uma proposta de mapeamento, e sim
uma proposta de roteamento, algo que poderia ser implementado em um
aplicativo. Ou um exercício para saber se a realidade da infraestrutura
rodoviária condiz com o que seria "ideal". E nem se fala da questão dos
critérios, raio de influência, tamanho da população é algo tão arbitrário,
e francamente bastante complicado. Algo que teria de sofrer tantos ajustes
regionais, centros metropolitanos, mesmo se aprovado acho que se
transformaria num inferno sem nenhum benefício além do meramente estético.

Não há dúvidas que existem várias rodovias que poderiam ser reclassificadas
para trunk, o que nos falta são critérios objetivos e simples. Na época do
top+5 eu fiz a proposta de que rodovias com cobrança de pedágio ou que são
consideradas privatizáveis poderiam ser consideradas trunk. É uma idéia,
não sei se é boa. Usar classificações oficiais para embasar as nossas é
outra sugestão. Por exemplo, uma via que poderia ser tanto secondary com
primary, às vezes o desempate poderia vir da classificação dos DEERs. E
sim, o DEER faz estudos de fluxo de trânsito, já fui parado para responder
a questionários (para onde vai? de onde vem? turismo ou trabalho?), sem
falar nos sensores permanentes ou temporários (parecendo uma mangueira
atravessada na pista). Quero crer que as classificações do DEER não são
simplesmente inferidas, pelo menos não me parecem.

então resumindo: sou contra a proposta, pois assim como no top+5, introduz
elementos ficionais no mapa com a justificativa de adensar artificialmente
a renderização

dito tudo isto, na verdade realmente tanto faz, ninguém usa o OSM para
quase nada. Depois de 15 anos a maioria das pessoas nem nunca ouviu falar,
tudo é só Google Maps. Além disto o mapa não é confiável, e da maneira como
opera, nunca vai ser.

sorry

Gerald
___
Talk-br mailing list

Re: [Talk-us] When is your doctor a clinic?

[Paul Johnson]

On Thu, Jan 23, 2020 at 3:30 PM Frederik Ramm  wrote:

> Hi,
>
> hunting down spam in OSM I often stumble over medical establishments in
> the US that have maximum-length description tags exhorting just how
> beatiful your smile will be after your visit to that dentist, etc.; I
> also find many objects that sound like a simple doctor's practice but
> are entered as "amenity=clinic", e.g.
>
> https://www.openstreetmap.org/node/4574659098


This happens a lot, i question the sources especially the georeferencing
(which probably means "looked up address on Google, copied lat and long
into OSM") to the point I delete on sight when I see edits similar to
Revision 1 of that node.  I might clean it up I've independently also
spotted the business and can do it better justice.  Just a quick look over
user 42TEAM's edit history suggests just another database spammer (usually
of the variety that just has a username of the same name as the business
that's being added).


> Especially in the US, when do you use amenity=doctors and when
> amenity=clinic - is this essentially self-determined by the business, or
> are there criteria that you as a mapper apply to select which to use?
>

There may be a disconnect with what the US (or that spammer) means.  Could
I get a clarification on the difference between "doctors" and "clinic" as
you understand it?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Type de highway pour voie de bus

[deuzeffe]

Bonsoir,

Merci à tout le monde pour les judicieuses remarques. J'aurais dû faire 
plus attention à ce genre de détail lorsque j'ai refait les lignes de 
bus de la commune. Le pire c'est que ce way était correctement taggué 
(coucou Capello13 ^^) avant qu'un néomappeur ne le modifie à sa sauce.


Je garde le access=no en l'état pour l'instant, n'ayant décelé aucun 
consensus ni tagging alternatif/complémentaire approprié. Mais j'ai 
peut-être loupé des trucs.


Domi, vélos autorisés sur cette voie là, je ne conseille pas. 
Pas.Du.Tout. Mais comme la commune fait sa mue cyclocompatible, ce n'est 
pas impossible. J'y jetterai un coup d’œil (à pieds :P) à l'occas.


--
deuzeffe

Le 21/01/2020 à 23:38, deuzeffe a écrit :

Hello,

Soit le way https://www.openstreetmap.org/way/346379468

C'est une voie de bus, tagguée :
access no
busway designated
highway road
name Voie de Bus - Ligne 10
oneway yes
psv yes

Osmose me signale que la classification de la voirie est à contrôler.

Je n'ai pas réussi à trouver dans le wiki quelle valeur doit avoir la 
clé highway.


Aide bienvenue, merci d'avance.


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

Re: [OSM-talk-fr] Aire de retournement

[Arnaud Champollion]

Le 23/01/2020 à 22:28, Vincent de Château-Thierry a écrit :
Si tu as un lien vers la zone ? C'est toujours plus simple pour se 
faire une idée.


Ah oui désolé j'ai oublié le lien


https://www.openstreetmap.org/changeset/79996713#map=19/44.08023/6.20833



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

[Talk-us] When is your doctor a clinic?

[Frederik Ramm]

Hi,

hunting down spam in OSM I often stumble over medical establishments in
the US that have maximum-length description tags exhorting just how
beatiful your smile will be after your visit to that dentist, etc.; I
also find many objects that sound like a simple doctor's practice but
are entered as "amenity=clinic", e.g.

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

Especially in the US, when do you use amenity=doctors and when
amenity=clinic - is this essentially self-determined by the business, or
are there criteria that you as a mapper apply to select which to use?

Bye
Frederik

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

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

Re: [OSM-talk-fr] Aire de retournement

[Vincent de Château-Thierry]

Bonsoir,

Le 23/01/2020 à 22:16, Arnaud Champollion a écrit :


Un contributeur avait tracé une aire de retournement de bus, d'une 
façon, je pense, pas efficace : un highway=track en forme de boucle, , 
avec name=aire de retournement de bus. Ou plus exactement il a ajouté ce 
nom à la boucle qui existait déjà.


J'ai supprimé le nom et qualifié le chemin en higway=turning_circle

Le wiki ne parle que de point pour cet élément, pas de way. JOSM m'a 
d'ailleurs donné un avertissement dans ce sens. Je pense que ce n'est 
donc toujours pas correct, mais comment faire du coup ? Supprimer la 
boucle (qui existe comme cela sur le terrain et qui est bien de type 
highway=track, même si les bus y font effectivement demi-tour) et 
ajouter un point ? Si l'on fait cela on perd les connexions avec les 
deux sentiers qui y sont connectés.


Si tu as un lien vers la zone ? C'est toujours plus simple pour se faire 
une idée.


merci
vincent

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

[OSM-talk-fr] Aire de retournement

[Arnaud Champollion]

Bonjour,

Un contributeur avait tracé une aire de retournement de bus, d'une 
façon, je pense, pas efficace : un highway=track en forme de boucle, , 
avec name=aire de retournement de bus. Ou plus exactement il a ajouté ce 
nom à la boucle qui existait déjà.


J'ai supprimé le nom et qualifié le chemin en higway=turning_circle

Le wiki ne parle que de point pour cet élément, pas de way. JOSM m'a 
d'ailleurs donné un avertissement dans ce sens. Je pense que ce n'est 
donc toujours pas correct, mais comment faire du coup ? Supprimer la 
boucle (qui existe comme cela sur le terrain et qui est bien de type 
highway=track, même si les bus y font effectivement demi-tour) et 
ajouter un point ? Si l'on fait cela on perd les connexions avec les 
deux sentiers qui y sont connectés.


Merci



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

Re: [OSM-talk-fr] Afficher un flux WMS de l'ONF dans JOSM

[Romain MEHUT]

Merci Thomas pour l'alternative.

Je viens d'envoyer un mél à l'ONF en expliquant le problème d'accès et le
souhait que ce soit corrigé.

Romain

Le jeu. 23 janv. 2020 à 21:33, Thomas Gratier 
a écrit :

> Salut Romain,
>
> Tu peux tricher avec l'URL suivante
> https://gist.githubusercontent.com/ThomasG77/a1af86730d6b0051d6781199364f2d42/raw/b8064ac7164333d80c31e8d0fe70e0a57bd52c8f/onf-capabilities.xml
> dans la partie "2. Entrer l'URL GetCapabilities" dans la section pour
> l'ajout de couches WMS dans JOSM
> C'est le même contenu que
> http://ws.carmencarto.fr/WMS/105/ONF_Forets?request=GetCapabilities
> mais j'ai nettoyé les tags XML et la déclaration liée au namespace inspire
> J'ai vérifié et cela permet de contourner le problème. Pas propre mais pas
> bloqué.
>
> Thomas Gratier
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[talk-ph] Follow-up on possible LGU-led mapping in Batangas

[Jherome Miguel]

It has been a month ago since I raised quality issues on map data added on
a possible local government-led mapping project in some municipalities in
Batangas near Taal Volcano. Last December, we have seen a spike in mapping
activity around the municipalities of Taal, Lemery, San Luis, San Nicolas,
and Santa Teresita in Batangas, and involves around 24+ users, many mapping
using accounts with their real names. I opened a papercut_fix ticket (
https://github.com/OSMPH/papercut_fix/issues/56), partially cleaned up the
questionable edits, sent private emails to some of the users involved, and
asked GOwin and maning on GitHub to contact directly any of the LGUs
involved, but there has been no response since then. Since the 2020
eruption of Taal Volcano, I have thought of a possibility the organized
mapping project has something to do with disaster preparedness (taking in
account the location of those municipalities around Taal Volcano), though
it also equally possible the editing is also for land use planning (for
Comprehensive Land Use Plan maps) and other purposes. Can someone follow up
attempts to contact the LGUs, especially through their disaster risk
reduction/management or planning/development offices (though this may not
be possible due to the lockdown on the volcano danger zone), or bring up
any previous attempts to contact them?


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

Re: [OSM-talk-fr] Afficher un flux WMS de l'ONF dans JOSM

[Thomas Gratier]

Salut Romain,

Tu peux tricher avec l'URL suivante
https://gist.githubusercontent.com/ThomasG77/a1af86730d6b0051d6781199364f2d42/raw/b8064ac7164333d80c31e8d0fe70e0a57bd52c8f/onf-capabilities.xml
dans la partie "2. Entrer l'URL GetCapabilities" dans la section pour
l'ajout de couches WMS dans JOSM
C'est le même contenu que
http://ws.carmencarto.fr/WMS/105/ONF_Forets?request=GetCapabilities
mais j'ai nettoyé les tags XML et la déclaration liée au namespace inspire
J'ai vérifié et cela permet de contourner le problème. Pas propre mais pas
bloqué.

Thomas Gratier


Le jeu. 23 janv. 2020 à 21:07, Romain MEHUT  a
écrit :

> Le jeu. 23 janv. 2020 à 12:05, marc marc  a
> écrit :
>
>>
>> solution pragmatique : écrire à l'ONF pour signaler que tel url ne va
>> plus après avoir vérifié sur leur site si une nouvelle n'est pas dispo.
>>
>
> Ok je me renseigne.
> Romain
> ___
> 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] adresse mail rejetée - gouvernance et transparence

[Philippe Verdy]

Ben  non... tant pis si vous ne comprenez pas ce qui se passe et si ça vous
dépasse. La cause est expliquée, documentée sur les sites qui parlent de ce
renforcement et des réglages nécessaires sur les gestionnaires de listes.
Il y a plein de référence et c'est pas dur à trouver sur le web. Google a
commencé à imposer ce renforcement, les autres ont suivi rapidement, et
notamment les gestionnaires de listes publicitaires qui ont très vite fait
de corriger le tir plutôt que se faire bloquer complètement. Nombre de
grands sites ont accompagné le mouvement, les utilisateurs ne s'en sont pas
plaint car ils demandaient une solution depuis longtemps pour authentifier
les expéditeurs et permettre de joindre alors les gestionnaires de
messagerie et de liste pour les mesures appropriées.
Ceux qui ne l'ont pas fait ce sont les spammeurs et usurpateurs d'identité
qui continuent à tenter d'envoyer leurs mails contrefaits à des
destinataires sur des fournisseurs de service qui n'ont pas encore cette
protection.
Ces authentifications des émetteurs (passant par l'authentification d'abord
de leur fournisseurs de service) sont des outils de plus pour contenir le
spam et les abus (notamment le phishing).

Les listes OSM sont les seules que j'utilise et qui n'ont encore rien fait
de leur côté pour se mettre dans les clous: tu peux montrer la moindre
signature DKIM, DMARC ou SPF des messages émis par les listes OSM, les
enregistrements "TXT" sur leur serveur de domaine DNS, les certificats de
sécurité, les clés de chiffrement des empreintes dans les messages émis par
les listes ? Il n'y a rien.

Le jeu. 23 janv. 2020 à 21:16, DH  a écrit :

> Le 23/01/2020 à 17:12, Philippe Verdy a écrit :
> > ...
> > C'est bien OSM qui a un problème sur l'installation et la mise à jour
> > de ce logiciel sur ses serveurs, mal configurés (y compris les infos
> > nécessaires mais toujours manquantes dans ses DNS) ou encore les
> > certificats de sécurité non installés (pour l'authentification des
> > serveurs ou pour que le logiciel MLM puisse signer à nouveau
> > *lui-même* les messages qu'il a lui-même modifiés, notamment le
> > contenu du corps ou la ligne de sujet car cela invalide les infos DKIM
> > et ARC/DMARC originales transmises telles quelles dans les entêtes des
> > messages relayés par la liste, qui deviennent invérifiables par les
> > tiers). Tant que ce ne sera pas fait, les serveurs OSM recevront des
> > "bounces" mais aussi tous ceux qui veulent répondre à un message
> > venant de la liste.
> >
> Philippe Verdy est sartrien ascendant huis-clos
>
> "L'enfer c'est les autres"
>
> Merci Marc pour ton boulot
>
>
> ___
> 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] adresse mail rejetée - gouvernance et transparence

[DH]

Le 23/01/2020 à 17:12, Philippe Verdy a écrit :

...
C'est bien OSM qui a un problème sur l'installation et la mise à jour 
de ce logiciel sur ses serveurs, mal configurés (y compris les infos 
nécessaires mais toujours manquantes dans ses DNS) ou encore les 
certificats de sécurité non installés (pour l'authentification des 
serveurs ou pour que le logiciel MLM puisse signer à nouveau 
*lui-même* les messages qu'il a lui-même modifiés, notamment le 
contenu du corps ou la ligne de sujet car cela invalide les infos DKIM 
et ARC/DMARC originales transmises telles quelles dans les entêtes des 
messages relayés par la liste, qui deviennent invérifiables par les 
tiers). Tant que ce ne sera pas fait, les serveurs OSM recevront des 
"bounces" mais aussi tous ceux qui veulent répondre à un message 
venant de la liste.



Philippe Verdy est sartrien ascendant huis-clos

"L'enfer c'est les autres"

Merci Marc pour ton boulot


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

Re: [OSM-talk-fr] Afficher un flux WMS de l'ONF dans JOSM

[Romain MEHUT]

Le jeu. 23 janv. 2020 à 12:05, marc marc  a
écrit :

>
> solution pragmatique : écrire à l'ONF pour signaler que tel url ne va
> plus après avoir vérifié sur leur site si une nouvelle n'est pas dispo.
>

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

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

[santamariense]

> A proposta se baseia na ligação entre duas cidades, mas quais duas cidades?
> Aí eu li o tal raio de influência, fazendo uma conta no caso de BH isto dá
> 1700 km. Então devo considerar que todas as cidades no raio de 1700 km com
> mais de 200 mil habitantes devem estar ligados por vias tipo trunk? Se der
> o resultado que eu tô pensando quase tudo viaria trunk, e perderíamos a
> hierarquia das vias.

Isso. Bem, é difcil imaginar o quão denso seria o mapa por ti
vislumbrado. Daí também entra a questão de analisar perante estudos a
possibilidade de flexibilizar a população por diferentes estados, como
já comentado. Em um primeiro momento, pode parecer que haverá 1 rota
diferente para cada ligação de BH com as cidades dentro do seu raio,
porém o que se procura é a rota ideal entre cada par de cidades,
ocorrendo, na prática, que a maioria das rotas irão se sobrepor em
diversos trechos. Por exemplo, estive analisando a ligação de São
Paulo com o Nordeste e o Sul, e é impressionante como Feira de Santana
e Curitiba, respectivamente, acabam por concentrar boa parte das rotas
de cidades de suas regiões até São Paulo.

> Sabe, isto me soa muito como um algorítmo, penso que seja factível fazer
> uma simulação. Tipo baixar o mapa, isolar as cidades por população e
> distância, e reclassificar as rodovias. E depois estudar como ficou a
> hierarquia viária. Pelo menos algo semelhante seria necessário para ajustar
> o tal raio de influência. Daria um bom projeto de TCC.

Bem colocado. É preciso aqui explanar que concomitantemente à análise
e discussão da proposta, vai se dar o resultado parcial em forma de
mapas das discussões das maiores classificações (trunk e primary),
antes de ser votado. Num primeiro momento cabe apresentar aqui a
proposta para se obter uma primeira impressão dos membros da
comunidade interessados no assunto.

> A premissa do esquema br2013 era que o formato da via seria proporcional à
sua importância. (...)

Sim, pelo esquema br2013 mede-se a importância de uma via pela sua
característica física. Exatamente isso que tem gerado vários casos da
chamada "salada de frutas" na classificação viaria, muitas vezes
ferindo o conceito de continuidade, quando o mapeador a leva ao pé da
letra (e é só dar uma passeada pelo mapa, ou mesmo acompanhar edições
Brasil afora, para se deparar com diversos casos). Na prática, a nova
proposta apresentada acaba levando em conta, no momento da seleção da
melhor rota entre duas cidades, aquelas vias que tiverem as melhores
características físicas, e isso acontece de forma natural. Já o
contrário nem sempre é verdade, pois uma melhor característica física
nem sempre representa uma maior importância da via, e isso ocorre
pelos mais variados motivos. É importante lembrar ainda que existem
inúmeras tags complementares que cumprem o papel de descrever
caracterstícas físicas e que podem ser, e são, utilizadas por
roteadores como parâmetros para o cálculo de rotas.

Quanto ao caso específico de MG, imagino que o fluxo de transito
poderia ajudar na seleção das chamadas rotas ideais. Por outro lado,
há problema de distribuitividade ao se analisar exclusivamente o fluxo
de trânsito. A título de exemplo, inúmeras ruas cetrais de uma capital
teriam mais fluxo que uma rodovia do interior do seu estado. Já,
quanto aos demais estados, creio que poucos teriam esses dados.

Eu poderia fazer uma análise de caso para MG de modo a aplicar esta
proposta, teria o link para esses dados?

--

> Uma dúvida que me veio foi quanto as regiões conurbadas. Aí no Rio Grande
> do Sul vocês consideraram elas como uma única cidade, inclusive, unindo a
> população dos municípios constituintes ou as ignoraram?

Consideramos. Inclusive interestadualmente ou internacionalmente, se
for o caso. Adicionei ao texto da proposta a questão de cidades
conurbadas.

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

Re: [Talk-it] Query pesanti

[Martin Koppenhoefer]

sent from a phone

> On 23. Jan 2020, at 18:37, Alfredo Gattai  wrote:
> 
> Sto usando overpass per tirare giu' le highway=track per regione ma per 
> alcune non ce la fa perche' eccede i 100mb
> A parte fare zone piu' piccole (come per provincia) che funziona quasi 
> ovunque ma non sempre perche' anche alcune province superano il limite e a 
> parte scaricarmi il Planet e lavorare in postgress che mi sembra eccessivo, 
> qualcuno ha qualche soluzione brillante e semplice?


io solitamente uso osmium-tool che legge direttamente i files pbf ed è molto 
veloce. Anche osmfilter è molto veloce, sempre in confronto a osmosis che è “lo 
standard” https://wiki.openstreetmap.org/wiki/Osmosis

tutt’e tre consentono di filtrare elementi secondo i loro tag (creare estratti)

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

Re: [OSM-talk-fr] adresse mail rejetée - gouvernance et transparence

[Philippe Verdy]

J'ai des bounces encore (chez moi) quand je réponds à quelqu'un à un
message de la liste s'il utilise une adresse @laposte.net ou certains
autres domaines privés (mais pas de bounce si j'écris directement ou met
cet utilisateur en CC en plus de la liste).

Les serveurs de liste OSM déconnent toujours, rien n'est réglé (depuis
presque un an que ces bounces se sont multipliés avec divers fournisseurs
de messagerie et que plein de monde ne reçoivent plus les messages de la
liste).

On m'a juste obligé ici à bidouiller mes paramètres Gmail pour les mettre
en config clairement non standard (autrement dit: ne pas répondre
directement avec l'adresse par laquelle j'ai reçu le message, mais forcer
une réponse avec mon adresse Gmail... qui n'est pas celle qu'un autre
utilisateur a utilisé pour m'écrire dans le même fil sur la même liste;
j'ai bidouillé ça spécifiquement pour les envois aux listes OSM, mais ça ne
marche nulle part ailleurs, notamment pas avec tout autre fournisseur de
listes qui rejette cette config foireuse: on est sensé répondre avec
l'adresse par laquelle on reçoit un message; pour les autres listes, cette
config ne peut pas marcher.

Ce problème concerne tous ceux qui ont plusieurs fournisseurs ou en ont
changé mais conservent leur adresse mail de contact, qu'ils ont redirigés
chez leur nouveau fournisseur ; ça a toujours marché depuis des années, ça
ne marche plus depuis près d'un an avec les listes de diffusion qui cassent
les empreintes numériques DKIM et DMARC, et dont les serveurs de listes ne
resignent pas eux-mêmes les messages qu'ils diffusent après les avoir
modifiés).

Changer de fournisseur et conserver ses adresses de contact et de
communication est un droit de chacun qu'OSM ne peut pas légitimement
interdire, ce n'est pas un abus. OSM n'a qu'à lire les RFC et se mettre à
jour avec les exigences actuelles, renforcées maintenant par les plus gros
fournisseurs de messagerie, au lieu de blâmer ces abonnés qui ne sont pas
du tout responsable de ces changements techniques pourtant indispensables à
la lutte contre le spam, les usurpations massives d'identité et la
falsification/le contournement des mails par d'autres que ces abonnés
réguliers.



Le jeu. 23 janv. 2020 à 19:34, Brice  a écrit :

> Le 23/01/2020 à 17:12, Philippe Verdy a écrit :
> > (...) Tant que ce ne sera pas fait, les serveurs OSM recevront des
> "bounces" mais aussi tous ceux qui veulent
> > répondre à un message venant de la liste.
>
> Utilisant une adresse @free.fr pour cette liste, j'étais régulièrement
> désabonné ; si cela continue (ce dont je doute),
> je le signalerai sur la liste
>
>
> > Le jeu. 23 janv. 2020 à 16:43, marc marc  > a écrit :
> > Philippe ayant résolu son soucis d'email wanadoo,
>
> Ouf
> et effectivement je reçois à nouveau ses longs courriels
>
> ___
> 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] Repère géodésique hors des frontières communales

[Philippe Verdy]

Je note aussi qu'à cet endroit la conflation des frontières communales
entre les sources cadastrales n'a pas eu lieu: une frontière indiquée par
une seule des communes a été utilisée arbitrairement, au lieu de prendre un
chemin moyen "estimé".

L'estimation moyenne est meilleure qu'un choix arbitraire selon une seule
commune, à défaut d'une conflation "réglementaire" dans une mise à jour
cadastrale tenant compte des ajustements et négos intercommunales pour
revoir leur triangulation géodésique et mettre d'accord les éventuels
occupants du terrain et le régime fiscal applicable (qui peuvent le
contester devant un tribunal administratif qui aura le dernier mot si les
communes ne s'accordent pas et le préfet local n'a pas pris un arrêté pour
leur imposer le règlement du litige frontalier).

Cette remarque vaut pour beaucoup de communes au moment où on a tracé leurs
frontières, certains n'ont pas pris la peine de charger les planches
cadastrales des communes voisines pour voir les désaccords (et la couche
cadastre du WMS fait les assemblages de carreaux de façon instable, en
prenant un peu au pif les carreaux d'une des communes au lieu de les
superposer, on ne voit pas la même chose selon le niveau de zoom, de plus
selon le nivbeau de zoom utilisé la précision géométrique varie avec plus
ou moins de points de référence! Il faut donc tracer au niveau de zoom le
plus élevé pour avoir plus de points, puis regarder et comparer les zones
de conflit en variant le zoom, ou bien charger séparément les deux planches
de chaque commune quand l'assemblage ne se fait pas bien).

Si on compare à d'autres pays voisins, la couche cadastrale française
aurait mieux fait de faire des superpositions pour montrer ces zones sans
conflation "officielle" et non choisir des carreaux de façon arbitraire
d'une commune à l'autre selon un point de référence unique dans le carreau.

Et ne pas oublier qu'en fin de compte c'est le terrain qui prime, même si
la triangulation sur les planches cadastrales montre des défaut: il y a des
éléments physiques communs aux deux planches, on peut les repérer sur
l'imagerie pour réaligner le tout.

C'est bien dommage que les communes à l'occasion de leur vectorisation
n'aient pas opté pour rétablir la précision de leurs planches selon les
repères géodésiques en place et les limites réelles de propriétés ou de
routes mesurées sur le terrain quand elles sont observables avec précision.

On peut comprendre qu'elles ne l'ont pas fait au temps des planches
dessinées à la main par les géomètres, puis numérisées en l'état en bitmap.
Revoir une triangulation et redessiner ces planches demandait trop de
travail, un travail plus facile à faire avec précision avec un format
numérique vectorisé, et que l'IGN peut leur faire de façon exacte sans tout
déformer et changer les proportions, angles et surfaces mesurées avec trop
d'écarts.

Aujourd'hui il y a des outils automatiques qui peuvent orthorectifier à
très bas coût leurs anciennes planches (même celles en bitmap si cela
conserve la lisibilité des libellés et symboles quand la numérisation en
bitmap est faite avec une résolution suffisante), mais ils ne peuvent pas
mettre d'accord des communes qui ont mis dans leurs planches des éléments
contestés par la commune voisine, ni les occupants qui depuis longtemps se
croyait dans une commune (ce genre de conflit devrait être limité
maintenant avec les récentes modifications de la fiscalité locale, mais de
telles erreurs historiques devraient être signalées et enregistrées dans
des annexes aux documents officiels de propriété ou consignés dans des
arrêtés municipaux ou préfectoraux) et les remettre aux normes de
triangulation actuelles et plus précises, avec un référentiel géodésique
commun (bien qu'on ait encore des écarts, dus au changement de référentiel
réglementaire, aux limites départementales des zones du vieux RGF sur le
continent métropolitain, où l'IGN aurait du produire un effort pour les
régler).



Le jeu. 23 janv. 2020 à 19:19, Philippe Verdy  a écrit :

> Bref ne surtout pas changer la frontière communale (vérifier le cadastre
> pour détecter un éventuel déplacement indésiarable de frontière) et ignorer
> le signalement
>
> Eventuellement, ajouter une note=* au noeud repère expliquant que ce n'est
> pas une erreur, mais il vaut mieux créer une relation de site pour grouper
> ce noeud avec les autres dans la "bonne" commune, comme ça l'outil de
> vérification pourra vérifier lui-même que "l'anomalie" est normale tant que
> les autres repères du site sont dans la "bonne" commune... à moins qu'ils
> soient tous "hors commune" pour les "grands" sites de triangulation ou
> d'alignement, mais que leur "centre" géographique au moins est bien sur la
> commune indiquée par leur code)
>
>
> Le jeu. 23 janv. 2020 à 18:51, leni  a écrit :
>
>>
>> Le 23/01/2020 à 17:06, Frédéric Rodrigo a écrit :
>> > Le 23/01/2020 à 16:59, marc marc a écrit :
>> >> Le 23.01.20 à 16:44, leni a écrit :
>> >>> Faudrait-il mieux déplacer 

Re: [OSM-talk-fr] adresse mail rejetée - gouvernance et transparence

[Brice]

Le 23/01/2020 à 17:12, Philippe Verdy a écrit :
(...) Tant que ce ne sera pas fait, les serveurs OSM recevront des "bounces" mais aussi tous ceux qui veulent 
répondre à un message venant de la liste.


Utilisant une adresse @free.fr pour cette liste, j'étais régulièrement désabonné ; si cela continue (ce dont je doute), 
je le signalerai sur la liste




Le jeu. 23 janv. 2020 à 16:43, marc marc mailto:marc_marc_...@hotmail.com>> a écrit :
Philippe ayant résolu son soucis d'email wanadoo,


Ouf
et effectivement je reçois à nouveau ses longs courriels

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

Re: [OSM-talk-fr] Repère géodésique hors des frontières communales

[Philippe Verdy]

Bref ne surtout pas changer la frontière communale (vérifier le cadastre
pour détecter un éventuel déplacement indésiarable de frontière) et ignorer
le signalement

Eventuellement, ajouter une note=* au noeud repère expliquant que ce n'est
pas une erreur, mais il vaut mieux créer une relation de site pour grouper
ce noeud avec les autres dans la "bonne" commune, comme ça l'outil de
vérification pourra vérifier lui-même que "l'anomalie" est normale tant que
les autres repères du site sont dans la "bonne" commune... à moins qu'ils
soient tous "hors commune" pour les "grands" sites de triangulation ou
d'alignement, mais que leur "centre" géographique au moins est bien sur la
commune indiquée par leur code)


Le jeu. 23 janv. 2020 à 18:51, leni  a écrit :

>
> Le 23/01/2020 à 17:06, Frédéric Rodrigo a écrit :
> > Le 23/01/2020 à 16:59, marc marc a écrit :
> >> Le 23.01.20 à 16:44, leni a écrit :
> >>> Faudrait-il mieux déplacer la frontière dans osm ?
> >> elle a été déplacée par import_fr en 2013 sans aucune source renseignée,
> >> sans lien ou descriptif permettant de rafraichir la mémoire sur
> >> l'opération. la version précédente était proche du cadastre
> >>
> >> si tu la déplaces pour la mettre à l'endroit du cadastre,
> >> le repère reste du mauvais côté... du coup pourquoi pas...
> >> mais cela ne résoud pas le soucis.
> >> si l'ign a elle aussi le soucis, alors faut leur écrire..
> Merci Marc
> >
> >
> > Des repères peuvent être du mauvais coté c'est normal.
> >
> > La commune est associé au site géodésique. La site à plusieurs
> > repères, certain peuvent être de l'autre coté.
> Merci Frédéric
> >
> >
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [AE] suppression ref:FR:SIREN de l'administration mis erronément mis sur place=*

[Philippe Verdy]

Les SIREN désignent les communes en tant qu'entité juridique, peu importe
leurs établissements (comme les mairies annexes dans certains de leurs
quartiers ou villages ou autres services, chaque établissement étant
numéroté par le SIRET, contenant le SIREN).

Il y a aussi des SIREN pour les intercommunalités, les départements et
régions (séparément pour les conseils départementaux ou régionaux, et les
préfectures ou sous-préfectures et autres administrations de l'Etat), et
tous les autres syndicats (SIVU, SICOM, gestionnaires de parcs ou agences
de bassins). Le SIREN est le code le plus aisé pour les intercommunalités.
Il est également plus fiable que le code commune (qui ne désigne pas
toujours la même entité juridique après les fusions ou scission de communes
et changement de statut) qui n'a de valeur que comme code géographique (et
est conservé même après les fusions/scissions de communes car il sert de
base à la création des SIREN et l'enregistrement officiels des individus à
l'état-civil, même s'il a fermé dans une commune, et des organisations à
l'Insee (SIREN et SIRET).

Le SIREN est valide à vie pour toute organisation jusqu'à sa dissolution et
la fin des recours juridique, et il n'est pas réutilisé contrairement aux
codes INSEE à 5 chiffres des communes, qui changent de couverture
territoriale: un code INSEE n'a pas de valeur claire sans l'associer à un
millésime (on doit donc les garder, et l'Insee justement le fait avec un
fichier annexe des "anciens" codes et des listes de changement: les anciens
codes ne sont juste plus utilisés mais remplacés pour les nouveaux usages
mais restent valide sur les usages existants). Ces codes Insee à 5 chiffres
sont donc une simplification.

Et on a des cas particuliers avec les communes déléguées qui ont changé de
département à l'occasion d'une fusion mais gardé le code Insee de leur
ancien département... alors que le code SIREN, lui a pu être terminé après
une fusion simple et en cas de défusion il y aura un nouveau code SIREN
tenant compte de leur code nouveau code Insee 5 chiffres millésimé qui
pourra leur être attribué dans le nouveau département... si elles y restent
et ne reviennent pas à l'ancien (auquel cas elles reprendront leur ancien
code Insee géographique). Le code Insee à 5 chiffres d'une commune
n'indique pas toujours leur département actuel, pas plus que les codes
SIREN, mais le département au moment de l'attribution initiale de ce code
commune.



Le jeu. 23 janv. 2020 à 18:41, marc marc  a
écrit :

> Bonjour,
>
> Après la suppression des ref:INSEE  fin novembre,
> il semle y avoir la même confusion avec ref:FR:SIREN
> de nombreux place (par exemple un village) sont renseigné
> avec le ref:FR:SIREN de la commune alors que c'est la ref
> de l'administration de la commune.
>
> voyez-vous un cas de figure la combinaison ref:FR:SIREN + place
> est correcte ? sinon je propose une édition mécanique pour les supprimer
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Repère géodésique hors des frontières communales

[leni]

Le 23/01/2020 à 17:06, Frédéric Rodrigo a écrit :

Le 23/01/2020 à 16:59, marc marc a écrit :

Le 23.01.20 à 16:44, leni a écrit :

Faudrait-il mieux déplacer la frontière dans osm ?

elle a été déplacée par import_fr en 2013 sans aucune source renseignée,
sans lien ou descriptif permettant de rafraichir la mémoire sur
l'opération. la version précédente était proche du cadastre

si tu la déplaces pour la mettre à l'endroit du cadastre,
le repère reste du mauvais côté... du coup pourquoi pas...
mais cela ne résoud pas le soucis.
si l'ign a elle aussi le soucis, alors faut leur écrire..

Merci Marc



Des repères peuvent être du mauvais coté c'est normal.

La commune est associé au site géodésique. La site à plusieurs 
repères, certain peuvent être de l'autre coté.

Merci Frédéric




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


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

Re: [OSM-talk-fr] adresse mail rejetée - gouvernance et transparence

[Philippe Verdy]

Note: la modération du compte gmail est toujours en vigueur, j'ai toujours
un mail automatique du serveur OSM en réponse, prévenant que mon message
est en attente sur une liste "modérée" où je suis pourtant inscrit et dont
je reçois les messages puisque j'y suis inscrit (disons au moins certains,
pas tous si j'en crois les archives). Je n'ai supprimé aucune inscription...

Bref ça ne marche pas, et la liste talk-fr diffuse toujours aléatoirement.
Je n'ai aucune indication si le message est livré ou pas.

Et visiblement bien d'autres ont aussi ce problème, je suis loin d'être le
seul (même ceux sans modération ou les listes en accès libre dépourvues de
modérateurs).

Il faut vraiment insister auprès des admins d'OSM pour qu'ils corrigent
leur serveur de liste défaillant au lieu de bloquer ou désinscrire
silencieusement inutilement des gens qui ne sont pas responsables de ces
défauts des serveurs de listes OSM, pas compatibles avec les exigences
renforcées de plus en plus nombreux des fournisseurs de messagerie (qui
vérifient les empreintes numériques des messages et sinon les rejette ou
renvoient des "bounces" techniquement corrects aux serveurs OSM pour de
bonnes raisons). Cela ne sert à rien de nous insulter entre nous pour ces
bounces dont nous ne sommes pas responsables ni nos fournisseurs de service
qui eux font leur travail correctement, et à rien non plus nous obliger à
changer de fournisseur.


Le jeu. 23 janv. 2020 à 16:43, marc marc  a
écrit :

> Le 17.01.20 à 11:45, Vincent de Château-Thierry a écrit :
> >>> Je suis partant pour faire partie de ce "pool".
> >> je t'ajoute volontiers
>
> j'ai donc ajouté Vincent en modérateur.
>
> Philippe ayant résolu son soucis d'email wanadoo,
> j'ai levé la modération de son compte
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-it] Query pesanti

[Francesco Ansanelli]

Il gio 23 gen 2020, 18:37 Alfredo Gattai  ha
scritto:

> Ciao lista,
>
> ho cercato un po' in rete prima di chiedere ma alla fine probabilmente
> qualcuno di voi ha la soluzione a portata di mano.
> Sto usando overpass per tirare giu' le highway=track per regione ma per
> alcune non ce la fa perche' eccede i 100mb
> A parte fare zone piu' piccole (come per provincia) che funziona quasi
> ovunque ma non sempre perche' anche alcune province superano il limite e a
> parte scaricarmi il Planet e lavorare in postgress che mi sembra eccessivo,
> qualcuno ha qualche soluzione brillante e semplice? Anche Josm non ce la fa
> con la memoria
>

Puoi scaricare il Pbf della tua regione, passare in formato Osm con
osmconvert e filtrare i dati con osmfilter.

Sul wiki trovi qualche info in più su questi potenti tool.

Francesco

>
> Alfredo
> ___
> 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

[OSM-talk-fr] [AE] suppression ref:FR:SIREN de l'administration mis erronément mis sur place=*

[marc marc]

Bonjour,

Après la suppression des ref:INSEE  fin novembre,
il semle y avoir la même confusion avec ref:FR:SIREN
de nombreux place (par exemple un village) sont renseigné
avec le ref:FR:SIREN de la commune alors que c'est la ref
de l'administration de la commune.

voyez-vous un cas de figure la combinaison ref:FR:SIREN + place
est correcte ? sinon je propose une édition mécanique pour les supprimer

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

[Talk-it] Query pesanti

[Alfredo Gattai]

Ciao lista,

ho cercato un po' in rete prima di chiedere ma alla fine probabilmente
qualcuno di voi ha la soluzione a portata di mano.
Sto usando overpass per tirare giu' le highway=track per regione ma per
alcune non ce la fa perche' eccede i 100mb
A parte fare zone piu' piccole (come per provincia) che funziona quasi
ovunque ma non sempre perche' anche alcune province superano il limite e a
parte scaricarmi il Planet e lavorare in postgress che mi sembra eccessivo,
qualcuno ha qualche soluzione brillante e semplice? Anche Josm non ce la fa
con la memoria

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

Re: [OSM-talk-fr] Afficher un flux WMS de l'ONF dans JOSM

[Philippe Verdy]

Un WMS c'est au départ un seul fichier XML descriptif qui contient toutes
les références aux serveurs de tuiles et décrire leur organisation. Ce
fichier est généralement (mais pas obligatoirement) hébergé par le même
fournisseur que le fournisseur des tuiles.

On peut en avoir une copie locale modifiée/"patchée" au lieu de le
télécharger depuis le serveur WMS (qui se charge alors de la diffusion ou
de ses mises à jour, ton logiciel le charge et le garde en cache).

Ensuite le logiciel de rendu utilisera les infos de ce fichier pour accéder
correctement aux tuiles avec les bonnes URL et les bons paramètres
d'affichage, et les bonnes métadonnées (dont celles de licence et droit
d'auteur, ou encore des infos sur les référentiels et projections utilisés,
ainsi que les infos sur le format des tuiles) pour que leur interprétation
et rendu soit corrects.

Le format XML n'est pas compliqué mais il impose une déclaration dans
l'entête des préfixes de "namespaces" pour les lier à une URI. Les préfixes
en XML sinon ne signifient rien, même pour XHTML ou SVG (et même le mot-clé
symbolique peut être librement redéfini, c'est la liaison du préfixe à
l'URI qui indique qu'il s'agit bien du même schéma et donc indique la
sémantique du fichier). Seuls quelques préfixes sont prédéfinis (il y en a
très peu, ce sont en fait des "pseudo-espaces" faisant partie intégrante de
la norme XML et qu'un fichier XML ne peut pas remplacer librement, car ces
espaces de noms sont réservés, notamment le préfixe "xml:").

Ainsi une balise XML nommée  ou  peut signifier
la même chose, si "toto" et "titi" sont liés à la même URI par la
déclaration de ces espaces dans l'entête XML. C'est ce qui fait la
versatilité du format XML, qui donne la possibilité d'encapsuler des
fichiers contenant des balises et attributs homonymes sans les modifier,
alors qu'ils ont des sémantiques différentes selon la déclaration des
préfixes dans la balise de leur élément conteneur. Les espaces de noms
peuvent aussi être utilisés seulement pour les noms des attributs
individuels et se mélanger à d'autres espaces de noms pour les balises
elles-mêmes. XML permet aussi de déclarer quel est l'espace de noms par
défaut, pour les balises et attributs n'ayant aucun préfixe, autrement à
dit à quelle URI ces balises et attributs sont liés. L'URI n'est qu'un
identifiant supposé unique pour un schéma de codage donné, elle n'a pas
besoin d'être téléchargée, même si souvent on peut la télécharger pour y
trouver un fichier de schéma XML (mais ce schéma peut être implicite et
intégré parmi les URI reconnues par l'utilisateur du fichier). C'est bien
l'URI qui indique la sémantique du fichier, pas seumement les noms de
balises ni les préfixes utilisés.

Si on ne lie pas les préfixes aux espaces de noms par une URI, le fichier
XML n'est pas conforme, l'interprétation est hasardeuse, l'encapsulation de
données depuis plusieurs sources utilisant des schémas différents est
impossible sans ambiguité. C'est vrai aussi pour XHTML.

Mais pas nécessaire pour HTML. même en HTML5 (dont l'espace de noms par
défaut est prédéfini par la déclaration de l'entête  où il
n'est même pas nécessaire de préciser l'URI)



HTML5 peut être utilisé *aussi* en syntaxe XHTML mais dans ce cas il devra
comporter cette déclaration d'espace de son propre espace de noms pour être
conforme XML, et les règles syntaxiques de fermeture explicite et
obligatoire de toutes les  balise d'XML s'imposent, alors qu'elles sont
partiellement levées en HTML5 comme c'était aussi déjà le cas pour HTML4 et
SGML, qui n'imposent pas cela et utilisent un espace de noms unique pour
toutes leurs balises et attributs et sinon imposent quelques espaces de
noms prédéfinis pour des cas spéciaux, le reste nécessite une déclaration
dans le "DTD" de la pseudo-balise   en tête du fichier; mais les
DTD ont été bannies en HTML5 à cause de risques de sécurité et surtout à
cause des déclarations "d'entités nommées" pouvant remplacer n'importe quoi
dans la syntaxe de ce qui suit avec un mécanisme proche de ceux des
"macros" dans les préprocesseurs; HTML5 à la place prédéclare un certain
nombre d'entités nommées, et bannit désormais toute déclaration
supplémentaire ou implicite, contrairement à ce que "tolérait" HTML4 dont
les entités nommées étaient ajoutées à loisir par différents navigateurs ou
éditeurs de documents : en HTML5 les balises nommées prédéfinies, qu'on ne
doit pas déclarer dans un DTD comme on pouvait le faire en HTML4 mais qui
compliquait les parseurs et posaient de sérieux problèmes de sécurité et
performance, ne concerne que des caractères isolés, pas n'importe quel
élément de syntaxe comme en SGML; tous les autres caractères doivent être
encodés directement, en UTF-8 par défaut s'il n'y a pas un autre "charset"
déclaré, et HTML5 ne reconnait que certains charsets et les traite de façon
différente d'HTML4 qui était plus permissif, notamment pour ce qui concerne
les charsets 8 bits ASCII, ISO 8859-1 et Windows-1252, tous mappés 

Re: [OSM-talk-fr] adresse mail rejetée - gouvernance et transparence

[Philippe Verdy]

Le compte Wanadoo est pourtant toujours abonné (et je reçois encore des
mails par là, y compris de la lsite). Mais j'ai modifié les règles Gmail
avec une règle spéciale pour les réponses à cause du bogue d'installation
des serveurs MLM d'OSM qui ne sont toujours pas conformes pour DKIM et
ARC/DMARC et pas complètement corrects non plus pour SPF.

Jamais je n'ai "usurpé" un compte par un quelconque "bidouillage". On m'a
plutôt imposé ce bidouillage des paramètres Gmail (pourtant les listes OSM
étaient inscrits en "liste blanche" à la fois chez Orange et Gmail et
depuis très longtemps).

La seule chose qui a changé c'est le renforcement (notamment depuis mars
2019) et la vérification (par la plupart des fournisseurs de comptes mail)
des règles de reroutage quand les messages contiennent des infos
DKIM/DMARC/SPF. La seule "usurpation" vient des serveurs OSM qui modifient
le contenu des messages et invalident les empreintes numériques indiquées
dans les messages originaux des expéditeurs à la liste.
"Wanadoo" n'est pas incorrect, pas plus qu'Orange.fr ou LaPoste.fr. Pas
plus que le logiciel utilisé par les serveurs. Cela a impacté pas mal de
fournisseurs de listes de diffusion, cela a été documenté la plupart ont
fait les changement nécessaires à leurs listes (y compris les réseaux
d'annonceurs publicitaires, et les gros FAI, dont Google et Orange aussi),
mais pas OSM !

C'est bien OSM qui a un problème sur l'installation et la mise à jour de ce
logiciel sur ses serveurs, mal configurés (y compris les infos nécessaires
mais toujours manquantes dans ses DNS) ou encore les certificats de
sécurité non installés (pour l'authentification des serveurs ou pour que le
logiciel MLM puisse signer à nouveau *lui-même* les messages qu'il a
lui-même modifiés, notamment le contenu du corps ou la ligne de sujet car
cela invalide les infos DKIM et ARC/DMARC originales transmises telles
quelles dans les entêtes des messages relayés par la liste, qui deviennent
invérifiables par les tiers). Tant que ce ne sera pas fait, les serveurs
OSM recevront des "bounces" mais aussi tous ceux qui veulent répondre à un
message venant de la liste.



Le jeu. 23 janv. 2020 à 16:43, marc marc  a
écrit :

> Le 17.01.20 à 11:45, Vincent de Château-Thierry a écrit :
> >>> Je suis partant pour faire partie de ce "pool".
> >> je t'ajoute volontiers
>
> j'ai donc ajouté Vincent en modérateur.
>
> Philippe ayant résolu son soucis d'email wanadoo,
> j'ai levé la modération de son compte
> ___
> 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] Repère géodésique hors des frontières communales

[Frédéric Rodrigo]

Le 23/01/2020 à 16:59, marc marc a écrit :

Le 23.01.20 à 16:44, leni a écrit :

Faudrait-il mieux déplacer la frontière dans osm ?

elle a été déplacée par import_fr en 2013 sans aucune source renseignée,
sans lien ou descriptif permettant de rafraichir la mémoire sur
l'opération. la version précédente était proche du cadastre

si tu la déplaces pour la mettre à l'endroit du cadastre,
le repère reste du mauvais côté... du coup pourquoi pas...
mais cela ne résoud pas le soucis.
si l'ign a elle aussi le soucis, alors faut leur écrire..



Des repères peuvent être du mauvais coté c'est normal.

La commune est associé au site géodésique. La site à plusieurs repères, 
certain peuvent être de l'autre coté.




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

Re: [OSM-talk-fr] Repère géodésique hors des frontières communales

[marc marc]

Le 23.01.20 à 16:44, leni a écrit :
> Faudrait-il mieux déplacer la frontière dans osm ?

elle a été déplacée par import_fr en 2013 sans aucune source renseignée,
sans lien ou descriptif permettant de rafraichir la mémoire sur
l'opération. la version précédente était proche du cadastre

si tu la déplaces pour la mettre à l'endroit du cadastre,
le repère reste du mauvais côté... du coup pourquoi pas...
mais cela ne résoud pas le soucis.
si l'ign a elle aussi le soucis, alors faut leur écrire..
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Type de highway pour voie de bus

[Philippe Verdy]

En France les piétons peuvent aller quasiment partout, sauf signalisation
ou équipement spécial (sidewalk en est un) mais ils peuvent traverser
partout et sont prioritaires. Les interdictions piétons sont matérialisées
par les a signalisation (y compris les panneaux autoroute et voies express,
et les barrières de séparation de chaussées). En zone urbaine ils ne sont
même pas obligés de traverser seulement aux passages protégés (mais ils le
font avec un partage des risques et les conducteurs sont malgré tout
responsables des accidents car, eux seulement, sont couverts par des
assurances obligatoires.

La question portait une un way mais toi tu ajoutes sidewalk=*, donc une
signalisation ou un équipement sur le way.
Evidemment, si le way porte access=no mais qu'il y a un sidewalk=*, les
piétons peuvent emprunter leurs "trottoirs" à moins qu'il y ait "foot=no"
en plus (donc ce ne sont plus réellement des trottoirs et le sidewalk=* est
en trop et les risques d'ambiguité sont élevés). Autant découper alors la
rue sur la section interdite à tous et taguer les trottoirs où ils existent
réellement.

Là tu cherches la complication si tu ne veux pas découper la rue.

Je n'ai pas pris l'exemple d'une rue barrée à tous pour travaux au hasard,
c'est un cas fréquent, mais temporaire le plus souvent (parfois mobile d'un
jour à l'autre, sauf très gros travaux comme la construction d'un tunnel ou
d'un ouvrage accessoire à un pont) et quand ça arrive les chantiers
prévoient quand même un passage pour les riverains (quitte à installer des
passerelles, ou prendre des mesures avec le voisinage pour leur demander
d'autoriser un droit de passage sur leur terrain privé, et éventuellement
ouvrir une clôture, puis en fin de travaux réparer ou reconstruire les
clôtures, remettre en état une bande de gazon piétinée, indemniser le
propriétaire pour les parterres de fleurs, ou compenser un agriculteur pour
sa bande de culture temporairement utilisée pour ce passage ou celui des
engins de chantier).

Si ces travaux sont durables (très gros chantiers durant des mois avec des
modifications importantes de l'infrastructure et du voisinage et toutes
sortes de restrictions variables autour, y compris une délimitation
changeante de la zone signalée de "chantier interdit au public" ou d'une
zone de danger spéciale comme les risques d'effondrement naturels ou
d'immeubles en péril ou en démolition), il peut cependant être utile de le
marquer dans OSM et prévoir un chemin "indicatif" prévoyant un passage
piétons ou riverains seulement (mais la zone de travaux devrait être taguée
pour prévenir que la situation est instable et que les parcours ne sont pas
exacts à tout moment; et d'ajouter un fixme=* qu'on pourra repérer dans un
outil de veille qualité pour vérifier la situation plus tard quand les
travaux seront terminés et la situation stabilisée, et pour améliorer la
précision ensuite quand on aura des images de qualité suffisante sur la
zone et pas juste une estimation à main levée de ce que cela "devrait"
être).


Le jeu. 23 janv. 2020 à 16:22, marc marc  a
écrit :

> Le 23.01.20 à 15:49, Philippe Verdy a écrit :
> > C'est toujours la totalité du "way"
>
> > L'attribut "foot=yes" est implicite pour quasiment tous les "highway=*"
>
> Fait donc l'expérience de TA théorie :
> prend donc n'importe quel highway=residential avec sidewalk=*,
> vas-y sur place et met toi en plein milieu de la bande voiture,
> restes-y une petite heure à faire des aller-retour sur cette bande
> voiture pour que les forces de l'ordre ai le temps de réagir,
> on verra si en France, un piéton circule sur "toujours la totalité
> du way" comme tu dis ou si ta vision est décalage avec la réalité.
> ___
> 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] Repère géodésique hors des frontières communales

[leni]

Le 21/01/2020 à 19:29, Jacques Lavignotte a écrit :


si tu passes par là : vérifier que le clocher est tjs là, 


OUI Il est toujours là. Vu ce soir même.


- mettre un survey:date=2020-01 sur les repères
- flager l'anomalie en faux positif sur osmose


C'est fait.

Merci, J.


Bonjour.

J'ai plusieurs fois ce signalement (sur la copie écran à droite) suite à 
la modification de la population due à la parution de l'INSEE 2020, 
mais, par contre, les repère sont toujours consultables sur le site de 
l'IGN, mais osmose signale leur présence à l'extérieur des frontières 
communale.


Dans JOSM ((sur la copie écran à gauche) il est à environ 14 m de la 
frontière (imagerie cadastre) et à 25 m de la frontière dans osm.


Mais si regarde sur la carte de l'IGN Ils semblent aussi du mauvais côté 
de la frontière municipale ; ce qui est étonnant, car sur la fiche, il 
est bien inscrit commune Arlos

Faudrait-il mieux déplacer la frontière dans osm ?
J'hésite, les boundary ... jamais touché, je modifie la population et je 
reçois 5 signalements, je vais faire une pose.



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

Re: [OSM-talk-fr] adresse mail rejetée - gouvernance et transparence

[marc marc]

Le 17.01.20 à 11:45, Vincent de Château-Thierry a écrit :
>>> Je suis partant pour faire partie de ce "pool".
>> je t'ajoute volontiers

j'ai donc ajouté Vincent en modérateur.

Philippe ayant résolu son soucis d'email wanadoo,
j'ai levé la modération de son compte
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Type de highway pour voie de bus

[marc marc]

Le 23.01.20 à 15:49, Philippe Verdy a écrit :
> C'est toujours la totalité du "way"

> L'attribut "foot=yes" est implicite pour quasiment tous les "highway=*"

Fait donc l'expérience de TA théorie :
prend donc n'importe quel highway=residential avec sidewalk=*,
vas-y sur place et met toi en plein milieu de la bande voiture,
restes-y une petite heure à faire des aller-retour sur cette bande
voiture pour que les forces de l'ordre ai le temps de réagir,
on verra si en France, un piéton circule sur "toujours la totalité
du way" comme tu dis ou si ta vision est décalage avec la réalité.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Type de highway pour voie de bus

[Philippe Verdy]

Le jeu. 23 janv. 2020 à 12:17, marc marc  a
écrit :

> je parle du cas simple, non tiré par les cheveux.
> exemple https://www.openstreetmap.org/way/16405595
> foot=yes ne veux donc pas dire "la rue entière est accessible
> aux piétons" (sinon ce serrait un living_street ou qlq chose du genre).
>

Ben non justement (mais retire le mot "rueentière", OSM ne l'utilise pas,
on tague chemin par chemin et au besoin on découpe la rue).
foot=yes veut dire que tout le "way" est accessible aux piétons (variante
possible: way:right=yes si c'est sur un seul côté, dans le sens du tracé)


> foot=yes (explicite sur l'objet ou implicite en fct de la valeur du
> highway=*) dit qu'un piéton a le droit de circuler sur au moins une
> partie de la rue, les autres tags et la loi sont là pour dire si c'est
> tout ou une partie.
>

Là encore "tout ou partie" est en trop ! C'est toujours la totalité du
"way" (qui n'est pas nécessairement la "rue" entière).

L'attribut "foot=yes" est implicite pour quasiment tous les "highway=*"
(sauf highway=motorway en France où par défaut "foot=no"),

Sauf si on a un "access=no" (dans ce cas le way est interdit à tous,
véhicules, cyclistes, piétons, chevaux, rollers...)
Et on doit ajouter au moins un "*=yes" pour un type de véhicule/piéton

Sinon avec "access=no" sans autre "*=yes", ce n'est plus du tout un
"highway=*", juste un décor ou un site barré à cause de danger imminent ou
permanent: chantier, risque d'effondrement, zone minée/contaminée,
inondation fréquente, comme les canaux de purge des barrages
hydroélectrique ou de débordement des eaux de ruissellement de surface vers
des bassins d'orage (en cas de précipitation violente pour ne pas saturer
le réseau des égouts, ne pas endommager les installations de traitement des
eaux usées ménagères, limiter la pollution des rivières et prévenir ou
contenir l'inondation du reste du territoire) qui ne devraient même pas
être des "highway=*" (mais des '"waterway=*' plus éventuellement
'intermittent=yes",  mais là cela reste encore "access=no" par défaut pour
tous sauf pour les embarcations dans le cas "waterway=river/canal" mais pas
"stream/ditch": pour que ce canal rarement inondé admette régulièrement des
piétons ou véhicules il faut un gué marqué pour l'autoriser, comme
"ford=yes" sur un noeud, ou un "foot=yes" sur le way pour le segment de
cours d'eau utilisable à pied, intermittent ou pas).

Les canaux de lâcher des eaux de barrages (ou eaux de refroidissement des
centrales ou d'autres installations industrielles) ont pu parfois être
autorisés dans le passé avec l'usage de sirènes et feux d'avertissement,
mais il y a eu des accidents grave (même pour des baigneurs ou pratiquants
de sports nautiques, ou encore des campeurs et promeneurs sur les rives
inondables à tout moment) et je ne pense pas que ce soit encore autorisé en
France, même si les avertisseurs et panneaux de danger sont encore là et
même imposés aux exploitants
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-cz] WeeklyOSM CZ 494

[Marián Kyral]

-- Původní e-mail --
Od: Michal Fabík 
Komu: talk-cz@openstreetmap.org
Datum: 23. 1. 2020 13:58:51
Předmět: Re: [talk-cz] WeeklyOSM CZ 494
"On 1/23/20 1:45 PM, majkaz wrote:
> Namapovat tam nějaký vjezd jako residential jen proto, aby to přestalo
vyskakovat, se mi opravdu nechce.
>
>
Nebylo vhodnější highway=service + service=driveway, případně + access=
private (pokud je to z nějakého zdroje poznat)? To by asi vyřešilo problém s
false positives a navíc by to i odpovídalo skutečnosti.
"



Přesně tak. Nemapuji úplně všechny příjezdovky, ale pokud je ta cesta delší,
vede mezi poli nebo k více domům, tak je vhodné to zmapovat, aby bylo vidět
kudu tudy, kdyby tam chtěl někdo na návštěvu.




Nicméně je potřeba si ověřit, že to je opravdu příjezdová cesta a není to
například nějaký vyšlapaný chodníček.




Marián




"
--
Michal Fabík


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

Re: [Talk-se] Malmö och Örnsköldsvik saknas på vektorkarta

[pangoSE]

Hej.

Jag tycker att vi skal tolka tätortsområden som administrativa gränser 
för våra städer. Det är den bästa källa vi har, alternativet är att göra 
dem subjektivt själva som jag ser det.


Det är korrekt att dem uppdateras av SCB vart 5-e år. SCB har dock bara 
släppt dem som CC-BY varför jag föreslår att vi tar dem från LM. Jag ser 
inte det som ett problem att gränserna uppdateras när byn byggs ut eller 
stadsdelar rivs.


Dem används inte bara av rendere också av tex 
https://maposmatic.osm-baustelle.de 
 där det inte i dagsläget går att 
göra en karta över tex Malmö av skälet att staden inte är definerad som 
område.


Se skillnaden när du söker här på härnösand vs malmö: 
https://maposmatic.osm-baustelle.de/new/#


Vi saknar altså vettiga admin boundaries på våra städer. Alla svenska 
städer jag testade utom Härnösand och Umeå kunde inte lätt hittas.


När man skapar bykartor då är det vettigt att bara ta med gatunamn inom 
byområdet och detta gör verktyget om vi har definerad gränserna.


Jag skapade precis denna cykelkarta för Umeå med alla gatunamn i en 
bilaga där området utanför tätorten är grått och gator som ligger 
utanför byområdet inte tas med i indexet, se: 
https://maposmatic.osm-baustelle.de/maps/100341/qlPljYcLvFQNZKTI 
direktlänk till pdfen: 
https://maposmatic.osm-baustelle.de/results//100342_2020-01-23_14-30_umea.pdf


mvh

pangoSE

On 2020-01-23 13:49, Andreas Vilén wrote:
Tätortspolygoner ändras varje gång det görs en ny uppdatering, ett 
område byggs eller liknande. Det finns ingen etablerad taggning för 
detta och jag tror inte det är lämpligt att lägga in.


Tätorter är inga administrativa enheter och har normalt inga gränser 
mer än rent statistiska.


/Andreas

Skickat från min iPhone

23 jan. 2020 kl. 13:18 skrev pangoSE >:



Hej
Jag testade uMaps vektorkarta med outdoor lagret från thunderforest. 
(se 
https://umap.openstreetmap.fr/en/map/stugor-och-vindskydd_410556#7/55.835/13.964)


På större zoom nivåer saknas städer i SE pga att dem endast är 
inritade som noder. tex 
https://nominatim.openstreetmap.org/details.php?place_id=133125


I Danmark ser det mycket bättre ut...

LM har släppt alla tätortspolygoner som CC0 så det är bara att importera.
(Se geojson fil här https://www.mediafire.com/folder/dzngn1k5y2xjq/)



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


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

Re: [talk-cz] WeeklyOSM CZ 494

[Michal Fabík]

On 1/23/20 1:45 PM, majkaz wrote:

Namapovat tam nějaký vjezd jako residential jen proto, aby to přestalo 
vyskakovat, se mi opravdu nechce.



Nebylo vhodnější highway=service + service=driveway, případně + access=private 
(pokud je to z nějakého zdroje poznat)? To by asi vyřešilo problém s false 
positives a navíc by to i odpovídalo skutečnosti.

--
Michal Fabík


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

Re: [Talk-se] Malmö och Örnsköldsvik saknas på vektorkarta

[Andreas Vilén]

Tätortspolygoner ändras varje gång det görs en ny uppdatering, ett område byggs 
eller liknande. Det finns ingen etablerad taggning för detta och jag tror inte 
det är lämpligt att lägga in.

Tätorter är inga administrativa enheter och har normalt inga gränser mer än 
rent statistiska.

/Andreas

Skickat från min iPhone

> 23 jan. 2020 kl. 13:18 skrev pangoSE :
> 
> Hej
> Jag testade uMaps vektorkarta med outdoor lagret från thunderforest. (se 
> https://umap.openstreetmap.fr/en/map/stugor-och-vindskydd_410556#7/55.835/13.964)
> 
> På större zoom nivåer saknas städer i SE pga att dem endast är inritade som 
> noder. tex https://nominatim.openstreetmap.org/details.php?place_id=133125
> 
> I Danmark ser det mycket bättre ut...
> 
> LM har släppt alla tätortspolygoner som CC0 så det är bara att importera.
> (Se geojson fil här https://www.mediafire.com/folder/dzngn1k5y2xjq/)
> 
> 
> 
> ___
> Talk-se mailing list
> Talk-se@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-se
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [talk-cz] WeeklyOSM CZ 494

[majkaz]

Bohužel mám obavu, že to na dobře zmapovaných místech povede k problémům. Když 
jsem se podívala v okolí, tak to vyhodilo příjezdy k barákům, co jsou za 
plotem, nebo čerstvě vyjetou "cestu" po louce (protože letecký snímek je patrně 
nasnímaný těsně po pouti, co se u nás koná přesně jednou v roce a na tu louku 
tudy vjíždí kolotočáři). Vyběhlo toho docela dost, ale skutečně chybějící ulice 
žádná.

Vysloveně si to říká o to, aby to nějaký snaživec, co na místě v životě nebyl, 
domapoval na dálku jako běžnou ulici. Specificky ty příjezdy k barákům se podle 
toho leteckého snímku rozeznat jako takové nedají, muselo by se minimálně do 
Panoramy, pokud je tam k dispozici. To ale moc lidí neudělá.

Ta nezmapovaná místa jsou taky problematická - pokud jsou to "dlouhé vsi", kde 
opravdu nejsou jiné ulice než ta státní, co tudy prochází, případně se tam 
kříží dvě takové a baráky jsou jen podél nich, bude je to jako "nezmapované" 
vyhazovat navěky. Namapovat tam nějaký vjezd jako residential jen proto, aby to 
přestalo vyskakovat, se mi opravdu nechce.

Majka
__
> Od: "Miroslav Suchy" 
> Komu: talk-cz@openstreetmap.org
> Datum: 23.01.2020 11:53
> Předmět: Re: [talk-cz] WeeklyOSM CZ 494
>
>Dne 19. 01. 20 v 16:36 Tom Ka napsal(a):
>> * Více zemí pro RapiD.
>
>Kouknul jsem na to a mezi novými zeměmi je i Česko.
>
>Můžete si to vyzkoušet např zde.
>
>https://mapwith.ai/rapid#background=Bing_features=boundaries=18.73/49.09943/15.82223
>Když stisknete Shift+R tak vám ukáže ulice které automaticky poznal z Bingu.
>Úplně stopro to není, ale lepší než drátem do oka.
>
>Dohromady s unmapped places
>  https://resultmaps.neis-one.org/unmapped#8/49.343/15.872
>to docela funguje. Na unmapped place si najdete vesnici, která nemá ulice nebo 
>service road a pomocí RapiD si tam
>necháte najít cesty a ty už "jenom" správně otagujete nebo dokreslíte.
>

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

Re: [OSM-talk-fr] passage en revue de l'utilisateur oc-OpenStreetMap

[Topographe Fou]

Bonjour,

Cela me rappelle un (bref) échange que j'avais eu avec lui il y a quelques
temps :
https://www.openstreetmap.org/changeset/68169859

Je ne suis pas allé plus loin.

Le jeu. 23 janv. 2020 à 12:20, marc marc  a
écrit :

> Bonjour,
>
> existe-t-il un outil pour lister les tags modifiés par un utilisateur ?
> pas un changeset à la fois mais l'ensemble.
> histoire de vérifier si ce sont des cas isolés à annuler à la main
> https://www.openstreetmap.org/changeset/68406347
> ou s'il faut faire appel au DWG pour un revert à grande échelle.
>
> je ne suis demandeur d'un coup de main pour vérifier l'un ou l'autre
> changeset au hasard car pour le moment je suis à 100% d'erreur.
>
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-se] Malmö och Örnsköldsvik saknas på vektorkarta

[pangoSE]

Hej
Jag testade uMaps vektorkarta med outdoor lagret från thunderforest. (se 
https://umap.openstreetmap.fr/en/map/stugor-och-vindskydd_410556#7/55.835/13.964)


På större zoom nivåer saknas städer i SE pga att dem endast är inritade 
som noder. tex 
https://nominatim.openstreetmap.org/details.php?place_id=133125


I Danmark ser det mycket bättre ut...

LM har släppt alla tätortspolygoner som CC0 så det är bara att importera.
(Se geojson fil här https://www.mediafire.com/folder/dzngn1k5y2xjq/)



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

Re: [talk-au] Shoulder and cycle usage

[Andrew Harvey]

On Thu, 23 Jan 2020 at 22:51, Sebastian Spiess  wrote:

> Hi,
>
> your case 1 appears to me like a parking lane. With or without cycle lane
> this is a common occurrence in most suburbs. I've asked about parking lanes
> some time ago.
>

The parking lane is separate though, it's not shared with the cycle lane.
So it's existence doesn't change the fact there is a cycle lane here. So
you'd just also add the parking lane tags.

Some people have been adding the tag cycleway:lane=doorzone where the
cyclelane exists within the door zone of a parking lane.


>
> case 2 - what is the lane between the two continuous lines for?
>

It's just a buffer between the cyclist and vehicles.


> case 3 - this is where I ask me at what width does a shoulder start being
> a shoulder?
>

In real life the shoulder refers to anything outside of the solid painted
line but before the gutter, even if it's too narrow for a car I'd still
consider it a shoulder.

I think https://wiki.openstreetmap.org/wiki/Key:shoulder should still be
used if not wide enough for a car, and let shoulder:width indicate that.


> case 4 - have not notices that one.
>

I searched for at least 15 minutes before finding one!


>
> I give you case 5 - similar to case 3 but with markings to indicate
> bicycle use, on junctions there are even green cycle lanes.
> https://www.openstreetmap.org/edit#map=20/-32.78641/151.92969
>

That looks like case 2 to me. It's a shoulder but it doubles as a cycle
lane.


>
> Case 5 was the reason I've raise the question. Following your cases I
> would tag it (shouder=yes, cycleway=lane) I do recall signs with bikes on
> them along the road, which I would interpret as official cycle way? However
> I noticed that there was no line marked on the outside of the road.
>
>
> I think that the shoulder tag is more important on higher level roads and
> rural roads. In urban areas, residential roads I would use the parking lane
> tags.
>

Sure there is a grey area in between, so I'd go with whichever best
describes it's primary use.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Shoulder and cycle usage

[Sebastian Spiess]

Hi,

your case 1 appears to me like a parking lane. With or without cycle
lane this is a common occurrence in most suburbs. I've asked about
parking lanes some time ago.

case 2 - what is the lane between the two continuous lines for?

case 3 - this is where I ask me at what width does a shoulder start
being a shoulder?

case 4 - have not notices that one.

I give you case 5 - similar to case 3 but with markings to indicate
bicycle use, on junctions there are even green cycle lanes.
https://www.openstreetmap.org/edit#map=20/-32.78641/151.92969

Case 5 was the reason I've raise the question. Following your cases I
would tag it (shouder=yes, cycleway=lane) I do recall signs with bikes
on them along the road, which I would interpret as official cycle way?
However I noticed that there was no line marked on the outside of the road.


I think that the shoulder tag is more important on higher level roads
and rural roads. In urban areas, residential roads I would use the
parking lane tags.


On 23/1/20 5:34 pm, Andrew Harvey wrote:
> On Tue, 21 Jan 2020 at 14:19, Sebastian S.  > wrote:
>
> Hi, what is the view of tagging road shoulders and particularly
> when they have painted bicycle signs?
>
> Motorways would be another candidate.
>
>
> I've seen a few different scenarios.
>
> - a dedicate cycle lane (only used as a cyclelane, not an emergency
> shoulder) cycleway=lane + shoulder=no
> eg https://www.openstreetmap.org/edit#map=20/-33.81151/151.18789
> - a shoulder which doubles as a marked cycle lane (it's an emergency
> shoulder, but with markings to indicate bicycle use) (shouder=yes,
> cycleway=lane)
> eg https://www.openstreetmap.org/edit#map=20/-34.64938/150.84838
> - a shoulder which can be used by bicycles but has no bicycle markings
> or signage (shoulder=yes cycleway=no, bicycle=yes)
> eg https://www.openstreetmap.org/edit#map=20/-34.58996/150.60760
> - have both a cycle lane and a shoulder, though segregated by paint
> (cycleway=lane, shoulder=yes) - no way to distinguish this from case
> (2) eg. https://www.openstreetmap.org/edit#map=20/-33.43134/151.29444
>
> I admit though this can be subjective.
>
> So my rule of thumb is if there is a painted marking for bicycles and
> it's separated from other traffic from paint then use cycleway=lane,
> you can also then consider if this is a road shoulder too and add
> shoulder=yes if so.
>
> On Wed, 22 Jan 2020 at 14:30, Ian Sergeant  > wrote:
>
> Hi, 
>
> Shoulders should always be tagged appropriately.
>
> Shoulders legally in Australia can be used by all bicycles -
> whether or not they have a bicycle stencil (painted bicycle sign) 
> And a bicycle lane is legally indicated by a sign and not a
> stencil.  Legally the stencil has no meaning at all.
>
>
> My view is we should be tagging based on the effective feature on the
> ground, and not solely based on if it meets a specific legal
> classification. So while legally it might need to meet certain
> crieteria to be an official "cycle lane" so long as it's dedicated for
> use by bicycles and separated from other traffic, it's effectively a
> cycleway=lane in OSM.

I've also seen some shoulders that are quite rough and not great cycle
lanes.

>  
>
> My personal advice currently in Australia is to caution against
> indicating there is bicycle infrastructure where there is no
> amenity.   Since, this is a far greater problem in OSM than
> missing cycle routes and infrastructure, and takes far longer to
> correct and survey.  Google Maps has actually come from behind to
> lead OSM in this aspect now in Sydney in most areas.
>
Ian, could you clarify the problem? I understand you refer to amenity as
in signs and stencils for cycle routes?
>
> Are there any places in particular you think we are lacking? I've been
> working hard to add new recently built infrastructure and well as
> remove cycle tags from OSM where there is nothing left on the ground
> anymore.
>  
>
> That said, most motorways that have a wide shoulder, a cycle
> stencil, and permit cycling have a bicycle lane indicated.  I
> think this is probably appropriate.
>
> Ian.
>
> On Tue, 21 Jan 2020 at 14:19, Sebastian S.  > wrote:
>
> Hi, what is the view of tagging road shoulders and
> particularly when they have painted bicycle signs?
>
> Motorways would be another candidate.
>
> A wiki entry for shoulder exists but is very basic
> 
> https://wiki.openstreetmap.org/wiki/Key:shoulder___
> Talk-au mailing list
> Talk-au@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-au
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org 
> 

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

[Fernando Trebien]

On Wed, Jan 22, 2020 at 4:41 PM Thierry Jean  wrote:
> sei que seria muito bom que, em função do nível de zoom possa-se, 
> progressivamente, ver aparecer as vias por hierarquia

Essa também é uma das intenções da proposta. No RS já dá pra ver bem
isso acontecendo no site do OSM ao passar do nível 5 pro 6 e do nível
7 pro 8. O efeito é bastante parecido com o que se observa, por
exemplo, na França, na Alemanha, na Espanha, nos Estados Unidos nas
regiões menos populosas, no Uruguai, na província de Buenos Aires na
Argentina, etc.

> utilizadas pelos algoritmos de navegação.

Aparentemente essa classificação funciona super bem com algoritmos de
navegação. A nível estadual, as rotas mais longas costumam todas
seguir pelas vias de mais alta classe na maior parte do percurso, que
é o esperado pelos usuários do mapa, e sair delas somente próximo da
origem e do final da rota, que também é o esperado, exceto em casos
mais raros. Isso acontece em boa parte porque a classificação
resultante acaba encontrando uma boa subdivisão espacial, dando
preferência às vias que são melhores para dirigir.

Da minha parte, eu verifiquei isso mais dentro das cidades (onde
apliquei essa metodologia já faz uns anos) do que no nível estadual
(onde foi aplicada só recentemente). Nas cidades, o roteamento passa a
aproximar bem mais aquele feito pelas ferramentas preferidas pelo
mercado (ex.: Waze, Google Maps). O resultado também costuma aproximar
o nível arterial que consta nos planos diretores (nesse caso, segue-se
a mesma ideia, trocando place=city por place=suburb e highway=trunk
por highway=secondary), e (o que acho mais interessante) é que ele
consegue capturar bem aquelas situações locais em que a realidade
diverge do plano. No nível estadual, parece ter esse efeito também.
Por exemplo, no RS, a principal rota entre as duas maiores cidades
(Porto Alegre e Caxias do Sul) é por rodovias estaduais, sendo que a
rodovia federal (pavimentada e em bom estado) que liga as duas, apesar
de ser federal, não é o melhor caminho. O método sugere então que
essas vias estaduais sejam trunk e que essa federal não seja, o que
produz um resultado que pareceu mais intuitivo à comunidade do RS.
Todos ganham: as pessoas que usam o mapa para roteamento, as que estão
julgando visualmente quais vias são geograficamente mais importantes,
e nós, mapeadores, que finalmente obtemos consenso.

-- 
Fernando Trebien

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

Re: [OSM-talk-fr] intégration des voies sans addr : trouveur leur localisation

[marc marc]

Merci pour vos réponses.

Hélas le cadastre n'a aucune connaissance des 4 voies sans addr
que je cherchais.
j'ai utilisé l'analyse des pdf via http://cadastre.openstreetmap.fr
ce qui m'a permit de trouver un des lieux-dit nomé dans le nom de la
voie. j'ai trouvé/ajouté ce qui semble le seul chemin pour s'en
approcher mais le cadastre n'a pas de nom pour celui-ci.

pas grave, je passe à la commune suivante :)

Le 22.01.20 à 15:03, Jérôme Seigneuret a écrit :
> https://www.cadastre.gouv.fr/scpc/accueil.do  
> Et d'ailleurs on retrouve plein de choses bizarres avec des noms de
> voies qui n'ont pas été changé sur certaines parcelles... l'alias n'est
> pas utilisé dans le cadastre. En effet c'est très fastidieux.Si  pas de
> rattachement parcellaire et que la voie est quand même connu, ça ne va
> pas plus loin et ne te propose pas de planche.
> 
> 
> 
> Le mer. 22 janv. 2020 à 14:25, Vincent de Château-Thierry
> mailto:osm.v...@free.fr>> a écrit :
> 
> Bonjour,
> 
> > De: "marc marc"  >
> >
> > existe-t-il un moyen de chercher le cadastre pour trouver
> > la localisation d'une voie sans addr ?
> > http://dev.cadastre.openstreetmap.fr/fantoir/ ne donne pas de
> > coordonées
> > Sur la couche cadastre, elles apparaissent souvent mais visualiser
> > toute l'étendue d'une commune est fastidieux.
> >
> > ou autre outil ?
> 
> Si à la voie recherchée sont rattachées des parcelles, alors tu peux
> chercher le nom de voie ici :
> https://www.cadastre.gouv.fr/scpc/accueil.do
> Tu auras autant de réponses que de parcelles correspondantes (et de
> feuilles concernées) avec une visu carto.
> 
> vincent
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> Cordialement,
> Jérôme Seigneuret
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

[OSM-talk-fr] passage en revue de l'utilisateur oc-OpenStreetMap

[marc marc]

Bonjour,

existe-t-il un outil pour lister les tags modifiés par un utilisateur ?
pas un changeset à la fois mais l'ensemble.
histoire de vérifier si ce sont des cas isolés à annuler à la main
https://www.openstreetmap.org/changeset/68406347
ou s'il faut faire appel au DWG pour un revert à grande échelle.

je ne suis demandeur d'un coup de main pour vérifier l'un ou l'autre
changeset au hasard car pour le moment je suis à 100% d'erreur.

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

Re: [OSM-talk] HOT Summit is looking for a location

[Jo]

It's unlikely that I will be able to make it to South Africa this year, but
I liked that the HOT Summit was adjacent to SotM like it was in Heidelberg
in 2019 and in Brussels a few years ago.

Polyglot

On Thu, Jan 23, 2020 at 12:00 PM Christine Karch 
wrote:

> Huhu,
>
> Hot Inc asked SotM Working Group because they are looking for a proper
> location for HOT Summit. They would like to hold their conference
> adjecent to SotM as it was in Heidelberg.
>
> We at the SotM Working Group will discuss this on our next meeting. What
> does the community think about this?
>
> Hot Inc has a survey at Twitter at the moment
>
> https://twitter.com/hotosm/status/1219750465098874880
>
> Kind regards,
>
> Christine
>
> ___
> 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: [OSM-talk-fr] Type de highway pour voie de bus

[marc marc]

je parle du cas simple, non tiré par les cheveux.
exemple https://www.openstreetmap.org/way/16405595
foot=yes ne veux donc pas dire "la rue entière est accessible
aux piétons" (sinon ce serrait un living_street ou qlq chose du genre).
foot=yes (explicite sur l'objet ou implicite en fct de la valeur du
highway=*) dit qu'un piéton a le droit de circuler sur au moins une
partie de la rue, les autres tags et la loi sont là pour dire si c'est
tout ou une partie.

Le 23.01.20 à 00:52, Philippe Verdy a écrit :
> Tu veux parler du cas particulier d'une rue barrée pour travaux avec une
> tranchée au milieu (interdite à tous avec des barrières autour, mais
> juste un passage de chaque côté par les trottoirs laissés libres pour
> les piétons (notamment les riverains qui doivent pouvoir encore entrer
> chez eux) ?
> Dans ce cas, oui les trottoirs sont obligatoires et on ne peut pas
> traverser la rue qui temporairement devient deux voies piétons séparées
> par des barrières et la tranchée, voire une seule voie d'un seul côté et
> sur une partie de la rue (juste ce qui est nécessaire pour laisser un
> accès aux riverains)
> Cependant ce n'est pas une situation durable, la tranchée dure quelques
> jours, et souvent elle se déplace. Cas qui existe pour une réfection des
> réseaux (égouts par exemple, mais il faut aussi rétablir ou maintenir
> les autres réseaux parallèles qui peuvent être temporairement dérivés:
> eau, gaz, électricité, téléphone/fibre).
> 
> Le mer. 22 janv. 2020 à 22:06, Stéphane Péneau
> mailto:stephane.pen...@wanadoo.fr>> a écrit :
> 
> Le 22/01/2020 à 20:41, marc marc a écrit :
> > Le 22.01.20 à 20:27, Stéphane Péneau a écrit :
> >> interdite à tout le monde, mais les trottoirs accessibles aux
> piétons.
> > access=no + foot=yes :)
> 
> Bah non, dans ce cas, la rue entière est accessible  aux piétons.
> Je parle de l'hypothétique cas où il n'y a que les trottoirs qui
> seraient accessibles à pied.
> 
> Stf
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [OSM-talk-fr] Afficher un flux WMS de l'ONF dans JOSM

[marc marc]

> Philippe Verdy wrote
>> corriger la syntaxe XML, et utiliser ce fichier> pour accéder aux tuiles...

comment injecteras-tu ce xml modifié dans la réponse reçue par josm ?
cela sent le 100% vapoware !

Le 23.01.20 à 10:32, Romain MEHUT a écrit :
> Sauf que je n'ai pas les compétences pour faire ce que tu proposes en
> correctif :(

solution pragmatique : écrire à l'ONF pour signaler que tel url ne va
plus après avoir vérifié sur leur site si une nouvelle n'est pas dispo.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk] HOT Summit is looking for a location

[Christine Karch]

Huhu,

Hot Inc asked SotM Working Group because they are looking for a proper
location for HOT Summit. They would like to hold their conference
adjecent to SotM as it was in Heidelberg.

We at the SotM Working Group will discuss this on our next meeting. What
does the community think about this?

Hot Inc has a survey at Twitter at the moment

https://twitter.com/hotosm/status/1219750465098874880

Kind regards,

Christine

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

Re: [talk-cz] WeeklyOSM CZ 494

[Miroslav Suchy]

Dne 19. 01. 20 v 16:36 Tom Ka napsal(a):
> * Více zemí pro RapiD.

Kouknul jsem na to a mezi novými zeměmi je i Česko.

Můžete si to vyzkoušet např zde.

https://mapwith.ai/rapid#background=Bing_features=boundaries=18.73/49.09943/15.82223
Když stisknete Shift+R tak vám ukáže ulice které automaticky poznal z Bingu.
Úplně stopro to není, ale lepší než drátem do oka.

Dohromady s unmapped places
  https://resultmaps.neis-one.org/unmapped#8/49.343/15.872
to docela funguje. Na unmapped place si najdete vesnici, která nemá ulice nebo 
service road a pomocí RapiD si tam
necháte najít cesty a ty už "jenom" správně otagujete nebo dokreslíte.

RapiD umí i budovy, ale to jsem ani nezkoušel, protože zpravidla máme mnohem 
lepší data v katastru.

Mirek

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

[Talk-de] Der HOT Summit sucht eine Location

[Christine Karch]

Huhu,

Hot Inc ist an die SotM Working Group herangetreten, da sie auf der
Suche nach einer geeigneten Location sind. Man würde sich gerne der SotM
anschliessen. Die SotM Working Group wird das Thema auf der nächsten
Sitzung besprechen. Wie sieht denn in der Community dazu das
Stimmungsbild aus? In Heidelberg hatten wir ja eine ähnliche Konstellation.

Hot Inc hat auf Twitter auch eine Umfrage zum Thema lanciert:

https://twitter.com/hotosm/status/1219750465098874880

Grüße Christine

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

Re: [talk-ph] Tagging of barangays and sitios/puroks

[Ervin Malicdem]

I am still for standardizing place=village  and the use of
place:PH=barangay for the purpose of synchronizing political designation to
the global tag. This will prevent re-evaluating each of the barangays in
the country that are already present in OSM and deciphering if it will be
tagged as a village or hamlet etc. by new mappers who are not adept with
population figures. And changing every map derived for OSM just to fit to
this change would cause more time to consume. Its population can be placed
in the population tag anyway.

Anything that is smaller than a barangay such as a sitio/purok can be
tagged as a place=hamlet and place:PH=sitio

Ervin M.
Schadow1 Expeditinos
A Filipino must not be a stranger to his own motherland.
https://www.s1expeditions.com


On Thu, Jan 23, 2020, 3:41 PM Eugene Alvin Villar,  wrote:

> The value is that we align better to the global tagging scheme with
> respect to human settlements. And there is a great variability in barangays
> that shoehorning them all into just place=village no longer makes sense.
> For example, Barangay 12 in Pasay is essentially just a small city block
> while Barangay 176 in Caloocan has a population of almost 250,000 making it
> more populous than majority of all PH cities. Both do not seem to be
> "villages" in the global OSM sense to me.
>
> Also, back when we decided to tag barangays as place=village, tags like
> place=quarter or place=suburb didn't exist yet.
>
> Finally, we can still mark these place nodes as barangays by adding the
> designation=barangay tag if you want to query for them.
>
> On Thu, Jan 23, 2020, 3:22 PM maning sambale, 
> wrote:
>
>> Pardon for my confusion, but I don's see the value of splitting
>> barangays to village and quarter in the context of the Philippines.
>>
>> On Thu, Jan 23, 2020 at 2:19 PM Jherome Miguel 
>> wrote:
>> >
>> > I also thought of using the Philippine Statistics Authority (PSA)
>> subclassifications of barangays to determine which gets quarter or village,
>> as being inside a city boundary doesn't make every barangay urban.
>> >
>> > * urban barangay - quarter
>> > * rural barangay - village
>> >
>> > We may also consider having a tag to handle the PSA subclassification.
>> >
>> > On Wed, Jan 22, 2020 at 8:03 PM Jherome Miguel 
>> wrote:
>> >>
>> >> Eugene suggested to tag barangays in cities as place=quarter when
>> applicable. We already agree to tag remote or rural sitios/puroks as
>> place=hamlet, and we haven't agreed on how to deal with urban barangays.
>> >>
>> >> On Wed, Jan 22, 2020 at 6:56 PM maning sambale <
>> emmanuel.samb...@gmail.com> wrote:
>> >>>
>> >>> From the wiki:
>> https://wiki.openstreetmap.org/wiki/Tag%3Aplace%3Dquarter
>> >>> "This does not have to be an administrative entity. "
>> >>>
>> >>> We agreed in the past that barangay is synonymous to place=village.
>> >>> Were there any changes with this view?
>> >>>
>> >>> On Thu, Jan 23, 2020 at 8:57 AM Jherome Miguel <
>> jheromemig...@gmail.com> wrote:
>> >>> >
>> >>> > I am already seeing retagging of barangays in urban areas (e.g.
>> Metro Manila) from place=village to place=quarter. Our present guidelines
>> for tagging local government unit (LGU) says barangays always get tagged as
>> village regardless if it's in an urban or rural area, but the
>> recommendation to tag urban barangays to quarter hasn't been documented yet
>> nor discussed (though I agree with it as they better reflect the situation
>> in urban areas and the general tagging recommendations).
>> >>> >
>> >>> > Our current guidelines on mapping sitios/puroks is to tag them as
>> place=neighbourhood, even if it's on a rural or isolated area. I tag them
>> as place=hamlet instead, as they better reflect how they are in reality
>> (those are usually clusters of homes with populations of ~100-200, though
>> those are just approximates as they are not covered in censuses) and best
>> follows general tagging recommendations. I'm also considering having this
>> scheme for sitios/puroks depending on their location:
>> >>> >
>> >>> > * Urban - place=neighbourhood
>> >>> > * Rural - place=hamlet
>> >>> > ___
>> >>> > talk-ph mailing list
>> >>> > talk-ph@openstreetmap.org
>> >>> > https://lists.openstreetmap.org/listinfo/talk-ph
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> cheers,
>> >>> maning
>> >>> --
>> >>> "Freedom is still the most radical idea of all" -N.Branden
>> >>> https://github.com/maning
>> >>> http://twitter.com/maningsambale
>> >>> --
>>
>>
>>
>> --
>> cheers,
>> maning
>> --
>> "Freedom is still the most radical idea of all" -N.Branden
>> https://github.com/maning
>> http://twitter.com/maningsambale
>> --
>>
>> ___
>> talk-ph mailing list
>> 

Re: [OSM-talk-fr] Type de highway pour voie de bus

[Stéphane Péneau]

Le 22/01/2020 à 22:25, marc marc a écrit :

Le 22.01.20 à 22:06, Stéphane Péneau a écrit :

Le 22/01/2020 à 20:41, marc marc a écrit :

Le 22.01.20 à 20:27, Stéphane Péneau a écrit :

interdite à tout le monde, mais les trottoirs accessibles aux piétons.

access=no + foot=yes :)

Bah non, dans ce cas, la rue entière est accessible  aux piétons.
Je parle de l'hypothétique cas où il n'y a que les trottoirs qui
seraient accessibles à pied.

la loi ne dit-elle pas que le piéton doit marcher sur le trotoir quand
il y en a un ?


Ah ben tient, il semblerait que ma période "urbaine" soit trop loin pour 
me souvenir de ça.


Merci.

Stf

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

Re: [OSM-talk-fr] Afficher un flux WMS de l'ONF dans JOSM

[Romain MEHUT]

Philippe Verdy wrote
> Chez moi non, j'ai aussi une erreur XML, le flux WMS inutilisable, reste à
> trouver un WMS corrigé donnant accès aux mêmes tuiles. Tu peux déjà créer
> une copie du WMS existant, corriger la syntaxe XML, et utiliser ce fichier
> pour accéder aux tuiles...
> C'est à signaler à l'office qui a mis en place ce XML bogué.

Sauf que je n'ai pas les compétences pour faire ce que tu proposes en
correctif :(

Romain




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

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

Re: [OSM-talk-fr] JOSM et Chromebook

[Philippe Verdy]

Je n'utilise pas ChromeOS, mais je trouve bizarre qu'il n'y ait pas de JRE
porté pour cet OS, même si ça oblige et réimplémenter certains composants
graphiques du JRE pour être compatible avec l'environnement graphique de
ChromeOS, basé sur une VM Java pas tout à fait compatible. Il doit bien
exister des packages Java pour rendre compatible les applis Java avec le
moteur Dalvik VM (je pense que c'est celui-là, comme sur Android; il doit y
avoir des différences notamment sur le JNI, la Reflection, et le contrôle
des paramètres de VM pour la mémoire ou le séquençage et le débogage).
Si je prends l'exemple d'Eclipse, il est utilisé pour générer des packages
pour un divers JRE dont ceux d'Oracle et Android, je n'ai pas vérifié s'il
y avait un ciblage ChromeOS en mode natif (et non seulement en tant que
support pour le déploiement final vers ChromeOS ou avec un émulateur
ChromeOS sur un autre OS supporté par ChromeOS).

Si je prends l'exemple de Dalvik VM, il y a bien un environnement de
développement et d'émulation sur Windows et Linux, dans le cadre du
développement pour Android, et des connecteurs pour faire du débogage à
distance sur un appareil Android connecté par exemple en USB, exécutant
l'application compilée depuis un autre OS sur un PC classique où se trouve
l'environnement de développement (avec de la capacité de stockage, plus de
mémoire, plus de connectivité, plus d'outils et de meilleures performances
et plus pratique à manipuler pour un développeur avec un vrai clavier et
une souris, et même la possibilité de faire compiler sur des serveurs
distants dans un cloud avec des repositories comme GitHub et divers
automates de tests automatiques pour la non-régression, la qualité du code,
la sécurité, l'analyse des composants dépendants, le versionnement et les
recommandations de sécurité pour leur mise à jour ou l'analyse des
problèmes de compatiblité, ou de dépréciation et d'obsolescence, de
certaines API jugées peu fiables ou au comportement non clairement défini
et pas forcément facilement portables, ou devenues inutilisables sans
paramétrage supplémentaire plus fin des permissions ou sans la prise en
charge des exceptions supplémentaires que peuvent retourner certaines API
qui ont été restreintes dans des versions ultérieures).

ChomeOS reste un OS très mineur en comparaison d'Android. Je ne suis pas
sûr que Google maintienne cet OS longtemps, si au final l'objectif c'est
juste d'avoir une base un peu plus musclée montrant ce que fera une future
version d'Android pour les tablettes et d'autres dispositifs (TV
connectées, smartwatches, enceintes connectée, navigateurs automobiles,
etc.). Il pourrait ne plus exister qu'avec son micronoyau Linux et le reste
avec l'environnement Android. en gros Google cherche à faire ce que
Microsoft a abandonné récemment pour Windows. Mais Microsoft va être
exigeant maintenant pour Android, il n'abandonne pas Windows 10 sur les
mobiles et tablettes sans demander à Google d'étendre les fonctionnalités
d'Android. Au final, ChromeOS semble voué à disparaître vers un Android
"standard" et un noyau Linux "tuné" pour lui: c'est une plateforme de
démonstration qui est là pour combler un vide chez Google, mais ça marchera
au moins quelques années encore (la durée de vie des appareils mobile étant
d'environ 3 ans avant que leur batterie lache ou que leur capacité mémoire
et de stockage les rende obsolètes et aussi inutilisables que les anciens
smartphones vendus avec Android 4 ou avant).

Face à Chrome OS, qui vise non pas les mobiles ou tablettes mais les PC
portables (convertibles), il reste encore un "concurrent" sérieux: Windows
10 (même en version bridée "S", que l'utilisateur peut débrider en version
Home sans obligation d'utiliser seulement les applis de Windows Store masi
aussi les applis Win32 classiques). ChromeOS est proposé comme alternative
simple (mais pas forcément moins cher) pour une gamme d'appareils (et du
côté de Microsoft ils ont fait assez fort sur les prix de leurs portables
convertibles Surface). Arrive devant les deux les alternatives chinoises
dont l'OS de Huawei depuis qu'il a été banni du marché Android: lui aussi
se base sur un noyau Linux et réutilise pas mal de composants libres des
univers Linux, Java et Android sans les modifier beaucoup. Et évidemment
aussi Apple avec iOS (mais Apple prend en charge maintenant directement le
JRE standard dans sa distrib de l'OS, et non plus Sun/Oracle comme avant).

Java reste une brique de base "commune" même si le coeur et la liste des
API supportées varie suivant ses distributions (et le reste doit être pris
en charge en chargeant des bibliothèques de compatiblité). L'autre
différence c'est la méthode de déploiement des packages compilés, très
différente avec Dalvik VM qui utilisent un autre format intermédiaire et
qui est recompilé sur la machine Android cible en forme binaire exécutable
au lieu d'utiliser dynamiquement le JIT du JRE Sun/Oracle, sans pour autant
donner un accès direct natif à l'OS 

Re: [Talk-dk] Hastighedsbegrænsninger i Århus Øst

[osm]

https://stiften.dk/artikel/ballade-og-gader%C3%A6s-p%C3%A5-aarhus-%C3%B8-vejbump-skal-d%C3%A6mpe-farten-2018-5-22(2)


-- 


> Sent: Wednesday, January 22, 2020 at 11:39 PM
> From: "Niels Elgaard Larsen" 
> To: "OpenStreetMap Denmark" 
> Subject: [Talk-dk] Hastighedsbegrænsninger i Århus Øst
>
> Er der nogen århusianere, der ved hvad hastighedsbegrænsningen er i Århus øst,
> omkring Bernhardt Jensens Boulevard.
> 
> Mapillary fotos viser nogle 40 km/h. Men de er tydeligvis midlertidige.
> På den anden side er der heller ikke noget rigtigt vejarbejde på billederne.
> 
> Det er et nyt område og måske er der nu permanente zoneskilte.
> 
> -- 
> Niels Elgaard Larsen
> 
> ___
> Talk-dk mailing list
> Talk-dk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-dk
>

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