Re: [OSM-talk-fr] Alignement cadastre

[Jean-Francois Nifenecker]

Le 09/10/2012 23:01, Pieren a écrit :

Il faudrait signaler ce problème soit à la DGFiP, soit au CDIF local
pour que ce soit corrigé. En même temps, il est probable qu'ils soient
déjà au courant (les géomètres experts devraient s'en rendre compte
avant nous) mais qu'il n'y ait pas de budget pour refaire le plan...


je m'interroge sur les éventuels conflits de voisinage lorsque, pour les 
résoudre, il faut faire appel au Cadastre...


--
Jean-Francois Nifenecker, Bordeaux

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

Re: [OSM-talk-fr] Osmose a changé de peau

[Jean-Francois Nifenecker]

Le 09/10/2012 21:20, Etienne Trimaille a écrit :

Le 9 octobre 2012 21:01, Jean-Francois Nifenecker
mailto:jean-francois.nifenec...@laposte.net>> a écrit :

l'interface d'OsmOse a changé : précédemment en regard de chaque
type d'erreur figurait son niveau (1, 2 ou 3). Cette information a
disparu. C'est dommage car je la trouvais très intéressante. J'ai
loupé qqch ou bien ?


C'est la "gravité" des erreurs.
Rouge, niveau 1
orange, niveau 2
et jaune le niveau 3.


Ahah !

Sauf que, sur mon poste et par défaut, la langue est "en" et que, en 
habitué de la langue de Guillaume Hochepoire, je n'avais pas changé. 
Dans mon cas, pas de points de couleur : suite à ton message je les ai 
cherchés un bon moment ces %$§& points...


Lorsque l'on choisi FR, alors plusieurs nouveautés : la fenêtre Osmose 
est par dessus la carte glissante et les merveilleux points sont là 
(suggestion : mettre le niveau en clair car la relation couleur-niveau 
n'est pas implicite).
-> Il semble que, lors de la transition de mode d'affichage entre 
l'ancien mode (sans les points) et le nouveau (avec), mon Firefox n'ait 
pas mis à jour son cache. Qu'on se le dise !


Note : je rejoins l'avis de Francescu. Lorsque l'on choisi "rien", eh 
bien c'est qu'on ne veut *rien* et non les erreurs par défaut. C'est 
assez perturbant au début. Bon, après, on s'y fait.

En matière d'usage je verrais :
-- choix d'un niveau -> les erreurs pour ce niveau
-- "rien" -> aucune erreur
-- "tout" -> toutes les erreurs pour le niveau sélectionné

Merci Étienne !
--
Jean-Francois Nifenecker, Bordeaux

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

Re: [OSM-talk-fr] Alignement cadastre

[Stéphane Péneau]

Mappant principalement en zone rurale, la plupart du temps, je pars du 
principe que le cadastre est décalé...


Mais... je suis impatient de voir ce que va donner le remaniement 
cadastrale dans les communes que je connais.


je m'interroge sur les éventuels conflits de voisinage lorsque, pour 
les résoudre, il faut faire appel au Cadastre...


Il n'est pas fait pour ça, et n'a pas de valeur légale dans ce genre de 
situation.


Stf

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

Re: [OSM-talk-fr] Osmose a changé de peau

[Stéphane Péneau]

Je rejoins les autres avis, si "rien" c'est "tout" alors autant 
supprimer le bouton "rien" puisque sa fonction est identique à "tout".


Dommage qu'il n'y ait pas le petit champs de recherche de lieu qu'on a 
sur openlayer.
A ce propos, quel est l'intérêt d'openlayer puisqu'on retrouve les même 
infos dans osmose ? Est-ce que ce ne serait pas plus judicieux de 
fusionner les 2 services ?



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

Re: [OSM-talk-fr] Osmose a changé de peau

[Stéphane Péneau]

Sur mon ordi, avec firefox, le lien "permalink" est superposé aux infos 
de coordonnées. Je suis le seul dans ce cas ?


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

Re: [OSM-talk-fr] Alignement cadastre

[Art Penteur]

Le 9 octobre 2012 20:51, Jean-Francois Nifenecker
 a écrit :
> Bonsoir,
>
> au cours de mes pérégrinations correctrices, j'ai rencontré un cas de bâti
> mal calé.
>[...]
>
> Ma "confiance" dans le Cadastre s'émousse très fortement...
>
> Quelles sont vos expériences ?

  J'ai de moins en moins confiance dans le cadastre en Haute-Garonne.
j'ai rencontré ce genre de décalage à Merville (au nord de Toulouse)
et dans une commune au sud-est (Je ne sais plus laquelle. Péchabou ?).

Bruno.

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

Re: [OSM-talk-fr] Frontière Guyane-Brésil

[Pieren]

2012/10/10 partir-en-vtt :

>
> Sur quelles données se baser sur des frontières aussi "difficiles" ?
>

Pour la partie terrestre, je me souviens d'un reportage sur un groupe
de légionnaires qui partaient en expédition pour dégager de grosses
bornes en béton qui marquaient la frontière au milieu de la forêt
vierge. Mais ça n'est pas le cadastre, hein, c'est genre "une borne
tous les 30 kms". Leurs coordonnées GPS doivent être connues et on
pourrait peut-être même les repérer sur les images aériennes si la
résolution est suffisante.
Sinon, les frontières sont définies par des traités internationaux et
utilisent souvent un cour d'eau comme repère simple. Donc les tracer
depuis l'imagerie aérienne a du sens sauf qu'il faut faire une
confiance toute relative au positionnement des images (mais c'est déjà
mieux que le tracé grossier de l'import CIA World Database actuel). La
difficulté peut aussi venir sur les îlots et branches multiples du
fleuve. Il est possible qu'il reste encore des désaccords sur la
position exacte de la frontière au mètre près et donc de
l'appartenance de tel ou tel îlot. Le mieux serait de comparer les
cartes officielles françaises et brésiliennes. D'après ce que j'ai
compris, seule la frontière sur le Rhin avec l'Allemagne a été très
précisement définie pour des raisons de droit et de recherche de
responsabilités en cas d'accident, et ce, dans un traité signé très
récemment (début des années 2000).

Pieren

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

Re: [OSM-talk-fr] Alignement cadastre

[Christian Quest]

Il ne faut pas non plus exagérer ni généraliser, tant dans un sens (le
cadastre est LA référence) que dans l'autre (le cadastre est vraiment
mal calé).

C'est du cas par cas et c'est une des raisons pour lesquelles on
l'intègre après un contrôle/travail que seul un humain peut faire en
recoupant les sources.

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

[OSM-talk-fr] IGN et data.ign.fr

[Cyrille Giquello]

Bonjour,

Extract:
Data.ign.fr est un site expérimental pour la diffusion de données de
l'IGN au format des Linked data. Il est mis en place dans le contexte
du projet collaboratif Datalift financé par l'Agence Nationale de la
Recherche (CONTINT 2010). L'objectif de ce projet est de mettre au
point une plate-forme pour la publication et l'interconnexion de
contenu selon le modèle des Linked data (formats RDF, OWL, SPARQL).

http://data.ign.fr/

Pour l'instant c'est pauvre en données :
Ontologie topographique : topo.owl
Données administratives : SPARQL Endpoint

-- 
Cyrille.

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

Re: [OSM-talk-fr] Comment décrire une borne qui rentre dans le sol?

[Pieren]

2012/9/20 Jean-Marc Liotier :

> Nan, liftgate c'est
> http://www.securityproductsolutions.com/Images/traffic-gate-3.jpg
>
> La borne au sol genre bite d'amarrage c'est "bollard" - et rentrant dans
> le sol ce serait donc barrier=rising_bollard

J'ai trouvé dans le wiki "barrier=bollard" + "bollard=rising" avec 291
occurences dans taginfo
(http://wiki.openstreetmap.org/wiki/Key:bollard). Donc beaucoup plus
que le "barrier=rising_bollard" qui, lui, n'est pas documenté. Les
hollandais proposent même un "automatic=yes"
(http://wiki.openstreetmap.org/wiki/NL:Tag:barrier%3Dbollard#Automatische.2C_.22Rising.22_Pollers)

Pieren

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

Re: [OSM-talk-fr] IGN et data.ign.fr

[Christian Quest]

En gros... GEOFLA en SPARQL ;)

Je suis à Etalab pour la journée à propos de Datalift, le projet de
web sémantique (voir sur http://datalift.org/fr ).


Le 10 octobre 2012 10:44, Cyrille Giquello  a écrit :
> Bonjour,
>
> Extract:
> Data.ign.fr est un site expérimental pour la diffusion de données de
> l'IGN au format des Linked data. Il est mis en place dans le contexte
> du projet collaboratif Datalift financé par l'Agence Nationale de la
> Recherche (CONTINT 2010). L'objectif de ce projet est de mettre au
> point une plate-forme pour la publication et l'interconnexion de
> contenu selon le modèle des Linked data (formats RDF, OWL, SPARQL).
>
> http://data.ign.fr/
>
> Pour l'instant c'est pauvre en données :
> Ontologie topographique : topo.owl
> Données administratives : SPARQL Endpoint
>
> --
> Cyrille.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] IGN et data.ign.fr

[rldhont]

Le 10/10/2012 11:03, Christian Quest a écrit :

En gros... GEOFLA en SPARQL ;)


OKI mais comment on  filtre les information ?
Quels sont les resources RDF que l'on peut utiliser pour filtrer les 
données ?

ça manque d'info quoi ;-)



Je suis à Etalab pour la journée à propos de Datalift, le projet de
web sémantique (voir sur http://datalift.org/fr ).


Le 10 octobre 2012 10:44, Cyrille Giquello  a écrit :

Bonjour,

Extract:
Data.ign.fr est un site expérimental pour la diffusion de données de
l'IGN au format des Linked data. Il est mis en place dans le contexte
du projet collaboratif Datalift financé par l'Agence Nationale de la
Recherche (CONTINT 2010). L'objectif de ce projet est de mettre au
point une plate-forme pour la publication et l'interconnexion de
contenu selon le modèle des Linked data (formats RDF, OWL, SPARQL).

http://data.ign.fr/

Pour l'instant c'est pauvre en données :
 Ontologie topographique : topo.owl
 Données administratives : SPARQL Endpoint

--
Cyrille.

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






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

Re: [OSM-talk-fr] Tuteurs pour volontaires européens ?

[Marc SIBERT]

Bonjour,

Je "up" le sujet et j'en profite pour répondre positivement à cette demande
de support à distance.
Par contre, et sauf erreur, je n'ai pas vu de présentation de volontaire
sur le forum.

A+

Marc

Le 4 octobre 2012 18:32, Christian Quest  a écrit :

> Demain se termine la formation EUROSHA de volontaires européens à
> laquelle je participe depuis le début de la semaine.
>
> De quoi s'agit-il ?
>
> Un vingtaine de volontaires ont suivit une formation de 3 semaines
> avant de partir dans différents pays d'Afrique (Burundi, Kenya, Tchad
> et Centrafrique) dans les semaines qui vont venir pour y faire de la
> cartographie à visée humanitaire sur OpenStreetMap.
>
> La formation OpenStreetMap s'est déroulée sur 4 jours (seulement) et a
> été très dense car elle couvrait: la présentation du projet avec le
> concept de licence libre de logiciels libres, de crowdsourcing, puis
> un aperçu des outils de contributions de l'imagerie aérienne, de la
> préparation d'une collecte sur le terrain, une cartopartie avec
> relevés par GPS, logger, walking papers et photos géotaguées, puis
> saisie dans JOSM, puis les outils de contrôle de qualité, les outils
> de coordination (OSM Task Manager d'HOT), et on va attaquer la partie
> exploitation des données.
>
> Vous imaginez bien que tout ça en 4 jours c'est un peu lourd à
> digérer... et qu'il va falloir consolider tout ça.
>
> Ils partent en mission dans les semaines à venir, et vont donc
> rapidement avoir à mettre les mains dans le cambouis et besoin d'être
> aidés.
>
> Je propose donc à ceux qui le souhaite et qui se sentent capable de
> prendre par la main des débutants d'avoir un rôle de tuteur et j'ai
> invité les volontaires francophones à venir sur
> http://forum.openstreetmap.fr/ pour se présenter pour qu'un tuteur
> puisse les suivre.
>
> Dans un premier temps, il s'agit essentiellement d'aider à prendre en
> main JOSM et de gagner en efficacité ainsi que de suivre les tracés de
> routes et de bâtiments faits sur les images bing dans leur zone de
> déploiement.
> Les règles de tagging seront à voir dans un deuxième temps, et elles
> sont un peu spécifiques à l'humanitaires et parfois différentes par
> rapport à nos habitudes.
>
> Plus d'infos:
> - http://hot.openstreetmap.org/projects/eurosha_0
> - http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team/Tutorships
>
> --
> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Alignement cadastre

[Jean-Francois Nifenecker]

Le 10/10/2012 10:28, Christian Quest a écrit :

Il ne faut pas non plus exagérer ni généraliser, tant dans un sens (le
cadastre est LA référence) que dans l'autre (le cadastre est vraiment
mal calé).

C'est du cas par cas et c'est une des raisons pour lesquelles on
l'intègre après un contrôle/travail que seul un humain peut faire en
recoupant les sources.



D'où l'intérêt immense qu'il y a de bien prévenir lors de l'intégration 
du bâti (voir autres discussions sur ce sujet).


Lorsque j'ai débuté cette intégration, il y a bien longtemps, j'ai 
commis moult erreurs involontaires (pas vrai Fred ?) sans bien mesurer 
toutes les particularités qui se rattachent au bâti intégré (bref, j'ai 
fait un peu bourrin). Tout particulièrement les décalages, quasi 
inexistants dans les zones urbaines que j'ai d'abord "traitées". C'est 
aujourd'hui que j'aborde les zones rurales par le petit bout de la 
lorgnette (Osmose) que je vois qu'il y a Cadastre et Cadastre.


D'autres problèmes comme les bâtiments se recouvrant et les interstices 
entre bâtiments (points de jonction non déclarés) montrent que 
l'intégration devrait se faire groupe de maisons par groupe de maisons 
tant les détails sont infimes (et pas toujours relevés par le validateur 
JOSM).


Ce qui montre l'importance de vérifier avec *très* grand soin avant 
l'intégration. Celle-ci ne peut donc pas être rapide, il faut que les 
contributeurs en aient conscience.



Quoi qu'il en soit, oui, le Cadastre est une bonne source de données, 
oui Bing est une bonne source de données et *grand merci* à tous ceux 
qui ont créé les outils permettant de les exploiter et de vérifier la 
qualité des données. C'est sur ce dernier terrain que nous serons 
j(a)ugés et c'est celui-là que nous devons améliorer.


Amicalement,
--
Jean-Francois Nifenecker, Bordeaux

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

Re: [OSM-talk-fr] Tuteurs pour volontaires européens ?

[Christian Quest]

Ca va venir, j'attendais d'avoir quelques tuteurs en stock pour leur
refaire signe...


Le 10 octobre 2012 11:14, Marc SIBERT  a écrit :
> Bonjour,
>
> Je "up" le sujet et j'en profite pour répondre positivement à cette demande
> de support à distance.
> Par contre, et sauf erreur, je n'ai pas vu de présentation de volontaire sur
> le forum.
>
> A+
>
> Marc
>
> Le 4 octobre 2012 18:32, Christian Quest  a écrit :
>
>> Demain se termine la formation EUROSHA de volontaires européens à
>> laquelle je participe depuis le début de la semaine.
>>
>> De quoi s'agit-il ?
>>
>> Un vingtaine de volontaires ont suivit une formation de 3 semaines
>> avant de partir dans différents pays d'Afrique (Burundi, Kenya, Tchad
>> et Centrafrique) dans les semaines qui vont venir pour y faire de la
>> cartographie à visée humanitaire sur OpenStreetMap.
>>
>> La formation OpenStreetMap s'est déroulée sur 4 jours (seulement) et a
>> été très dense car elle couvrait: la présentation du projet avec le
>> concept de licence libre de logiciels libres, de crowdsourcing, puis
>> un aperçu des outils de contributions de l'imagerie aérienne, de la
>> préparation d'une collecte sur le terrain, une cartopartie avec
>> relevés par GPS, logger, walking papers et photos géotaguées, puis
>> saisie dans JOSM, puis les outils de contrôle de qualité, les outils
>> de coordination (OSM Task Manager d'HOT), et on va attaquer la partie
>> exploitation des données.
>>
>> Vous imaginez bien que tout ça en 4 jours c'est un peu lourd à
>> digérer... et qu'il va falloir consolider tout ça.
>>
>> Ils partent en mission dans les semaines à venir, et vont donc
>> rapidement avoir à mettre les mains dans le cambouis et besoin d'être
>> aidés.
>>
>> Je propose donc à ceux qui le souhaite et qui se sentent capable de
>> prendre par la main des débutants d'avoir un rôle de tuteur et j'ai
>> invité les volontaires francophones à venir sur
>> http://forum.openstreetmap.fr/ pour se présenter pour qu'un tuteur
>> puisse les suivre.
>>
>> Dans un premier temps, il s'agit essentiellement d'aider à prendre en
>> main JOSM et de gagner en efficacité ainsi que de suivre les tracés de
>> routes et de bâtiments faits sur les images bing dans leur zone de
>> déploiement.
>> Les règles de tagging seront à voir dans un deuxième temps, et elles
>> sont un peu spécifiques à l'humanitaires et parfois différentes par
>> rapport à nos habitudes.
>>
>> Plus d'infos:
>> - http://hot.openstreetmap.org/projects/eurosha_0
>> - http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team/Tutorships
>>
>> --
>> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] IGN et data.ign.fr

[Christian Quest]

Peace and LOV !

http://lov.okfn.org/dataset/lov/details/vocabularySpace_Space.html

Les vocabulaires (ontology) liés aux données géographiques...


Le 10 octobre 2012 11:06, rldhont  a écrit :
> Le 10/10/2012 11:03, Christian Quest a écrit :
>
>> En gros... GEOFLA en SPARQL ;)
>
>
> OKI mais comment on  filtre les information ?
> Quels sont les resources RDF que l'on peut utiliser pour filtrer les données
> ?
> ça manque d'info quoi ;-)
>
>
>>
>> Je suis à Etalab pour la journée à propos de Datalift, le projet de
>> web sémantique (voir sur http://datalift.org/fr ).
>>
>>
>> Le 10 octobre 2012 10:44, Cyrille Giquello  a écrit :
>>>
>>> Bonjour,
>>>
>>> Extract:
>>> Data.ign.fr est un site expérimental pour la diffusion de données de
>>> l'IGN au format des Linked data. Il est mis en place dans le contexte
>>> du projet collaboratif Datalift financé par l'Agence Nationale de la
>>> Recherche (CONTINT 2010). L'objectif de ce projet est de mettre au
>>> point une plate-forme pour la publication et l'interconnexion de
>>> contenu selon le modèle des Linked data (formats RDF, OWL, SPARQL).
>>>
>>> http://data.ign.fr/
>>>
>>> Pour l'instant c'est pauvre en données :
>>>  Ontologie topographique : topo.owl
>>>  Données administratives : SPARQL Endpoint
>>>
>>> --
>>> Cyrille.
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] Alignement cadastre

[Ab_fab]

Est-ce qu'il serait possible de faire une visualisation combinant :

_ Les limites communales osm (on peut prendre celle de
layers.openstreetmap.fr)
_ Les limites communales geofla (ça doit pouvoir se trouver quelque part)
_ les limites communales individuelles des communes, provenant du dépôt
cadastre

Pour ce dernier point, on pourrait avoir une couche de tuiles, ou bien
générer les contours à la volée d'une commune à étudier et de celles de ses
voisines.

Pour le peu d'import de bâti que j'ai fait, j'ai constaté un décalage pour
la commune de Lassouts
(12)alors
que les communes alentours semblaient cohérentes entre elles, au
moins au niveau des limites admin.
L'outil état-communes (cf. lien pour lassouts) donnant les communes
limitrophes, je me dis que cela ne doit pas hors de portée.

Si on a de plus la possibilité d'afficher la couche d'imagerie Bing et les
points géodésiques, ça pourrait faire un bon outil de vérif par croisement
des sources à disposition

Le 10 octobre 2012 11:26, Jean-Francois Nifenecker <
jean-francois.nifenec...@laposte.net> a écrit :

> Le 10/10/2012 10:28, Christian Quest a écrit :
>
>  Il ne faut pas non plus exagérer ni généraliser, tant dans un sens (le
>> cadastre est LA référence) que dans l'autre (le cadastre est vraiment
>> mal calé).
>>
>> C'est du cas par cas et c'est une des raisons pour lesquelles on
>> l'intègre après un contrôle/travail que seul un humain peut faire en
>> recoupant les sources.
>>
>>
> D'où l'intérêt immense qu'il y a de bien prévenir lors de l'intégration du
> bâti (voir autres discussions sur ce sujet).
>
> Lorsque j'ai débuté cette intégration, il y a bien longtemps, j'ai commis
> moult erreurs involontaires (pas vrai Fred ?) sans bien mesurer toutes les
> particularités qui se rattachent au bâti intégré (bref, j'ai fait un peu
> bourrin). Tout particulièrement les décalages, quasi inexistants dans les
> zones urbaines que j'ai d'abord "traitées". C'est aujourd'hui que j'aborde
> les zones rurales par le petit bout de la lorgnette (Osmose) que je vois
> qu'il y a Cadastre et Cadastre.
>
> D'autres problèmes comme les bâtiments se recouvrant et les interstices
> entre bâtiments (points de jonction non déclarés) montrent que
> l'intégration devrait se faire groupe de maisons par groupe de maisons tant
> les détails sont infimes (et pas toujours relevés par le validateur JOSM).
>
> Ce qui montre l'importance de vérifier avec *très* grand soin avant
> l'intégration. Celle-ci ne peut donc pas être rapide, il faut que les
> contributeurs en aient conscience.
>
>
> Quoi qu'il en soit, oui, le Cadastre est une bonne source de données, oui
> Bing est une bonne source de données et *grand merci* à tous ceux qui ont
> créé les outils permettant de les exploiter et de vérifier la qualité des
> données. C'est sur ce dernier terrain que nous serons j(a)ugés et c'est
> celui-là que nous devons améliorer.
>
> Amicalement,
> --
> Jean-Francois Nifenecker, Bordeaux
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] Osmose a changé de peau

[Mickaël Guéret]

"Rien", c'est différent de "Tout" car cela permet de ne sélectionner
ensuite qu'un seul type d'erreur, en ne cochant que celle-ci dans la
liste plutôt que décocher toutes les autres...

Mika 

Le mercredi 10 octobre 2012 à 09:32 +0200, Stéphane Péneau a écrit :
> Je rejoins les autres avis, si "rien" c'est "tout" alors autant 
> supprimer le bouton "rien" puisque sa fonction est identique à "tout".
> 
> Dommage qu'il n'y ait pas le petit champs de recherche de lieu qu'on a 
> sur openlayer.
> A ce propos, quel est l'intérêt d'openlayer puisqu'on retrouve les même 
> infos dans osmose ? Est-ce que ce ne serait pas plus judicieux de 
> fusionner les 2 services ?
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



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

Re: [OSM-talk-fr] Alignement cadastre

[Christian Quest]

Une couche GEOFLA sur layers.openstreetmap.fr pourrait être facilement
ajoutée et utile.
Pour une couche de limites administratives directement issues du
cadastre, il faudrait toutes les extraire sur les communes en cadastre
vecteur et en faire une couche à part... rien d'insurmontable, je
pense même en avoir une copie "historique" de juin 2010 où j'avais
fait une extraction globale du cadastre.

Pour les communes limitrophes, j'utilise GEOFLA sur l'outil
etat-commune avec un peu de PostGIS.


Le 10 octobre 2012 11:41, Ab_fab  a écrit :
> Est-ce qu'il serait possible de faire une visualisation combinant :
>
> _ Les limites communales osm (on peut prendre celle de
> layers.openstreetmap.fr)
> _ Les limites communales geofla (ça doit pouvoir se trouver quelque part)
> _ les limites communales individuelles des communes, provenant du dépôt
> cadastre
>
> Pour ce dernier point, on pourrait avoir une couche de tuiles, ou bien
> générer les contours à la volée d'une commune à étudier et de celles de ses
> voisines.
>
> Pour le peu d'import de bâti que j'ai fait, j'ai constaté un décalage pour
> la commune de Lassouts (12) alors que les communes alentours semblaient
> cohérentes entre elles, au moins au niveau des limites admin.
> L'outil état-communes (cf. lien pour lassouts) donnant les communes
> limitrophes, je me dis que cela ne doit pas hors de portée.
>
> Si on a de plus la possibilité d'afficher la couche d'imagerie Bing et les
> points géodésiques, ça pourrait faire un bon outil de vérif par croisement
> des sources à disposition
>
> Le 10 octobre 2012 11:26, Jean-Francois Nifenecker
>  a écrit :
>
>> Le 10/10/2012 10:28, Christian Quest a écrit :
>>
>>> Il ne faut pas non plus exagérer ni généraliser, tant dans un sens (le
>>> cadastre est LA référence) que dans l'autre (le cadastre est vraiment
>>> mal calé).
>>>
>>> C'est du cas par cas et c'est une des raisons pour lesquelles on
>>> l'intègre après un contrôle/travail que seul un humain peut faire en
>>> recoupant les sources.
>>>
>>
>> D'où l'intérêt immense qu'il y a de bien prévenir lors de l'intégration du
>> bâti (voir autres discussions sur ce sujet).
>>
>> Lorsque j'ai débuté cette intégration, il y a bien longtemps, j'ai commis
>> moult erreurs involontaires (pas vrai Fred ?) sans bien mesurer toutes les
>> particularités qui se rattachent au bâti intégré (bref, j'ai fait un peu
>> bourrin). Tout particulièrement les décalages, quasi inexistants dans les
>> zones urbaines que j'ai d'abord "traitées". C'est aujourd'hui que j'aborde
>> les zones rurales par le petit bout de la lorgnette (Osmose) que je vois
>> qu'il y a Cadastre et Cadastre.
>>
>> D'autres problèmes comme les bâtiments se recouvrant et les interstices
>> entre bâtiments (points de jonction non déclarés) montrent que l'intégration
>> devrait se faire groupe de maisons par groupe de maisons tant les détails
>> sont infimes (et pas toujours relevés par le validateur JOSM).
>>
>> Ce qui montre l'importance de vérifier avec *très* grand soin avant
>> l'intégration. Celle-ci ne peut donc pas être rapide, il faut que les
>> contributeurs en aient conscience.
>>
>>
>> Quoi qu'il en soit, oui, le Cadastre est une bonne source de données, oui
>> Bing est une bonne source de données et *grand merci* à tous ceux qui ont
>> créé les outils permettant de les exploiter et de vérifier la qualité des
>> données. C'est sur ce dernier terrain que nous serons j(a)ugés et c'est
>> celui-là que nous devons améliorer.
>>
>> Amicalement,
>> --
>> Jean-Francois Nifenecker, Bordeaux
>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> --
> ab_fab
> "Il n'y a pas de pas perdus"
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] Tuteurs pour volontaires européens ?

[Frédéric Rodrigo]

Moi aussi je suis dispo pour ça, en Français ou en Anglais.

Le 10/10/2012 11:27, Christian Quest a écrit :

Ca va venir, j'attendais d'avoir quelques tuteurs en stock pour leur
refaire signe...


Le 10 octobre 2012 11:14, Marc SIBERT  a écrit :

Bonjour,

Je "up" le sujet et j'en profite pour répondre positivement à cette demande
de support à distance.
Par contre, et sauf erreur, je n'ai pas vu de présentation de volontaire sur
le forum.

A+

Marc

Le 4 octobre 2012 18:32, Christian Quest  a écrit :


Demain se termine la formation EUROSHA de volontaires européens à
laquelle je participe depuis le début de la semaine.

De quoi s'agit-il ?

Un vingtaine de volontaires ont suivit une formation de 3 semaines
avant de partir dans différents pays d'Afrique (Burundi, Kenya, Tchad
et Centrafrique) dans les semaines qui vont venir pour y faire de la
cartographie à visée humanitaire sur OpenStreetMap.

La formation OpenStreetMap s'est déroulée sur 4 jours (seulement) et a
été très dense car elle couvrait: la présentation du projet avec le
concept de licence libre de logiciels libres, de crowdsourcing, puis
un aperçu des outils de contributions de l'imagerie aérienne, de la
préparation d'une collecte sur le terrain, une cartopartie avec
relevés par GPS, logger, walking papers et photos géotaguées, puis
saisie dans JOSM, puis les outils de contrôle de qualité, les outils
de coordination (OSM Task Manager d'HOT), et on va attaquer la partie
exploitation des données.

Vous imaginez bien que tout ça en 4 jours c'est un peu lourd à
digérer... et qu'il va falloir consolider tout ça.

Ils partent en mission dans les semaines à venir, et vont donc
rapidement avoir à mettre les mains dans le cambouis et besoin d'être
aidés.

Je propose donc à ceux qui le souhaite et qui se sentent capable de
prendre par la main des débutants d'avoir un rôle de tuteur et j'ai
invité les volontaires francophones à venir sur
http://forum.openstreetmap.fr/ pour se présenter pour qu'un tuteur
puisse les suivre.

Dans un premier temps, il s'agit essentiellement d'aider à prendre en
main JOSM et de gagner en efficacité ainsi que de suivre les tracés de
routes et de bâtiments faits sur les images bing dans leur zone de
déploiement.
Les règles de tagging seront à voir dans un deuxième temps, et elles
sont un peu spécifiques à l'humanitaires et parfois différentes par
rapport à nos habitudes.

Plus d'infos:
- http://hot.openstreetmap.org/projects/eurosha_0
- http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team/Tutorships

--
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest




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








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

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Frédéric Rodrigo]

Le 09/10/2012 16:02, Cyrille Giquello a écrit :

Salut,
Comment taguer name="Commissariat de Secteur de Tours Nord/St Cyr sur Loire" ?
Osmose dit "Le tag name contient deux noms"
(http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#5030)


Laisse Osmose dire ce qu'il veut ! Tu le marque en faux positif si tu 
veux et puis c'est tout.

Par contre Osmose va aussi signaler le "St".

Frédéric.


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

Re: [OSM-talk-fr] Tuteurs pour volontaires européens ?

[Pierre Béland]

Je suis aussi disponible.

 
Pierre 



>
> De : Marc SIBERT 
>À : Discussions sur OSM en français  
>Cc : Severin Menard ; nicolas chavent 
> 
>Envoyé le : Mercredi 10 octobre 2012 5h14
>Objet : Re: [OSM-talk-fr] Tuteurs pour volontaires européens ?
> 
>
>Bonjour,
>
>Je "up" le sujet et j'en profite pour répondre positivement à cette demande de 
>support à distance.
>Par contre, et sauf erreur, je n'ai pas vu de présentation de volontaire sur 
>le forum.
>
>A+
>
>Marc
>
>
>Le 4 octobre 2012 18:32, Christian Quest  a écrit :
>
>Demain se termine la formation EUROSHA de volontaires européens à
>>laquelle je participe depuis le début de la semaine.
>>
>>De quoi s'agit-il ?
>>
>>Un vingtaine de volontaires ont suivit une formation de 3 semaines
>>avant de partir dans différents pays d'Afrique (Burundi, Kenya, Tchad
>>et Centrafrique) dans les semaines qui vont venir pour y faire de la
>>cartographie à visée humanitaire sur OpenStreetMap.
>>
>>La formation OpenStreetMap s'est déroulée sur 4 jours (seulement) et a
>>été très dense car elle couvrait: la présentation du projet avec le
>>concept de licence libre de logiciels libres, de crowdsourcing, puis
>>un aperçu des outils de contributions de l'imagerie aérienne, de la
>>préparation d'une collecte sur le terrain, une cartopartie avec
>>relevés par GPS, logger, walking papers et photos géotaguées, puis
>>saisie dans JOSM, puis les outils de contrôle de qualité, les outils
>>de coordination (OSM Task Manager d'HOT), et on va attaquer la partie
>>exploitation des données.
>>
>>Vous imaginez bien que tout ça en 4 jours c'est un peu lourd à
>>digérer... et qu'il va falloir consolider tout ça.
>>
>>Ils partent en mission dans les semaines à venir, et vont donc
>>rapidement avoir à mettre les mains dans le cambouis et besoin d'être
>>aidés.
>>
>>Je propose donc à ceux qui le souhaite et qui se sentent capable de
>>prendre par la main des débutants d'avoir un rôle de tuteur et j'ai
>>invité les volontaires francophones à venir sur
>>http://forum.openstreetmap.fr/ pour se présenter pour qu'un tuteur
>>puisse les suivre.
>>
>>Dans un premier temps, il s'agit essentiellement d'aider à prendre en
>>main JOSM et de gagner en efficacité ainsi que de suivre les tracés de
>>routes et de bâtiments faits sur les images bing dans leur zone de
>>déploiement.
>>Les règles de tagging seront à voir dans un deuxième temps, et elles
>>sont un peu spécifiques à l'humanitaires et parfois différentes par
>>rapport à nos habitudes.
>>
>>Plus d'infos:
>>- http://hot.openstreetmap.org/projects/eurosha_0
>>- http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Team/Tutorships
>>
>>--
>>Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>>
>>
>
>___
>Talk-fr mailing list
>Talk-fr@openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chef-lieu de commune...

[Eric Sibert]

"is_in" pour dire dans quel district et région se trouve la place
(point-virgule comme séparateur)


Ah non, pas le is_in, vade retro stanas ;-)

Éventuellement, pourquoi pas. Néanmoins, je trouve que le is_in ne  
permet pas de bien de hiérarchiser l'information. Comment on fait pour  
savoir à quels niveaux administratifs correspondent les valeurs  
successives du is_in? Ou alors comme c'est proposé dans le wiki  
is_in:municipality, is_in:district, is_region. M'enfin, dans tous les  
cas, on n'a pas d'objet dans OSM en relation de l'entité  
administrative sur le terrain, pour indiquer par exemple les noms  
malgache et français de l'entité.



"admin_centre=yes" par exemple sur le chef-lieu (facile à transposer
lorsque les limites apparaitront)


Là, on ne sait pas à quel niveau administratif ça se réfère. En plus  
admin_centre est presque exclusivement utilisé comme de la relation  
boundary. Il y a aussi la proposition de Vincent d'utiliser  
capital=(admin_level). Ou d'autres variantes comme  
admin_centre=(admin_level). Ou rajouter séparément admin_level=* au  
noeud place=* en complément de admin_centre=yes.


Il reste à traiter le cas où le nom du chef-lieu de commune est  
différent du nom de la commune.


Franchement, il n'y aurait pas de modèle avec relation? mais autre que  
boundary? Ca me rappelle les discussions sur les modèles linéaires vs.  
surfaciques pour les empilements de structures administratives. Il n'y  
a pas de pays qui ait adopté le modèle surfacique, c'est-à-dire une  
relation département qui contienne juste la liste des communes le  
constituant (+ admin_centre=* ;-) )?


Eric


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

Re: [OSM-talk-fr] Chef-lieu de commune...

[Vincent de Chateau-Thierry]

Bonjour,

> De : "Eric Sibert" 
>
> > "is_in" pour dire dans quel district et région se trouve la place
> > (point-virgule comme séparateur)
> 
> Ah non, pas le is_in, vade retro stanas ;-)
> 
> Franchement, il n'y aurait pas de modèle avec relation? mais autre que 
> boundary? Ca me rappelle les discussions sur les modèles linéaires vs. 
> surfaciques pour les empilements de structures administratives. Il n'y 
> a pas de pays qui ait adopté le modèle surfacique, c'est-à-dire une 
> relation département qui contienne juste la liste des communes le 
> constituant (+ admin_centre=* ;-) )?
> 

Le rôle subarea ? Vade retro satanas :-)

Plus sérieusement, tu voudrais composer un "arbre administratif"
malgache via une / des relations qui agrégeraient les différents nodes
place=*, la subtilité étant dans le rôle de chacun ? (Je ne suis pas bien sûr
d'avoir compris ton besoin en fait). 

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Cyrille Giquello]

Le 10 octobre 2012 12:07, Frédéric Rodrigo  a écrit :
> Le 09/10/2012 16:02, Cyrille Giquello a écrit :
>
>> Salut,
>> Comment taguer name="Commissariat de Secteur de Tours Nord/St Cyr sur
>> Loire" ?
>> Osmose dit "Le tag name contient deux noms"
>> (http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#5030)
>
>
> Laisse Osmose dire ce qu'il veut ! Tu le marque en faux positif si tu veux
> et puis c'est tout.

Ah bon ?! Mais pour moi Osmose était le maître de la perfitude d'osm.
Tu me détruis un graal !
;-)

Mais si je le marque faux-positif, il va revenir un jour, non ?

> Par contre Osmose va aussi signaler le "St".

Ok, ça je peux le faire :-)

Merci Fred.

>
> Frédéric.
>

-- 
Cyrille.

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

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Fabien]

Le 10 octobre 2012 15:26, Cyrille Giquello  a écrit :
> Le 10 octobre 2012 12:07, Frédéric Rodrigo  a écrit :
>> Le 09/10/2012 16:02, Cyrille Giquello a écrit :
>>
>>> Salut,
>>> Comment taguer name="Commissariat de Secteur de Tours Nord/St Cyr sur
>>> Loire" ?
>>> Osmose dit "Le tag name contient deux noms"
>>> (http://wiki.openstreetmap.org/wiki/FR:Osmose/erreurs#5030)
>>
>>
>> Laisse Osmose dire ce qu'il veut ! Tu le marque en faux positif si tu veux
>> et puis c'est tout.
>
> Ah bon ?! Mais pour moi Osmose était le maître de la perfitude d'osm.
> Tu me détruis un graal !
> ;-)
>
> Mais si je le marque faux-positif, il va revenir un jour, non ?
>
>> Par contre Osmose va aussi signaler le "St".
>
> Ok, ça je peux le faire :-)

Sauf que là aussi, si le terrain n'écrit pas Saint-Chose comme il faut
c'est pas osmose qui doit dicter sa loi !
Exemple : 
http://osmose.openstreetmap.fr/map/?zoom=18&lat=43.31694&lon=5.4065&layers=B000FFT&item=3010,3020,3030,3031,3032,3033,3040,3050,3060,3070,3080,3090,3091,3100,3110,3120,3150,3160,3170,8060&level=1,2,3

C'est bien écrit St-Just Raguse pour l'arrêt de bus donc il faut pas
modifier. Tant pis si l'orthographe est foireuse faut se plaindre à
ceux qui font les panneaux :)

Fabien
>
> Merci Fred.
>
>>
>> Frédéric.
>>
>
> --
> Cyrille.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

[OSM-talk-fr] [Presse] Microsoft et OpenStreetMap

[Cyrille Giquello]

Extract: Microsoft a compris depuis longtemps que sa solution maison -
Bing Maps - ne permettrait pas de concurrencer le leader du secteur.
La marque a donc choisi une autre option en se rapprochant, fin 2010,
du projet collaboratif OpenStreetMap.

http://www.liberation.fr/medias/2012/10/08/smartphones-les-gros-sous-des-cartes_851826

-- 
Cyrille.

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

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Vincent de Chateau-Thierry]

> De : "Fabien" 
> 
> Sauf que là aussi, si le terrain n'écrit pas Saint-Chose comme il faut
> c'est pas osmose qui doit dicter sa loi !
> Exemple : http://osmose.openstreetmap.fr/map/?
zoom=18&lat=43.31694&lon=5.4065&layers=B000FFT&item=3010,3020,3030,3031,3
032,3033,3040,3050,3060,3070,3080,3090,3091,3100,3110,3120,3150,3160,3170,8060&level=1,2,
3
> 
> C'est bien écrit St-Just Raguse pour l'arrêt de bus donc il faut pas
> modifier. Tant pis si l'orthographe est foireuse faut se plaindre à
> ceux qui font les panneaux :)
> 

À te suivre, en voyant une plaque de rue "Rue du Gal Laclerc" tu taggues :
name=Rue du Gal Leclerc ?
Voir :
http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
En substance : lorsqu'on connaît la signification d'une abréviation, on ne 
taggue
pas l’abréviation mais le mot complet.

vincent

Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ?
Je crée ma boîte mail www.laposte.net

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

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Fabien]

Le 10 octobre 2012 16:36, Vincent de Chateau-Thierry
 a écrit :
>
>> De : "Fabien"
>>
>> Sauf que là aussi, si le terrain n'écrit pas Saint-Chose comme il faut
>> c'est pas osmose qui doit dicter sa loi !
>> Exemple : http://osmose.openstreetmap.fr/map/?
> zoom=18&lat=43.31694&lon=5.4065&layers=B000FFT&item=3010,3020,3030,3031,3
> 032,3033,3040,3050,3060,3070,3080,3090,3091,3100,3110,3120,3150,3160,3170,8060&level=1,2,
> 3
>>
>> C'est bien écrit St-Just Raguse pour l'arrêt de bus donc il faut pas
>> modifier. Tant pis si l'orthographe est foireuse faut se plaindre à
>> ceux qui font les panneaux :)
>>
>
> À te suivre, en voyant une plaque de rue "Rue du Gal Laclerc" tu taggues :
> name=Rue du Gal Leclerc ?
Oui
> Voir :
> http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
> En substance : lorsqu'on connaît la signification d'une abréviation, on ne 
> taggue
> pas l’abréviation mais le mot complet.
C'est même indiqué ici : "Apart from following the above rules, you
should always enter the full name as it appears on the street name
signs."
En substance : vous devez toujours écrire le nom comme il apparaît sur
les panneaux.

Leur partie qui dit de ne pas faire d'abbréviation c'est par exemple
la «CAF des Bouches-du-Rhônes» doit être taggée : Caisse d'Allocation
Familiale des Bouches-du-Rhône
On n'est pas sensé forcément savoir que CAF c'est ça.

Fabien
>
> vincent
>
> Une messagerie gratuite, garantie à vie et des services en plus, ça vous 
> tente ?
> Je crée ma boîte mail www.laposte.net
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

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

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Jean Couteau]

Le 10/10/2012 16:47, Fabien a écrit :
>> À te suivre, en voyant une plaque de rue "Rue du Gal Laclerc" tu taggues :
>> name=Rue du Gal Leclerc ?
> Oui

Et tu fais comment quand le panneau à l'entrée de la rue indique "Rue du
Gal Leclerc" et de l'autre côté "Rue du Général Leclerc" ?

Jean



signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Francescu GAROBY]

Le 10 octobre 2012 16:47, Fabien  a écrit :

> Le 10 octobre 2012 16:36, Vincent de Chateau-Thierry
>  a écrit :
> >
> >> De : "Fabien"
> >>
> >> Sauf que là aussi, si le terrain n'écrit pas Saint-Chose comme il faut
> >> c'est pas osmose qui doit dicter sa loi !
> >> Exemple : http://osmose.openstreetmap.fr/map/?
> >
> zoom=18&lat=43.31694&lon=5.4065&layers=B000FFT&item=3010,3020,3030,3031,3
> >
> 032,3033,3040,3050,3060,3070,3080,3090,3091,3100,3110,3120,3150,3160,3170,8060&level=1,2,
> > 3
> >>
> >> C'est bien écrit St-Just Raguse pour l'arrêt de bus donc il faut pas
> >> modifier. Tant pis si l'orthographe est foireuse faut se plaindre à
> >> ceux qui font les panneaux :)
> >>
> >
> > À te suivre, en voyant une plaque de rue "Rue du Gal Laclerc" tu taggues
> :
> > name=Rue du Gal Leclerc ?
> Oui
> > Voir :
> >
> http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
> > En substance : lorsqu'on connaît la signification d'une abréviation, on
> ne taggue
> > pas l’abréviation mais le mot complet.
> C'est même indiqué ici : "Apart from following the above rules, you
> should always enter the full name as it appears on the street name
> signs."
> En substance : vous devez toujours écrire le nom comme il apparaît sur
> les panneaux.
>
> Leur partie qui dit de ne pas faire d'abbréviation c'est par exemple
> la «CAF des Bouches-du-Rhônes» doit être taggée : Caisse d'Allocation
> Familiale des Bouches-du-Rhône
> On n'est pas sensé forcément savoir que CAF c'est ça.
>
> Ceci dit, il y a des noms de rues abrégés, pour lesquels il est parfois
difficile de retrouver le nom exact. Je pense à toutes les rues portant le
nom d'un régiment militaire, cas assez fréquents en Basse-Normandie.
La solution, indiquée sur le
wiki,
est de faire un mix : le tag 'name' porte le nom complet et on rajoute un
tag 'short_name' avec le nom abrégé.

Francescu

> Fabien
> >
> > vincent
> >
> > Une messagerie gratuite, garantie à vie et des services en plus, ça vous
> tente ?
> > Je crée ma boîte mail www.laposte.net
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org
> > http://lists.openstreetmap.org/listinfo/talk-fr
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Cordialement,
Francescu GAROBY
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Fabien]

Le 10 octobre 2012 16:54, Jean Couteau  a écrit :
> Le 10/10/2012 16:47, Fabien a écrit :
>>> À te suivre, en voyant une plaque de rue "Rue du Gal Laclerc" tu taggues :
>>> name=Rue du Gal Leclerc ?
>> Oui
>
> Et tu fais comment quand le panneau à l'entrée de la rue indique "Rue du
> Gal Leclerc" et de l'autre côté "Rue du Général Leclerc" ?
>
Pas sûr : alt_name ?
> Jean
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Jean-Claude Repetto]

Le 10/10/2012 16:36, Vincent de Chateau-Thierry a écrit :



À te suivre, en voyant une plaque de rue "Rue du Gal Laclerc" tu taggues :
name=Rue du Gal Leclerc ?
Voir :
http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
En substance : lorsqu'on connaît la signification d'une abréviation, on ne 
taggue
pas l’abréviation mais le mot complet.




Attention, ça peut conduire à des dérives.

Par exemple, la "Rue de la Colle d'Artaud", à Six-Fours :
- les plaques portent le nom incorrect de "Rue du Col d'Artaud".
- Google Maps (ou son fournisseur) a cru que "col" était l'abbréviation 
de "colonel", et donc cette rue s'appelle désormais "Rue du Colonel 
d'Artaud" sur les cartes Google. Rien à voir avec le nom d'origine !


Jean-Claude


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

[OSM-talk-fr] écoles et osmose

[djo_man]

bonjour à tous

dans osmose, il y a
"a mapper"- "école non intégrée"
mais aussi
"intégration"- "école"

cela parle semble-il des mêmes écoles restant à intégrer

mais pourtant lorsque l'on corrige l'un il ne corrige pas 
automatiquement autre ?


djo_man


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

Re: [OSM-talk-fr] [Presse] Microsoft et OpenStreetMap

[Emilie Laffray]

Oui enfin c'est quand meme un peu incorrect. A ma connaissance, Bing n'a
pas fait le moindre bruit pour utiliser OSM a part fournir la carto
aerienne et un fond OSM quelque part (meme pas genere eux meme).
Bing Map de toute facon c'est base quasi entierement sur les produits de
Nokia (NavTeq) sur pas mal de points (geocodeur, cartographie, etc...).
S'ils gardent OSM pret quelque part, il le cache tres bien.

Emilie Laffray

2012/10/10 Cyrille Giquello 

> Extract: Microsoft a compris depuis longtemps que sa solution maison -
> Bing Maps - ne permettrait pas de concurrencer le leader du secteur.
> La marque a donc choisi une autre option en se rapprochant, fin 2010,
> du projet collaboratif OpenStreetMap.
>
>
> http://www.liberation.fr/medias/2012/10/08/smartphones-les-gros-sous-des-cartes_851826
>
> --
> Cyrille.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Presse] Microsoft et OpenStreetMap

[Pieren]

2012/10/10 Emilie Laffray :

> Bing Map de toute facon c'est base quasi entierement sur les produits de
> Nokia (NavTeq) sur pas mal de points (geocodeur, cartographie, etc...).
> S'ils gardent OSM pret quelque part, il le cache tres bien.

Les choses vont peut-être changer. On s'interroge quand on voit ce
genre d'application:
http://frontdoor.cloudapp.net/

Pieren

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

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Pieren]

2012/10/10 Jean-Claude Repetto :

> Par exemple, la "Rue de la Colle d'Artaud", à Six-Fours :
> - les plaques portent le nom incorrect de "Rue du Col d'Artaud".
> - Google Maps (ou son fournisseur) a cru que "col" était l'abbréviation de
> "colonel", et donc cette rue s'appelle désormais "Rue du Colonel d'Artaud"
> sur les cartes Google. Rien à voir avec le nom d'origine !

C'est un cas intéressant.
- les plaques comme le plan de ville officiel ([1]) et le cadastre
indiquent tous "Rue du Col d'Artaud".
- google comme le géoportail de l'IGN se trompent et utilisent "Rue du
Colonel d'Artaud"

Je ne sais pas d'où tu sors le nom "Rue de la Colle d'Artaud" mais
d'après ce document ([2]), c'est une colline qui se dirait "colo" en
provençal et qui a donné "la colle d'Artaud", déformé ensuite en "col
d'Artaud". Mais la dénomination courante reste "col d'Artaud".
De toute façon, comme le panneau correspond au plan de ville, il n'y a
pas matière à discuter (en tout cas, pour nous, parce que Google
semble pomper sur le géoportail ou inversement).

Pieren

[1] http://www.mairie-six-fours.fr/plans/plan2011recto.pdf
[2] http://marius.autran.pagesperso-orange.fr/rues/lexique_rues_a.html

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

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Christian Rogel]

Le 10 oct. 2012 à 18:39, Pieren a écrit :
> 
> Je ne sais pas d'où tu sors le nom "Rue de la Colle d'Artaud" mais
> d'après ce document ([2]), c'est une colline qui se dirait "colo" en
> provençal et qui a donné "la colle d'Artaud", déformé ensuite en "col
> d'Artaud". Mais la dénomination courante reste "col d'Artaud".
> De toute façon, comme le panneau correspond au plan de ville, il n'y a
> pas matière à discuter (en tout cas, pour nous, parce que Google
> semble pomper sur le géoportail ou inversement).

Ce qui serait intéressant, ce seraitde retrouver la délibération municipale
(si c'est possible, car les appellations les plus anciennes n'ont pas toujours
été décidées en CM).

Christian Rogel___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] écoles et osmose

[Frédéric Rodrigo]

Le 10/10/2012 17:03, djo_man a écrit :

bonjour à tous

dans osmose, il y a
"a mapper"- "école non intégrée"
mais aussi
"intégration"- "école"

cela parle semble-il des mêmes écoles restant à intégrer


C'est bien ça.



mais pourtant lorsque l'on corrige l'un il ne corrige pas
automatiquement autre ?


Si, c'est automatique, le délai est juste de 6h.

Frédéric.


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

[OSM-talk-fr] Tram T4 Bondy-Aulnay : railway=light_rail ou railway=tram ?

[teuxe]

Bonjour,

Question de tag : réutilisant l'infrastructure ferroviaire de l'ancienne ligne 
SNCF Bondy-Aulnay dite des Coquetiers, le tram-train T4 devrait-il plutôt être 
marqué comme "light_rail" ou comme "tram" ? Actuellement selon qu'on soit plus 
proche de Bondy ou d'Aulnay-sous-Bois, l'un ou l'autre des tags est utilisé.

Les autres trams de la région parisienne (T1, T2, T3) sont marqués 
"railway=tram".
Merci pour votre avis,

Teuxe

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

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Philippe Verdy]

C'est sûr qu'on voit rarement sur les plaques de rues l'expansion
complète de l'abréviation "Boulevard du 3e RPIMa" (Régiment
parachutiste d'infanterie de la Marine)... On doit modérer un peu
quand c'est l'abréviation qui est plus connue que le nom complet (qui
a pu même changer de signification sans changer le sigle ou l'acronyme
qu'on continu de prononcer comme un sigle ou acronyme).

Mais pour une abréviation à peine moins longue que le nom complet et
qui mentionne la prononciation correcte comme "St" ou "Ste" au lieu de
Saint(e)", qu'on ne prononce jamais lettre à lettre, et qui est
évidente pour un humain francophone, la question ne se pose pas : on
n'abrège pas (les logiciels abrégeront eux-mêmes si-nécessaire pour
faire tenir le texte dans un espace limité).

Autre exemple: les mots "-sur-" ou "-sous-" sont fréquemment abrégés
par exemple "/" ou "s/s" sur les plaques d'entrée d'agglomération ou
les panneaux indicateurs directionnels. Certaines communes à noms long
peuvent y avoir des parties abrégées aussi (exemple :
"Frontenay-Rohan-Rohan" dans le 79, qu'on trouve affiché sur certains
panneaux en "Frontenay-R.-R.", mais pas tous les panneaux, pas plus
que dans les annuaires ou les bulletins municipaux, ni les
publications de la communauté de communes et des autres collectivités
locales, ou dans la base INSEE ; personne n'épelle ces "R" isolément,
sauf ceux qui tombent sur ces panneaux et ne savent pas les lire, mais
ce n'est pas gênant car cela ne donne aucune ambiguïté selon le lieu
où on les voit, l'association avec le nom complet qu'on pourrait avoir
étant aussi évidente même si l'abréviation est inattendue). Ces
abréviations sont juste contextuelles, juste adaptées au support
physique limité où on les trouve spécifiquement pour un usage très
local.

Le 10 octobre 2012 16:55, Francescu GAROBY  a écrit :
>
>
> Le 10 octobre 2012 16:47, Fabien  a écrit :
>
>> Le 10 octobre 2012 16:36, Vincent de Chateau-Thierry
>>  a écrit :
>> >
>> >> De : "Fabien"
>> >>
>> >> Sauf que là aussi, si le terrain n'écrit pas Saint-Chose comme il faut
>> >> c'est pas osmose qui doit dicter sa loi !
>> >> Exemple : http://osmose.openstreetmap.fr/map/?
>> >
>> > zoom=18&lat=43.31694&lon=5.4065&layers=B000FFT&item=3010,3020,3030,3031,3
>> >
>> > 032,3033,3040,3050,3060,3070,3080,3090,3091,3100,3110,3120,3150,3160,3170,8060&level=1,2,
>> > 3
>> >>
>> >> C'est bien écrit St-Just Raguse pour l'arrêt de bus donc il faut pas
>> >> modifier. Tant pis si l'orthographe est foireuse faut se plaindre à
>> >> ceux qui font les panneaux :)
>> >>
>> >
>> > À te suivre, en voyant une plaque de rue "Rue du Gal Laclerc" tu taggues
>> > :
>> > name=Rue du Gal Leclerc ?
>> Oui
>> > Voir :
>> >
>> > http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
>> > En substance : lorsqu'on connaît la signification d'une abréviation, on
>> > ne taggue
>> > pas l’abréviation mais le mot complet.
>> C'est même indiqué ici : "Apart from following the above rules, you
>> should always enter the full name as it appears on the street name
>> signs."
>> En substance : vous devez toujours écrire le nom comme il apparaît sur
>> les panneaux.
>>
>> Leur partie qui dit de ne pas faire d'abbréviation c'est par exemple
>> la «CAF des Bouches-du-Rhônes» doit être taggée : Caisse d'Allocation
>> Familiale des Bouches-du-Rhône
>> On n'est pas sensé forcément savoir que CAF c'est ça.
>>
> Ceci dit, il y a des noms de rues abrégés, pour lesquels il est parfois
> difficile de retrouver le nom exact. Je pense à toutes les rues portant le
> nom d'un régiment militaire, cas assez fréquents en Basse-Normandie.
> La solution, indiquée sur le wiki, est de faire un mix : le tag 'name' porte
> le nom complet et on rajoute un tag 'short_name' avec le nom abrégé.
>
> Francescu
>>
>> Fabien
>> >
>> > vincent
>> >
>> > Une messagerie gratuite, garantie à vie et des services en plus, ça vous
>> > tente ?
>> > Je crée ma boîte mail www.laposte.net
>> >
>> > ___
>> > Talk-fr mailing list
>> > Talk-fr@openstreetmap.org
>> > http://lists.openstreetmap.org/listinfo/talk-fr
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
>
> --
> Cordialement,
> Francescu GAROBY
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>

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

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Philippe Verdy]

Le 10 octobre 2012 16:47, Fabien  a écrit :
> Leur partie qui dit de ne pas faire d'abbréviation c'est par exemple
> la «CAF des Bouches-du-Rhônes» doit être taggée : Caisse d'Allocation
> Familiale des Bouches-du-Rhône
> On n'est pas sensé forcément savoir que CAF c'est ça.

Je suis d'accord, mais c'est alors faire une enquête sur un terrain
sans rien savoir sur lui ni apprendre à le connaître. Bref même
raisonnement que pour ceux qui cartographient des terres inconnues
d'eux depuis leur chaise : ce n'est plus une enquête de terrain, c'est
du tourisme !

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

Re: [OSM-talk-fr] Tram T4 Bondy-Aulnay : railway=light_rail ou railway=tram ?

[Eric SIBERT]

Et l'espacement des rails comparé au chemin de fer classique et aux 
autres lignes de tram?


A Baltimore, il y a un truc qui s'appelle le light_rail, qui est 
d'ailleurs taggué comme tel. En centre-ville, ça ressemble à du tram qui 
roule au milieu de la chaussée. Quand on part en banlieue, c'est en site 
propre qui fait plus penser au RER. L'espacement est celui des trains: 
1435 mm.


http://osm.org/go/ZZfUD8nPo--



Éric

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

Re: [OSM-talk-fr] Chef-lieu de commune...

[Philippe Verdy]

Le 10 octobre 2012 15:09, Eric Sibert  a écrit :
> Là, on ne sait pas à quel niveau administratif ça se réfère. En plus
> admin_centre est presque exclusivement utilisé comme de la relation
> boundary. Il y a aussi la proposition de Vincent d'utiliser
> capital=(admin_level). Ou d'autres variantes comme
> admin_centre=(admin_level). Ou rajouter séparément admin_level=* au noeud
> place=* en complément de admin_centre=yes.

C'est bien pour ça que le modèle utilisé en Espagne (dont les communes
comptent de nombreuses petites localités avec chacune leur nom
spécifique, souvent différent de la commune elle-même) marche bien :

capital = 8 pour les localités qui sont chef-lieu de la commune (ou
"municipio" en espagnol), c'est-à-dire sont là où siège la mairie (ou
"ajuntamento" en espagnol) ; mais le nom de la localité n'indique pas
forcément le nom réel de la commune elle-même, qui est précisé dans la
relation communale, capital=7 pour les chef-lieu de comarques,
capital=6 pour les capitales de province, capital=4 pour les capitales
de communauté autonome, capital=2 pour la capitale du pays..

Noter que certaines zones (par exemple certaines provinces, mais aussi
certaines communes) ont deux capitales officielles (donc deux noeuds
membres admin_centre dans leur relation), chacun des noeud portant
alors la même valeur capital=n, mais ayant chacun leur propre nom qui
n'impacte le nom donné aux zones dont elle est capitale.

Noter aussi que la capitale d'une communauté autonome (capital=4)
n'est pas nécessairement non plus capitale de la province (niveau 6)
où elle se situe (son admin_centre mentionne un autre point que la
capitale de communauté, et sur ce noeud on a capital=6).

Aucun problème donc en Espagne, ça marche très bien !

Même avec la réforme en cours des comarques et les nouvelles
organisations administratives propres à chaque communauté autonome
(qui ne tiennent pas compte du découpage administratif national des
communautés en provinces, et qui créent des nouveaux regroupements de
comarques en régions et sous-régions, ou en districts, ou en conseils
insulaires, ou qui effacent complètement les anciennes comarques, et
parfois aussi annulent le découpage national des communes, au delà de
la réforme aussi de leur propre toponymie dans la langue régionale
officielle) : le découpage administratif national (avec des
admin_level numériques) ne sert plus alors que pour l'organisation des
services nationaux de l'Etat non transférés dans la compétence des
communautés autonomes, ou pour les circonscriptions électorales pour
les députés au parlement national.

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

[OSM-talk-fr] Limites communales dans les DOM

[Pierre Touzard]

Bonsoir à tous,

Quel dommage que l'on ne puisse pas trouver ici
(http://export.openstreetmap.fr/contours-administratifs/export-communes/)
les limites communales sur les DOM...

Il manque :
971 : Guadeloupe (cadastre entièrement vectorisé)
972 : Martinique (cadastre entièrement vectorisé)
973 : Guyane (cadastre récemment entièrement vectorisé mais pas diffusé sur
cadastre.gouv.fr)
974 : Réunion (cadastre entièrement vectorisé)
976 : Mayotte (cadastre entièrement vectorisé mais pas diffusé sur
cadastre.gouv.fr)

Quelqu'un a-t-il une méthode pour récupérer facilement les contours des
communes sur ces départements ?

Pierre T.



--
View this message in context: 
http://gis.19327.n5.nabble.com/Limites-communales-dans-les-DOM-tp5729803.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Alignement cadastre

[RÉAU Simon]

Sur l'indre et loire, certaines communes contenait quelques planches mal 
géoréférencées mais depuis quelques semaines on a des mis a jours qui 
semble parfaites vis a vis des images de Bing et des repères géodésiques.



Le 09/10/2012 20:51, Jean-Francois Nifenecker a écrit :

Bonsoir,

au cours de mes pérégrinations correctrices, j'ai rencontré un cas de 
bâti mal calé. Et, curieusement, mappant en extérieur aujourd'hui, 
voilà-t-y pas que je tombe sur un deuxième cas de l'espèce. Moi qui 
n'avais jamais rencontré de commune dont le bâti était mal placé, me 
voilà verni.


Le premier cas : commune de Launac en Haute-Garonne. J'ai constaté un 
décalage du bâti par rapport à l'imagerie Bing. La position de deux 
points géodésiques distants sur la commune (église du village, église 
d'un hameau à l'ouest) confirme que c'est le Cadastre qui est dans les 
choux et l'imagerie Bing qui est correcte.


-> j'ai recalé tout ce beau monde a-la-mano (vivent les filtres JOSM 
!). Et puis recalé le "reste" (les %$§&@ piscines) et les highways 
puisque les contributeurs, sagement, avaient décalé leurs positions en 
proportion du bâti.
Pfff... 4 heures de boulot. Par chance, le bâti y est facilement 
sélectionnable par groupe si bien que le travail a avancé assez 
rapidement.


Ce qui me surprend le plus sur cette commune c'est que (1) elle n'est 
pas spécialement située en montagne mais au contraire dans une plaine 
à l'ouest de Toulouse et (2) que le décalage (LES décalages devrais-je 
dire) n'était pas régulier, c'est le moins que l'on puisse dire. J'ai 
trouvé des différences en moyenne de 15 mètres mais allant dans 
certains cas jusqu'à 25 mètres ! Et le secteur le plus à l'Est était 
correctement calé.
En outre, des bâtiments proches (une maison et un appentis sur son 
terrain) pouvaient être décalés différemment.
Enfin, certains décalages étaient "en rotation", certes légère mais 
suffisamment importante pour être remarquée (et ça, j'ai pas corrigé).


Le second cas : commune de Saint-Amant de Boixe (Charente) où j'ai 
passé la journée. Décalage très visible sur le fond Bing. La position 
du point géodésique sur le clocher de l'abbatiale confirme l'erreur 
cadastrale.


Ici, le décalage est moins important qu'à Launac et sans doute 
beaucoup plus régulier (majoritairement vers le Nord). Ici non plus, 
le relief ne peut être mis en cause, la Charente n'étant pas réputée 
pour ses cols de haute montagne.


Je m'attends à un peu plus de boulot de recalage qu'à Launac car le 
bâti y est plus dense, il va donc être plus difficile de sélectionner 
des groupes de bâtiments peu étendus.



Ma "confiance" dans le Cadastre s'émousse très fortement...

Quelles sont vos expériences ? Comment gérez-vous la rotation sous JOSM ?



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

Re: [OSM-talk-fr] Chef-lieu de commune...

[Eric SIBERT]

C'est bien pour ça que le modèle utilisé en Espagne (dont les communes
comptent de nombreuses petites localités avec chacune leur nom
spécifique, souvent différent de la commune elle-même) marche bien :


Je viens de jeter un coup d’œil au modèle espagnol:

Il y a des relations de type=boundary. Un exemple:
admin_level = 6
place   = county
rank= county

is_in = Comunidad Valenciana, Spain
is_in:country = Spain
is_in:region  = Comunidad Valenciana
ine:provincia = 03

rôles outer : les limites
rôles subarea : la liste des municipalités
rôle admin_centre : le(s) chef-lieu(x)

Et quand je vais sur le nœud place du chef-lieu, je trouve:
admin_level = 6
capital = 6
is_in  = Alicante, Comunidad Valenciana, Spain
is_in:continent= Europe
is_in:municipality = Alacant/Alicante
is_in:province_code = 03
place = city

De mon point de vue, c'est ce que j'appelle bétonner. En poussant plus 
loin, les nombreuses informations redondantes peuvent poser problème 
pour la maintenance de la base.


Et comme je l'ai déjà expliqué, faute de limites communales, mettre en 
place des relations type=boundary paraît capilotracté. Sans relation, 
juste capital=(admin_level) ne permet pas de couvrir tous les cas. Il 
faut au moins compléter avec des is_in:*=.


Éric

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

Re: [OSM-talk-fr] Osmose a changé de peau

[Philippe Verdy]

Le 10 octobre 2012 09:32, Stéphane Péneau  a écrit :
> Je rejoins les autres avis, si "rien" c'est "tout" alors autant supprimer le
> bouton "rien" puisque sa fonction est identique à "tout".

Cela affiche la même chose que "tout" mais la fonction reste
différente puisque ça décoche toutes les cases, ce qui permet d'en
cocher une seule d'un seul clic pour ne plus voir qu'un seul type
d'alerte/

Maintenant je pense que "rien" ne devrait aussi rien afficher du tout,
d'une part c'est perturbant au début, d'autre part on peut très bien
vouloir temporairement ne rien afficher du tout, soit parce qu'eon
avait sélectionné une case et que pour éviter de zoomer sur une zone
pour l'identifier sur la carte en arrière-plan on souhaute cacher les
bulles, soit parce qu'on veut arrêter d'arrêter d'interroger
dynamiquement le serveur, afin de se déplacer plus rapidement sur la
carte (avec un minimum de requêtes) et zoomer sur une zone d'intérêt
donnée où on va aller chercher un ou plusieurs types d'alertes (voire
toutes).

Nouveauté de cette version d'Osmose : les remplissages en couleur des
zones par niveau administratif ou politique/électoral faits jusqu'à
présent sur Layers sont disponibles aussi sur Osmose dans le menu de
droite.

Un regret (sous Osmose NG, comme déjà avant sur Layers): toujours pas
de séparation des zones "boundary=political" selon leur sous-type
"political_subdivision=*" (surtout gênant actuellement en France où
cela concerne déjà la distinction, impossible à voir séparément, des
cantons et des circonscriptions législatives qui sont mélangés dans la
sélection et provoquent des anomalies de fermeture de polygones ou des
superpositions de polygones de la même couleur avec seulement un
changement du niveau d'intensité de la transparence, et la
superposition excessive des libellés).

Pas même les régions NUTS-2 pour la France (même si ce ne sont pas
'stricto sensu' des découpages administratifs mais des découpages
économiques d'aménagement du territoire national, qui iraient pourtant
créer un admin_level=3  en France (sans chef-lieu donc sans membre
admin_centre dans leur relation, est-ce un vrai problème puisque on a
des tas de communes aussi sans admin_centre désigné, voire plusieurs
dans niveaux admin d'autres pays européens ?). Alors qur tout est en
place pour les afficher correctement.

Alors qu'on a une séparation des EPCI à fiscalité propre pour la
France (boundary=local_authority utilisé différemment au moins en
Angletere), mais pas de distinction possibles des autres EPCI sans
fiscalité propre (comme les SIVU et SIVOM qui existent encore et
manquent dans la base OSM, voire aussi les les pays et pays Loi Voynet
qui regroupent ces EPCI sans tenir compte nécessairement des
frontières administratives des régions ou départements puisque les
EPCI peuvent être à cheval).

Et rien en place n'est prévu pour visualiser d'autres limites : les
structures européennes de coopération régionale transfrontalière, les
circonscriptions électorales au parlement européen, les adadémies, les
zones de défense et régions militaires, les régions de police
nationale ou gendarmerie, les zones de police municipale, les régions
judiciaires, les régions hospitalières et de couverture médicale, les
étendues des charges notariales, des agences de bassin, des régions
maritimes... Pas plus que le découpage « administratif religieux »
(c'est à dire des paroisses, unités paroissiales, évêchés ou
arhevêchés...)

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

Re: [OSM-talk-fr] Chef-lieu de commune...

[Eric SIBERT]

Le rôle subarea ? Vade retro satanas :-)

Plus sérieusement, tu voudrais composer un "arbre administratif"
malgache via une / des relations qui agrégeraient les différents nodes
place=*, la subtilité étant dans le rôle de chacun ?


Oui, c'est bien ça. J'ai juste du mal à construire des relations 
type=boundary en l'absence de frontière. Ça me paraît contre nature.


Éric

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

Re: [OSM-talk-fr] Frontière Guyane-Brésil

[Philippe Verdy]

Dans cette zone très densément irriguée, et où la végétation noie tout
et change les écoulements des cours d'eau, et où les zones inondées
bougent sans arrêt je me demande l'intérêt de l'acuité visuelle des
images Bing haute résolution de la Guyane (pas sûr d'ailleurs que Bing
soit la source la plus récente ni la plus précise).

Ok les bornes plantées en terre ne devraient pas bouger de si tôt
(sauf si des garinperos les déplacent exprès pour implanter un site
d'orpaillage clandestin), ce qui risque dene pas être repérés avant un
bon moment quand même l'armée française a du mal à s'y rendre et les
retrouver dans la végétation ou sur une terre désormais inondée.

Hormi la région côtière qui est plus peuplée et mieux équipée, les
limites intérieures dans la forêt, où les communes couvrent des zones
gigantesques quasiment vides de population résidente (les populations
amérindiennes y sont aussi nomades que les sites d'orpaillage légaux
ou non), sont très relatives. Même sur les cours d'eaux servant de
frontière naturelle avec les pays voisins.

Au mieux on repérera les villages et leur petit aérodrome dans
certaines clairières hors d'eau, et avant que l'armée revienne, les
pistes de terre qui les relient difficilement (encore moins bien que
les cours d'eau) auront eu le temps de bouger selon les aléas naturels
ou l'exploitation forestière ou agricole.

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

Re: [OSM-talk-fr] Pushpin: nouvelle appli iOS pour contribuer

[Marc]

Le 10/10/2012 07:55, Christian Quest a écrit :

C'est une première version... je pense qu'il faut faire remonter un
max de remarques et de suggestion d'améliorations pour la faire
évoluer dans le bon sens.


Ayé c'est fait...


--

Marc http://www.openstreetmap.org/user/plonk/


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

Re: [OSM-talk-fr] Le rendu est-il un tabou ?

[Philippe Verdy]

Pontifier ? parler en odeur de sainteté ? Alors qu'on me fait dire ce
que je ne pense pas? Je ne bulle pas.

Les noms des lignes frontières ont toujours été indicatifs et pas
prescriptifs, utilisés d'abord par et pour les éditeurs, pas pour le
rendu (c'est vrai partout dans le monde). On me fait dire que c'est là
pour taguer pour le rendu alors que jamais ils n'ont été sensés
apparaître et que de toute façon ils n'apparaissent pas sur les lignes
de frontières rendues ; ou pas mieux en tout cas ni plus souvent que
les noms prescriptifs donnés aux relations (ceux-là sont affichés sans
aucun critère significatifs de toute façon, et peuvent par exemple
masquer totalement le nom d'une rue pour afficher un des noms des
relations, même si pourtant ce sont des objets différents non liés).

Si on tagait réellement les noms pour le rendu, on ne donnerait plus
aucun nom, même aux relations, pour s'assurer que le nom de la rue
sera là, ou pour éviter de voir le nom d'une commune deux fois (un nom
au centroïde du polygone ou à la position de son membre de rôle
"label", et autant de noms que les noeuds des localités membres de la
relation avec le rôle "admin_centre", même si ces noms sont les mêmes
très souvent pour les communes en France).

Comme il n'y a strictement aucune règle définie clairement là-dessus,
aucun rendu ne peut être correct et cohérent et ce n'est pas un tag à
ce niveau qui changera quelquechose puisque le résultat n'est pas
stable du tout et dépend du rendu ou non des noms d'autres objets dans
le voisinage.

Le 9 octobre 2012 21:36, Hélène PETIT  a écrit :
> Le 07/10/2012 22:58, Philippe Verdy a écrit :
>
>> Non ce n'est pas "délibérément" pour le rendu. Rien à voir, tu te
>> trompes.
>
> Philippe, si tu pouvais arrêter de pontifier, s'te plait.

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

Re: [OSM-talk-fr] Encore un peu d'opendata... sur mp2013.fr

[Philippe Verdy]

Le 9 octobre 2012 16:03, Sylvain Maillard  a écrit :
> au début j'ai pensé n'avoir rien compris à ce fichier xml, mais dans
> l'exemple que j'ai donné le point est clairement situé dans la mer (enfin,
> dans le port) et non pas en pleine ville, et il doit bien y avoir 2 km de
> décalage !

Si c'est déjà dans le port c'est déjà dans une commune, et c'est sans
soute suffisant à l'échelle du secteur couvert par eux dans leur asso.
Bref ils n'ont pas eu à géolocaliser la ville, il ont fait comme sur
une carte de France affiché au mur avec des punaises et ça leur
suffit, ils n'ont pas été plus loin.

2 km d'écart c'est pas si mal pour la couverture locale d'une asso
dont la portée est souvent bien plus grande que ça.

J'en reviens donc à ma solution proposée de qualifier les points
importés avec une distance maximale d'imprécision, comme si on
importait non pas des points mais des cercles du rayon donné, dans
lequel le point réel est localisé, pour assurer le suivi de ce qui n'a
pas été rellement intégré avec une meilleure précision.

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

Re: [OSM-talk-fr] Chef-lieu de commune...

[Vincent de Chateau-Thierry]

Le 10/10/2012 21:07, Eric SIBERT a écrit :

Le rôle subarea ? Vade retro satanas :-)

Plus sérieusement, tu voudrais composer un "arbre administratif"
malgache via une / des relations qui agrégeraient les différents nodes
place=*, la subtilité étant dans le rôle de chacun ?


Oui, c'est bien ça. J'ai juste du mal à construire des relations
type=boundary en l'absence de frontière. Ça me paraît contre nature.



Je ne sais pas si tu as un usage en tête pour ce que tu vas modéliser ?
Si c'est juste pour fixer l'organisation administrative et organiser des 
relations d'inclusions sans géométrie, personnellement je pencherais 
plus pour des relations imbriquées que pour le recours au tag is_in et à 
ses déclinaisons, pour plusieurs raisons :

- la relation lie des IDs d'objets (plus fiable)
- le is_in donne comme clé de rattachement du texte, plus ambigü (fautes 
de frappe possibles, divergences sur l'orthographe)
- la relation donne une vue synthétique, ne serait-ce que par la 
capacité à lister les membres d'une même relation
- le is_in ne met en relation que des couples d'objets : celui qui porte 
le tag, et celui référencé dans la valeur du tag. On ne voit pas 
facilement ensemble plusieurs objets ayant le même tag is_in.


Concrètement, j'imagine par exemple :
- pour chaque commune, une relation de type "commune" avec comme membres 
tous les nodes place=* dont tu sais qu'ils sont dans le périmètre de la 
commune. La relation a pour valeur de tag name le nom (administratif) de 
la commune, qui peut être distinct de chacun des noms de lieux "place". 
Un des nodes place porte le rôle admin_centre, les autres ont un rôle à 
définir (place, village, hameau, etc.) ou pas de rôle du tout.
- pour chaque district, une relation de type district, avec comme 
membres les relations de type "commune" des communes formant le 
district. On peut éventuellement coller à chacune un rôle, par exemple 
"commune".
- idem un niveau au dessus avec pour chaque région, une relation de type 
region regroupant ses districts, sauf à utiliser les limites actuelles 
(admin_level=4) pour composer directement des relations de type boundary.


L'idée est de permettre temporairement la description de la hiérarchie 
administrative sans géométrie surfacique, pour au moins les districts et 
communes. On remplace l'inclusion spatiale (celle dont on bénéficie en 
France avec nos niveaux région et département complets) par l'inclusion 
dans des relations.
Le jour où tu disposes des limites de districts, tu peux remplacer les 
relations "district" par des relations "boundary" avec admin_level=6. 
Idem pour les communes.


vincent

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

Re: [OSM-talk-fr] tag name avec double nom (Osmose)

[Vincent de Chateau-Thierry]

Le 10/10/2012 16:47, Fabien a écrit :

Le 10 octobre 2012 16:36, Vincent de Chateau-Thierry
 a écrit :



De : "Fabien"

Sauf que là aussi, si le terrain n'écrit pas Saint-Chose comme il faut
c'est pas osmose qui doit dicter sa loi !
Exemple : http://osmose.openstreetmap.fr/map/?

zoom=18&lat=43.31694&lon=5.4065&layers=B000FFT&item=3010,3020,3030,3031,3
032,3033,3040,3050,3060,3070,3080,3090,3091,3100,3110,3120,3150,3160,3170,8060&level=1,2,
3


C'est bien écrit St-Just Raguse pour l'arrêt de bus donc il faut pas
modifier. Tant pis si l'orthographe est foireuse faut se plaindre à
ceux qui font les panneaux :)



À te suivre, en voyant une plaque de rue "Rue du Gal Laclerc" tu taggues :
name=Rue du Gal Leclerc ?

Oui

Voir :
http://wiki.openstreetmap.org/wiki/Names#Abbreviation_.28don.27t_do_it.29
En substance : lorsqu'on connaît la signification d'une abréviation, on ne 
taggue
pas l’abréviation mais le mot complet.

C'est même indiqué ici : "Apart from following the above rules, you
should always enter the full name as it appears on the street name
signs."
En substance : vous devez toujours écrire le nom comme il apparaît sur
les panneaux.



Sur la même page du wiki mais quelques lignes au dessus, tu liras : "Si 
une plaque de rue contient des abréviations dont vous ne connaissez pas 
le développement, tagguez avec l'abréviation en attendant que quelqu'un 
d'autre place le nom complet".


Ça fait vraiment partie des valeurs ajoutées de nos contributions que de 
pouvoir décrire le terrain sans le photocopier lettre à lettre. Le 
projet s'appelle bien OSM, pas OCR :-)


vincent

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

Re: [OSM-talk-fr] Chef-lieu de commune...

[Philippe Verdy]

Le 10 octobre 2012 20:59, Eric SIBERT  a écrit :
>> C'est bien pour ça que le modèle utilisé en Espagne (dont les communes
>> comptent de nombreuses petites localités avec chacune leur nom
>> spécifique, souvent différent de la commune elle-même) marche bien :
>
>
> Je viens de jeter un coup d’œil au modèle espagnol:
>
> Il y a des relations de type=boundary. Un exemple:
> admin_level = 6
> place   = county

dans la relation le place=* ici inutile, a priori, place c'est plutôt
pour les noeuds, bien que place soit associé à la population du lieu
et que cette population ne se définit pas au noeud (dont on ne sait
pas quelle étendue in concerne, mais sur la surface entière donc bien
sur la relation.

> rank= county

doublon inutile à priori de admin_level=6. Sauf que justement en
Espagne le découpage administratif est en pleine mutation et la
hiérarchie des niveaux va être profondément modifiée. Je pense que ce
rank permet de conserver une trace du type d'entité que cela désigne,
avant que la structure hiérarchique soit modifiée (donc aussi les
numéros assignés en valeur d'admin_level.

> is_in = Comunidad Valenciana, Spain
> is_in:country = Spain
> is_in:region  = Comunidad Valenciana

Les is-in là sont tous documentaires, pas forcément nécessaires. C'est
déjà blindé autrement de façon nettement plus pratique par les
relations parent/enfant de rôle subarea.

> ine:provincia = 03

Comme nos références INSEE en France.

> rôles outer : les limites

Comme en France, mais aussi facilement cassé qu'en France
(heureusement les suareas aident à restaurer les ambiguités.

> rôles subarea : la liste des municipalités

Liste qui doit rester exhaustive de toutes les communes (au niveau
suivant) couvertes. Cela ne détermine PAS les contours qui peuvent
être plus larges que ces communes.

> rôle admin_centre : le(s) chef-lieu(x)

Tout à fait : un ou plusieurs chef-lieux en admin_center
Les subarea sont pour assurer l'exhausitivité de la liste des communes membres

> Et quand je vais sur le nœud place du chef-lieu, je trouve:
> admin_level = 6

Sauf là c'est une erreur, ce devrait rester admin_level=8 (voire 9)
car le noeud n'est pas celui de la province mais celui de la
municipalité (voire même de la localité).

> capital = 6

Ça c'est bon

> is_in  = Alicante, Comunidad Valenciana, Spain
> is_in:continent= Europe
> is_in:municipality = Alacant/Alicante
> is_in:province_code = 03

Là aussi uniquement documentaire, car totalement blindé par les
relations parent/enfant de rôle subarea (indépendamment des chemins
frontières listés dans la relation)

> place = city

C'est comme en France ici, mais c'est en fait pas l'endroit idéal pour
mettre ça puisque ça dépend de la population. Hors les localités en
Espagne ont des noms et des couvertures plus petites que la
municipalité, qui n'est correctement décrite dans sa surface comme
dans son nom QUE dans la relation (laquelle est l'endroit idéal pour
importer les chiffres de population, ainsi que toutes les
traductions).

> De mon point de vue, c'est ce que j'appelle bétonner. En poussant plus loin,
> les nombreuses informations redondantes peuvent poser problème pour la
> maintenance de la base.

Du point de vue espagnol, non, car ce qui est bétonné ce sont les
relations parent/enfant entre les relations, et leurs tags donnant les
noms, traductions, classifications hiérarchiques, populations. Ce sont
les contours indiqués en chemins membres qui ne sont pas stables mais
peuvent être régénérés récursivement.

Toutes les autres données sur les chemins et les noeuds sont alors redondantes.

> Et comme je l'ai déjà expliqué, faute de limites communales, mettre en place
> des relations type=boundary paraît capilotracté. Sans relation, juste
> capital=(admin_level) ne permet pas de couvrir tous les cas. Il faut au
> moins compléter avec des is_in:*=.

Si on n'a pas encore de limites communales, on peut déjà créer les
relations pour y mettre en membre non pas des frontières internes et
externes, mais au moins tous les noeuds de localités ou lieux-dits
inclus dedans, ou pas loin de cette frontière. On distinguera le rôle
'admin_center" pour la localité chef-lieu, et pour les autres
localités on pourrait utiliser en attendant un rôle "place" (qui
deviendront inutiles si on a pu fermer toutes les frontières autour
des localités (de rôles admin_center et place).

Le modèle hiérarchique se construit quand même, on peut commencer avec
des frontières grossières soit au niveau le plus grand du pays et ses
provinces ou régions, soit au niveau le plus fin des localités les
plus petites ou des quartiers, ou dans un ordre quelconque. On n'a
aucune contrainte dans l'ordre de travail, et il est possible de
dresser rapidement des listes exhaustives de toutes les relations
administratives nécessaires et leur hiérarchie, même sans aucune
frontière (qui viennent après et qu'on sait construire alors en
analyse montante comme descendante).

Les subarea évitent égaleme

Re: [OSM-talk-fr] Chef-lieu de commune...

[Philippe Verdy]

Sinon tu peux regarder aussi la république tchèque, totalement achevée
et blindée elle aussi par des subareas.

Encore tant pis pour la France qui s'y refuse pour des mauvaises
raisons ou des incompréhensions qui n'ont pas lieu sur le prétendu
"modèle surfacique" alors que les relations parent/enfant ne
déterminent PAS les surfaces totales, juste une couverture complète ou
partielle de la surface d'une relation enfant, représentée par ses
frontières, par la surface de son/ses parents qu divent être le plus
exhaustif possible mais peuvent ne pas couvrir QUE leurs seuls
enfants).

Les subareas sont là pour l'exhaustivité du modèle hiérarchique et
recouvre une relation de dépendance, partielle ou totale, même lorsque
des morceaux de surface du parent ne sont inclus dans AUCUNE des
relations enfants, puisque le parent peut être plus grand que l'union
de ses enfants, et puisque leurs enfants peuvent aussi avoir des
intersections de surface non nulle.

Le 10 octobre 2012 23:20, Philippe Verdy  a écrit :
> Le 10 octobre 2012 20:59, Eric SIBERT  a écrit :
>>> C'est bien pour ça que le modèle utilisé en Espagne (dont les communes
>>> comptent de nombreuses petites localités avec chacune leur nom
>>> spécifique, souvent différent de la commune elle-même) marche bien :
>>
>>
>> Je viens de jeter un coup d’œil au modèle espagnol:
>>
>> Il y a des relations de type=boundary. Un exemple:
>> admin_level = 6
>> place   = county
>
> dans la relation le place=* ici inutile, a priori, place c'est plutôt
> pour les noeuds, bien que place soit associé à la population du lieu
> et que cette population ne se définit pas au noeud (dont on ne sait
> pas quelle étendue in concerne, mais sur la surface entière donc bien
> sur la relation.
>
>> rank= county
>
> doublon inutile à priori de admin_level=6. Sauf que justement en
> Espagne le découpage administratif est en pleine mutation et la
> hiérarchie des niveaux va être profondément modifiée. Je pense que ce
> rank permet de conserver une trace du type d'entité que cela désigne,
> avant que la structure hiérarchique soit modifiée (donc aussi les
> numéros assignés en valeur d'admin_level.
>
>> is_in = Comunidad Valenciana, Spain
>> is_in:country = Spain
>> is_in:region  = Comunidad Valenciana
>
> Les is-in là sont tous documentaires, pas forcément nécessaires. C'est
> déjà blindé autrement de façon nettement plus pratique par les
> relations parent/enfant de rôle subarea.
>
>> ine:provincia = 03
>
> Comme nos références INSEE en France.
>
>> rôles outer : les limites
>
> Comme en France, mais aussi facilement cassé qu'en France
> (heureusement les suareas aident à restaurer les ambiguités.
>
>> rôles subarea : la liste des municipalités
>
> Liste qui doit rester exhaustive de toutes les communes (au niveau
> suivant) couvertes. Cela ne détermine PAS les contours qui peuvent
> être plus larges que ces communes.
>
>> rôle admin_centre : le(s) chef-lieu(x)
>
> Tout à fait : un ou plusieurs chef-lieux en admin_center
> Les subarea sont pour assurer l'exhausitivité de la liste des communes membres
>
>> Et quand je vais sur le nœud place du chef-lieu, je trouve:
>> admin_level = 6
>
> Sauf là c'est une erreur, ce devrait rester admin_level=8 (voire 9)
> car le noeud n'est pas celui de la province mais celui de la
> municipalité (voire même de la localité).
>
>> capital = 6
>
> Ça c'est bon
>
>> is_in  = Alicante, Comunidad Valenciana, Spain
>> is_in:continent= Europe
>> is_in:municipality = Alacant/Alicante
>> is_in:province_code = 03
>
> Là aussi uniquement documentaire, car totalement blindé par les
> relations parent/enfant de rôle subarea (indépendamment des chemins
> frontières listés dans la relation)
>
>> place = city
>
> C'est comme en France ici, mais c'est en fait pas l'endroit idéal pour
> mettre ça puisque ça dépend de la population. Hors les localités en
> Espagne ont des noms et des couvertures plus petites que la
> municipalité, qui n'est correctement décrite dans sa surface comme
> dans son nom QUE dans la relation (laquelle est l'endroit idéal pour
> importer les chiffres de population, ainsi que toutes les
> traductions).
>
>> De mon point de vue, c'est ce que j'appelle bétonner. En poussant plus loin,
>> les nombreuses informations redondantes peuvent poser problème pour la
>> maintenance de la base.
>
> Du point de vue espagnol, non, car ce qui est bétonné ce sont les
> relations parent/enfant entre les relations, et leurs tags donnant les
> noms, traductions, classifications hiérarchiques, populations. Ce sont
> les contours indiqués en chemins membres qui ne sont pas stables mais
> peuvent être régénérés récursivement.
>
> Toutes les autres données sur les chemins et les noeuds sont alors 
> redondantes.
>
>> Et comme je l'ai déjà expliqué, faute de limites communales, mettre en place
>> des relations type=boundary paraît capilotracté. Sans relation, juste
>> capital=(admin_level) ne permet pas de couvrir tous les cas. Il faut

Re: [OSM-talk-fr] Chef-lieu de commune...

[Philippe Verdy]

Dernier intérêt du modèle parent/enfant à subarea : le cas où les
enfants ont des intersections de surface non nulle concerne les
territoires qui se partagent pacifiquement l'administration conjointe
d'une même portion de territoire, ou bien qui se disputent un même
territoire (contestation de leur limites territoriales). On peut le
faire théoriquement aussi uniquement avec les chemins de rôles
"outer"/"inner" mais on ne dispose d'aucun outil permettant d'en
vérifier la validité, pusique la requête sera purement géométrique
(laquelle ne marche pas du tout avec les frontières incomplètes).

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

Re: [OSM-talk-fr] Chef-lieu de commune...

[Philippe Verdy]

Autre intérêt du modèle à subarea : le cas où le modèle hiérarchique
théorique n'est pas complet pour chaque niveau.
Prenons le cas de la Belgique, elle est divisée en 3 régions
(admin_level=4) elles même divisées en provinces (admin_level=6) et
arrondissements (admin_level=7).

Pourtant une des trois régions (niveau 3), celle de
Bruxelles-Capitale, n'est divisée en AUCUNE province (niveau 6), bien
que la région soit elle-même un arrondissement unique (niveau 7).

De fait la Belgique n'est pas totalement couverte par la liste de ses
provinces (cas similaire aussi en Allemagne avec les statuts
différents des Villes-Etats)

Si on faut une requête seulement géométrique, on va détecter un trou
dans la couverture au niveau 6, et rien n'indiquera qu'il faut aussi
inclure l'arrondissement de niveau 7. Avec les subareas, on n'indique
explcitement : les enfants "subarea" de la région de
Bruxelles-Capitale (niveau 4) sont son unique arrondissement au niveau
7 (tel qu'indiqué dans la définition de sa relation), et non une
province de niveau 6.

En Espagne, où chaque communauté autonome va pouvoir disposer de sa
propre organisation administrative, les niveaux ne seront pas
équivalents d'une communauté autonome à l'autre, et pourtant il faut
un modèle pour synthétiser la définition admministrative de chacune.

De plus, si on revient en Belgique, celle-ci dispose de deux types de
divisions indépendantes au niveau en dessous :
- les 3 régions (avec pour chacune un parlement compétent) qui
couvrent toute la Belgique
- les 3 communautés lingusitiques (avec aussi pour chacune un
parlement compétent), différentes des régions, mais qui recouvre
également la Belgique en totalité.

La Belgique dispose donc dans sa définition de 6 membres subarea. bien
que distingués par leur type (indiqué dans les attributs propres aux
relations enfants). Le parcours exhaustif selon un type de division ou
l'autre reste possible. Mais impossible à certifier avec un modèle
ayant juste des frontières externes non réellement qualifiées.

Le modèle sans subarea utilisé en France ne fonctionne bien (avec
beaucoup de difficultés) QUE parce qu'il forme une hiérarchie
administrative uniforme à tous les niveaux, et offrant une couverture
totale formant une partition de l'espace national (ce n'est déjà plus
vrai pour la France avec les collectivités uniques ou fusionnées dans
les DOM et COM, ou avec les EPCI...)

Il ne marche pas plus avec les frontières floues (pas de ligne
administrative claire entre deux territoires enfants, qui se
recouvrent alors partiellement dans la zone frontalière plus ou moins
partagée autour de leurs contours flous, et délimitée par les
frontières d'extension *maximales* de chaque territoire enfant.

Même en France où des petites zones de gestion conjointe existent
aussi pour des territoires partagés (y compris avec des pays voisins :
on a le cas en métropole avec la Suisse à l'aéroport de Mulhouse-Bâle
: souveraineté française de jure, mais administration suisse ; on a le
cas avec l'Espagne pour une partie des eaux territoriales dans le
Golfe de Gascogne).

Les admin_level du modèle hiérarchique complet et uniforme, et
partitionné (sans superpositions) basé uniquement sur les contours
externes ont du plomb dans l'aile... Et la France fait cavalier seul
dans OSM en voulant imposer aux autres pays un modèle basé uniquement
sur des frontières étanches et exclusives, et difficiles à maintenir
cohérentes.

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

Re: [OSM-talk-fr] Tram T4 Bondy-Aulnay : railway=light_rail ou railway=tram ?

[Jérome Armau]

Les wikis anglophones et allemands ont l'air de considérer que le critère
principal est une plateforme séparée de la circulation routière sur la
majorité du parcours pour le light_rail, alors que le tram est mêlé à la
circulation. Ce qui voudrait dire que pour Paris, T1 et T3 sont tram, T4
est light_rail et T2 est un OVNI (les sections actuellement ouvertes sont
clairement du type light_rail, mais le nouveau prolongement à Pont de
Bezons est plutôt tram il me semble).

Les lignes françaises les plus semblables au T4 parisien sont le T3
lyonnais et le tram-train Mulhouse - Vallée de la Thur, qui sont toutes
deux railway=tram. Du coup, j'ai l'impression que l'usage francais est
assez différent de ce qui se fait à l'étranger... faudrait-il corriger ça ?

2012/10/10 Eric SIBERT 

> Et l'espacement des rails comparé au chemin de fer classique et aux autres
> lignes de tram?
>
> A Baltimore, il y a un truc qui s'appelle le light_rail, qui est
> d'ailleurs taggué comme tel. En centre-ville, ça ressemble à du tram qui
> roule au milieu de la chaussée. Quand on part en banlieue, c'est en site
> propre qui fait plus penser au RER. L'espacement est celui des trains: 1435
> mm.
>
> http://osm.org/go/ZZfUD8nPo--
>
>
>
> Éric
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Séparation commune et Landuse : demande vérification.

[Marc]

Bonjour,

Ayant le sentiment que les limites administratives sont des trucs 
fragiles, je viens demander une vérification sur ma séparation du 
Landuse residential de la limite administrative.
La frontière entre Médan et Villenes était intégrée au multipolygone  de 
zone résidentiel de Villenes.

J'ai
- dupliqué les points à chaque extrémité (obtenu trois points) et 
deplacé ceux des ways dédié landuse,

- prolongé le way landuse pour fermer le multipolygone,
- refusionnés les points dupliqués (ceux resté en double sur les ways 
limite administrative)

- supprimé de la relation landuse les ways de la limite administrative.

Le changeset correspondant est là:
http://www.openstreetmap.org/browse/changeset/13449892

Ai-je merdé ?

Cordialement.

--

Marc http://www.openstreetmap.org/user/plonk/


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

[OSM-talk-fr] Ç'ui-la, je l'comprends pas…

[JB]

 

OSRM m'y a fait regarder de plus prêt, il évite un passage de cette
route principale pour passer par le petit village voisin (tiens, le
bouton permalink a disparu ? Chez vous aussi ?). Un coup d'œil sous
JOSM, je vois rien qui ne va pas, ni sur le way, ni sur les nodes, mais
OSMI indique bien un « small component », que je ne trouve pas non-plus
sous JOSM :
http://tools.geofabrik.de/osmi/?view=routing&lon=5.59845&lat=44.83161&zoom=18


Le way : 164407528, au niveau de la frontière Clelles-St-Martin de
Clelles. 

La dernière modification de la voie date du 12 septembre, les
small-components ont-ils été compilés avant ? OSRM utilise des données
OSM à jour, il me semble ? 

Rondoudjou, qu'est-ce qui empêche OSRM de
faire passer des voitures par là ? 

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

Re: [OSM-talk-fr] Ç'ui-la, je l'comprends pas…

[Etienne Trimaille]

Le 11 octobre 2012 07:55, JB  a écrit :
>
> (tiens, le bouton permalink a disparu ? Chez vous aussi ?).
>

Non non. Dans la description de ton itinéraire, clique sur "générer un
lien".
http://osrm.at/1vx

Dans OSRM, tu peux aussi afficher les smallcomponents dans la liste des
calques. C'est à mon avis le même calque que sur geofabrik.

Je pense que les données d'OSRM ne sont pas à jour car le tracé de la route
au nord du marqueur vert ne correspond pas à mapnik.
Par contre pour géofabrik, les données sont d'hier normalement. Je ne
comprends pas l'erreur ... :/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr