Re: [OSM-talk-fr] Noms des quartiers en ville postal_code)

2020-08-17 Par sujet Philippe Verdy 
Le mer. 1 juil. 2020 à 20:06,  a écrit :

> J'ai vérifié : il existe une réalisation de ce formatage en PHP, donc si
> vous pensez que c'est intéressant un petit +1 sur
>
> https://github.com/osm-search/Nominatim/issues/213#issuecomment-652466541
>
> Je vois une scorie d'une ancienne version anglaise qui est présente sur la
> page FR:Key:place  :
> postal_code  Text [image:
> nœud]  [image: chemin]
>  [image: zone]
>  Code postal. (Lui préférer
> addr:postcode =*)
>
> Or la pratique en France (sauf par Philippe !) c'est d'utiliser comme
> ailleurs dans le monde postal_code
>  sur les communes et
> et de réserver les addr:* aux adresses.
>

C'est une pseudo-règle qui n'existe pas en France: les communes n'ont
elles-même pas de code postal propre puisqu'elles se les partage à
plusieurs (très souvent) et peuvent aussi en avoir plusieurs (pour les
communes importantes ou dans le territoire n'est pas entièrement desservi
par la poste sur la base des limites territoriales (exemple des propriétés
frontalières qui ne sont desservies que depuis une rue/route d'une autre
commune, la connexion entre les deux étant par des chemins privés).

L'association aussi des rues avec les communes c'est le code FANTOIR et là
aussi une même rue peut avoir plusieurs codes FANTOIR pour la même section,
ou des codes différents pour des sections différentes. quand la rue
transite par plusieurs communes ou oscille de l'une à l'autre. Chaque
FANTOIR comporte son nom propre attribué par la commune correspondante,
mais on ne le retrouve pas toujours comme nom sur le terrain car la voie
publique peut même ne pas avoir du tout d'intersection sur la commune
concernée, même si elle est l'unique accès public aux propriétés concernées
qui sont sur l'autre commune. De fait les points d'adresse ne sont pas
simples à associer aux rues.

Les codes postaux en revanche suivent la topologie des voies publiques pour
des raisons de facilité de distribution postale, sans tenir compte des
limites territoriales adminsitratives (et donc pas non plus du FANTOIR.

Alors que faire; on a deux tags historiques issus de
propositions différentes toutes apprrouvées ou massivement utilisées "de
facto": postal_code=* (qui est ue redondance introduite de façon très mal
faite comme tag "informatif" mais souvent faux pour les communes. Il ne
marche pas) et addr:postcode=* qui lui a été étudié spécifiquemetn pour les
adresses du shcéma général des adresses (totalement indépendant du
découpage administratif, comme c'est bien le cas en France, mais aussi chez
la pluaprt de nos voisins, y compris en Allemagne où le schéma dit de
Karksruhe a été défini et approuvé, utilisé aussi en Belgique et ailleurs).

Il a fallu du temps pour qu'en France on se mette aussi à avoir des
relations "boundary" pour les zones postales (comme cela a été fait bien
avant en Allemagne et Belgique). Mais maintenant c'est en place.
La question est plutôt: doit-on garder encore mention des codes
postaux dans les relations communales ? A mon vis non, c'est une redondance
qui marche mal et en fait est devenu plus gênant qu'utile.

Quel tag utiliser en revanche pour les relations "boundary" des zones
postales: la logique voudrait qu'on y mette aussi les tags "addr:*" du
schéma de Karlsruhe. Mais pour l'isntant aucune décision d'unification n'a
eu lieu.

Je n'ai pas de préférence pour une solution ou une autre. On trouve les
deux tags en France (issus de diférents imports ou différents
contibuteurs individuels), les deux tags sont à considérer comme
équivalents et ne devraient pas être différents s'ils sont renseignés
simultanément. S'ils sont identiques, Un d'eux est redondants mais il y a
aussi des tags liés comme "source:addr:postcode" ou "source:postal_code"
qui doivent "matcher" le tag correspondant: si on supprime un tag
"redondant" en laissant le mauvais "source=*", on a des warnings sur une
sources d'un tag inexistant. Il faut juste être cohérent. J'ai juste pris
le décision de minimiser l'impact des changements tout en réduisant le
nombre de "warnings" de validation (car quand on en a trop, on ne voit pas
les autres plus importants que ceux-là qui sont somme toutes mineurs). Je
n'ai pas pris de décision d'unification.

La seule chose calire est qu'on a des tags "addr:*:=*" pour les **noeuds**
POI; mais que souvent on n'y rensigne pas grand chose, à peine un numéro
parfois un nom de rue, mais toujours pas de décision pour éliminer les
autres champs.

En particulier la solution des relations "associatedStreet" n'est toujours
pas prise, et n'est utilisée "en masse" mais partiellement qu'en France.
Ailleurs, les "associatedStreet" sont très critiquées

Re: [OSM-talk-fr] ref:fr vers site http://t4t35.fr/Megalithes/

2020-08-17 Par sujet Yves P. 
>
> Normalement il a été intégré à josm non ?
>
> Oui c'est ça
(les explications étaient là pour rapeller l'historique )

Ce que je souhaite, c'est d'avoir des données cohérentes
>
Parfait

> mais outre le fait d'avoir des risques de coupure en cas de non
> fonctionnement de wikidata
>
On peut mettre ces description dans OSMdata (data items)

> je n'ose imaginer le travail s'il fallait dupliquer tous les arrêts de bus
> dans wikidata ...
>
Ce n'est pas une obligation, d'ailleurs c'est même débile de tout avoir en
double.

> dans osm, j'ai trouvé
>
> 10231 objets avec site_type=megalith
> dont 2 031 avec wikidata=*
> 1 277 avec wikipedia=*
>
Si il y a une page Wikipedia, elle a forcément un élément wikidata.

Tu as le choix de mettre les identifiants soit dans OSM, doit dans les
éléments wikidata existants et déjà référencés dans OSM.

> des ref et des name avec diverses formes de t4t35
> 263 avec ref:t4t35.fr=*
> 5 avec ref:t4t35=*
> 2 avec ref=t4t35.fr*
> 2 avec ref:fr=t4t35.fr *
> 206 name:t4t35.fr=*
> 20 name:T4T35.fr =*
> 1 avec name:t4t35=*
> 20 avec website=http://www.t4t35.fr/Megalithes/AfficheSite.aspx?NumSite=*
>

ref:fr:xyz bof car même si t4t35 est hébergé en France, il traite des
megalithes quelque soit le pays.
Idem pour megalithic.co.uk

Si je dois créer une clé dans OSM autant la faire simple à saisir :
ref:t4t35
ref:megalithic

Autre critère à prendre en compte. Est-ce qu'il y a des applications
existantes qui utilisent ces identifiants ?
(Dans OSM et ou Wikidata)

Si non, tu fais ce que tu veux.
Si oui, il faut garder les clés quelles utilisent, ou au moins en discuter
avec leurs auteurs.

> 5 avec ref=megalithic.co.uk * (qui devrait logiquement) plutôt être ref:**
>
Oui

> 64 avec website=https://www.megalithic.co.uk/article.php?sid=*
>
Tu peux les remplacer à terme par ref:xyz=1234

6 avec source=http://www.t4t35.fr/Megalithes/AfficheSite.aspx?NumSite=*
> 2 avec source=https://www.megalithic.co.uk/article.php?sid=*
>
Si il n'y a pas de ref:xyz=* tu à termes peux l'ajouter

Il me semble qu'il faudrait ne conserver qu'une ref:* de chaque type et
> peut-être la décrire dans le wiki.
>
Oui et la décrire systématiquement

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

Re: [OSM-talk-fr] Nouvelles orthos HR... trouvées au fond d'un FTP

2020-08-17 Par sujet Percherie OnDaNet 

Merci les gars ;-)

ça fonctionne nickel. Reste à tester avec Vespucci dès que j'ai le temps 
(sauf si vous m'indiquez que ça ne fonctionnera pas avec)


Le 17/08/2020 à 11:29, Christian Quest a écrit :

Le 17/08/2020 à 11:19, Percherie OnDaNet a écrit :

Question à deux centimes d'un bouley de passage ;-p


Je n'arrive pas à trouver la couche "tous_fr" dans les préférence 
d'imagerie josm ou sur le wiki dédié : 
https://josm.openstreetmap.de/wiki/Maps


Où puis-je le trouver ?


Elle n'y est pas listée.

Tu peux prendre "orthohr" qui agrège les différents millésimes 
uniquement des OrthoHR. Il manquera juste les orthos locales.


Tu peux aussi prendre un millésime particulier, ce qui permet d'être 
sur de n'avoir de visible que des images d'une année donnée.


Il faudrait ajouter 2018 et 2019 qui ne sont pas listés, mais qui 
existent.




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

Re: [OSM-talk-fr] Renseigner un « Lieu-dit »

2020-08-17 Par sujet osm . sanspourriel 

Y compris en mettant un nom qui ne correspond pas à un lieu-dit dans le
coin ?

Je suis évidemment contre une telle pratique.

> Effet de bord : Cela facilite beaucoup l'affectation du nom du
lieu-dit à la numérotation des maisons sous JOSM ou Id.

C'est à dire faire deux faux au lieu d'un seul.

Le champ associé est addr:place pas addr:street.

Ça peut se discuter mais c'est le statut actuel.

Jean-Yvon

Le 17/08/2020 à 11:19, Rpnpif via Talk-fr - talk-fr@openstreetmap.org a
écrit :

Bonjour,

Le 16/08/2020 à 19:19, Jacques Lavignotte a écrit :

Je regarde le Wiki et je vois que ça peut-être "place" ou "hamlet" si
habité.

Mais ceci :

https://www.openstreetmap.org/way/157107477#map=15/45.1635/-0.1552

me semble très discutable...


Qu'en penser ?

J.


Mettre le nom du lieu-dit comme nom d'une voie est très fréquent.
Geoportail (IGN) le fait souvent sur ses cartes.

Effet de bord : Cela facilite beaucoup l'affectation du nom du
lieu-dit à la numérotation des maisons sous JOSM ou Id.

Ensuite, est-ce une pratique souhaitable ? Ça se discute. L'avantage
est de donner un nom à la voie ou portion de voie sous-jacente qui
sinon serait souvent anonyme.

Personnellement, je ne trouve pas gênant de le faire. Ce n'est pas le
facteur (surtout en cette période de remplacement) qui me contredira.

Ce qui n'empêche pas effectivement d'ajouter aussi des place=*.

.--

Rpnpif

___
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] Nouvelles orthos HR... trouvées au fond d'un FTP

2020-08-17 Par sujet Christian Quest 

Le 17/08/2020 à 11:19, Percherie OnDaNet a écrit :

Question à deux centimes d'un bouley de passage ;-p


Je n'arrive pas à trouver la couche "tous_fr" dans les préférence 
d'imagerie josm ou sur le wiki dédié : 
https://josm.openstreetmap.de/wiki/Maps


Où puis-je le trouver ?


Elle n'y est pas listée.

Tu peux prendre "orthohr" qui agrège les différents millésimes 
uniquement des OrthoHR. Il manquera juste les orthos locales.


Tu peux aussi prendre un millésime particulier, ce qui permet d'être sur 
de n'avoir de visible que des images d'une année donnée.


Il faudrait ajouter 2018 et 2019 qui ne sont pas listés, mais qui existent.

--
Christian Quest - OpenStreetMap France


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

Re: [OSM-talk-fr] Josm imagerie: couche "tous_fr"

2020-08-17 Par sujet Cyrille37 OSM via Talk-fr 

Bonjour,

Le 17/08/2020 à 11:19, Percherie OnDaNet a écrit :
Je n'arrive pas à trouver la couche "tous_fr" dans les préférence 
d'imagerie josm ou sur le wiki dédié : 
https://josm.openstreetmap.de/wiki/Maps


Tu dois l'ajouter à la mano, dans les préférences d'imagerie, ajout TMS 
avec simplement l'url suivante et le nom du calque:


tms:https://wms.openstreetmap.fr/tms/1.0.0/tous_fr/{zoom}/{x}/{y}

Cyrille37.


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

Re: [OSM-talk-fr] Renseigner un « Lieu-dit »

2020-08-17 Par sujet Rpnpif via Talk-fr 

Bonjour,

Le 16/08/2020 à 19:19, Jacques Lavignotte a écrit :
Je regarde le Wiki et je vois que ça peut-être "place" ou "hamlet" si 
habité.


Mais ceci :

https://www.openstreetmap.org/way/157107477#map=15/45.1635/-0.1552

me semble très discutable...


Qu'en penser ?

J.


Mettre le nom du lieu-dit comme nom d'une voie est très fréquent. 
Geoportail (IGN) le fait souvent sur ses cartes.


Effet de bord : Cela facilite beaucoup l'affectation du nom du lieu-dit 
à la numérotation des maisons sous JOSM ou Id.


Ensuite, est-ce une pratique souhaitable ? Ça se discute. L'avantage est 
de donner un nom à la voie ou portion de voie sous-jacente qui sinon 
serait souvent anonyme.


Personnellement, je ne trouve pas gênant de le faire. Ce n'est pas le 
facteur (surtout en cette période de remplacement) qui me contredira.


Ce qui n'empêche pas effectivement d'ajouter aussi des place=*.

.--

Rpnpif

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

Re: [OSM-talk-fr] Nouvelles orthos HR... trouvées au fond d'un FTP

2020-08-17 Par sujet Percherie OnDaNet 

Question à deux centimes d'un bouley de passage ;-p


Je n'arrive pas à trouver la couche "tous_fr" dans les préférence 
d'imagerie josm ou sur le wiki dédié : 
https://josm.openstreetmap.de/wiki/Maps


Où puis-je le trouver ?


Cordialement

Le 14/08/2020 à 19:00, Christian Quest a écrit :
Il y a quelques jours, Mapbox a publié un billet de blog annonçant une 
couverture en ortho-photos opendata sur la majorité de la France 
provenant de l'IGN.


https://blog.mapbox.com/france-imagery-is-live-c594e2e88ea7

Comme d'autres sur twitter, j'ai été très étonné de la couverture qui 
incluait de nombreux départements non listés sur la page officielle 
des données opendata diffusées par l'IGN.


Ces orthos étaient cachées au fond d'un FTP, certaines depuis janvier 
2019 sans qu'aucune publication n'y fasse référence.


Bref... j'ai lancé les téléchargements, décompression et recompression 
et une partie est déjà ajoutée sur wms.openstreetmap.fr


Pour 2018 en 15cm, il y a : 75, 78, 91, 92, 93 (ces deux derniers 
avaient été publiés en opendata par les départements eux-même il y a 
plus d'un an).


Toujours pour 2018 en 20cm, j'ai déjà ajouté: 01 02 29 33 37 38 et 94.

Le reste va suivre petit à petit...


Le plus simple pour les utiliser est la couche "tous_fr" qui agrège 
toutes les orthos en priorisant par date puis résolution.



PS pour Cyrille: sur Tours tu as maintenant du 20cm de 2018 ;)



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

Re: [OSM-talk-fr] Doutes sur un groupe de modifications

2020-08-17 Par sujet Arnaud Champollion 

Le 13/08/2020 à 13:53, Arnaud Champollion a écrit :


- Soit, plus fin, en supprimant les chemins en V1 non visibles sur 
l'orthophoto et en supprimant les champs "name" sur tous.


Pas de réponse du Crétin de l'Alpe.
Le nettoyage a été effectué.



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