date:20140108

Le 8 janvier 2014 23:38, Feth Arezki  a écrit :

> Bonjour,
>
> plus par maladresse que par manque de curiosité, je découvre ce soir la
> volonté d'Opendata de la communauté de communes du Sénonais :
> http://www.cc-senonais.fr/presentation_geosenonais.php
>
> On lit sur cette page, sous "Conditions d’utilisation" que "merci de bien
> vouloir mentionner la source et les mentions obligatoires de chaque donnée
> dans une utilisation professionnelle ou personnelle" -> nous aurions
> seulement
> une obligation de mention ?
>
>

Il y a une nuance importante: copyright pour l'IGN et pas de mention
copyright pour le reste, c'est plutôt bon signe.

C'est éventuellement possible pour les données provenant de la CC, il
faudrait qu'elle mette ça au propre en choisissant une vraie licence.




> Outre que je crois ne pas avoir le droit de reprendre les données IGN,
> j'ai du
> mal à saisir la portée de ces conditions d'utilisation. Si vous comprenez,
> dites-moi, et sinon je poserai la question aux interessés.
>
> Admettons qu'on lève l'obstacle juridique, il me semble que les données
> affichées sur http://ccs.sirap.fr/simap/ (cliquer dans la partie gauche),
> en
> particulier dans les contraintes, peuvent être utiles dans OSM, mais je ne
> saurai pas juger de la pertinence.
> Je suis à peu près sûr de l'intérêt des zones innondables / flood_prone=yes
> (différentes de ce que m'a montré le notaire pour la crue de 1910
> d'ailleurs)
> ou des sites archéologiques, les points d'apport volontaire (dont je
> vérifierai l'existence...) ou les monuments, par contre, fait-on figurer
> les
> power=minor_line et leurs poteaux.
>
> J'espérais trouver ici le cours des nombreux canaux qui disparaissent dans
> des
> buses et réapparaissent un peu au hasard, mais j'ai trouvé la position
> précise
> des chemins et rivières dans les parcs boisés, j'espère pouvoir l'intégrer
> !
>
> Si -toujours une fois l'obstacle juridique passé- vous connaissez une
> moulinette facilitant l'intégration de tout cela, ça me branche.
>


Le plus simple serait de prendre contact avec le SIG de la CC, de s'appuyer
sur cette volonté de se mettre à l'opendata et de leur dire "chiche" (c'est
à la mode).
Dans ce cas, plutôt qu'un accès par un serveur web de visualisation qui ne
suit aucun standard, ne pourraient-ils pas mettre à disposition en
téléchargement des données brutes (vectorielles) dont ils sont producteurs
? Ce on pourra en faire quelques chose même si c'est pas forcément hyper
simple.

Etant le local de l'étape... tu tente le coup ? chiche ? ;)

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

[OSM-talk-fr] opendata à la CC du Sénonais

2014-01-08 Par sujet Feth Arezki

Bonjour,

plus par maladresse que par manque de curiosité, je découvre ce soir la 
volonté d'Opendata de la communauté de communes du Sénonais :
http://www.cc-senonais.fr/presentation_geosenonais.php

On lit sur cette page, sous "Conditions d’utilisation" que "merci de bien 
vouloir mentionner la source et les mentions obligatoires de chaque donnée 
dans une utilisation professionnelle ou personnelle" -> nous aurions seulement 
une obligation de mention ?

Outre que je crois ne pas avoir le droit de reprendre les données IGN, j'ai du 
mal à saisir la portée de ces conditions d'utilisation. Si vous comprenez, 
dites-moi, et sinon je poserai la question aux interessés.

Admettons qu'on lève l'obstacle juridique, il me semble que les données 
affichées sur http://ccs.sirap.fr/simap/ (cliquer dans la partie gauche), en 
particulier dans les contraintes, peuvent être utiles dans OSM, mais je ne 
saurai pas juger de la pertinence.
Je suis à peu près sûr de l'intérêt des zones innondables / flood_prone=yes 
(différentes de ce que m'a montré le notaire pour la crue de 1910 d'ailleurs) 
ou des sites archéologiques, les points d'apport volontaire (dont je 
vérifierai l'existence...) ou les monuments, par contre, fait-on figurer les 
power=minor_line et leurs poteaux.

J'espérais trouver ici le cours des nombreux canaux qui disparaissent dans des 
buses et réapparaissent un peu au hasard, mais j'ai trouvé la position précise 
des chemins et rivières dans les parcs boisés, j'espère pouvoir l'intégrer !

Si -toujours une fois l'obstacle juridique passé- vous connaissez une 
moulinette facilitant l'intégration de tout cela, ça me branche.

Bonne nuit,
-- 
Feth

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

[OSM-talk-fr] Tous cartographes

http://www.iledefrance.fr/tous-cartographes

Avec notamment Gaël mais pas pour les arbres guadeloupéens ;)

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

Re: [OSM-talk-fr] Meilleure méthode pour repérer les chemins privés

2014-01-08 Par sujet Feth Arezki

Bonsoir,

Le mercredi 8 janvier 2014, 22:58:54 Eric Debeau a écrit :
> Si je constate que le chemin traverse en 'diagonale' une parcelle, alors
> j'en déduis que le chemin est privé et je ne le renseigne pas sauf s'il y a
> un droit de passage officiel (vérifié).
Pourquoi ne pas le cartographier quand même avec access=private ?
Après tout c'est un chemin, et en dehors des problématiques de routage, il me 
semble que sa présence peut donner du sens à une carte.

-- 
Feth

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

Re: [OSM-talk-fr] Du Fantoir


Le 08/01/2014 22:31, Vincent de Château-Thierry a écrit :



Le 08/01/2014 22:22, Romain MEHUT a écrit :


On déplace la frontière?


On regarde ce que disent les cadastres ?


Même si la rue n'est pas dans la commune ça n'empêche pas les adresses 
d'y être. C'est le cas des boulevard de Bordeaux dont la voie elle même 
est à bordeaux, mais seulement les maison d'un seul coté sont à Bordeaux.



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

[OSM-talk-fr] Meilleure méthode pour repérer les chemins privés

2014-01-08 Par sujet Eric Debeau

Bonsoir

Est ce qu'il y a une méthode pour savoir si un chemin est privé ? J'ai vu
d'anciennes discussions sur le sujet, mais je n'ai pas vu de méthode
définie pour déterminer si un chemin est privé ou s'il y a un droit de
passage (tout public) associé sur un chemin privé.

Ma méthode pour l'instant est de regarder dans les données du cadastre si
le chemin est bien associé à des parcelles spécifiques. En général, les
chemins sont associées à des parcelles étroites.
Si je constate que le chemin traverse en 'diagonale' une parcelle, alors
j'en déduis que le chemin est privé et je ne le renseigne pas sauf s'il y a
un droit de passage officiel (vérifié).

Ne pourrait-on pas obtenir la liste des parcelles publiques auprès des
instances en charge du cadastre ?

Autre question : Comment doit on renseigner dans OSM les droits de passages
pour tout public (et pas un droit de passage pour des voisins) ?

Merci

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

Re: [OSM-talk-fr] codes postaux...

2014-01-08 Par sujet Vincent de Château-Thierry



Le 08/01/2014 20:18, Christophe Merlet a écrit :

Le 08/01/2014 18:37, Pieren a écrit :

2013/12/22 Christian Quest :


Un peu d'harmonisation ne ferait pas de mal car on a un mélange de
addr:postcode=* et postal_code=* parfois sur la relation parfois sur le
noeud place=*



On en est où de cette harmonisation ? La page d'accueil du wiki
signale sur l' "image of the week" que les allemands viennent de créer
des relations de type "type=boundary" + "boundary=postal_code"  sur
l'ensemble de leur territoire (en les détachant complètement des
relations "boundary=administrative"). La relation contient des
attributs "postal_code" et "postal_code_level" (les détails sur leur
procédure :
https://wiki.openstreetmap.org/wiki/DE:Konsolidierung_der_PLZ-Relationen_in_Deutschland_2013


Dommage franchement d'avoir utilisé postal_code et non addr:postcode. 
Taginfo à l'issue du chantier allemand indique 60.000 relations avec 
addr:postcode, contre 12.000 avec postal_code, sachant que ledit 
chantier vient d'apporter à lui seul 8000 de ces 12.000 relations. On 
marche sur la tête :-(



Moi j'ai regardé sur quelques communes en Alsace et le code postal ne
figure pas sur la relation "boundary=administrative".
Faudrait-il migrer l'ensemble de codes postaux sur les relations
"boundary=administrative" et créer des relations
"boundary=postal_code" lorsque ça n'est pas possible autrement
(communes à plusieurs codes).
Ou faudrait-il faire pareil sur l'ensemble du territoire avec des
relations "boundary=administrative" partout , à l'image de ce que
viennent de faire nos collègues allemands en quelques semaines ? (et
beaucoup en Belgique aussi, d'après ce que j'ai compris)


Nominatim prend en compte dans sa version 2.1 boundary=postal_code

C'est une bonne idée de l'utiliser, non pas lorqu'un même code postal
est utilisé par plusieurs communes, mais plutôt pour délimiter les zones
d'une communes qui utilise différents codes postaux.


taginfo.fr recense, avec les objets taggués en boundary=administrative, 
29.000 combinaisons avec le tag addr:postcode=* , et 0 présence de 
postal_code=*. On a donc quoi qu'on dise un peu d'harmonisation, de 
fait. (Ne pas se fier à la centaine de relations boundary=postal_code de 
taginfo.fr, ce sont des zones de CP allemandes, le comptage de 
taginfo.fr ne s'arrête pas pile à la frontière.)


Passer à un modèle où les zones postales seraient des entités en propre, 
à part, pourquoi pas. On aurait à terme une modélisation uniforme entre 
zones postales englobant une à plusieurs communes, et zones postales à 
cheval sur des morceaux de communes. Et on aurait une vision plus simple 
des emprises postales (plutôt que noyées comme attributs des communes 
dans 99% des cas). Mais ça fera 6000 relations en plus (ça va pas plaire 
à tout le monde ;-) ).


vincent

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

Re: [OSM-talk-fr] Du Fantoir

2014-01-08 Par sujet Vincent de Château-Thierry




Le 08/01/2014 22:22, Romain MEHUT a écrit :


On déplace la frontière?


On regarde ce que disent les cadastres ?

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

Re: [OSM-talk-fr] Du Fantoir

Le 8 janvier 2014 22:20, Pieren  a écrit :


> En passant, cet exemple est encore pire. Le way se trouve entièrement
> dans une seule des deux communes (et non sur la frontière). Il y aura
> donc erreur ou même conflit avec les autres attributs d'adresse qu'on
> déduit à partir du polygone communal (code postal, code insee). Bon
> courage pour que ça fonctionne correctement avec les outils de
> geocoding.
>

On déplace la frontière?

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

Re: [OSM-talk-fr] Du Fantoir

2014/1/8 Christian Quest :

> le FANTOIR est donc bien lié aux adresses
Sur ce point, j'admet. J'ai naivement fait confiance aux différents
descriptifs du fantoir que j'ai pu lire (y compris sur l'opendata).
Ca ne justifie pas d'utiliser systématiquement une relation
associatedStreet si les adresses sont déjà présentes dans OSM ou s'il
n'y a pas d'adresses du tout.

En passant, cet exemple est encore pire. Le way se trouve entièrement
dans une seule des deux communes (et non sur la frontière). Il y aura
donc erreur ou même conflit avec les autres attributs d'adresse qu'on
déduit à partir du polygone communal (code postal, code insee). Bon
courage pour que ça fonctionne correctement avec les outils de
geocoding.

Pieren

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

Re: [OSM-talk-fr] Du Fantoir

Le 8 janvier 2014 21:27, Romain MEHUT  a écrit :

> Le 8 janvier 2014 12:22, Romain MEHUT  a écrit :
>
>
>
>> cf.
>> http://addr.openstreetmap.fr/nancy/?zoom=19&lat=48.68871&lon=6.15494&layers=BT&item=100
>> Bien vu c'est ça l'explication. Un morceau dans Nancy et un autre dans
>> Laxou. Mais du coup, ça va faire 2 relations AssociatedStreet avec le même
>> nom de rue.
>>
>
> J'ai fait l'intégration de la rue que je donnais en exemple. Et j'ai
> indiqué le ref:FR:FANTOIR dans les relations car je suis aussi dans le cas
> où une section de rue (http://www.openstreetmap.org/way/10522781) porte
> deux noms, un name:left et un name:right. Si je devais mettre le
> ref:FR:FANTOIR sur le way, il me faudrait créer un ref:FR:FANTOIR:left et
> un ref:FR:FANTOIR:right. Alors relation ou pas relation?
>


CQFD... le FANTOIR est donc bien lié aux adresses avant d'être liée à la
voirie... ce sont une fois de plus les cas particuliers qui revèlent la
cohérence des modèles envisagés.

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

Re: [OSM-talk-fr] Du Fantoir

Le 8 janvier 2014 12:22, Romain MEHUT  a écrit :


> cf.
> http://addr.openstreetmap.fr/nancy/?zoom=19&lat=48.68871&lon=6.15494&layers=BT&item=100
> Bien vu c'est ça l'explication. Un morceau dans Nancy et un autre dans
> Laxou. Mais du coup, ça va faire 2 relations AssociatedStreet avec le même
> nom de rue.
>

J'ai fait l'intégration de la rue que je donnais en exemple. Et j'ai
indiqué le ref:FR:FANTOIR dans les relations car je suis aussi dans le cas
où une section de rue (http://www.openstreetmap.org/way/10522781) porte
deux noms, un name:left et un name:right. Si je devais mettre le
ref:FR:FANTOIR sur le way, il me faudrait créer un ref:FR:FANTOIR:left et
un ref:FR:FANTOIR:right. Alors relation ou pas relation?

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

Re: [OSM-talk-fr] combien d'adresses en Alsace ?

2014-01-08 Par sujet DH


Le 08/01/2014 19:48, Pierre Knobel a écrit :
J'ai travaillé sur le nord est (Vosges du nord et outre foret). Je m'y 
remettrai a nouveau  quand j'aurais du temps libre, mais je ne sais 
pas quand.
C'est bizarre, je croyais que le taux de couverture etait bcp plus 
important dans le Bas-Rhin.


En tout cas bravo pour les statistiques!

Comme évoqué il y a quelques biais et statistiques et cartographiques. 1 
adresse par commune (via opendata -> mairie, écoles, postes, etc.) 
changerait globalement la perception globale de la carte. Il ne faut 
jamais oublier qu'il n'y a jamais de carte juste mais que des cartes 
pour !!!
J'ai sur ma toux do liste, une analyse basée sur des critères objectifs 
(population, nb de logements, surtout collectifs, etc.) pour ne plus 
dépendre de référentiels externes (soumis eux-mêmes à des contraintes 
constitutionnelles).

Pensez pièces jaunes !!!


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

Re: [OSM-talk-fr] codes postaux...

2014-01-08 Par sujet Christophe Merlet


Le 08/01/2014 18:37, Pieren a écrit :

2013/12/22 Christian Quest :


Un peu d'harmonisation ne ferait pas de mal car on a un mélange de
addr:postcode=* et postal_code=* parfois sur la relation parfois sur le
noeud place=*


On en est où de cette harmonisation ? La page d'accueil du wiki
signale sur l' "image of the week" que les allemands viennent de créer
des relations de type "type=boundary" + "boundary=postal_code"  sur
l'ensemble de leur territoire (en les détachant complètement des
relations "boundary=administrative"). La relation contient des
attributs "postal_code" et "postal_code_level" (les détails sur leur
procédure : 
https://wiki.openstreetmap.org/wiki/DE:Konsolidierung_der_PLZ-Relationen_in_Deutschland_2013
)

Moi j'ai regardé sur quelques communes en Alsace et le code postal ne
figure pas sur la relation "boundary=administrative".
Faudrait-il migrer l'ensemble de codes postaux sur les relations
"boundary=administrative" et créer des relations
"boundary=postal_code" lorsque ça n'est pas possible autrement
(communes à plusieurs codes).
Ou faudrait-il faire pareil sur l'ensemble du territoire avec des
relations "boundary=administrative" partout , à l'image de ce que
viennent de faire nos collègues allemands en quelques semaines ? (et
beaucoup en Belgique aussi, d'après ce que j'ai compris)


Nominatim prend en compte dans sa version 2.1 boundary=postal_code

C'est une bonne idée de l'utiliser, non pas lorqu'un même code postal 
est utilisé par plusieurs communes, mais plutôt pour délimiter les zones 
d'une communes qui utilise différents codes postaux.



Librement,
--
Christophe Merlet (RedFox)

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

[OSM-talk-fr] openriverboatmap en rade?

2014-01-08 Par sujet Claude


Bonsoir

http://{s}.layers.openstreetmap.fr/openriverboatmap/

est en rade?

merci
Claude

--
 Envoyé avec Mozilla Thunderbird ---


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

Re: [OSM-talk-fr] combien d'adresses en Alsace ?

2014-01-08 Par sujet Pierre Knobel

J'ai travaillé sur le nord est (Vosges du nord et outre foret). Je m'y
remettrai a nouveau  quand j'aurais du temps libre, mais je ne sais pas
quand.
C'est bizarre, je croyais que le taux de couverture etait bcp plus
important dans le Bas-Rhin.

En tout cas bravo pour les statistiques!


On Wednesday, January 8, 2014, HELFER Denis  wrote:
> Bonjour et bonne année à tous,
>
>
>
> Je suis particulièrement l’évolution de la saisie des adresses dans OSM
tout particulièrement en Alsace depuis quelques années. C’est actuellement
et, entre autres, pour un projet important de collectivités alsaciennes,
une donnée clé pour appuyer des applications porte-à-porte sur la base OSM.
>
> Pour l’Alsace, le volume total d’adresses à saisir est plus que
conséquent : il dépasse les 520.000 !
>
> Fin 2009, nous en avions un peu moins de 14.000 dans la base ; plus de
110.000 en mai 2011 ; 256.000 à la toute fin de 2013. Que de chemin
parcouru …  mais il en reste encore la moitié à faire.
>
> Vous me direz : mais où ?
>
>
>
> La réponse en image :
http://listes.openstreetmap.fr/wws/d_read/local-alsace/cartes/tx_couv_adresses_20140103.jpg
>
> Et en graphique :
http://listes.openstreetmap.fr/wws/d_read/local-alsace/cartes/progression_adresses_OSM_20131230.jpg
>
>
>
> Quelques mots d’explication :
>
> Le taux de couverture est obtenu en comparant le nombre d’adresses
présentes dans OSM par commune (géotraitement) et celui issu de la base
cadastrale (à laquelle j’avais accès dans une autre vie et qui date de
2009-2010). Ce n’est pas scientifiquement irréprochable, mais c’est une
première approche.
>
>
>
> Vous l’avez bien compris, je cherche de l’aide !!! Pour ma part, je
poursuis l’intégration des adresses opendata de l’agglomération de Mulhouse
(http://addr.openstreetmap.fr/mulhouse/ ) pour que celle-ci devienne n°1
dans ce chart : http://addr.openstreetmap.fr/stats.php en attendant les
adresses sur la communauté urbaine de Strasbourg prévues pour le printemps
2014.
>
>
>
> A vot’ bon coeur
>
>
>
> Denis
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Lac Inle, Birmanie : Vous cherchez un beau défi pour 2014?

2014-01-08 Par sujet Pierre Béland

Le lac Inle, le joyau de la Birmanie en péril
http://www.slate.fr/story/81933/lac-inle

Cet article présente un endroit très particulier avec villages et potagers 
flottants sur le lac. Mais comment reconnaitre cette réalité dans OSM?

L'imagerie Bing est excellente. C'est impressionnant à voir à partir de JOSM
voir http://www.openstreetmap.org/#map=17/20.46307/96.90767


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

Re: [OSM-talk-fr] codes postaux...

2013/12/22 Christian Quest :

> Un peu d'harmonisation ne ferait pas de mal car on a un mélange de
> addr:postcode=* et postal_code=* parfois sur la relation parfois sur le
> noeud place=*

On en est où de cette harmonisation ? La page d'accueil du wiki
signale sur l' "image of the week" que les allemands viennent de créer
des relations de type "type=boundary" + "boundary=postal_code"  sur
l'ensemble de leur territoire (en les détachant complètement des
relations "boundary=administrative"). La relation contient des
attributs "postal_code" et "postal_code_level" (les détails sur leur
procédure : 
https://wiki.openstreetmap.org/wiki/DE:Konsolidierung_der_PLZ-Relationen_in_Deutschland_2013
)

Moi j'ai regardé sur quelques communes en Alsace et le code postal ne
figure pas sur la relation "boundary=administrative".
Faudrait-il migrer l'ensemble de codes postaux sur les relations
"boundary=administrative" et créer des relations
"boundary=postal_code" lorsque ça n'est pas possible autrement
(communes à plusieurs codes).
Ou faudrait-il faire pareil sur l'ensemble du territoire avec des
relations "boundary=administrative" partout , à l'image de ce que
viennent de faire nos collègues allemands en quelques semaines ? (et
beaucoup en Belgique aussi, d'après ce que j'ai compris)

Pieren

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

Re: [OSM-talk-fr] Du Fantoir

2014/1/8 Tetsuo Shima :

> Tu parles de lieu sans adresse? J'ai un peu du mal a suivre. A priori
> toutes les parcelles sont adressables au sens fantoir, puisque celui
> ci sert essentiellement d'outil a MAJIC pour adresser chaque
> parcelles! Seulement les élément de fantoir ne sont qu'un élément de
> l'adresse des parcelle et propriétaire au sens de la DGI. Forcément
> l'adresse de la résidence des propriétaire est aussi une adresse
> postal puisque c'est la qu'on leur adresse l'avis d'impot.

Je parle d'adresses postales, bien-sûr. Dans OSM, on n'a pas de
parcelles. Et dans le vocabulaire OSM, une "adresse" est toujours une
adresse postale (même Philou ne confondrait pas avec une adresse IP).
On va finir par se comprendre ;-)

Pieren

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

Re: [OSM-talk-fr] Du Fantoir

@Pieren

Tu parles de lieu sans adresse? J'ai un peu du mal a suivre. A priori
toutes les parcelles sont adressables au sens fantoir, puisque celui
ci sert essentiellement d'outil a MAJIC pour adresser chaque
parcelles! Seulement les élément de fantoir ne sont qu'un élément de
l'adresse des parcelle et propriétaire au sens de la DGI. Forcément
l'adresse de la résidence des propriétaire est aussi une adresse
postal puisque c'est la qu'on leur adresse l'avis d'impot.

Le 8 janvier 2014 16:48, Pieren  a écrit :
> 2014/1/8 Tetsuo Shima :
>
>> A bon? Je comprends pas bien. Le code Fantoir est effectivement un
>> alias des nom de voie, nom de voie qui sont les adresses. Le numéro
>> n'est qu'un élément en plus de l'adresse, mais on peut tres bien avoir
>> comme adresse un voie, sans avoir de numéro, ou pas de voie et juste
>> une pseudo, voie ou un lieu dit, sans numéro ou vaec numéro.
>
> Il y a un problème de définition ;-) Le code fantoir identifie la
> voie. Le nom de la voie est effectivement un élément constitutif d'une
> adresse - comme le nom de la ville ou le code postal - mais pas le
> code fantoir. Cet attribut n'est peut-être limité qu'à ce rôle dans
> l'administration fiscale. Mais dans OMS, ça devient un attribut de la
> voie, pour un usage plus général et pas seulement une composante de
> l'adresse.
> Il y a aussi plein de voies sans adresses, ni habitations mais qui
> doivent quand même avoir un code fantoir, non ?
>
> Le descriptif du fichier FANTOIR donne comme définition:
> "Le fichier des voies et lieux-dits ou fichier FANTOIR recense par commune:
> - les voies
> - les lieux-dits
> - les ensembles immobiliers
> - les pseudo-voies
> Il est constitué de l'ensemble des références topographiques qu'elles
> soient annulées ou actives"
>
> A aucun moment, ça ne parle d'adresse.
>
>> Il faudrait donc deux
>> collections. Une des nom au sens de l'adresse qui irait naturellement
>> dans associatedstreet, et une des référence "DDE" qui irait dans une
>> relation "associatedroad" ou un sous type de associated street.
>
> Ouh la, une relation de plus ;-) Une relation par attribut finalement,
> ou presque ;-) Je suis sûr qu'osm2pgsql pourrait y retrouver ses
> petits mais ça m'étonnerait que les contributeurs humains y gagnent en
> facilité de lecture puisqu'il faudra ouvrir toutes les relations pour
> voir l'ensemble des attributs (en espérant qu'ils n'entrent pas en
> contradiction).
>
> 2014/1/8 Christian Quest :
>> 1 code FANTOIR à faire correspondre à 1 objet OSM et le plus
>> approprié pour ça m'a l'air d'être la relation associatedStreet.
>
> Ca implique de mettre des relations associatedStreet partout, même là
> où il n'y a pas d'adresses, donc d'en changer fondamentalement la
> définition. Une telle modification nécessiterait d'en discuter à un
> niveau plus large que cette liste. Autrement, c'est du bricolage.
>
> Pieren
>
> ___
> 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] Du Fantoir

2014/1/8 Tetsuo Shima :

> A bon? Je comprends pas bien. Le code Fantoir est effectivement un
> alias des nom de voie, nom de voie qui sont les adresses. Le numéro
> n'est qu'un élément en plus de l'adresse, mais on peut tres bien avoir
> comme adresse un voie, sans avoir de numéro, ou pas de voie et juste
> une pseudo, voie ou un lieu dit, sans numéro ou vaec numéro.

Il y a un problème de définition ;-) Le code fantoir identifie la
voie. Le nom de la voie est effectivement un élément constitutif d'une
adresse - comme le nom de la ville ou le code postal - mais pas le
code fantoir. Cet attribut n'est peut-être limité qu'à ce rôle dans
l'administration fiscale. Mais dans OMS, ça devient un attribut de la
voie, pour un usage plus général et pas seulement une composante de
l'adresse.
Il y a aussi plein de voies sans adresses, ni habitations mais qui
doivent quand même avoir un code fantoir, non ?

Le descriptif du fichier FANTOIR donne comme définition:
"Le fichier des voies et lieux-dits ou fichier FANTOIR recense par commune:
- les voies
- les lieux-dits
- les ensembles immobiliers
- les pseudo-voies
Il est constitué de l'ensemble des références topographiques qu'elles
soient annulées ou actives"

A aucun moment, ça ne parle d'adresse.

> Il faudrait donc deux
> collections. Une des nom au sens de l'adresse qui irait naturellement
> dans associatedstreet, et une des référence "DDE" qui irait dans une
> relation "associatedroad" ou un sous type de associated street.

Ouh la, une relation de plus ;-) Une relation par attribut finalement,
ou presque ;-) Je suis sûr qu'osm2pgsql pourrait y retrouver ses
petits mais ça m'étonnerait que les contributeurs humains y gagnent en
facilité de lecture puisqu'il faudra ouvrir toutes les relations pour
voir l'ensemble des attributs (en espérant qu'ils n'entrent pas en
contradiction).

2014/1/8 Christian Quest :
> 1 code FANTOIR à faire correspondre à 1 objet OSM et le plus
> approprié pour ça m'a l'air d'être la relation associatedStreet.

Ca implique de mettre des relations associatedStreet partout, même là
où il n'y a pas d'adresses, donc d'en changer fondamentalement la
définition. Une telle modification nécessiterait d'en discuter à un
niveau plus large que cette liste. Autrement, c'est du bricolage.

Pieren

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

[OSM-talk-fr] combien d'adresses en Alsace ?

Bonjour et bonne année à tous,

Je suis particulièrement l'évolution de la saisie des adresses dans OSM tout
particulièrement en Alsace depuis quelques années. C'est actuellement et, entre
autres, pour un projet important de collectivités alsaciennes, une donnée clé
pour appuyer des applications porte-à-porte sur la base OSM.
Pour l'Alsace, le volume total d'adresses à saisir est plus que conséquent : il
dépasse les 520.000 !
Fin 2009, nous en avions un peu moins de 14.000 dans la base ; plus de 110.000
en mai 2011 ; 256.000 à la toute fin de 2013. Que de chemin parcouru ... mais
il en reste encore la moitié à faire.
Vous me direz : mais où ?

La réponse en image :
http://listes.openstreetmap.fr/wws/d_read/local-alsace/cartes/tx_couv_adresses_20140103.jpg
Et en graphique :
http://listes.openstreetmap.fr/wws/d_read/local-alsace/cartes/progression_adresses_OSM_20131230.jpg

Quelques mots d'explication :
Le taux de couverture est obtenu en comparant le nombre d'adresses présentes
dans OSM par commune (géotraitement) et celui issu de la base cadastrale (à
laquelle j'avais accès dans une autre vie et qui date de 2009-2010). Ce n'est
pas scientifiquement irréprochable, mais c'est une première approche.

Vous l'avez bien compris, je cherche de l'aide !!! Pour ma part, je poursuis
l'intégration des adresses opendata de l'agglomération de Mulhouse
(http://addr.openstreetmap.fr/mulhouse/ ) pour que celle-ci devienne n°1 dans
ce chart : http://addr.openstreetmap.fr/stats.php en attendant les adresses sur
la communauté urbaine de Strasbourg prévues pour le printemps 2014.

A vot' bon coeur

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

Re: [OSM-talk-fr] Améliorer GPS en ville sans connexion data?

J'ai également un Galaxy Nexus et c'est vrais que a froid le GPS est un peu
long à obtenir un fix.

Mais le plus simple est quand tu as une connexion de charger les
éphémérides en activant le wifi par exemple et d'activer le GPS. Dans GPS
Status tu peux même forcer à télécharger les éphémérides. De mon expérience
au de là de 1 jours ils n'aident plus à accélérer le fix.

Frédéric.



Le 8 janvier 2014 15:55, Ab_fab  a écrit :

> Pour me faire une idée de l'état du GPS j'utilise GPS Status comme
> mentionné par Eric,
> ainsi que l'appli U-blox U-center (qui marche bien même si la puce du
> téléphone n'est pas de cette marque).
>
> GPS status permet de voir rapidement la fraîcheur des éphémérides A-GPS
> enregistrés dans le tel
> (si tu veux tenter le coup avec du wifi gratuit plutôt qu'en faisant appel
> à du data roaming)
>
> Sinon, certains appareils ont des pb hardware / software (version
> d'Android) bien spécifiques. Je ne sais pas ce qu'il en est précisément du
> Galaxy Nexus, mais une recherche sur le net sera peut être fructueuse.
>
>
> Le 8 janvier 2014 15:09, Eric  a écrit :
>
>>  > Il ne fonctionne que lorsque je me trouve en extérieur dans une zone
>>> sans
>>> > aucun bâtiment. J'imagine que les immeubles empêchent d'obtenir des
>>> signaux
>>> > de différents satellites.
>>>
>>
>> Salut ! Pas très normal quand meme, meme en ville, meme entre des
>> immeubles, tu devrais avoir un signal meme imprecis au bout de quelques
>> dizaines de secondes. As tu essayé avec OSMAnd ? Voit-il des satellites
>> (indiqué en heut à droite, forme XX/YY). Actuellement sur mon Android j'en
>> vois 5 (avec une précision de 200m) alors que je suis enfermé dans un
>> bureau. Tu peux avoir des details via une appli android qui doit s'appeller
>> "GPS Satus" ou quelque chose comme ca qui t'en dira plus sur les satellites
>> recus.
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> ab_fab 
> "Il n'y a pas de pas perdus", Nadja
>
> ___
> 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] Améliorer GPS en ville sans connexion data?

2014-01-08 Par sujet Ab_fab

Pour me faire une idée de l'état du GPS j'utilise GPS Status comme
mentionné par Eric,
ainsi que l'appli U-blox U-center (qui marche bien même si la puce du
téléphone n'est pas de cette marque).

GPS status permet de voir rapidement la fraîcheur des éphémérides A-GPS
enregistrés dans le tel
(si tu veux tenter le coup avec du wifi gratuit plutôt qu'en faisant appel
à du data roaming)

Sinon, certains appareils ont des pb hardware / software (version
d'Android) bien spécifiques. Je ne sais pas ce qu'il en est précisément du
Galaxy Nexus, mais une recherche sur le net sera peut être fructueuse.


Le 8 janvier 2014 15:09, Eric  a écrit :

> > Il ne fonctionne que lorsque je me trouve en extérieur dans une zone sans
>> > aucun bâtiment. J'imagine que les immeubles empêchent d'obtenir des
>> signaux
>> > de différents satellites.
>>
>
> Salut ! Pas très normal quand meme, meme en ville, meme entre des
> immeubles, tu devrais avoir un signal meme imprecis au bout de quelques
> dizaines de secondes. As tu essayé avec OSMAnd ? Voit-il des satellites
> (indiqué en heut à droite, forme XX/YY). Actuellement sur mon Android j'en
> vois 5 (avec une précision de 200m) alors que je suis enfermé dans un
> bureau. Tu peux avoir des details via une appli android qui doit s'appeller
> "GPS Satus" ou quelque chose comme ca qui t'en dira plus sur les satellites
> recus.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
ab_fab 
"Il n'y a pas de pas perdus", Nadja
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Du Fantoir

Le 8 janvier 2014 14:18, Pieren  a écrit :

> 2014/1/8 Christian Quest :
>
> > Mettre le ref:FR:FANTOIR sur la relation (quand elle existe) évite de le
> > répéter sur chaque tronçon de voie et aussi de retrouver facilement
> toutes
> > adresses qui y sont liées.
>
> Encore une fois, code fantoir et adresses sont deux choses
> différentes. Pour éviter de dupliquer le code fantoir, vous allongez
> aussi la liste des membres 'street'. Où est le gain ? Quand je pense
> qu'on me disait que l'impact du tag source=cadastre sur la base était
> au final assez négligeable. L'argument de dire qu'on va économiser
> quelques octets ici est assez faible.
> Je vais redonner la définition d'associatedStreet : "provide a
> connection between housenumber and street.". Rien d'autre. Si vous
> migrez le code fantoir, pourquoi ne pas migrer tous les autres tags du
> highway: name, ref, oneway, access, etc ? Pourquoi celui-là et pas les
> autres ? Restons cohérents.
>
> Pieren
>


Je recherche en fait une cohérence avec le principe "one feature, one OSM
element"*.

1 code FANTOIR à faire correspondre à 1 objet OSM et le plus approprié pour
ça m'a l'air d'être la relation associatedStreet.


* http://wiki.openstreetmap.org/wiki/FR:One_feature,_one_OSM_element

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

Re: [OSM-talk-fr] Du Fantoir

> Encore une fois, code fantoir et adresses sont deux choses
> différentes.

A bon? Je comprends pas bien. Le code Fantoir est effectivement un
alias des nom de voie, nom de voie qui sont les adresses. Le numéro
n'est qu'un élément en plus de l'adresse, mais on peut tres bien avoir
comme adresse un voie, sans avoir de numéro, ou pas de voie et juste
une pseudo, voie ou un lieu dit, sans numéro ou vaec numéro.

Le code FANTOIR c'est justement un élément d'adresse et pas un élément
de voirie.

L'objectif de FANTOIR ce justement d'établir des liste d'adresse pour
pouvoir rapprocher chaque résident entre IRPP et taxe locale, de
maniere a éviter les adresse fictive, ou multiple, de les trou dans
l'impot foncier et taxe d'habitation etc.

Pour cela il faut pour identifier de maniere unique les adresse. Pour
les commune c'est facile on a déjà un code INSEE, pour les voies on a
donc créée RIVOLI/FANTOIR. Les numéros de rue eux sont naturellement
un index a eux seul, meme s'il y a encore des ambiguité de ce coté
entre le bis ter, A,B,C ou les communes sans numéros de rue...

> Pour éviter de dupliquer le code fantoir, vous allongez
> aussi la liste des membres 'street'. Où est le gain ?

C'est un probleme logique.
D'un coté on a des segment physique de voirie, d'un autre coté on a
des élément logique de voirie.
Il est intéressant de modéliser ces élément logique, nom, référence,
code Fantoir, dans un modele a coté du modele physique justement parce
que la réalité logique d'une voie, et assez éloigné de la réalité
logique des segment membre en question.


> Quand je pense
> qu'on me disait que l'impact du tag source=cadastre sur la base était
> au final assez négligeable. L'argument de dire qu'on va économiser
> quelques octets ici est assez faible.

Ce n'est pas un probleme de "poids", c'est un probleme de modele de donnée.

On a le meme probleme avec le reférence de voie route antionel numéro
machin, département truc. Pour bien faire il faudrait que les segment
d'une meme voie au sens de sa référence soit regroupé dans un
collection. Reconstruire a posterio la D951 a partir des infos actuel
de la base c'est pas évident évident avec les doublons de voie
différente ou de meme voie portant la meme référence. Tu me répondras
qu'on a qu'a filtrer géographiquement ... mais je vois arriver gros
comme une maison des exemples ou cette reconstruction a posteriori va
merder.

On le fait bien pour les riviere, les voie de chemin de fer, les voies
cyclable, j'ai du mal a comprendre pourquoi ca ne se fait pas
naturellement pour les voie routière.

> Je vais redonner la définition d'associatedStreet : "provide a
> connection between housenumber and street.". Rien d'autre. Si vous
> migrez le code fantoir, pourquoi ne pas migrer tous les autres tags du
> highway: name, ref, oneway, access, etc ? Pourquoi celui-là et pas les
> autres ? Restons cohérents.

oneway et access sont souvent propre a chaque segments?! seul name et
ref est commun a chacune des voie "logique". Il faudrait donc deux
collections. Une des nom au sens de l'adresse qui irait naturellement
dans associatedstreet, et une des référence "DDE" qui irait dans une
relation "associatedroad" ou un sous type de associated street.

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

Re: [OSM-talk-fr] Améliorer GPS en ville sans connexion data?

2014-01-08 Par sujet Eric

>
> > Il ne fonctionne que lorsque je me trouve en extérieur dans une zone sans
> > aucun bâtiment. J'imagine que les immeubles empêchent d'obtenir des
> signaux
> > de différents satellites.
>

Salut ! Pas très normal quand meme, meme en ville, meme entre des
immeubles, tu devrais avoir un signal meme imprecis au bout de quelques
dizaines de secondes. As tu essayé avec OSMAnd ? Voit-il des satellites
(indiqué en heut à droite, forme XX/YY). Actuellement sur mon Android j'en
vois 5 (avec une précision de 200m) alors que je suis enfermé dans un
bureau. Tu peux avoir des details via une appli android qui doit s'appeller
"GPS Satus" ou quelque chose comme ca qui t'en dira plus sur les satellites
recus.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Du Fantoir

2014/1/8 Christian Quest :

> Ce que nous connaissons de FANTOIR ne contient effectivement que les voies,
> mais je pense que son usage interne est d'être une base aux adresses des
> propriétés (parcelles, bâti) et ainsi que des contribuables, non ?

Si le code fantoir n'a qu'un usage interne, inutile de l'importer dans
OSM. Si on pense qu'il peut être utile à d'autres choses, il faut
seulement le considérer comme un attribut de la voie, un alias, le
genre de chose qu'on a toujours mis sur le highway et dupliqué à
l'envie lorsque celui-ci était fragmenté. Une chose qui ne gênait
personne jusqu'ici.
Je sais bien qu'on est ici dans la classique confrontation entre ceux
"qui veulent tout migrer dans des relations" et ceux "qui n'aiment pas
les relations". Mais au-delà des arguments habituels, il faut
comprendre que placer un attribut de la voie comme l'est le code
fantoir sur la relation associatedStreet serait un changement dans la
définition de cette relation et un changement dans le traitement
habituel des attributs liés à la voie elle-même.

Pieren

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

Re: [OSM-talk-fr] Améliorer GPS en ville sans connexion data?

2014-01-08 Par sujet Vladimir Vyskocil

Bonjour,

On 8 janv. 2014, at 01:09, Shohreh  wrote:

> Bonjour
> 
> À l'expérience, le GPS de mon smartphone Android (Galaxy Nexus) ne
> fonctionne quasiment pas en ville à l'étranger à cause de l'absence de
> connexion data (data roaming).
> 
> Il ne fonctionne que lorsque je me trouve en extérieur dans une zone sans
> aucun bâtiment. J'imagine que les immeubles empêchent d'obtenir des signaux
> de différents satellites.
> 
> Passer du Android standard à Cyanogenmod n'a rien changé sur ce point.
> 
> Y a-t-il un moyen de contourner ce problème sans activer le data roaming et
> faire exploser ma note de communication?

J'avais remarqué avec mon iPhone qu'il suffit d'activer brièvement le data 
roaming pour effectuer un premier fix GPS puis ensuite on peut le couper et 
cela continue de fonctionner.
J'avais fait cette expérience en arrivant en Guadeloupe ou tant que je n'avais 
pas fait cette manipulation il était impossible au téléphone de se géolocaliser.

> 
> Merci.
> 

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

Re: [OSM-talk-fr] Du Fantoir

2014/1/8 Christian Quest :

> Mettre le ref:FR:FANTOIR sur la relation (quand elle existe) évite de le
> répéter sur chaque tronçon de voie et aussi de retrouver facilement toutes
> adresses qui y sont liées.

Encore une fois, code fantoir et adresses sont deux choses
différentes. Pour éviter de dupliquer le code fantoir, vous allongez
aussi la liste des membres 'street'. Où est le gain ? Quand je pense
qu'on me disait que l'impact du tag source=cadastre sur la base était
au final assez négligeable. L'argument de dire qu'on va économiser
quelques octets ici est assez faible.
Je vais redonner la définition d'associatedStreet : "provide a
connection between housenumber and street.". Rien d'autre. Si vous
migrez le code fantoir, pourquoi ne pas migrer tous les autres tags du
highway: name, ref, oneway, access, etc ? Pourquoi celui-là et pas les
autres ? Restons cohérents.

Pieren

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

Re: [OSM-talk-fr] Du Fantoir

Le 8 janvier 2014 13:47, Tetsuo Shima  a écrit :

> Fantoir ne fait pas que les voie, il fait aussi les lieux dits et il y
> en a beaucoup, ce qui explique notament les statistique parfois
> bizarre de la couche QA, ou des villages ont toutes les rues taggé
> correctement et ou il est affiché seulement 50%.
>
>
Pourtant, il me semble que ma requête ne prend en compte que les "voies",
pas les pseudo-voies ni les lieux dits.
C'est de toute façon un premier jet, qu'il faut affiner en regardant dans
le détail sur quelques communes où on ne s'explique pas les différences.


Pour le probleme des "voie adresse" vs "segment de voie" ne serait il
> pas envisageable d'imposer une relation associated street par voie ...
> et par lieu dit. Relation qui matérialiserait la voie logique elle
> meme, et pas juste les segment physique que sont les way.
>
> On pourrait meme alors virer les name des way ... et se baser sur la
> relation pour dessiner les nom des voie. Bon je sais c'est extreme,
> mais c'est plus logique que la succession de segment avec le nom
> recopié a l'infini sur chaque petit bout.
>


Dans un premier temps, ça va poser un problème à la majorité des rendus
utilisant la chaine classique osm2pgsl > postgis > mapnik

Mais dans un deuxième temps, ça permettrait aussi de ne rendre le nom que
sur la voie de plus grande importance, je pense aux rues avec des contre
allées où on trouve le nom un peu partout ce qui n'apporte par vraiment
d'information et réduit la lisibilité globale.

Il ne faut oublier non plus que les données OSM ne servent pas qu'au rendu
de cartes.



>
> Le 8 janvier 2014 13:32, Pieren  a écrit :
> > Euh, au risque de me répéter, je pense que mettre le code fantoir sur
> > une relation associatedStreet est, au final, une très, très mauvaise
> > idée (je sais, c'est dans le wiki, c'est moi qui l'ait mis, mais je ne
> > faisais qu'officialiser ce qui était dit ici même).
> >
> > Il y a de nombreuses relations qui n'ont qu'une partie de la rue (sans
> > parler des rues sans adresses). Ca veut dire que tous les segments de
> > rues qui ne sont pas dans la relation n'auront pas de code fantoir !
> > Soit vous forcez tout le monde à mettre tous les segments de la rue
> > dans la relation (ce qui serait en quelque sorte une redéfinition de
> > la relation qui n'était pas faite pour ça à l'origine), soit vous
> > laissez le code sur les ways. Je croyais que le code fantoir était lié
> > aux voies, pas aux adresses. Et là, on mélange un peu les serviettes
> > et les torchons.
>


Ce que nous connaissons de FANTOIR ne contient effectivement que les voies,
mais je pense que son usage interne est d'être une base aux adresses des
propriétés (parcelles, bâti) et ainsi que des contribuables, non ?

De toute façon, les noms de voies et de lieux-dits servent bien à la base à
fixer des adresses ou alors un truc m'échappe dans ton message.

Mettre le ref:FR:FANTOIR sur la relation (quand elle existe) évite de le
répéter sur chaque tronçon de voie et aussi de retrouver facilement toutes
adresses qui y sont liées.

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

Re: [OSM-talk-fr] Du Fantoir

2014-01-08 Par sujet Nicolas Dumoulin

Le mercredi 8 janvier 2014 13:47:08 Tetsuo Shima a écrit :
> Fantoir ne fait pas que les voie, il fait aussi les lieux dits et il y
> en a beaucoup, ce qui explique notament les statistique parfois
> bizarre de la couche QA, ou des villages ont toutes les rues taggé
> correctement et ou il est affiché seulement 50%.

J'ai jeté un œuil sur ma commune et apparemment Christian n'inclue pas les 
lieux-dits dans les stats, uniquement les voies ("type de voie" == 1 à la 
colonne 109).

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Du Fantoir

2014-01-08 Par sujet V de Chateau-Thierry

Bonjour,

> De : "Pieren"
>
> Il y a de nombreuses relations qui n'ont qu'une partie de la rue (sans
> parler des rues sans adresses). Ca veut dire que tous les segments de
> rues qui ne sont pas dans la relation n'auront pas de code fantoir !
> Soit vous forcez tout le monde à mettre tous les segments de la rue
> dans la relation (ce qui serait en quelque sorte une redéfinition de
> la relation qui n'était pas faite pour ça à l'origine), soit vous
> laissez le code sur les ways. Je croyais que le code fantoir était lié
> aux voies, pas aux adresses. Et là, on mélange un peu les serviettes
> et les torchons.

Mettre tous les segments dans la relation apporterait un intérêt à cette 
construction
un peu informe qu'est la relation associatedStreet. Avec une incitation claire 
à intégrer
tous les ways, on gagnerait en homogénéité, et on pourrait envisager des usages 
de 
façon plus fiable, sans avoir à se demander où est le morceau de rue inclus 
dans la
relation, ni quelle proportion de la géométrie complète de la rue il couvre.

vincent

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

Re: [OSM-talk-fr] Du Fantoir

Fantoir ne fait pas que les voie, il fait aussi les lieux dits et il y
en a beaucoup, ce qui explique notament les statistique parfois
bizarre de la couche QA, ou des villages ont toutes les rues taggé
correctement et ou il est affiché seulement 50%.

Pour le probleme des "voie adresse" vs "segment de voie" ne serait il
pas envisageable d'imposer une relation associated street par voie ...
et par lieu dit. Relation qui matérialiserait la voie logique elle
meme, et pas juste les segment physique que sont les way.

On pourrait meme alors virer les name des way ... et se baser sur la
relation pour dessiner les nom des voie. Bon je sais c'est extreme,
mais c'est plus logique que la succession de segment avec le nom
recopié a l'infini sur chaque petit bout.

Le 8 janvier 2014 13:32, Pieren  a écrit :
> 2014/1/8 Nicolas Dumoulin :
>
>>> Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ?
>> Après, est-ce que ça va être pratique ? Est-ce que les contributeurs 
>> débutants
>> vont s'y retrouver et pas tout casser ? Quand les outils d'édition 
>> permettrant
>> de gérer ça simplement sans faire d'erreur ?
>
> Euh, au risque de me répéter, je pense que mettre le code fantoir sur
> une relation associatedStreet est, au final, une très, très mauvaise
> idée (je sais, c'est dans le wiki, c'est moi qui l'ait mis, mais je ne
> faisais qu'officialiser ce qui était dit ici même).
>
> Il y a de nombreuses relations qui n'ont qu'une partie de la rue (sans
> parler des rues sans adresses). Ca veut dire que tous les segments de
> rues qui ne sont pas dans la relation n'auront pas de code fantoir !
> Soit vous forcez tout le monde à mettre tous les segments de la rue
> dans la relation (ce qui serait en quelque sorte une redéfinition de
> la relation qui n'était pas faite pour ça à l'origine), soit vous
> laissez le code sur les ways. Je croyais que le code fantoir était lié
> aux voies, pas aux adresses. Et là, on mélange un peu les serviettes
> et les torchons.
>
> Pieren
>
> ___
> 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] Du Fantoir

On le met sur la relation quand on a une relation, ça factorise. Mais je ne
vois de problème à le mettre sur des ways.

associatedStreet c'est plus qu'une relation pour les adresses, ça regroupe
les composantes d'une rue.


Le 8 janvier 2014 13:32, Pieren  a écrit :

> 2014/1/8 Nicolas Dumoulin :
>
> >> Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ?
> > Après, est-ce que ça va être pratique ? Est-ce que les contributeurs
> débutants
> > vont s'y retrouver et pas tout casser ? Quand les outils d'édition
> permettrant
> > de gérer ça simplement sans faire d'erreur ?
>
> Euh, au risque de me répéter, je pense que mettre le code fantoir sur
> une relation associatedStreet est, au final, une très, très mauvaise
> idée (je sais, c'est dans le wiki, c'est moi qui l'ait mis, mais je ne
> faisais qu'officialiser ce qui était dit ici même).
>
> Il y a de nombreuses relations qui n'ont qu'une partie de la rue (sans
> parler des rues sans adresses). Ca veut dire que tous les segments de
> rues qui ne sont pas dans la relation n'auront pas de code fantoir !
> Soit vous forcez tout le monde à mettre tous les segments de la rue
> dans la relation (ce qui serait en quelque sorte une redéfinition de
> la relation qui n'était pas faite pour ça à l'origine), soit vous
> laissez le code sur les ways. Je croyais que le code fantoir était lié
> aux voies, pas aux adresses. Et là, on mélange un peu les serviettes
> et les torchons.
>
> Pieren
>
> ___
> 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] Du Fantoir

2014/1/8 Nicolas Dumoulin :

>> Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ?
> Après, est-ce que ça va être pratique ? Est-ce que les contributeurs débutants
> vont s'y retrouver et pas tout casser ? Quand les outils d'édition permettrant
> de gérer ça simplement sans faire d'erreur ?

Euh, au risque de me répéter, je pense que mettre le code fantoir sur
une relation associatedStreet est, au final, une très, très mauvaise
idée (je sais, c'est dans le wiki, c'est moi qui l'ait mis, mais je ne
faisais qu'officialiser ce qui était dit ici même).

Il y a de nombreuses relations qui n'ont qu'une partie de la rue (sans
parler des rues sans adresses). Ca veut dire que tous les segments de
rues qui ne sont pas dans la relation n'auront pas de code fantoir !
Soit vous forcez tout le monde à mettre tous les segments de la rue
dans la relation (ce qui serait en quelque sorte une redéfinition de
la relation qui n'était pas faite pour ça à l'origine), soit vous
laissez le code sur les ways. Je croyais que le code fantoir était lié
aux voies, pas aux adresses. Et là, on mélange un peu les serviettes
et les torchons.

Pieren

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

Re: [OSM-talk-fr] Du Fantoir

C’est toujours la question sempiternelle : faut-il tout décrire y compris les 
relations spatiales (was « is_in »)? D’un point de vue sgbd, plusieurs adresses 
mais une seule rue. Nous n’avons jamais indiqué que telle rue appartient à 
telle commune (il faudrait une relation de l’ensemble des voies de la commune). 
On se base sur la relations spatiale, non ?
Le vrai problème, c’est hétérogénéité des méthodes et, donc, la réutilisation 
des données pour tout type de public (du lambda à l’expert).

De : Frédéric Rodrigo [mailto:fred.rodr...@gmail.com]
Envoyé : mercredi 8 janvier 2014 13:23
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Du Fantoir

Le problème c'est que du coup il est moins facile déterminer dans qu'elle 
commune est la rue !

Le 8 janvier 2014 13:17, HELFER Denis 
mailto:denis.hel...@rff.fr>> a écrit :
Ce qui m'a fait hésiter à adopter la solution de deux relations, c'est que les 
numéros sont cohérents ; il n'y a pas de doublons sinon la question eût été 
résolue.

-Message d'origine-
De : Tetsuo Shima [mailto:tets...@gmail.com]
Envoyé : mercredi 8 janvier 2014 13:04
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Du Fantoir
C'est assez courant, d'avoir une rue avec le meme nom a cheval sur deux 
communes. Parfois le nom change un tout petit peu, genre rue de machin chose, 
puis route de machin chose, mais souvent le nom reste, seul la numérotation 
change. Et effectivement a chaque fois je fais deux relations, de toutes façon 
sinon les numéro se chevauche et on a des doublons.

Le 8 janvier 2014 12:43, Nicolas Dumoulin 
mailto:nicolas_openstreetmap@dumoulin63.net>>
 a écrit :
> Le mercredi 8 janvier 2014 12:30:20 Christian Quest a écrit :
>> Les adresses d'une partie de la rue doivent correspondre à une
>> commune et le reste à l'autre commune, non ?
>>
>> Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ?
>
> Logique, oui c'est sûr.
>
> Après, est-ce que ça va être pratique ? Est-ce que les contributeurs
> débutants vont s'y retrouver et pas tout casser ? Quand les outils
> d'édition permettrant de gérer ça simplement sans faire d'erreur ?
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
> ___
> 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

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

Re: [OSM-talk-fr] Du Fantoir

Le problème c'est que du coup il est moins facile déterminer dans qu'elle
commune est la rue !


Le 8 janvier 2014 13:17, HELFER Denis  a écrit :

> Ce qui m'a fait hésiter à adopter la solution de deux relations, c'est que
> les numéros sont cohérents ; il n'y a pas de doublons sinon la question eût
> été résolue.
>
> -Message d'origine-
> De : Tetsuo Shima [mailto:tets...@gmail.com]
> Envoyé : mercredi 8 janvier 2014 13:04
> À : Discussions sur OSM en français
> Objet : Re: [OSM-talk-fr] Du Fantoir
>
> C'est assez courant, d'avoir une rue avec le meme nom a cheval sur deux
> communes. Parfois le nom change un tout petit peu, genre rue de machin
> chose, puis route de machin chose, mais souvent le nom reste, seul la
> numérotation change. Et effectivement a chaque fois je fais deux relations,
> de toutes façon sinon les numéro se chevauche et on a des doublons.
>
> Le 8 janvier 2014 12:43, Nicolas Dumoulin <
> nicolas_openstreetmap@dumoulin63.net> a écrit :
> > Le mercredi 8 janvier 2014 12:30:20 Christian Quest a écrit :
> >> Les adresses d'une partie de la rue doivent correspondre à une
> >> commune et le reste à l'autre commune, non ?
> >>
> >> Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ?
> >
> > Logique, oui c'est sûr.
> >
> > Après, est-ce que ça va être pratique ? Est-ce que les contributeurs
> > débutants vont s'y retrouver et pas tout casser ? Quand les outils
> > d'édition permettrant de gérer ça simplement sans faire d'erreur ?
> >
> > --
> > Nicolas Dumoulin
> > http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
> >
> > ___
> > 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Du Fantoir

Ce qui m'a fait hésiter à adopter la solution de deux relations, c'est que les 
numéros sont cohérents ; il n'y a pas de doublons sinon la question eût été 
résolue.

-Message d'origine-
De : Tetsuo Shima [mailto:tets...@gmail.com] 
Envoyé : mercredi 8 janvier 2014 13:04
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Du Fantoir

C'est assez courant, d'avoir une rue avec le meme nom a cheval sur deux 
communes. Parfois le nom change un tout petit peu, genre rue de machin chose, 
puis route de machin chose, mais souvent le nom reste, seul la numérotation 
change. Et effectivement a chaque fois je fais deux relations, de toutes façon 
sinon les numéro se chevauche et on a des doublons.

Le 8 janvier 2014 12:43, Nicolas Dumoulin 
 a écrit :
> Le mercredi 8 janvier 2014 12:30:20 Christian Quest a écrit :
>> Les adresses d'une partie de la rue doivent correspondre à une 
>> commune et le reste à l'autre commune, non ?
>>
>> Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ?
>
> Logique, oui c'est sûr.
>
> Après, est-ce que ça va être pratique ? Est-ce que les contributeurs 
> débutants vont s'y retrouver et pas tout casser ? Quand les outils 
> d'édition permettrant de gérer ça simplement sans faire d'erreur ?
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
> ___
> 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] Du Fantoir

C'est assez courant, d'avoir une rue avec le meme nom a cheval sur
deux communes. Parfois le nom change un tout petit peu, genre rue de
machin chose, puis route de machin chose, mais souvent le nom reste,
seul la numérotation change. Et effectivement a chaque fois je fais
deux relations, de toutes façon sinon les numéro se chevauche et on a
des doublons.

Le 8 janvier 2014 12:43, Nicolas Dumoulin
 a écrit :
> Le mercredi 8 janvier 2014 12:30:20 Christian Quest a écrit :
>> Les adresses d'une partie de la rue doivent correspondre à une commune et
>> le reste à l'autre commune, non ?
>>
>> Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ?
>
> Logique, oui c'est sûr.
>
> Après, est-ce que ça va être pratique ? Est-ce que les contributeurs débutants
> vont s'y retrouver et pas tout casser ? Quand les outils d'édition permettrant
> de gérer ça simplement sans faire d'erreur ?
>
> --
> Nicolas Dumoulin
> http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin
>
> ___
> 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] Petite idée de présentation

2014-01-08 Par sujet David Crochet


Bonjour

Peut-être le faire sous forme d'un diaporama (mise à jour plus facile, 
ajout d'information,)


Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] Du Fantoir

2014-01-08 Par sujet Nicolas Dumoulin

Le mercredi 8 janvier 2014 12:30:20 Christian Quest a écrit :
> Les adresses d'une partie de la rue doivent correspondre à une commune et
> le reste à l'autre commune, non ?
> 
> Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ?

Logique, oui c'est sûr.

Après, est-ce que ça va être pratique ? Est-ce que les contributeurs débutants 
vont s'y retrouver et pas tout casser ? Quand les outils d'édition permettrant 
de gérer ça simplement sans faire d'erreur ?

-- 
Nicolas Dumoulin
http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin

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

Re: [OSM-talk-fr] Du Fantoir

Les adresses d'une partie de la rue doivent correspondre à une commune et
le reste à l'autre commune, non ?

Ca me semblerait logique d'avoir 2 associatedStreet, pas vous ?


Le 8 janvier 2014 12:26, HELFER Denis  a écrit :

>  La même chose entre Zillisheim et Flaxlanden ici :
> http://tile.openstreetmap.fr/?zoom=19&lat=47.69681&lon=7.30695&layers=B000FF
>
> J’ai pris le parti d’une seule relation.
>
>
>
> Denis
>
>
>
> *De :* Romain MEHUT [mailto:romain.me...@gmail.com]
> *Envoyé :* mercredi 8 janvier 2014 12:23
> *À :* Discussions sur OSM en français
> *Objet :* Re: [OSM-talk-fr] Du Fantoir
>
>
>
> Le 8 janvier 2014 12:14, Marc SIBERT  a écrit :
>
> Un exemple ? Une rue commune a deux communes :-) ?
>
> cf.
> http://addr.openstreetmap.fr/nancy/?zoom=19&lat=48.68871&lon=6.15494&layers=BT&item=100
>
> Bien vu c'est ça l'explication. Un morceau dans Nancy et un autre dans
> Laxou. Mais du coup, ça va faire 2 relations AssociatedStreet avec le même
> nom de rue.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] Du Fantoir

La même chose entre Zillisheim et Flaxlanden ici : 
http://tile.openstreetmap.fr/?zoom=19&lat=47.69681&lon=7.30695&layers=B000FF
J'ai pris le parti d'une seule relation.

Denis

De : Romain MEHUT [mailto:romain.me...@gmail.com]
Envoyé : mercredi 8 janvier 2014 12:23
À : Discussions sur OSM en français
Objet : Re: [OSM-talk-fr] Du Fantoir

Le 8 janvier 2014 12:14, Marc SIBERT mailto:m...@sibert.fr>> a 
écrit :

Un exemple ? Une rue commune a deux communes :-) ?
cf. 
http://addr.openstreetmap.fr/nancy/?zoom=19&lat=48.68871&lon=6.15494&layers=BT&item=100
Bien vu c'est ça l'explication. Un morceau dans Nancy et un autre dans Laxou. 
Mais du coup, ça va faire 2 relations AssociatedStreet avec le même nom de rue.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Du Fantoir

Le 8 janvier 2014 12:14, Marc SIBERT  a écrit :

> Un exemple ? Une rue commune a deux communes :-) ?
>
cf.
http://addr.openstreetmap.fr/nancy/?zoom=19&lat=48.68871&lon=6.15494&layers=BT&item=100
Bien vu c'est ça l'explication. Un morceau dans Nancy et un autre dans
Laxou. Mais du coup, ça va faire 2 relations AssociatedStreet avec le même
nom de rue.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Du Fantoir

2014-01-08 Par sujet Marc SIBERT

Un exemple ? Une rue commune a deux communes :-) ?

--
Marc
m...@sibert.fr
Le 8 janv. 2014 11:56, "Romain MEHUT"  a écrit :

> Bonjour,
>
> On fait comment quand une même rue possède 2 ref Fantoir différents?
>
> Romain
>
> Le 7 janvier 2014 22:12, Frédéric Rodrigo  a
> écrit :
>
> ___
> 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] Du Fantoir