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

[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: [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

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

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: [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

[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

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: [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

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

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