Re: [OSM-talk-fr] Message d'erreur d'iD concernant les "points"

[Philippe Verdy]

Pas si évident, il y a parfois besoin de plusieurs nœuds pour des services
différents dans le même bâtiment (ou la même zone incluant le bâtiment).

On a eu le cas avec les écoles, il y a aussi les cas de services à des
étages différents du même bâtiment, c'est un cas fréquent en milieu urbain
dense, où il n'est pas réellement sensé de diviser le bâtiment et tous ces
services sont à la même adresse (juste une différence de porte, ou d'étage
mais pas toujours car il peut y avoir un accueil/secrétariat commun).

Taguer les points dans le bâtiment ou sur sa bordure à la porte d'accès
c'est selon... mais même si on les place à l'accès, il y a encore plus de
chance que plusieurs services alors doivent s'y superposer, et donc plus
moyen d'avoir plusieurs noeuds et les tags vont se mélanger sur le même
noeud (puisqu'on ne superpose pas plusieurs noeuds, il faut une séparation).

Le sam. 25 janv. 2020 à 21:24, marc marc  a
écrit :

> Le 25.01.20 à 21:21, Romain MEHUT a écrit :
> > iD râle si un nœud, décrit par exemple comme un commerce,
> > est contigu du pourtour d'un bâtiment.
>
> cela me semble une bonne idée, le commerce n'est pas une partie du
> contour mais qlq chose dans le batiment.
>
>  Je ne rencontre pas d'erreur avec JOSM
>
> ce serrait une bonne idée à proposer
> ___
> 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] Ajout de NRO : blocage d'un contributeur à envisager ?

[deuzeffe]

Sinon, il est aussi à l'origine de cette umap : 
https://framacarte.org/fr/map/ftth-france-nro-et-pmz_65687#7/47.413/0.879


Qui montre qu'il y en a des qui tagguent un peu yolo, type name=NRO de 
Trifouillis-les-Oies.


Va falloir faire une sacré ménage :(

Le 25/01/2020 à 23:18, deuzeffe a écrit :

Vais essayer de le capter sur twitter, si c'est bien le même.
Don't move please :)

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

Le 25.01.20 à 21:07, Romain MEHUT a écrit :

Qu'en pensez-vous ?


il a fait un doublon, ta remarque est justifiée qu'il faut mettre à jour
l'objet existant.

il aurait du répondre avant de continuer avec des nouveaux objets,
tout a fait d'accord aussi.

en meme temps cela fait que 2 jours et résoudre l'erreur serra facile.
mais si tu veux, demande un 0-hour ban (un blocage qui oblige
l'utilisateur à lire le message, il peux continuer ensuite...
s'il le fait et continue ses erreurs, ce serra évidement une raison
d'être + instant/long en blocage)
___
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] Motorroad sur Trunk en France

[Florimond Berthoux]

Et c'est écrit où sur le wiki que panneau "route automobile" => trunk ?

Le sam. 25 janv. 2020 à 23:06, marc marc  a
écrit :

> Le 25.01.20 à 23:03, Florimond Berthoux a écrit :
> > mais je vois
>
> moi je vois pas les panneaux sur les 2 premiers qui sont la base de la
> classification en fr
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Ajout de NRO : blocage d'un contributeur à envisager ?

[deuzeffe]

Vais essayer de le capter sur twitter, si c'est bien le même.
Don't move please :)

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

Le 25.01.20 à 21:07, Romain MEHUT a écrit :

Qu'en pensez-vous ?


il a fait un doublon, ta remarque est justifiée qu'il faut mettre à jour
l'objet existant.

il aurait du répondre avant de continuer avec des nouveaux objets,
tout a fait d'accord aussi.

en meme temps cela fait que 2 jours et résoudre l'erreur serra facile.
mais si tu veux, demande un 0-hour ban (un blocage qui oblige
l'utilisateur à lire le message, il peux continuer ensuite...
s'il le fait et continue ses erreurs, ce serra évidement une raison
d'être + instant/long en blocage)
___
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] Motorroad sur Trunk en France

[marc marc]

Le 25.01.20 à 23:03, Florimond Berthoux a écrit :
> mais je vois

moi je vois pas les panneaux sur les 2 premiers qui sont la base de la
classification en fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Motorroad sur Trunk en France

[Florimond Berthoux]

primary
https://www.google.fr/maps/@48.1664989,-0.6847208,3a,75y,210.97h,73.46t/data=!3m6!1e1!3m4!1sCUHL_1l1nFYhhYDxdgJyFg!2e0!7i16384!8i8192
trunk
https://www.google.fr/maps/@48.1614843,-0.6886588,3a,75y,192.69h,72.7t/data=!3m6!1e1!3m4!1shROxjGu0LaPy2zjvuIfLfQ!2e0!7i16384!8i8192
trunk + motorroad
https://www.google.fr/maps/@48.1577855,-0.6893419,3a,75y,192.69h,72.7t/data=!3m6!1e1!3m4!1siMRHFTPWZWx50HTHVOcdpw!2e0!7i16384!8i8192
(mais je vois qu'il n'a justement pas de tag motorroad, mais c'est pour
illustrer le problème)

Le sam. 25 janv. 2020 à 21:30, marc marc  a
écrit :

> Le 25.01.20 à 21:12, Florimond Berthoux a écrit :
> > un panneau "route pour automobile" après la premier sortie,
> > où le tag motorroad est fort utile.
>
> pq cette partie n'est pas en highway=trunk ?
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

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

[marc marc]

Le 25.01.20 à 18:36, deuzeffe a écrit :
> pour la couche cadastre (par ex.), qui est donc en LO, on indique quand
> même nom, source et millésime, non ?

on a 3 outils différents et 3 source=* différentes dans le texte.
pas génial pour les outils qui veulent retrouver l'info
en plus, source=... 2019 ne dit pas que cela a été fait avec la source
en 2019 parce que le gars (moi et d'autres) qui s'occupent de faire la
maj ne le font pas nécessairement au passage de l'an... et meme si c'est
fait ce jour c'est pas nécessairement publié ce jour... et meme si c'est
publié c'est pas nécessairement re-télécharger ce jour..

alors ce serrait p'tre plus que temps de passer à des données simple
et à jour : source=cadastre sur le changet date : celle du changeset
au moins on aurait plus de source définie sur une date alors que la
géométrie a changé entre temps...

à défaut source=casatre AAA serrait deja un petit pas en avant
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ajout de NRO : blocage d'un contributeur à envisager ?

[marc marc]

Le 25.01.20 à 21:07, Romain MEHUT a écrit :
> Qu'en pensez-vous ?

il a fait un doublon, ta remarque est justifiée qu'il faut mettre à jour
l'objet existant.

il aurait du répondre avant de continuer avec des nouveaux objets,
tout a fait d'accord aussi.

en meme temps cela fait que 2 jours et résoudre l'erreur serra facile.
mais si tu veux, demande un 0-hour ban (un blocage qui oblige
l'utilisateur à lire le message, il peux continuer ensuite...
s'il le fait et continue ses erreurs, ce serra évidement une raison
d'être + instant/long en blocage)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Message d'erreur d'iD concernant les "points"

[marc marc]

Le 25.01.20 à 21:34, Romain MEHUT a écrit :
> Le sam. 25 janv. 2020 à 21:24, marc marc a écrit :
> 
> 
> cela me semble une bonne idée, le commerce n'est pas une partie du
> contour mais qlq chose dans le batiment.
> 
> 
> C'est pourtant une pratique répandue de désigner un commerce à partir de
> là où on y accède. Marc j'imagine que tu vas répondre qu'il suffit de
> dissocier le point d'accès du commerce lui-même.

je répond qu'on confond la porte et le commerce.

conséquence pratique : dire la porte est accessible PMR sans savoir
ce qu'il en est du POI parce qu'il n'a pas été dedans POI.
ou le POI double porte (chose qu'on ne sait pas quand on est
devant la 1ere porte)
le poi au moins 1mm dans le bâtiment résout bien des problèmes.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Message d'erreur d'iD concernant les "points"

[Romain MEHUT]

Le sam. 25 janv. 2020 à 21:24, marc marc  a
écrit :

>
> cela me semble une bonne idée, le commerce n'est pas une partie du
> contour mais qlq chose dans le batiment.
>

C'est pourtant une pratique répandue de désigner un commerce à partir de là
où on y accède. Marc j'imagine que tu vas répondre qu'il suffit de
dissocier le point d'accès du commerce lui-même.

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

Re: [OSM-talk-fr] Motorroad sur Trunk en France

[Philippe Verdy]

l'indication ne me parait pas fausse. "highway=trunk" est utilisé sur
toutes les voies express pour automobiles à chaussées séparées, non
classées comme "autoroutes" (motorway) et qui n'autorisent donc pas les 130
km/h (note: toutes les autoroutes ne sont pas en totalité à 130 km/h, elles
ont des sections plus lentes, parfois plus lentes que les voies express
"trunk", notamment en périphérie urbaine ou près de certains embranchements
d'autoroutes, ou parce que localement le passage est plus étroit et il y a
moins de voies ou le séparateur de chaussées se limite à une glissière, ou
sur certaines pentes longues).
Je n'ai pas vu d'utilité de "motorroad" en France en plus de "trunk" et
"motorway".

Les "autoroutes" de Bretagne sont presque toutes des "trunk", leur
classement autoroutier est bloqué depuis longtemps, mais pas à cause de la
gratuité car après tout il y a bien une section d'autoroute gratuite
(motorway) au nord de Rennes vers Avranches, mais par volonté régionale de
ne pas les mettre à 130 km/h ou peut-être conserver la possibilité
d'ajouter d'autres échangeurs pour les liaisons transversales rapides
(nationales ou départementales, classées aussi en "trunk" en partie, qui
manquent encore (une nationale centrale en particulier n'en finit plus de
se construire en "trunk", section par section, depuis des décennies et les
transversales ne sont toujours pas là, comme Rennes - Redon -
Saint-Nazaire, Saint-Brieux - Ploërmel - Vannes... et d'autres au Finistère
; les trunks complets sont ceux qui font le tour de la côte, mais il manque
une section au nord de l'Ille-et-Vilaine pour Saint-Brieuc - Dinan -
Avranche).

Le sam. 25 janv. 2020 à 21:12, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> Bonsoir,
>
> Je suis tombé sur une phrase qui m'a étonné sur la page de la clé
> motorroad du wiki
> «France
> This tag is not required, just use highway=trunk. »
> https://wiki.openstreetmap.org/wiki/Key:motorroad?uselang=fr#France
>
> Et effectivement pas de traduction en français de la page, et sur la page
> française de Trunk l'explication du tag est resté en anglais.
>
> Cette phrase me parait assez fausse parce qu'en France une motorroad ça a
> un panneau voir
> https://fr.wikipedia.org/wiki/Route_pour_automobiles#En_France
> Le tag est très utilisé dans le pays des Trunk (Bretagne) et ailleurs.
> Et pour ce qui me concerne j'ai l'exemple d'une voie rapide dont un
> premier tronçon est cyclable puis un panneau "route pour automobile" après
> la premier sortie, où le tag motorroad est fort utile.
>
> Alors, je corrige la page ?
>
> --
> Florimond Berthoux
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Motorroad sur Trunk en France

[marc marc]

Le 25.01.20 à 21:12, Florimond Berthoux a écrit :
> un panneau "route pour automobile" après la premier sortie, 
> où le tag motorroad est fort utile.

pq cette partie n'est pas en highway=trunk ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Message d'erreur d'iD concernant les "points"

[marc marc]

Le 25.01.20 à 21:21, Romain MEHUT a écrit :
> iD râle si un nœud, décrit par exemple comme un commerce,
> est contigu du pourtour d'un bâtiment.

cela me semble une bonne idée, le commerce n'est pas une partie du
contour mais qlq chose dans le batiment.

 Je ne rencontre pas d'erreur avec JOSM

ce serrait une bonne idée à proposer
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Message d'erreur d'iD concernant les "points"

[Romain MEHUT]

Bonsoir à nouveau,

Cette fois il s'agit d'un comportement d'iD qui m'intrigue issu de cette
phrase : "*A “point” created in the iD editor is actually a standalone
“node” with a set of “tags” on it.*" (
https://learnosm.org/en/beginner/id-editor/#adding-points)

Autrement dit, iD râle si un nœud, décrit par exemple comme un commerce,
est contigu du pourtour d'un bâtiment. Je ne rencontre pas d'erreur avec
JOSM. Est-ce une règle spécifique à iD ?

Merci.

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

[OSM-talk-fr] Motorroad sur Trunk en France

[Florimond Berthoux]

Bonsoir,

Je suis tombé sur une phrase qui m'a étonné sur la page de la clé motorroad
du wiki
«France
This tag is not required, just use highway=trunk. »
https://wiki.openstreetmap.org/wiki/Key:motorroad?uselang=fr#France

Et effectivement pas de traduction en français de la page, et sur la page
française de Trunk l'explication du tag est resté en anglais.

Cette phrase me parait assez fausse parce qu'en France une motorroad ça a
un panneau voir
https://fr.wikipedia.org/wiki/Route_pour_automobiles#En_France
Le tag est très utilisé dans le pays des Trunk (Bretagne) et ailleurs.
Et pour ce qui me concerne j'ai l'exemple d'une voie rapide dont un premier
tronçon est cyclable puis un panneau "route pour automobile" après la
premier sortie, où le tag motorroad est fort utile.

Alors, je corrige la page ?

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

[OSM-talk-fr] Ajout de NRO : blocage d'un contributeur à envisager ?

[Romain MEHUT]

Bonsoir,

Je n'aime pas devoir pointer un contributeur en particulier mais en
l'absence de retour de sa part suite à mes remarques, je préfère partager
avec vous l'objet de mon désaccord cf.
https://www.openstreetmap.org/changeset/79965462

Donc ce contributeur ajoute en grand nombre des "NRO". 1ère chose que je
lui ai fait remarquer est qu'il n'y a pas lieu que ces objets aient un tag
name. 2ème chose, il a ajouté des NRO alors que préexistaient des objets
man_made=telephone_office et telecom=central_office et ces tags sont
aujourd'hui dépréciés cf.
https://wiki.openstreetmap.org/wiki/Tag:telecom%3Dexchange Il conviendrait
donc de reprendre les tags des objets existants plutôt qu'en ajouter des
nouveaux.

Et malgré mes remarques, il a continué à contribuer sans en tenir compte ex
: https://www.openstreetmap.org/node/7156119118.

Qu'en pensez-vous ?

Merci.

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

Re: [OSM-talk-fr] Quel tag pour un magasin...

[marc marc]

Le 25.01.20 à 19:28, pepilepi...@ovh.fr a écrit :
> Je l'avais pas vu sur le wiki. Faut l'ajouter ?
> 

ce n'est jamais une mauvaise chose de documenter :)
au pire qlq rajoutera "p'tre pas une bonne idée d'un tag par produit" :p
mais il faudra avoir mieux à proposer, donc y gagnera aussi si cela
arrive :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quel tag pour un magasin...

[pepilepi...@ovh.fr]

Le 25/01/2020 à 14:50, marc marc a écrit :
> Le 25.01.20 à 14:43, pepilepi...@ovh.fr a écrit :
>> ... dont la principale activité est la vente de cartouches d'encre pour
>> imprimantes ?
> je ne suis pas convaincu de la solution d'avoir un type de shoop=* pour
> chaque magasin mono-produit mais il existe shop=printer_ink


Super, merci !

Je l'avais pas vu sur le wiki. Faut l'ajouter ?


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


-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

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

Re: [OSM-talk-fr] Authentification fix-edit

[Jacques Lavignotte]

Le 25/01/2020 à 18:19, deuzeffe via Talk-fr a écrit :

Et comme le jeton est partagé, ça devrait fonctionner. En tout cas, cmçm. 


cmçm parfois et je n'arrive pas à déterminer le contexte.

Pour l'instant je n'ai plus matière..

Merci à toutses <- nouvelle écriture inclusive.


J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

___
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

[deuzeffe]

Ok. Faudrait que ça soit signalé aux diversses administrations qui 
blablatises encore ainsi ;)


Bon, et pour la couche cadastre (par ex.), qui est donc en LO, on 
indique quand même nom, source et millésime, non ?


Le 25/01/2020 à 16:00, Christian Quest a écrit :
Tout ça c'est du bla bla (obsolète), qui de toute façon ne fait que 
reprendre de façon alambiquée les termes de la Loi (ah, ce besoin des 
administrations de faire des phrases... pour reprendre Audiard).


Indiquer quelque part source et millésime suffit, le plus simple étant 
sur le changeset.


Bla bla obsolète vu qu'on y parle d'obtenir une copie sous une forme 
numérique, contre le paiement d'une redevance, ce qui n'est plus légal 
depuis déjà plusieurs années (Loi Valter)... et de droits sui generis 
des bases de données, droit largement supprimé par la Loi Lemaire pour 
celles constituées par les administrations. Rien d'étonnant pour un site 
web optimisé pour du 800x600 ;)



Le 25/01/2020 à 12:53, deuzeffe a écrit :

Ça ressemble à celle mentionnée sur le site du cadastre, non ?
Cf 
https://cadastre.gouv.fr/scpc/html/CU_01_ConditionsGenerales_fr.html?dontSaveLastForward_TOKEN=C1BM-QP7J-85OB-ATJI-GJP6-V5RL-I6D1-TJ7E= 



(mais quelle URL ALC !!!)

Ce qui, d'après Marc-marc relayant la parole de Christian, n'est plus 
d'actualité quant à l'obligation de mettre l'attribution sur le fond 
cadastre... (je ne sais pas s'il s'agit de cette discussion là : 
https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/095969.html 
)




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

Re: [OSM-talk-fr] Authentification fix-edit

[deuzeffe via Talk-fr]

Le 25/01/2020 à 13:40, Jacques Lavignotte a écrit :


You must be logged in order to use the tag editor


Ah oui, faut être connecté.


Login :

La demande d’autorisation a échoué

Le jeton d’autorisation n’est pas valide.

et là je ne sais pas régler l'authentification :(


Tu ne serais pas dans un onglet contextuel par hasard (pire, dans une 
fenêtre de navigation privée) ? Un refus de certains cookies ?


Je suis bien authentifié pour ID 


Et comme le jeton est partagé, ça devrait fonctionner. En tout cas, cmçm.


et JOSM.


Yep, mais pas dans le navigateur ^^
--
deuzeffe

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

Re: [OSM-talk-fr] Bases ULM : sports_centre ?

[osm . sanspourriel]

local_ref=LF5124

Le 25/01/2020 à 13:23, marc marc - marc_marc_...@hotmail.com a écrit :

il y a la piste aeroway=airstrip éventuellement avec une référence (qui
me parait bien étrange pour être locale, locale serrait 1 2 3, ca m'a
plutôt d’être une ref qui est + étendue que locale)


Ce n'est pas la ref IATA 
ni la ICAO ,
donc c'est du local.

1, 2 ce serait ref.

Mais je suis assez d'accord avec toi sauf que c'est bien ainsi dans le wiki.

Ici local = France et comme c'est LF, c'est basé sur un schéma mondial
(code pays ICAO + nombre).

https://wiki.openstreetmap.org/wiki/Aeroways#Codes
local codes: in some countries these have been tagged with local_ref= ;
for example the codes assigned by basulm/ffplum to nearly all fields in
France, of the form LFddnn, with dd standing for the "departement".

Jean-Yvon

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

On peut renvoyer Carmen à la spécif que j'ai trouvée concernant la
conformité INSPIRE:
https://inspire.ec.europa.eu/file/1556/download?token=2IJ7xEJG
(à partir de la page 60)

Ce n'est pas marqué clairement, mais XML 1.1 n'est pas imposé, mais les
espaces de noms spécifiques à Inspire (hors de la norme WMS d'OGC, qui
devrait être en version 1.3 et non plus 1.1.1) devraient être déclarés dans
le XML (de préférence à la racine de l'élément ), ce qui est oublié
par Carmen dans les services web qu'il a confiés à nos offices publics et
qu'il utilise ces espaces dans les contenus de l'élément racine du
document, comme il le fait déjà pour chaque attribut "xlink:*" ou "xsi:*",
bien que cela serait aussi bien de les déclarer seulement à la racine 
que pour chacun des éléments utilisant ces attributs):



http://inspire.ec.europa.eu/schemas/inspire_vs_ows11/1.0”
   xmlns:inspire_vs=“
http://inspire.ec.europa.eu/schemas/inspire_vs_ows11/1.0”
   xmlns:inspire_common=“http://inspire.ec.europa.eu/schemas/common/1.0”
>
...


Il y a un exemple page 63 du PDF INSPIRE ci-dessus.


Le sam. 25 janv. 2020 à 16:18, Philippe Verdy  a écrit :

> J'ajoute que la version 1.1 ou 1.1.1 de WMS est obsolète et son support a
> été retiré des spécifications sur
> https://www.opengeospatial.org/standards/wms
> Bref Carmen n'est pas à jour (pourtant un fix est simple à faire dans les
> XML générés, une ligne en plus dans la DTD et un pseudo-attribut dans
> l'élément racine) !
>
>
> Le sam. 25 janv. 2020 à 16:15, Philippe Verdy  a écrit :
>
>> Il y a le même problème à l'INPN, dont les WMS ne se chargent pas non
>> plus dans JOSM (même exception: préfixe "inspire_vs:" non lié à une
>> déclaration d'espace de nom dans l'élément XML racine, la même DTD incluse
>> ne suffit pas pour XML.
>>
>> Les autres outils SIG (QGIS) utilisent sans doute non pas un parseur XML
>> normal mais un parseur SGML qui se moque des espaces de noms XML (ou un
>> vieux parseur XML avant la standardisation des espaces de noms... alors que
>> le WMS en fait usage pour d'autres espaces de noms comme "xlink:" et
>> "xsi:"), et traite uniquement des noms d'éléments complets (avec leur
>> préfixe inclus, inséparable et non remplaçable comme c'est le cas en XML)
>> déclarés dans la DTD incluse dont XML se moque pas mal.
>>
>>
>> https://inpn.mnhn.fr/telechargement/cartes-et-information-geographique/nat/natura
>>
>>
>> (ce sont les données des ZSC et ZPS transmises à l'Union européenne
>> concernant les zones Natura 2000).
>>
>> JOSM semble vouloir la conformité XML stricte 1.1 publiée en 2004, mais
>> cette façon de faire c'est du vieux XML 1.0 de 1998. C'est pourtant la
>> version 1.0 de XML qui est déclarée dans l'entête WMS. Mais JOSM la lit
>> comme du XML 1.1. En fin de compte c'est peut-être bien un bogue de JOSM.
>>
>> Ceci dit je ne sais pas si la norme WMS impose la conformité XML 1.1
>> (pourtant pas difficile à réaliser : juste un pseudo-attribut xmlns:*=* à
>> ajouter dans la balise racine, et une ligne dans la DTD incluse pour
>> déclarer cet attribut, même s'il a une valeur fixe). Cela semble être le
>> cas pour la version WMS 1.3, mais le même logiciel Carmen utilisé par l'ONF
>> et l'INPN utilise une ancienne version WMS 1.1.
>>
>> Je ne sais pas trop quoi en penser. Dans le cadre Inspire il devrait y
>> avoir une spécification des versions et de la compatibilité requise sur les
>> services ouverts proposés.
>>
>>
>>
>>
>> Le sam. 25 janv. 2020 à 12:53, deuzeffe  a
>> écrit :
>>
>>> Ça ressemble à celle mentionnée sur le site du cadastre, non ?
>>> Cf
>>>
>>> https://cadastre.gouv.fr/scpc/html/CU_01_ConditionsGenerales_fr.html?dontSaveLastForward_TOKEN=C1BM-QP7J-85OB-ATJI-GJP6-V5RL-I6D1-TJ7E=
>>>
>>> (mais quelle URL ALC !!!)
>>>
>>> Ce qui, d'après Marc-marc relayant la parole de Christian, n'est plus
>>> d'actualité quant à l'obligation de mettre l'attribution sur le fond
>>> cadastre... (je ne sais pas s'il s'agit de cette discussion là :
>>>
>>> https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/095969.html
>>> )
>>>
>>> Le 24/01/2020 à 18:27, Vincent Bergeot a écrit :
>>> > Le 24/01/2020 à 15:41, marc marc a écrit :
>>> >> une idée de la licence de cette couche ?
>>> >
>>> > quand on veut télécharger les données on tombe sur un truc long /
>>> >
>>> > Exploitation des fichiers et données
>>> > Sous réserve du respect des droits de propriété intellectuelle qui
>>> leur
>>> > sont attachés, mentionnés dans les métadonnées, les informations mises
>>> à
>>> > disposition peuvent être utilisées par toute personne qui le souhaite
>>> à
>>> > d'autres fins que celles de la mission de service public pour les
>>> > besoins de laquelle elles ont été élaborées ou sont détenues. La
>>> > réutilisation des informations suppose que celles-ci ne soient pas
>>> > altérées, que leur sens ne soit pas dénaturé et que leurs sources et
>>> la
>>> > date de leur dernière mise à jour soient mentionnées (ex : " Source :
>>> > Service xxx, données 2005). Ces 

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

[Philippe Verdy]

J'ajoute que la version 1.1 ou 1.1.1 de WMS est obsolète et son support a
été retiré des spécifications sur
https://www.opengeospatial.org/standards/wms
Bref Carmen n'est pas à jour (pourtant un fix est simple à faire dans les
XML générés, une ligne en plus dans la DTD et un pseudo-attribut dans
l'élément racine) !


Le sam. 25 janv. 2020 à 16:15, Philippe Verdy  a écrit :

> Il y a le même problème à l'INPN, dont les WMS ne se chargent pas non plus
> dans JOSM (même exception: préfixe "inspire_vs:" non lié à une déclaration
> d'espace de nom dans l'élément XML racine, la même DTD incluse ne suffit
> pas pour XML.
>
> Les autres outils SIG (QGIS) utilisent sans doute non pas un parseur XML
> normal mais un parseur SGML qui se moque des espaces de noms XML (ou un
> vieux parseur XML avant la standardisation des espaces de noms... alors que
> le WMS en fait usage pour d'autres espaces de noms comme "xlink:" et
> "xsi:"), et traite uniquement des noms d'éléments complets (avec leur
> préfixe inclus, inséparable et non remplaçable comme c'est le cas en XML)
> déclarés dans la DTD incluse dont XML se moque pas mal.
>
>
> https://inpn.mnhn.fr/telechargement/cartes-et-information-geographique/nat/natura
>
>
> (ce sont les données des ZSC et ZPS transmises à l'Union européenne
> concernant les zones Natura 2000).
>
> JOSM semble vouloir la conformité XML stricte 1.1 publiée en 2004, mais
> cette façon de faire c'est du vieux XML 1.0 de 1998. C'est pourtant la
> version 1.0 de XML qui est déclarée dans l'entête WMS. Mais JOSM la lit
> comme du XML 1.1. En fin de compte c'est peut-être bien un bogue de JOSM.
>
> Ceci dit je ne sais pas si la norme WMS impose la conformité XML 1.1
> (pourtant pas difficile à réaliser : juste un pseudo-attribut xmlns:*=* à
> ajouter dans la balise racine, et une ligne dans la DTD incluse pour
> déclarer cet attribut, même s'il a une valeur fixe). Cela semble être le
> cas pour la version WMS 1.3, mais le même logiciel Carmen utilisé par l'ONF
> et l'INPN utilise une ancienne version WMS 1.1.
>
> Je ne sais pas trop quoi en penser. Dans le cadre Inspire il devrait y
> avoir une spécification des versions et de la compatibilité requise sur les
> services ouverts proposés.
>
>
>
>
> Le sam. 25 janv. 2020 à 12:53, deuzeffe  a
> écrit :
>
>> Ça ressemble à celle mentionnée sur le site du cadastre, non ?
>> Cf
>>
>> https://cadastre.gouv.fr/scpc/html/CU_01_ConditionsGenerales_fr.html?dontSaveLastForward_TOKEN=C1BM-QP7J-85OB-ATJI-GJP6-V5RL-I6D1-TJ7E=
>>
>> (mais quelle URL ALC !!!)
>>
>> Ce qui, d'après Marc-marc relayant la parole de Christian, n'est plus
>> d'actualité quant à l'obligation de mettre l'attribution sur le fond
>> cadastre... (je ne sais pas s'il s'agit de cette discussion là :
>> https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/095969.html
>> )
>>
>> Le 24/01/2020 à 18:27, Vincent Bergeot a écrit :
>> > Le 24/01/2020 à 15:41, marc marc a écrit :
>> >> une idée de la licence de cette couche ?
>> >
>> > quand on veut télécharger les données on tombe sur un truc long /
>> >
>> > Exploitation des fichiers et données
>> > Sous réserve du respect des droits de propriété intellectuelle qui leur
>> > sont attachés, mentionnés dans les métadonnées, les informations mises
>> à
>> > disposition peuvent être utilisées par toute personne qui le souhaite à
>> > d'autres fins que celles de la mission de service public pour les
>> > besoins de laquelle elles ont été élaborées ou sont détenues. La
>> > réutilisation des informations suppose que celles-ci ne soient pas
>> > altérées, que leur sens ne soit pas dénaturé et que leurs sources et la
>> > date de leur dernière mise à jour soient mentionnées (ex : " Source :
>> > Service xxx, données 2005). Ces conditions portent sur l'ensemble des
>> > fichiers livrés, à savoir, les fichiers de données, les métadonnées et
>> > l'avertissement.
>> >
>> > Sont ainsi possible, sous ces conditions, la présentation sur tout
>> > support, y compris sur Internet, des données et métadonnées, ainsi que
>> > toute étude ou analyse résultant de l'exploitation de ces informations.
>> >
>> > L'utilisateur peut également changer le format informatique et adapter
>> > les données et métadonnées pour les intégrer à son propre système
>> > d'information ou les mettre à disposition. Il peut agréger les
>> > informations, ajouter ou supprimer des attributs, sélectionner une
>> > partie du territoire, et réaliser une généralisation géographique. Il
>> > doit alors veiller à respecter scrupuleusement la qualité des données
>> et
>> > à ne pas en dénaturer le sens.
>> >
>> > Toutefois, ces différentes utilisations des données devront tenir
>> compte
>> > des caractéristiques et des limites indiquées dans les métadonnées qui
>> > leur sont associées. Les utilisateurs sont mis particulièrement en
>> garde
>> > contre toute interprétation, utilisation ou présentation des données à
>> > une échelle plus grande que celle indiquée dans les métadonnées, par
>> > 

[OSM-talk-fr] Proposition - RFC - Organisation des lignes aériennes (consécutive à line_attachment)

[François Lacombe]

Salut à tous,

Nouvelle année, nouvelles propositions. Voici celle que je souhaite pousser
en premier.
Elle est formulée dans le cadre du nettoyage de tower:type et d sa
suppression complète des supports électriques.
Expliqué il y a quelques temps dans mon journal :
https://www.openstreetmap.org/user/InfosReseaux/diary/391058

Elle concerne la topologie et l'organisation des lignes aériennes
(électriques mais pas que).
https://wiki.openstreetmap.org/wiki/FR:Proposed_features/Lines_management

La RFC a déjà commencé depuis quelques temps sur la ML internationale, je
viens de finir de traduire en français.
La clé est déjà utilisée à quelques endroits par d'autres utilisateurs.

Il me manque des photos libres de situations comme celle-ci :
https://wiki.openstreetmap.org/wiki/File:Power_line_chart_pole_loop.png
pour compléter les exemples
Si quelqu'un a quelque chose qui ressemble autour de chez lui, je suis
preneur.

Par ailleurs n’hésitez pas à essayer de transcrire ce que vous verriez sur
le terrain avec les valeurs proposées pour s'assurer que tout fonctionne
bien
Auquel cas on pourra compléter les exemples si nécessaire.
Certaines valeurs marchent même pour les remontées mécaniques si vous allez
au ski (tout comme line_attachment=pulley)

Merci par avance pour vos commentaires et bon weekend

François
___
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]

Il y a le même problème à l'INPN, dont les WMS ne se chargent pas non plus
dans JOSM (même exception: préfixe "inspire_vs:" non lié à une déclaration
d'espace de nom dans l'élément XML racine, la même DTD incluse ne suffit
pas pour XML.

Les autres outils SIG (QGIS) utilisent sans doute non pas un parseur XML
normal mais un parseur SGML qui se moque des espaces de noms XML (ou un
vieux parseur XML avant la standardisation des espaces de noms... alors que
le WMS en fait usage pour d'autres espaces de noms comme "xlink:" et
"xsi:"), et traite uniquement des noms d'éléments complets (avec leur
préfixe inclus, inséparable et non remplaçable comme c'est le cas en XML)
déclarés dans la DTD incluse dont XML se moque pas mal.

https://inpn.mnhn.fr/telechargement/cartes-et-information-geographique/nat/natura


(ce sont les données des ZSC et ZPS transmises à l'Union européenne
concernant les zones Natura 2000).

JOSM semble vouloir la conformité XML stricte 1.1 publiée en 2004, mais
cette façon de faire c'est du vieux XML 1.0 de 1998. C'est pourtant la
version 1.0 de XML qui est déclarée dans l'entête WMS. Mais JOSM la lit
comme du XML 1.1. En fin de compte c'est peut-être bien un bogue de JOSM.

Ceci dit je ne sais pas si la norme WMS impose la conformité XML 1.1
(pourtant pas difficile à réaliser : juste un pseudo-attribut xmlns:*=* à
ajouter dans la balise racine, et une ligne dans la DTD incluse pour
déclarer cet attribut, même s'il a une valeur fixe). Cela semble être le
cas pour la version WMS 1.3, mais le même logiciel Carmen utilisé par l'ONF
et l'INPN utilise une ancienne version WMS 1.1.

Je ne sais pas trop quoi en penser. Dans le cadre Inspire il devrait y
avoir une spécification des versions et de la compatibilité requise sur les
services ouverts proposés.




Le sam. 25 janv. 2020 à 12:53, deuzeffe  a écrit :

> Ça ressemble à celle mentionnée sur le site du cadastre, non ?
> Cf
>
> https://cadastre.gouv.fr/scpc/html/CU_01_ConditionsGenerales_fr.html?dontSaveLastForward_TOKEN=C1BM-QP7J-85OB-ATJI-GJP6-V5RL-I6D1-TJ7E=
>
> (mais quelle URL ALC !!!)
>
> Ce qui, d'après Marc-marc relayant la parole de Christian, n'est plus
> d'actualité quant à l'obligation de mettre l'attribution sur le fond
> cadastre... (je ne sais pas s'il s'agit de cette discussion là :
> https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/095969.html
> )
>
> Le 24/01/2020 à 18:27, Vincent Bergeot a écrit :
> > Le 24/01/2020 à 15:41, marc marc a écrit :
> >> une idée de la licence de cette couche ?
> >
> > quand on veut télécharger les données on tombe sur un truc long /
> >
> > Exploitation des fichiers et données
> > Sous réserve du respect des droits de propriété intellectuelle qui leur
> > sont attachés, mentionnés dans les métadonnées, les informations mises à
> > disposition peuvent être utilisées par toute personne qui le souhaite à
> > d'autres fins que celles de la mission de service public pour les
> > besoins de laquelle elles ont été élaborées ou sont détenues. La
> > réutilisation des informations suppose que celles-ci ne soient pas
> > altérées, que leur sens ne soit pas dénaturé et que leurs sources et la
> > date de leur dernière mise à jour soient mentionnées (ex : " Source :
> > Service xxx, données 2005). Ces conditions portent sur l'ensemble des
> > fichiers livrés, à savoir, les fichiers de données, les métadonnées et
> > l'avertissement.
> >
> > Sont ainsi possible, sous ces conditions, la présentation sur tout
> > support, y compris sur Internet, des données et métadonnées, ainsi que
> > toute étude ou analyse résultant de l'exploitation de ces informations.
> >
> > L'utilisateur peut également changer le format informatique et adapter
> > les données et métadonnées pour les intégrer à son propre système
> > d'information ou les mettre à disposition. Il peut agréger les
> > informations, ajouter ou supprimer des attributs, sélectionner une
> > partie du territoire, et réaliser une généralisation géographique. Il
> > doit alors veiller à respecter scrupuleusement la qualité des données et
> > à ne pas en dénaturer le sens.
> >
> > Toutefois, ces différentes utilisations des données devront tenir compte
> > des caractéristiques et des limites indiquées dans les métadonnées qui
> > leur sont associées. Les utilisateurs sont mis particulièrement en garde
> > contre toute interprétation, utilisation ou présentation des données à
> > une échelle plus grande que celle indiquée dans les métadonnées, par
> > exemple à une échelle cadastrale pour un zonage numérisé à 1:25000.
> >
> > Les informations mises à disposition ne sont pas fournies en vue d'une
> > utilisation particulière, et aucune garantie quant à leur aptitude à un
> > usage particulier n'est apportée par le service fournisseur.
> >
> > En conséquence, l'utilisateur apprécie notamment :
> > o l'opportunité d'utiliser les données ;
> > o la compatibilité des fichiers avec ses systèmes informatiques ;
> > o l'adéquation des données à ses besoins ;
> 

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

[Christian Quest]

Tout ça c'est du bla bla (obsolète), qui de toute façon ne fait que 
reprendre de façon alambiquée les termes de la Loi (ah, ce besoin des 
administrations de faire des phrases... pour reprendre Audiard).


Indiquer quelque part source et millésime suffit, le plus simple étant 
sur le changeset.


Bla bla obsolète vu qu'on y parle d'obtenir une copie sous une forme 
numérique, contre le paiement d'une redevance, ce qui n'est plus légal 
depuis déjà plusieurs années (Loi Valter)... et de droits sui generis 
des bases de données, droit largement supprimé par la Loi Lemaire pour 
celles constituées par les administrations. Rien d'étonnant pour un site 
web optimisé pour du 800x600 ;)



Le 25/01/2020 à 12:53, deuzeffe a écrit :

Ça ressemble à celle mentionnée sur le site du cadastre, non ?
Cf 
https://cadastre.gouv.fr/scpc/html/CU_01_ConditionsGenerales_fr.html?dontSaveLastForward_TOKEN=C1BM-QP7J-85OB-ATJI-GJP6-V5RL-I6D1-TJ7E=


(mais quelle URL ALC !!!)

Ce qui, d'après Marc-marc relayant la parole de Christian, n'est plus 
d'actualité quant à l'obligation de mettre l'attribution sur le fond 
cadastre... (je ne sais pas s'il s'agit de cette discussion là : 
https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/095969.html 
)



--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Authentification fix-edit

[marc marc]

Le 25.01.20 à 13:40, Jacques Lavignotte a écrit :
> You must be logged in order to use the tag editor
> 
> Login :
> 
> La demande d’autorisation a échoué

sur la barre du menu, dernière élément "Connexion"
te renvoi vers https://osmose.openstreetmap.fr/fr/login
qui te renvois vers osm.org pour valider qu'osmose peux modifier les
données avec ton compte
c'est à quel moment que cela ne fonctionne pas ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quel tag pour un magasin...

[marc marc]

Le 25.01.20 à 14:43, pepilepi...@ovh.fr a écrit :
> 
> ... dont la principale activité est la vente de cartouches d'encre pour
> imprimantes ?

je ne suis pas convaincu de la solution d'avoir un type de shoop=* pour
chaque magasin mono-produit mais il existe shop=printer_ink
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Quel tag pour un magasin...

[pepilepi...@ovh.fr]

... dont la principale activité est la vente de cartouches d'encre pour
imprimantes ? L'équivalent physique de https://www.francetoner.fr/, en
quelque sorte.

J'en ai déjà vu plusieurs et c'est sacrément pratique
!, mais je ne vois pas de tag approprié.

  * shop=computer et computer:parts, non, ça va vraiment pas.
  * shop=stationery... Bin... non, mon p'tit magasin y vend QUE des
cartoiuches d'encre, on n'y trouve pas la moitié d'un seul stylo...

Des idées ?

Merci,

Jean-Pierre

-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

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

Re: [OSM-talk-fr] Fix-josm et fix-edit

[Philippe Verdy]

fix-josm est plus prudent que fix-edit quand c'est une relation
frontalière, à mois que la modif soit un simple tag et ne touche pas à la
géométrie (exemple way manquant ou autointersection qu'il faut corriger
sans casser le reste qui peut utiliser une partie commune de la géométrie,
même si ce ne sont que des noeuds et pas des ways,).
Ceci dit il faut être habitué à l'autre éditeur, JOSM et iD ne s'utilisent
pas du tout de la même façon, puisque JOSM ne charge pas tout dans la zone,
et qu'il faut aussi faire des chargements à la demande, notamment
CTRL+ALT+D pour les dépendances des ways et noeuds, alors que iD charge
tout ce qui est dans la zone d'affichage... en principe, et ça limite
fortement les modifs qu'on doit faire sur les grands objets qui ne tiennent
pas entier à l'écran)
La plupart des signalements Osmose proposant des "fix-*" sont pour les tags
seulement, mais l'automatisme essaye de deviner ce qui pourrait être une
config correcte à partir de ce qui semble renseigné, mais comme il détecte
déjà une erreur ou ambiguïté possible, il faut quand même vérifier et pas
appliquer bêtemetn les fix qui ne sont que suggérés (il peut y avoir
d'autres solutions surtout si à la base les tags utilisés par Osmose
étaient carrément faux.
Osmose peut aussi être trop pointilleux ou se tromper dans les suggestions
concernant les name=* et notamment l'orthographe: il se base sur un
dictionnaire pour les cas courants, seulement mais ne connait pas tous les
particularismes locaux, y compris la capitalisation de certains sigles
qu'il pourraient confondre avec des mots communs, et les noms
d'organisations et marques quand il n'y a pas non plus de référence SIREN
pour faire le lien facilement avec la base SIREN ouverte et publique ou un
encore plus rarement un numéro RCS ; une vérification peut consister à
chercher cette société ou marque dans un annuaire, vérifier l'existence de
leur propre site web s'il est indiqué, et le visiter, c'est souvent plus à
jour que les annuaires de tiers ; et ne pas se laisser berner par la
typographie des titres et logos, regarder plutôt leurs page "contact/infos
éditeur/vie privée" et autres mentions légales, on devrait y trouver les
codes RCS et SIREN et retrouver l'inscription officielle pour les noms de
sociétés, ou l'inscription INPI pour les marques et enseignes).
Les bases publiques peuvent aussi se contredire entre elles, et souvent la
capitalisation et l'accentuation est le cadet de leur soucis, les panneaux
sur le terrain, l'adresse postale, et même les factures, tickets de caisse
ou devis n'aident pas toujours non plus quand les noms sont écrits
entièrement en capitales. Dans ce cas c'est juste une question de bon sens,
le libellé doit rester clair, non ambigu, facilement lisible.

Le sam. 25 janv. 2020 à 13:11, deuzeffe  a écrit :

> Le 24/01/2020 à 22:56, Jacques Lavignotte a écrit :
>
> >>> fix-edit, je suppose que ça fait la même chose.
> >>
> >> Voui, mais sans sortir du frontend osmose. Extrêmement pratique pour
> >> corriger les erreurs minimes (orthographe, rajout de source, etc.)
> >>
> >> Tiens, Jacques, essaie-le avec ça :
> >>
> https://osmose.openstreetmap.fr/fr/map/?#zoom=13=45.694=1.0198=5xxx=1%2C2%2C3==
> >
> > J'ai un peu cherché dans JOSM avant de voir qu'il faut « Fichier /
> > mettre à jour les modifications » avant d'envoyer
> >
> > Est-ce bien celà ?
>
> Je n'utilise _jamais_ fix-josm ^^ Je voulais que tu regardes comment on
> se sert de fix-edit pour des trucs simples (oui, quitte à le retrouver
> avec des avalanches de signalements parce qu'on n'a pas fait toutes les
> corrections nécessaires sur l'objet).
>
> --
> deuzeffe - des fois, c'est rapide et des fois, pas.
>
> ___
> 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] Authentification fix-edit

[Jacques Lavignotte]

Le 25/01/2020 à 13:11, deuzeffe a écrit :

Le 24/01/2020 à 22:56, Jacques Lavignotte a écrit :


Je n'utilise _jamais_ fix-josm ^^ Je voulais que tu regardes comment on 
se sert de fix-edit pour des trucs simples (oui, quitte à le retrouver 
avec des avalanches de signalements parce qu'on n'a pas fait toutes les 
corrections nécessaires sur l'objet).


J'en ai fait quelques unes avec fix-josm que je trouve bien commode pour 
corriger certaines de mes erreurs :( Donc je m'attends à un déluge ;)



Par ailleurs je n'arrive pas à faire marcher fix-edit :

You must be logged in order to use the tag editor

Login :

La demande d’autorisation a échoué

Le jeton d’autorisation n’est pas valide.

et là je ne sais pas régler l'authentification :(

Je suis bien authentifié pour ID et JOSM.

Help !

Merci, Jacques

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)


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

Re: [OSM-talk-fr] Osmose : Erreur sur remplacement clés "ref" sur réseaux de transports en commun

[leni]

Le 22/12/2019 à 10:15, marc marc a écrit :

Le 21.12.19 à 22:29, deuzeffe a écrit :

Ce qui m'amène à une question de béotienne (éternelle) mais plus
générale : doit-on (ou jusqu'où doit-on) préciser/affiner les ref:FR
pour les réseaux de transport ?

je pense que cela n'apporte que des désavantages :
- l'exemple du réseau arc en ciel montre que croire qu'une ref:FR est
unique est une erreur.


Ah bon ? explique moi  ... (comme indiqué deux messages au-dessus 
ref:FR:aec31)  peut-être mal construit mais pas unique ?


Je ne suis pas ...cien (ni base de données ni cartographe) simple 
contributeur (je ne comprends parfois pas grand chose - par exemple 
"espace de nom" j'ai cherché sur internet et c'est devenu encore plus 
incompréhensible ) et pour une bonne partie ma référence c'est le wiki 
où on peut voir pas quelques réseau de bus dans ce cas avec ref:* (et 
pas qu'en France 
(https://www.openstreetmap.org/node/2619430580#map=20/50.84947/4.34751=T) 
et pas que pour les réseaux de transport ...



donc si on voulait une clef unique, il faudrait aller encore plus loin
ref:pays:region voir commune
- tout utilisateur voulant ajouter une ref doit trouver un exemple bien
tagé à proximité ou trouver la page wiki ad-hoc.
Oui, il faudrait une page, aujourd'hui, il y en a deux 
https://wiki.openstreetmap.org/wiki/France/Liste_des_r%C3%A9f%C3%A9rences_nationales 
et https://wiki.openstreetmap.org/wiki/FR:Key:ref qui ne semblent pas 
être identiques et il y a des manques.

- cela implique aussi automatiquement qu'il y aura des ref dans des
mauvaises clefs, donc un travail conséquent de maintenance à faire.
- niveau utilisation des données, cibler les arrêts d'une route d'un
operateur est aussi facile que cibler ref:FR:...
Si tu dis que c'est aussi facile ... , sûrement pour vous qui gérez tout 
ensemble (les arrêts et les itinéraires) en tout cas, pas pour moi qui 
suis plutôt intéressé par les arrêts que par les itinéraires (que je ne 
vois pas quand je me balade -mais que je mets à jour de temps en temps, 
j'y passe trop de temps d'ailleurs) et maintenant j'ai plus de mal à les 
retrouver depuis qu'on ne leur indique plus le network et en plus 
jungleBus dans josm et osmose me crient dessus parce que mes arrêts ne 
sont rattachés à aucun itinéraire ...

- à côté de cela, pour une route, la ref se met dans ref, tant à
Marseille ou à Genève.
Oui, il n'y a pas souvent des routes qui ont un n° national, un régional 
et un local

pour les arrêts multi-opérateurs, une règle simple pourrait s'inspirer
des routes :
- la ref du réseau local du lieu -> ref=*
- la ref du réseau régional reg_ref=*
il ne resterait alors que des exeptions, quand un arrêt se trouve en
bordure de 2 réseaux locaux.
pour ceux là, ref:=* avec  valant exactement la
même chose que la clef operator=* de la relation route simplifierait
bien des choses.


Une structuration serait sans doute mieux, mais pas, il me semble, en 
limitant à reg_ si c'était aussi facile ...  , car Il ne faut pas 
oublier que :
- le réseau régional n'a pas encore mis -partout- d'open-data, il n'y a 
pas un seul réseau régional, actuellement la Haute-Garonne a un 
open-data avec des données pour le réseau régional du département et un 
des données pour le réseau des transports scolaires régionaux du 
département avec des n° d'arrêts différents entre les deux réseaux, 
comment je différencie reg_ref=* et reg_ts_ref ?
- les réseaux métropolitains, les réseaux de regroupements de communes 
(en Haute-Garonne prés de toulouse, les deux type co-existaient avec des 
arrêts communs, puis le réseau de la métropole s'est agrandi en 
absorbant les réseaux des regroupements et ceux de certaines communes 
mitoyennes.
- ces réseaux métropolitains/regroupements ne sont pas forcément les 
réseaux locaux, je connais au moins une commune de la métropole qui a 
crée un TAD local qui s'adresse aux habitants des quartiers les moins 
bien desservis par les transports en commun de la métropole

- et j'oublie certainement d'autres choses

mais je rêve d'un n° unique BATO ???

cordialement

leni


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

Re: [OSM-talk-fr] Bases ULM : sports_centre ?

[marc marc]

Le 25.01.20 à 13:07, deuzeffe a écrit :
> on fait comment pour renseigner qu'un tel terrain permet la
> pratique de l'ULM (à part sans le name=*) ?

séparer les 2 pour éviter la confusion du lieu global, de la piste et de
ce qui s'y passe

il y a la piste aeroway=airstrip éventuellement avec une référence (qui
me parait bien étrange pour être locale, locale serrait 1 2 3, ca m'a
plutôt d’être une ref qui est + étendue que locale)

s'il y a une base, alors c'est plus qu'une piste, c'est piste + route
d'accès + hangard + p'tre un local pour le public ou une buvette + p'tre
un parking. c'est le tout qui forme la base avec un polygone ou un noeud
si on connait mal l'étendue.

ou alors ce n'est pas une base dédié mais un club sportif qui utilise
une partie d'un aérodrome. alors plutôt un nœud, par exemple dans leur
hangar club=sport + sport=*
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fix-josm et fix-edit

[deuzeffe]

Le 24/01/2020 à 22:56, Jacques Lavignotte a écrit :


fix-edit, je suppose que ça fait la même chose.


Voui, mais sans sortir du frontend osmose. Extrêmement pratique pour 
corriger les erreurs minimes (orthographe, rajout de source, etc.)


Tiens, Jacques, essaie-le avec ça : 
https://osmose.openstreetmap.fr/fr/map/?#zoom=13=45.694=1.0198=5xxx=1%2C2%2C3== 


J'ai un peu cherché dans JOSM avant de voir qu'il faut « Fichier / 
mettre à jour les modifications » avant d'envoyer


Est-ce bien celà ?


Je n'utilise _jamais_ fix-josm ^^ Je voulais que tu regardes comment on 
se sert de fix-edit pour des trucs simples (oui, quitte à le retrouver 
avec des avalanches de signalements parce qu'on n'a pas fait toutes les 
corrections nécessaires sur l'objet).


--
deuzeffe - des fois, c'est rapide et des fois, pas.

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

[OSM-talk-fr] Bases ULM : sports_centre ?

[deuzeffe]

Bonjour,

À la suite de correction orthotypo., osmose me remonte des signalements 
pour des conflits d'attributs, sur des bases ULM, en particulier (par 
ex. https://www.openstreetmap.org/node/3702778707 )


Les tags sont les suivants :
aeroway=airstrip
leisure=sports_centre
local_ref=LF5124
name=Base ULM Reims Concept ULM
sport=ultralight_aviation

Frédéric me confirme que l'on ne peut pas les considérer comme des 
sports_centre (https://github.com/osm-fr/osmose-backend/issues/743 )

Soit.

Mais sport=* ne doit pas être utilisé seul (sans leisure=sports_centre 
ou équivalent).

Ok.

Donc, on fait comment pour renseigner qu'un tel terrain permet la 
pratique de l'ULM (à part sans le name=*) ?


Merci pour vos lumières.
--
deuzeffe - corriger les typo. dans la doc., c'est moins risqué

___
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

[deuzeffe]

Ça ressemble à celle mentionnée sur le site du cadastre, non ?
Cf 
https://cadastre.gouv.fr/scpc/html/CU_01_ConditionsGenerales_fr.html?dontSaveLastForward_TOKEN=C1BM-QP7J-85OB-ATJI-GJP6-V5RL-I6D1-TJ7E=


(mais quelle URL ALC !!!)

Ce qui, d'après Marc-marc relayant la parole de Christian, n'est plus 
d'actualité quant à l'obligation de mettre l'attribution sur le fond 
cadastre... (je ne sais pas s'il s'agit de cette discussion là : 
https://lists.openstreetmap.org/pipermail/talk-fr/2020-January/095969.html 
)


Le 24/01/2020 à 18:27, Vincent Bergeot a écrit :

Le 24/01/2020 à 15:41, marc marc a écrit :

une idée de la licence de cette couche ?


quand on veut télécharger les données on tombe sur un truc long /

Exploitation des fichiers et données
Sous réserve du respect des droits de propriété intellectuelle qui leur 
sont attachés, mentionnés dans les métadonnées, les informations mises à 
disposition peuvent être utilisées par toute personne qui le souhaite à 
d'autres fins que celles de la mission de service public pour les 
besoins de laquelle elles ont été élaborées ou sont détenues. La 
réutilisation des informations suppose que celles-ci ne soient pas 
altérées, que leur sens ne soit pas dénaturé et que leurs sources et la 
date de leur dernière mise à jour soient mentionnées (ex : " Source : 
Service xxx, données 2005). Ces conditions portent sur l'ensemble des 
fichiers livrés, à savoir, les fichiers de données, les métadonnées et 
l'avertissement.


Sont ainsi possible, sous ces conditions, la présentation sur tout 
support, y compris sur Internet, des données et métadonnées, ainsi que 
toute étude ou analyse résultant de l'exploitation de ces informations.


L'utilisateur peut également changer le format informatique et adapter 
les données et métadonnées pour les intégrer à son propre système 
d'information ou les mettre à disposition. Il peut agréger les 
informations, ajouter ou supprimer des attributs, sélectionner une 
partie du territoire, et réaliser une généralisation géographique. Il 
doit alors veiller à respecter scrupuleusement la qualité des données et 
à ne pas en dénaturer le sens.


Toutefois, ces différentes utilisations des données devront tenir compte 
des caractéristiques et des limites indiquées dans les métadonnées qui 
leur sont associées. Les utilisateurs sont mis particulièrement en garde 
contre toute interprétation, utilisation ou présentation des données à 
une échelle plus grande que celle indiquée dans les métadonnées, par 
exemple à une échelle cadastrale pour un zonage numérisé à 1:25000.


Les informations mises à disposition ne sont pas fournies en vue d'une 
utilisation particulière, et aucune garantie quant à leur aptitude à un 
usage particulier n'est apportée par le service fournisseur.


En conséquence, l'utilisateur apprécie notamment :
o l'opportunité d'utiliser les données ;
o la compatibilité des fichiers avec ses systèmes informatiques ;
o l'adéquation des données à ses besoins ;
o s'il dispose de la compétence suffisante pour utiliser les 
informations mises à disposition.


L'utilisateur veille à vérifier que l'actualité des informations mises à 
disposition est compatible avec chaque usage qu'il en fait.
Il est invité à informer le service mettant les informations à 
disposition des erreurs et anomalies qu'il pourrait éventuellement 
relever dans ces informations, ce service restant libre d'apprécier la 
suite à donner à ce signalement.




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

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

[Philippe Verdy]

En tout cas ça ne peut pas être défini à highway=turning_circle sur le way
(ce n'est défini que sur un noeud d'extrémité, éventuellement connecté à
d'autres chemins)
highway=servive semble le mieux étant donné l'accès résidentiel connecté
dessus et le fait que les bus les utilise.
Tu peux toujours rajouter surface=unpaved (bien que ça me semble plutôt
surface=compacted, sinon les bus ne pourraient pas passer dessus
régulièrement sans former des ornières, ce n'est pas un chemin de terre ou
une trace dans la pelouse, c'est au moins empierré et compacté, même s'il y
a un peu de terre dedans ou un peu d'herbe pousse dessus, et pas non plus
un "track" agricole ou industriel, alors que c'est un usage régulier des
bus et véhicules, piétons et sans doute aussi cyclistes, et aucune
restriction).
La question c'est plutôt: highway=service ou residential? Je penche pour
service car il n'y a plus rien d'autre connecté desservi que la voie de
service privée vers le nord, l'usage des bus , et sinon les chemins piétons
vers la forêt , il n'y a pas d'arrêt aménagé possible, même pas de
stationnement latéral, c'est juste fait pour faire demi-tour autour de
l'îlot.
Et aussi le nom de la rue doit être ramené dessus: c'est bien une voie
publique (pour les bus et sinon les marcheurs vers la forêt), et l'allée
privée vers le nord est aussi à l'adresse de cette rue.


Le ven. 24 janv. 2020 à 07:53, Arnaud Champollion <
arnaud.champoll...@linux-alpes.org> a écrit :

> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fix-josm et fix-edit

[pepilepi...@ovh.fr]

Le 24/01/2020 à 22:56, Jacques Lavignotte a écrit :
>
>
> Le 24/01/2020 à 22:38, deuzeffe a écrit :
>
> Bonsoir deuzeffe
>
>> Le 24/01/2020 à 22:14, pepilepi...@ovh.fr a écrit :
>
> Bonsoir pepilepioux
>
>>> josm : ça charge dans JOSM l'élément concerné tel qu'il est lu dans
>>> la base, à toi de faire ensuite les modifs.
>>>
>>> fix-josm : ça charge dans JOSM l'élément concerné PUIS ça lui
>>> applique dans JOSM la correction indiquée en vert. T'as plus qu'à
>>> envoyer !
>>>
>>> fix-edit, je suppose que ça fait la même chose.
>>
>> Voui, mais sans sortir du frontend osmose. Extrêmement pratique pour
>> corriger les erreurs minimes (orthographe, rajout de source, etc.)
>>
>> Tiens, Jacques, essaie-le avec ça :
>> https://osmose.openstreetmap.fr/fr/map/?#zoom=13=45.694=1.0198=5xxx=1%2C2%2C3==
>>
>>
>> (je pense que le lien fonctionne correctement...)
>
> Il fonctionne.
>
> J'ai un peu cherché dans JOSM avant de voir qu'il faut « Fichier /
> mettre à jour les modifications » avant d'envoyer


Oui, en effet...

En fait, je ne fais JAMAIS de correction pure et simple, brute, depuis
Osmose, je fais toujours aussi une correction de géométrie ou de
position. Par exemple pour les "Poste transformateur électrique mineur
non intégré" je recopie le point proposé par Osmose sur le bâtiment ou
l'armoire de rue que j'ai vu ou qui est déjà présent dans OSM en tant
que "building=yes".

Donc JOSM détecte qu'il y a eu une modif, et il envoie toutes les modifs.


>
> Est-ce bien celà ?
>
> Merci, Jacques
>
>

-- 


Si ma réponse n'a pas résolu ton problème, c'est que tu n'as pas posé la
bonne question.

___
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

[Vincent Bergeot]

Le 25/01/2020 à 09:34, Christian Quest a écrit :

Le 24/01/2020 à 18:27, Vincent Bergeot a écrit :

Le 24/01/2020 à 15:41, marc marc a écrit :

une idée de la licence de cette couche ?


quand on veut télécharger les données on tombe sur un truc long /
[]


Ceci correspond donc globalement à la Licence Ouverte.


il me semble aussi mais je me sens rassuré de te voir l'écrire.

Vérifiez juste dans les métadonnées qu'il n'est pas fait mention de 
droits de propriété intellectuelle de tiers...


voici le lien de téléchargement (environ 5Mo) reçu pour la plus belle 
région de france : 
http://tele.carmencarto.fr/DOWNLOADS/rdf_pub.frt_reg75_1579886482_6349.zip


Je ne comprends rien aux fichiers, si vous y lisez quelques choses de 
compréhensible, je suis intéressé à la fois par le contenu mais aussi 
comment vous avez ouvert les divers fichiers !


à plus

--
Vincent Bergeot


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

Re: [OSM-talk-fr] Accès à Osmose

[Frédéric Rodrigo]

Le 25/01/2020 à 10:19, Jacques Lavignotte a écrit :

Bonjour,

L'accès à http://osmose.openstreetmap.fr/ est souvent très lent.

Y'a t-il des horaires de tâches programmées où le serveur est plus 
chargé ?


Merci

J.


Il y a des taches en continues

http://munin.openstreetmap.fr/buildbot-day.html


Par contre quand il y a en plus un autovacuum de la base c'est plus lent

http://munin.openstreetmap.fr/osm28.openstreetmap.fr/osm153.openstreetmap.fr/postgres_autovacuum.html

On a bien améliorer les choses, il n'y en a plus en continue, et la 
dernier grosse modif pour ça est encore en cours de mise en place dans 
la base de données.




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

[OSM-talk-fr] Accès à Osmose

[Jacques Lavignotte]

Bonjour,

L'accès à http://osmose.openstreetmap.fr/ est souvent très lent.

Y'a t-il des horaires de tâches programmées où le serveur est plus chargé ?

Merci

J.

--
GnuPg : 156520BBC8F5B1E3 Because privacy matters.
« Quand est-ce qu'on mange ? » AD (c) (tm)

___
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

[Christian Quest]

Le 24/01/2020 à 18:27, Vincent Bergeot a écrit :

Le 24/01/2020 à 15:41, marc marc a écrit :

une idée de la licence de cette couche ?


quand on veut télécharger les données on tombe sur un truc long /

Exploitation des fichiers et données
*Sous réserve du respect des droits de propriété intellectuelle qui 
leur sont attachés, mentionnés dans les métadonnées*, les informations 
mises à disposition peuvent être utilisées par toute personne qui le 
souhaite à d'autres fins que celles de la mission de service public 
pour les besoins de laquelle elles ont été élaborées ou sont détenues. 
La réutilisation des informations suppose que celles-ci ne soient pas 
altérées, que leur sens ne soit pas dénaturé et que leurs sources et 
la date de leur dernière mise à jour soient mentionnées (ex : " Source 
: Service xxx, données 2005). Ces conditions portent sur l'ensemble 
des fichiers livrés, à savoir, les fichiers de données, les 
métadonnées et l'avertissement.


Sont ainsi possible, sous ces conditions, la présentation sur tout 
support, y compris sur Internet, des données et métadonnées, ainsi que 
toute étude ou analyse résultant de l'exploitation de ces informations.


L'utilisateur peut également changer le format informatique et adapter 
les données et métadonnées pour les intégrer à son propre système 
d'information ou les mettre à disposition. Il peut agréger les 
informations, ajouter ou supprimer des attributs, sélectionner une 
partie du territoire, et réaliser une généralisation géographique. Il 
doit alors veiller à respecter scrupuleusement la qualité des données 
et à ne pas en dénaturer le sens.


Toutefois, ces différentes utilisations des données devront tenir 
compte des caractéristiques et des limites indiquées dans les 
métadonnées qui leur sont associées. Les utilisateurs sont mis 
particulièrement en garde contre toute interprétation, utilisation ou 
présentation des données à une échelle plus grande que celle indiquée 
dans les métadonnées, par exemple à une échelle cadastrale pour un 
zonage numérisé à 1:25000.


Les informations mises à disposition ne sont pas fournies en vue d'une 
utilisation particulière, et aucune garantie quant à leur aptitude à 
un usage particulier n'est apportée par le service fournisseur.


En conséquence, l'utilisateur apprécie notamment :
o l'opportunité d'utiliser les données ;
o la compatibilité des fichiers avec ses systèmes informatiques ;
o l'adéquation des données à ses besoins ;
o s'il dispose de la compétence suffisante pour utiliser les 
informations mises à disposition.


L'utilisateur veille à vérifier que l'actualité des informations mises 
à disposition est compatible avec chaque usage qu'il en fait.
Il est invité à informer le service mettant les informations à 
disposition des erreurs et anomalies qu'il pourrait éventuellement 
relever dans ces informations, ce service restant libre d'apprécier la 
suite à donner à ce signalement.




Ceci correspond donc globalement à la Licence Ouverte.

Vérifiez juste dans les métadonnées qu'il n'est pas fait mention de 
droits de propriété intellectuelle de tiers...


--
Christian Quest - OpenStreetMap France

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