Re: [OSM-talk-fr] Erreur Osmose 1070 (highway vs. building)

[Matthias Dietrich]

Le 1 juin 2012 01:04, Philippe Verdy  a écrit :
>
> La solution consiste à découper ce way fermé en tronçon, le tout dans
> une relation, pour que les parties partagées par le bâtiment ne posent
> pas de problème. Dans ce cas on reportera area=yes sur la relation
> définissant la place, et on l'enlève des ways membres à ne pas oublier
> sinon la relation dessinera une rue circulaire et ne remplira pas
> toute la place.
>
> On peut alors aussi découper les ways fermés des bâtiments eux aussi
> en tronçon pour qu'ils se partage les tronçons non fermés qui limitent
> à la fois le bâtiment et la place. Là encore on reporte les attributs
> du bâtiment des ways vers la relation.
>
>
Je n’appellerais pas forcément cela une solution, à supposer qu'Osmose
n'ait rien à redire avec une telle modélisation.
On peut bien sûr utiliser des relations à la place de simples ways, mais en
fin de compte, du point de vue géométrique,
on se retrouve avec le même résultat : 2 polygones qui se touchent par un
segment. Dans les 2 cas, la surface de recouvrement est nulle,
il n'y a donc pas de chevauchement.

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

[OSM-talk-fr] Au sud ? Plus au sud...

[Christian Quest]

C'est ici: http://www.openstreetmap.org/?lat=-75.09995&lon=123.3364&zoom=16

Lien signalé sur le formulaire contact de http://openstreetmap.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] Au sud ? Plus au sud...

[Ab_fab]

Excellent !
Quelle est la source ? Je ne vois pas d'imagerie dans Potlatch 2

Concernant les voies de circulation, je n'ai pas trouvé de mention de
revêtement de type glace dans le wiki
(mais 41 occurences de "surface = ice" selon taginfo).
Cela pourrait donc être ajouté

Il y a cette possibilité également :
http://wiki.openstreetmap.org/wiki/Key:ice_road
Mais peut être à réserver aux "grands axes" locaux :
http://fr.wikipedia.org/wiki/Transport_en_Antarctique#Routes

Je vois sur la description des tracés de pistes "bicycle = yes"
Et je suis bien curieux de savoir s'ils ont des vélos sur place ;-)

Le 1 juin 2012 11:00, Christian Quest  a écrit :

> C'est ici:
> http://www.openstreetmap.org/?lat=-75.09995&lon=123.3364&zoom=16
>
> Lien signalé sur le formulaire contact de http://openstreetmap.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
>



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

[OSM-talk-fr] Cadastre vectoriel décalé de près de 400m... un record ?

[Christian Quest]

En voulant importer les limites de la commune de Leugny (89), je suis
tombé sur des limites existantes visiblement TRES décalées.
J'ai donc regénéré les fichiers .osm de ces communes, et le cadastre
vectoriel y est décalé d'environ 400m.

J'ai vérifié avec les repères géodésiques et cela confirme ce
décalage. Bing étant correctement calé j'ai repris les
boundary=administrative que j'ai recalé visuellement sur bing. C'est
pas parfait mais nettement mieux que ce qui était présent.

Avez-vous déjà rencontré des décalages si importants sur du cadastre vectoriel ?

-- 
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] Moteurs de rendu de cartes utilisant le modèle public_transport ?

[teuxe]

Bonjour tout le monde,

Je me passionne pour l'intégration des données de transports publics dans OSM : 
en ce moment j'ajoute et je corrige un certain nombre de trajets de bus sur 
l'est de la région parisienne, mais je ne m'arrêterai pas là, les voies ferrées 
étant aussi un autre de mes dadas :)

Je voulais savoir s'il existe actuellement un moteur de rendu qui prenne en 
compte le nouveau modèle de données pour les transports publics, approuvé en 
avril 2011 par la communauté, et qui semble plus en adéquation avec les besoins 
de "logique structurante" qui ont pu être récemment légèrement abordés sur 
cette liste de discussion ;)
http://wiki.openstreetmap.org/wiki/Public_transport

Actuellement, le rendu "Carte de transport" par défaut sur openstreetmap.org 
considère les relations route=bus mais ne prend pas en compte d'autres parties 
importantes du modèle, en particulier les arrêts (highway=bus est rendu comme 
d'habitude, avec l'ancien sens, même lorsqu'il est associé à une relation 
"stop_area") et peut-être même pas les "super-relations" route_master=bus. Je 
suspecte qu'il ne soit d'ailleurs pas du tout question du modèle 
public_transport dans le rendu de ces tuiles.

D'autres amateurs de ce type de données qui pourraient m'éclairer ?


Teuxe


PS. Quelqu'un sait s'il est possible de réordonner les membres d'une relation ? 
Avec quel outil ?

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

Re: [OSM-talk-fr] Cadastre vectoriel décalé de près de 400m... un record ?

[teuxe]

Oh, 400 mètres, c'est si peu ; moins de 5 minutes à pied :D


- Mail Original -
De: "Christian Quest" 
À: "Discussions sur OSM en français" 
Envoyé: Vendredi 1 Juin 2012 11h28:02 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: [OSM-talk-fr] Cadastre vectoriel décalé de près de 400m... un record ?

En voulant importer les limites de la commune de Leugny (89), je suis
tombé sur des limites existantes visiblement TRES décalées.
J'ai donc regénéré les fichiers .osm de ces communes, et le cadastre
vectoriel y est décalé d'environ 400m.

J'ai vérifié avec les repères géodésiques et cela confirme ce
décalage. Bing étant correctement calé j'ai repris les
boundary=administrative que j'ai recalé visuellement sur bing. C'est
pas parfait mais nettement mieux que ce qui était présent.

Avez-vous déjà rencontré des décalages si importants sur du cadastre vectoriel ?

-- 
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] Moteurs de rendu de cartes utilisant le modèle public_transport ?

[Gilles Bassière]

Le vendredi 01 juin 2012 à 12:04 +0200, te...@free.fr a écrit :
> Bonjour tout le monde,
> 
> Je me passionne pour l'intégration des données de transports publics dans OSM 
> : en ce moment j'ajoute et je corrige un certain nombre de trajets de bus sur 
> l'est de la région parisienne, mais je ne m'arrêterai pas là, les voies 
> ferrées étant aussi un autre de mes dadas :)
> 
> Je voulais savoir s'il existe actuellement un moteur de rendu qui prenne en 
> compte le nouveau modèle de données pour les transports publics, approuvé en 
> avril 2011 par la communauté, et qui semble plus en adéquation avec les 
> besoins de "logique structurante" qui ont pu être récemment légèrement 
> abordés sur cette liste de discussion ;)
> http://wiki.openstreetmap.org/wiki/Public_transport
> 
> Actuellement, le rendu "Carte de transport" par défaut sur openstreetmap.org 
> considère les relations route=bus mais ne prend pas en compte d'autres 
> parties importantes du modèle, en particulier les arrêts (highway=bus est 
> rendu comme d'habitude, avec l'ancien sens, même lorsqu'il est associé à une 
> relation "stop_area") et peut-être même pas les "super-relations" 
> route_master=bus. Je suspecte qu'il ne soit d'ailleurs pas du tout question 
> du modèle public_transport dans le rendu de ces tuiles.
> 
> D'autres amateurs de ce type de données qui pourraient m'éclairer ?
> 
> 
> Teuxe
> 
> 
> PS. Quelqu'un sait s'il est possible de réordonner les membres d'une relation 
> ? Avec quel outil ?


Je fais un peu le même boulot à Marseille. J'ai listé sur le wiki les
quelques visualisation que je connais :
http://wiki.openstreetmap.org/wiki/Marseille/Transports_en_commun#Outils

Je sais que certains ne sont pas conforme au schéma Public Transport. Je
ne sais pas s'il en existe un qui soit complètement conforme.

Cordialement
-- 
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/



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

Re: [OSM-talk-fr] Moteurs de rendu de cartes utilisant le modèle public_transport ?

[Christian Quest]

Réponse très partielle ;)

Le 1 juin 2012 12:04,   a écrit :
> PS. Quelqu'un sait s'il est possible de réordonner les membres d'une relation 
> ? Avec quel outil ?
>


L'éditeur de relation de JOSM permet de trier les membres (icone
"A..Z" à gauche).

-- 
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] Ordonner les membres d'une relation (était: Re: Moteurs de rendu de cartes utilisant le modèle public_transport ?)

[Gilles Bassière]

Le vendredi 01 juin 2012 à 12:04 +0200, te...@free.fr a écrit :
> PS. Quelqu'un sait s'il est possible de réordonner les membres d'une relation 
> ? Avec quel outil ?

Avec l'éditeur de relation de JOSM, tu peux réordonner les membres.
Regarde les boutons à gauche de la liste des membres, il y a une flèche
vers le bas et une autre vers le haut.

Cordialement
-- 
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/



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

Re: [OSM-talk-fr] Ordonner les membres d'une relation (était: Re: Moteurs de rendu de cartes utilisant le modèle public_transport ?)

[Nicolas Croiset]

Le 01-06-2012 12:15, Gilles Bassière a écrit :

Le vendredi 01 juin 2012 à 12:04 +0200, te...@free.fr a écrit :
PS. Quelqu'un sait s'il est possible de réordonner les membres d'une 
relation ? Avec quel outil ?


Avec l'éditeur de relation de JOSM, tu peux réordonner les membres.
Regarde les boutons à gauche de la liste des membres, il y a une 
flèche

vers le bas et une autre vers le haut.


Il y a également un bouton tri qui refait l'ordonnancement 
automatiquement. c'est bien plus rapide !


A+

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

Re: [OSM-talk-fr] Cadastre vectoriel décalé de près de 400m... un record ?

[Eric Sibert]

Avez-vous déjà rencontré des décalages si importants sur du cadastre  
vectoriel ?


J'ai déjà rencontré en haute montagne des limites fausses à 200 m près  
sans parler des lignes droites tracées entre sommets sans suivre la  
ligne de crête. En plaine, je suis tombé une fois sur une divergence  
alors que je traçais une voie ferrée. Ca sentait l'erreur de saisie au  
calage du cadastre. Ca donne quoi vis à vis des communes voisines?



Eric


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

[OSM-talk-fr] Apport du GeoFLA pour les nodes "place" : chantier terminé

[Vincent de Chateau-Thierry]

Bonjour,
Ce message pour annoncer la fin de PlaceMaker 1ere version [1] annoncé 
initialement ici :
http://lists.openstreetmap.org/pipermail/talk-fr/2012-March/042052.html

2 mois plus tard, cette interface n'a plus d'objet, dans la mesure où les 4000 
et
quelques points déduits du GeoFLA et situés dans une commune sans aucun node 
place=*,
ont été traités. Les derniers points datent d'hier.

Merci aux contributeurs qui ont pris de leur temps ! Ce chantier aura permis de 
réduire
fortement les situations où on ne sait même pas donner le nom d'une commune en 
centrant
la carte dessus, ou en interrogeant Nominatim. 

Entre temps sont arrivés les outils d'intégration des bureaux de poste [2] et 
des
établissements scolaires [3]. L'avancement, dans les 2 cas, est modeste : pas 
encore 10%
des bureaux de postes intégrés, pas encore 2% des écoles. Donc avis aux 
amateurs, il y a
de quoi faire.

vincent

[1] : http://osm.vdct.free.fr/geofla/index.html
[2] : http://osm.vdct.free.fr/postes/index.html
[3] : http://nomino.comptoir.net/etablissements/


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] Osmose - faux positif soundex

[Jocelyn Jaubert]

2012/5/31 Frédéric Rodrigo :
>> Et il revient encore :
>>
>> http://osmose.openstreetmap.fr/map/?zoom=16&lat=48.31134&lon=1.99758&item=5050
>>
>> Les faux positifs sont-ils effacés de la base régulièrement ?
>
>
> On a bien constaté le problème. Par contre l'on n'a toujours pas identifié
> la source.
> Normalement les faux positifs qui ne se reproduisent plus sont purgés. Mais
> là ce n'est pas le cas.

Est-ce que ça ne serait pas parce que l'erreur est marquée en
"corrigé" plutôt qu'en "faux-positif" ?

En tout cas, je vois l'erreur apparaitre là (datant du 31 mai):

http://osmose.openstreetmap.fr/utils/done.py?source=156&item=5050&class=1

Et il n'y a rien d'intéressant dans la liste des faux-positifs:

http://osmose.openstreetmap.fr/utils/false-positive.py?item=5050&class=1


Les erreurs marquées corrigés sont effectivement retenu pendant
quelques jours avant d'être supprimé de la base de donnée - ceci afin
de vérifier si l'erreur a été bien corrigée dans la base de donnée
d'OSM.

Les faux-positifs restent dans osmose, mais sont liés à une position
exacte du marqueur, et au numéro de l'élément (node, way, relation).
Ce qui veut dire que si l'élement change (ajout de nodes, déplacement
ou découpage en plusieurs morceaux), le faux-positif sera ignoré pour
les nouvelles erreurs générés. Ça pourrait expliquer d'autre cas
similaires.


Il y a peut-être une autre raison lié à l'analyse soundex elle-même.
L'analyse reporte des erreurs de façon statistique, en estimant les
noms qui paraissent inexacts par rapport aux autres noms déjà présent
dans la base de donnée d'OSM. Il se pourrait qu'un changement sur un
élément ailleurs dans la région crée des erreurs non-présente
auparavant. Je ne suis pas vraiment convaincu par cette explication,
mais ça pourrait expliquer le souci.


-- 
Jocelyn

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

Re: [OSM-talk-fr] Ordonner les membres d'une relation (était: Re: Moteurs de rendu de cartes utilisant le modèle public_transport ?)

[teuxe]

Merci à vous ! Je devrai trier à la main, car il s'agit d'un ordre de segments 
et d'arrêts, sans possibilité de tri alpha-numérique (à moins de numéroter les 
arrêts...).

Teuxe

- Mail Original -
De: "Nicolas Croiset" 
À: talk-fr@openstreetmap.org
Envoyé: Vendredi 1 Juin 2012 12h28:49 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: Re: [OSM-talk-fr] Ordonner les membres d'une relation (était:  Re:  
Moteurs de rendu de cartes utilisant le modèle public_transport ?)

Le 01-06-2012 12:15, Gilles Bassière a écrit :
> Le vendredi 01 juin 2012 à 12:04 +0200, te...@free.fr a écrit :
>> PS. Quelqu'un sait s'il est possible de réordonner les membres d'une 
>> relation ? Avec quel outil ?
>
> Avec l'éditeur de relation de JOSM, tu peux réordonner les membres.
> Regarde les boutons à gauche de la liste des membres, il y a une 
> flèche
> vers le bas et une autre vers le haut.

Il y a également un bouton tri qui refait l'ordonnancement 
automatiquement. c'est bien plus rapide !

A+

___
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] Apport du GeoFLA pour les nodes "place" : chantier terminé

[Art Penteur]

Le 1 juin 2012 13:28, Vincent de Chateau-Thierry  a écrit :
[...]
> Entre temps sont arrivés les outils d'intégration des bureaux de poste [2] et 
> des
> établissements scolaires [3]. L'avancement, dans les 2 cas, est modeste : pas 
> encore 10%
> des bureaux de postes intégrés, pas encore 2% des écoles. Donc avis aux 
> amateurs, il y a
> de quoi faire.

   Certe, mais la situation n'est pas la même.
   Le GeoFLA est une bonne source, on peut viser l'intégration à 100%
et le contrôle de chaque import était minime.
  La qualité du fichier des points de contact publics de la Poste est
beaucoup moindre (pour rappel : cela va de points parfaitement situés
à des points placés dans une commune plus ou moins homonyme d'un autre
département, et passant par ceux situés dans la bonne rue mais au
mauvais endroit, ou tout simplement au centre de la commune).
  Donc :
- la fusion avec les bureaux de poste existants est facile,
   - l'import de bureaux qui ont une adresse et qui sont dans une
commune avec cadastre vectorisé comportant le numéro de rue est
possible et vérifiable (qualité primordiale pour OSM)
   - les autres cas sont moins faciles, voire impossible sans visite
sur place (adresse = "au bourg")

  La vitesse d'import va donc être plus faible, et l'objectif ne peut
pas être 100%.

   Au fait, est-il possible de faire des statistiques de distance
entre la position dans le fichier de la poste et la position sur le
terrain ?

Art.

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

Re: [OSM-talk-fr] Cadastre vectoriel décalé de près de 400m... un record ?

[Christian Quest]

Le 1 juin 2012 13:26, Eric Sibert  a écrit :
> J'ai déjà rencontré en haute montagne des limites fausses à 200 m près sans
> parler des lignes droites tracées entre sommets sans suivre la ligne de
> crête. En plaine, je suis tombé une fois sur une divergence alors que je
> traçais une voie ferrée. Ca sentait l'erreur de saisie au calage du
> cadastre. Ca donne quoi vis à vis des communes voisines?
>

Là on est en plaine, donc ce n'est pas lié au relief.
C'est un ensemble de communes qui ont ce décalage, c'est ça qui m'a le
plus étonné.

Retrouver la bonne position des limites a été facile avec bing car
elles suivent des routes, des champs, des lisières de foret ou des
cours d'eau. Heureusement que bing est bien calé dans le coin et qu'on
a les repères géodésiques comme référence !

-- 
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] Ordonner les membres d'une relation (était: Re: Moteurs de rendu de cartes utilisant le modèle public_transport ?)

[Christian Quest]

Le 1 juin 2012 13:37,   a écrit :
> Merci à vous ! Je devrai trier à la main, car il s'agit d'un ordre de 
> segments et d'arrêts, sans possibilité de tri alpha-numérique (à moins de 
> numéroter les arrêts...).
>

Le tri n'est pas alphanumérique, mais logique... par rôle, puis par
type et ensuite en gérant la continuité des géométries. C'est l'ordre
que j'ai repéré, mais j'ai pas regardé le code pour avoir
confirmation.

Avec l'icône de tri automatique de JOSM, les segments d'itinéraire se
trient donc sur leur continuité. Tu peux regrouper les segments de
voirie ensemble, puis les sélectionner pour ne trier que la voirie
sans toucher aux arrêts. C'est comme ça que je fais, ensuite je
regarde les coupures (clic-droit sur un les membres avec une coupure
dans l'itinéraire -> visualiser la coupure).

L'éditeur de relation a plein de petits astuces comme ça bien utiles !

-- 
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] Cadastre vectoriel décalé de près de 400m... un record ?

[teuxe]

Les cadastres de la région auraient-ils été réalisés à l'époque en rapport à 
des points géodésiques avec des coordonnées incorrectes ? Il me semble que les 
repères géodésiques étaient repérés par triangulation du temps où les GPS 
n'existaient pas, eux-mêmes référencés par rapport à quelques points 
"stratégiques"... Une erreur entre quelques points et tout le reste serait 
décalé ?

Teuxe

- Mail Original -
De: "Christian Quest" 
À: "Discussions sur OSM en français" 
Envoyé: Vendredi 1 Juin 2012 13h49:36 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: Re: [OSM-talk-fr] Cadastre vectoriel décalé de près de 400m... un record 
?

Le 1 juin 2012 13:26, Eric Sibert  a écrit :
> J'ai déjà rencontré en haute montagne des limites fausses à 200 m près sans
> parler des lignes droites tracées entre sommets sans suivre la ligne de
> crête. En plaine, je suis tombé une fois sur une divergence alors que je
> traçais une voie ferrée. Ca sentait l'erreur de saisie au calage du
> cadastre. Ca donne quoi vis à vis des communes voisines?
>

Là on est en plaine, donc ce n'est pas lié au relief.
C'est un ensemble de communes qui ont ce décalage, c'est ça qui m'a le
plus étonné.

Retrouver la bonne position des limites a été facile avec bing car
elles suivent des routes, des champs, des lisières de foret ou des
cours d'eau. Heureusement que bing est bien calé dans le coin et qu'on
a les repères géodésiques comme référence !

-- 
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] Apport du GeoFLA pour les nodes "place" : chantier terminé

[Vincent de Chateau-Thierry]

> De : "Art Penteur" 
>
> Le 1 juin 2012 13:28, Vincent de Chateau-Thierry  a écrit :
> [...]
> > Entre temps sont arrivés les outils d'intégration des bureaux de poste [2] 
> > et des
> > établissements scolaires [3]. L'avancement, dans les 2 cas, est modeste : 
> > pas encore 
10%
> > des bureaux de postes intégrés, pas encore 2% des écoles. Donc avis aux 
> > amateurs, il 
y a
> > de quoi faire.
> 
> Certe, mais la situation n'est pas la même.
> Le GeoFLA est une bonne source, on peut viser l'intégration à 100%
> et le contrôle de chaque import était minime.
> La qualité du fichier des points de contact publics de la Poste est
> beaucoup moindre (pour rappel : cela va de points parfaitement situés
> à des points placés dans une commune plus ou moins homonyme d'un autre
> département, et passant par ceux situés dans la bonne rue mais au
> mauvais endroit, ou tout simplement au centre de la commune).
> Donc :
> - la fusion avec les bureaux de poste existants est facile,
> - l'import de bureaux qui ont une adresse et qui sont dans une
> commune avec cadastre vectorisé comportant le numéro de rue est
> possible et vérifiable (qualité primordiale pour OSM)
> - les autres cas sont moins faciles, voire impossible sans visite
> sur place (adresse = "au bourg")
> 
> La vitesse d'import va donc être plus faible, et l'objectif ne peut
> pas être 100%.
> 

Je suis bien sûr d'accord avec ton constat. Je ne dis pas qu'on atteindra les 
100%, et
parti comme c'est, on en a de toute façon pour un bout de temps, sur chacun des 
2 sujets.
Mais un des leviers pour que ces sujets avancent, c'est d'en parler, d'où le 
coup de pub
que j'ai voulu glisser dans mon mail :-)

Un autre levier serait d'afficher sur la même carte
- les données en base mais dépourvues de références prouvant leur intégration 
(ref:FR:LaPoste, ref:UAI)
- et les données à intégrer
Ça indiquerait simplement quels objets en attente d'intégration sont 
potentiellement
le doublon d'un objet en base, donc des objets candidats à la fusion. On sait 
que
ceux-là sont plus rapides / plus simples à intégrer. Je ne dis pas quand je le 
ferai
côté bureaux de postes, car j'ai un peu de mal à trouver du temps en ce moment.

> Au fait, est-il possible de faire des statistiques de distance
> entre la position dans le fichier de la poste et la position sur le
> terrain ?
> 

Oui, grâce au tag ref:xxx, il est trivial de mesurer la distance entre les 2 
positions.
Je me le note, pour les bureaux de poste.

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] Cadastre vectoriel décalé de près de 400m... un record ?

[Romain MEHUT]

Bonjour,

Je dérive un peu de la question initiale de Christian pour vous demander le
pourquoi de ces cadastres décalés? Je peux comprendre qu'une image aérienne
puisse l'être du fait des défauts de prises de vue mais pour le cadastre,
il devrait quand même y avoir une expertise professionnelle assurant un
géoréférencement précis, non?

Romain

Le 1 juin 2012 14:06,  a écrit :

> Les cadastres de la région auraient-ils été réalisés à l'époque en rapport
> à des points géodésiques avec des coordonnées incorrectes ? Il me semble
> que les repères géodésiques étaient repérés par triangulation du temps où
> les GPS n'existaient pas, eux-mêmes référencés par rapport à quelques
> points "stratégiques"... Une erreur entre quelques points et tout le reste
> serait décalé ?
>
> Teuxe
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Cadastre vectoriel décalé de près de 400m... un record ?

[Christian Quest]

Le 1 juin 2012 14:06,   a écrit :
> Les cadastres de la région auraient-ils été réalisés à l'époque en rapport à 
> des points géodésiques avec des coordonnées incorrectes ? Il me semble que 
> les repères géodésiques étaient repérés par triangulation du temps où les GPS 
> n'existaient pas, eux-mêmes référencés par rapport à quelques points 
> "stratégiques"... Une erreur entre quelques points et tout le reste serait 
> décalé ?


Sur géoportail, le cadastre raster est bien calé, ainsi que les
emprises des bâtiments (une couche différente d'info sur géoportail,
d'ailleurs les bâtiments n'ont pas la même forme que sur le vieux
cadastre raster).

J'ai vérifié un repère géodésique de source IGN signalant la position
d'un clocher d'église... et ça correspondait bien à bing. Ouf !


D'où peut provenir l'erreur ? aucune idée, mais en tout cas, ça montre
que la DGI ne vérifie pas sérieusement les infos qu'on lui transmet...

-- 
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] Salon Solutions Linux

[Romain MEHUT]

Bonjour,

D'après ce que je sais, Gaël y sera et Ab_fab devrait donner un coup de
main.

Romain

Le 31 mai 2012 16:13, rldhont  a écrit :

> Bonjour,
>
> Est-ce-que l'association OSM-France a demandé un Stand pour les Solutions
> Linux de cette année qui auront lieu au CNIT (La Défense) du 19 au 21 juin
> 2012 ?
>
> René-Luc
>
> __**_
> 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] Salon Solutions Linux

[rldhont]

Comme depuis 5 ans j'avais prévu d'y aller et donc de passer du temps 
sur le stand!


Le 01/06/2012 14:32, Romain MEHUT a écrit :

Bonjour,

D'après ce que je sais, Gaël y sera et Ab_fab devrait donner un coup 
de main.


Romain

Le 31 mai 2012 16:13, rldhont > a écrit :


Bonjour,

Est-ce-que l'association OSM-France a demandé un Stand pour les
Solutions Linux de cette année qui auront lieu au CNIT (La
Défense) du 19 au 21 juin 2012 ?

René-Luc

___
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


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

Re: [OSM-talk-fr] Cadastre vectoriel décalé de près de 400m... un record ?

[Eric Sibert]

Sur géoportail, le cadastre raster est bien calé, ainsi que les
emprises des bâtiments (une couche différente d'info sur géoportail,
d'ailleurs les bâtiments n'ont pas la même forme que sur le vieux
cadastre raster).


L'IGN a utilisé une méthode de calage "à l'arrache" en détectant les  
similitudes entre les planches cadastre scannées et l'orthophoto. Ils  
annoncent quelques mètres de précision. Et tant qu'il y a des  
parcelles, ça va pas mal.


D'ailleurs, ça m'amène à la réflexion qu'on ne devrait utiliser le  
cadastre que là où il y a des parcelles. Exit la haute montagne...



D'où peut provenir l'erreur ? aucune idée, mais en tout cas, ça montre
que la DGI ne vérifie pas sérieusement les infos qu'on lui transmet...


Je m'interroge toujours sur les méthodes utilisées par la DGI. Il y a  
une norme traitant de la qualité des mesures pour caler les planches.  
En pratique, ça voudrait dire qu'il faut mesurer sur le terrain au GPS  
de précision plusieurs points par planche. Quand on voit les  
décalages, je doute que ce soit le cas. En plus 400 m en plaine, ça  
doit commencer à les déformer sérieusement les planches. Il devrait y  
avoir des alertes. Ca doit être pour ça que je continue à voir bosser  
les géomètres sur le terrain avec théodolite/télémètre, le cadastre  
étant trop mal géoréférencé ;-)


Eric


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

[OSM-talk-fr] questions de débutants en carto accessible

[Claude Laurent]

Bonjour,
Nous avions lancé un appel asses général pour être aidé à débuter sur JOSM et 
plus généralement la carto accessible, il y'a quelques temps, mais nous n'avons 
pas vraiment eu de réponse. Nous avons tout de même un peu avancé, et nous 
sommes maintenant en mesure de préciser nos demandes.

Je précise que nous nous essayons (grands débutants) à de la carto 
d'accessibilité, donc nous ne faisons (pour le moment) que tagger pour les 
trottoirs.

Voici nos questions :
par exemple : un trottoir qui s'arrête à la moitié d'une rue. Comment rajouter 
un noeud et un chemin dans JOSM ?
Pour le tag de hauteur de trottoir : il nous semble avoir compris qu'il s'agit 
de la hauteur du 'bateau' (l'endroit que l'on franchi en face des passages 
cloutés), et non pas la hauteur du trottoir le long de la rue. Donc comment 
faire pour distinguer les deux extrémités du trottoir et ainsi quantifier 
« l'entrée » et la « sortie » ?
sur un trottoir globalement très bien fichu, je rencontre un obstacle (ex : 
inclinaison de sortie de garage). Comment tagger ce trottoir, est-ce que je 
rajoute un noeud à l'endroit de l'obstacle, ou est-ce que c'est toute la 
longueur du trottoir que l'on taggue comme l'obstacle ?
Soit une unique rue constituée de 3 tronçons dans JOSM, les tronçons sont 
taggués différemment car leurs trottoirs sont différents. Mais j'ai un problème 
car le nom de la rue est renseigné pour chaque tronçon, donc sur la carte il 
s'affiche 3 fois. Et si je re-solidarise les tronçons alors mes différences de 
trottoir sont perdues. J'espère être clair... comment on gère ça ?

Je profite de ce message pour relancer notre appel :
Si quelqu'un de plus expérimenté que nous passe du côté de Lyon (Craponne pour 
être précis) : alors nous serions ravis de le recevoir !!

Merci de vos réponses.

Cordialement,




Laurent CLAUDE
Animateur coordinateur au SAJ Anagalis

ARIMC - Les Tourrais de Craponne
2 rue des Tourrais
69290 Craponne
Tel 04 37 41 75 78
Fax 04 37 41 75 73

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

Re: [OSM-talk-fr] Apport du GeoFLA pour les nodes "place" : chantier terminé

[Nicolas Dumoulin]

Le vendredi 1 juin 2012 13:28:47 Vincent de Chateau-Thierry a écrit :
> Bonjour,
> Ce message pour annoncer la fin de PlaceMaker 1ere version [1] annoncé
> initialement ici :
> http://lists.openstreetmap.org/pipermail/talk-fr/2012-March/042052.html
> 
> 2 mois plus tard, cette interface n'a plus d'objet, dans la mesure où les
> 4000 et quelques points déduits du GeoFLA et situés dans une commune sans
> aucun node place=*, ont été traités. Les derniers points datent d'hier.
> 
> Merci aux contributeurs qui ont pris de leur temps ! Ce chantier aura permis
> de réduire fortement les situations où on ne sait même pas donner le nom
> d'une commune en centrant la carte dessus, ou en interrogeant Nominatim.

Super,

Maintenant, il faudrait vérifier le positionnement des points qui existait 
avant. En effet, en traçant dans le Cantal, je corrige le positionnement de pas 
mal de nœuds place=* déjà présents.
Il serait donc pas mal de faire une passe sur toutes les communes françaises 
pour vérifier la distance entre le positionnement Geofla et l'emplacement du 
nœud du chef-lieu de commune (s'il est possible de le trouver). Bien 
évidemment, le test n'aurait pas forcément beaucoup de sens pour les communes 
avec une forte densité urbaine, mais en zone rural, un écart de 500 mètres est 
plus embettant.
Il faudrait donc filtrer la liste des communes pour ne garder que celles avec 
une faible population (données INSEE).

Ça vous semble pertinent ?

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

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

Re: [OSM-talk-fr] Apport du GeoFLA pour les nodes "place" : chantier terminé

[Frédéric Rodrigo]

Le 01/06/2012 14:07, Vincent de Chateau-Thierry a écrit :

Un autre levier serait d'afficher sur la même carte
- les données en base mais dépourvues de références prouvant leur intégration
(ref:FR:LaPoste, ref:UAI)
- et les données à intégrer
Ça indiquerait simplement quels objets en attente d'intégration sont 
potentiellement
le doublon d'un objet en base, donc des objets candidats à la fusion. On sait 
que
ceux-là sont plus rapides / plus simples à intégrer. Je ne dis pas quand je le 
ferai
côté bureaux de postes, car j'ai un peu de mal à trouver du temps en ce moment.


C'est prévu de faire ça dans osmose. Les postes sans ref sont déjà 
affichées.


http://osmose.openstreetmap.fr/map/?item=7050

Il est également prévu d'afficher les objets à importer pour :
- les postes,
- les écoles,
- les monuments historiques.
Le code est déjà écrit, il faut encore le tester et le déployer sur le site.

L'import pourra se faire dans josm via le lien "josm fix", en place 
depuis peu, qui charge un objet corrigé dans josm.


Frédéric.

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

[OSM-talk-fr] JDLL 2012

[Yannick VOYEAUD]

Bonjour à toutes et tous,

Les JDLL se préparent.
Merci de commencer à voir si on doit penser à un stand pour OSM et/ou un 
atelier.


Pour information les JDLL déménagent et s'installent dans le centre de 
Lyon. La date retenue est le samedi 17 et dimanche 19 novembre
Le thème général est le réseau domestique avec toutes ses composantes 
comme ssh, le nuage en local, la domotique, l'accès pour les handicaps, ...


Amitiés

--
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org

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

Re: [OSM-talk-fr] Salon Solutions Linux

[Jean Couteau]

Le 01/06/2012 14:42, rldhont a écrit :
> Comme depuis 5 ans j'avais prévu d'y aller et donc de passer du temps
> sur le stand!

Moi je serais au salon, je pourrais peut-être faire un tour, mais je
dois aussi tenir le stand du boulot, donc ça sera peut-être qu'en speed.

Jean

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

Re: [OSM-talk-fr] Ordonner les membres d'une relation (était: Re: Moteurs de rendu de cartes utilisant le modèle public_transport ?)

[Philippe Verdy]

Le 1 juin 2012 13:55, Christian Quest  a écrit :
> Avec l'icône de tri automatique de JOSM, les segments d'itinéraire se
> trient donc sur leur continuité. Tu peux regrouper les segments de
> voirie ensemble, puis les sélectionner pour ne trier que la voirie
> sans toucher aux arrêts. C'est comme ça que je fais, ensuite je
> regarde les coupures (clic-droit sur un les membres avec une coupure
> dans l'itinéraire -> visualiser la coupure).

Ce tri automatique marche asez mal avec les circuits des lignes de bus
qui suivent des segments de rue communs (mais en sens contraire)...
Par exemple si dans une direction il fait un décrochement vers une rue
pour en ressortir en faisant demi-tour (autour d'un rond-point par
exemple) et reprendre la ligne principale.

Dans le sens contraire, ce décrochement n'est pas suivi. Il est très
courant que les chemins dans une direction et dans une autre ne soient
pas strictement le long des mêmes rues (sens uniques obligent ou parce
que le décrochement pour ramasser ou déposer des passagers n'est
utilisé principalement que dans une seule direction, surtout si le
décrochement est proche d'un autre terminus).

On a parfois aussi le cas du passage multiple en un même arrêt sans
que les chemins se superposent.

Même en séparant les chemins selon la direction, cela ne suffit pas
pour ordonner correctement une des directions si elle suit justement
la boucle de décrochement.

La solution consisterait alors à découper le circuit en relations
séparées afin que les chemins de chacune ne forment plus de boucles ni
de double passage au même endroit. Ensuite utiliser une autre relation
pour réunir ces chemins.

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

Re: [OSM-talk-fr] Osmose - faux positif soundex

[Maetma 91]

Le 1 juin 2012 13:36, Jocelyn Jaubert  a écrit :
> 2012/5/31 Frédéric Rodrigo :
>>> Et il revient encore :
>>>
>>> http://osmose.openstreetmap.fr/map/?zoom=16&lat=48.31134&lon=1.99758&item=5050
>>>
>>> Les faux positifs sont-ils effacés de la base régulièrement ?
>>
>>
>> On a bien constaté le problème. Par contre l'on n'a toujours pas identifié
>> la source.
>> Normalement les faux positifs qui ne se reproduisent plus sont purgés. Mais
>> là ce n'est pas le cas.
>
> Est-ce que ça ne serait pas parce que l'erreur est marquée en
> "corrigé" plutôt qu'en "faux-positif" ?

Il se peut que je me trompe en cliquant mais à chaque fois je doute.

Je viens par ailleurs de faire un test sur un autre Soundex que je
venais de corriger et que j'ai mis en faux-positif et il est allé dans
la liste des corrigés. Pourtant le lien sur l'erreur avait l'air bon
(false). Le problème vient peut-être de là.

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

Re: [OSM-talk-fr] Osmose - faux positif soundex

[Philippe Verdy]

Le 1 juin 2012 13:36, Jocelyn Jaubert  a écrit :
> Les erreurs marquées corrigés sont effectivement retenu pendant
> quelques jours avant d'être supprimé de la base de donnée - ceci afin
> de vérifier si l'erreur a été bien corrigée dans la base de donnée
> d'OSM.

C'est là l'anomalie: dès que tu les supprimes de ta base, au prochain
import de données, ils vont réapparaître car tu ne sais plus que ce
sont des faux-positifs.

Tu devrais les garder quitte à les cacher, tant que les éléments OSM
marqués comme faux-positifs persistent dans la base OSM. Tu ne dois
les effacer QUE si l'objet en question n'est plus dans les données
OSM. Tu peux en revanche les regénérer si les objets en question ont
été modifiés d'une façon qui ne permet pas de savoir que ce sont
toujours des faux-positifs ou de nouveaux vrais positifs.

Ce veut dire garder au minimum les versions de ces objets marqués
comme faux-positifs !

D'autre part, les garder te permettra de faire une analyse globale
(statistiques) de ces faux-positifs, qui peuvent signaler un problème
de tes algos d'analyse, afin de les améliorer ou de savoir s'il est
encore pertinent de faire certains tests ou s'il ne vaudrait pas mieux
le supprimer et faire une analyse sur d'autres choses plus
pertinentes.

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

Re: [OSM-talk-fr] Cadastre vectoriel décalé de près de 400m... un record ?

[sergio7826]

Bonjour,
Je ne sais pas si cela a une origine commune, mais le bâti de la commune
d'Andon dans le 06, présente (via le plugin JOSM) un décalage de 300m vers
le Sud.
Ou tout au moins en présentait un fin 2011 lors de son importation (qui a
été recalé correctement par "jcr83").
Salutations

--
View this message in context: 
http://gis.19327.n5.nabble.com/Cadastre-vectoriel-decale-de-pres-de-400m-un-record-tp5711013p5711091.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] Au sud ? Plus au sud...

[Philippe Verdy]

Ces "routes" en Antarctique n'en sont pas, protection de
l(environnement oblige (et aussi à cause du Traité de l'Antarctique
qui limite les constructions qui peuvent être faites).

Au mieux on devrait les taguer en tant que "pistes". Elles ne sont le
fruit d'aucun travaux, ce sont juste des passages utilisables par les
véhicules de transport pour les expéditions, car le relief le permet.

Elles n'ont pas de réelles matérialisation, sauf éventuellement un
dégagement des congères et amas de neiges par des engins qui n'amènent
rien d'autre sur le terrain, et se contentent de traver une voie qui
disparaitra vite aux prochaines chutes de neige, ou parce que cela
passe sur des couloirs de glaciers en mouvement qui se fracturent sous
leur propre poussée en route vers l'océan.

Bref ce ne sont que des passages "recommandés" permettant de prévoir
les routes suivies (et aussi de prévoir les éventuels moyens de
secours aériens au cas où on reste en panne dessus, pour pouvoir
relocaliser facilement les naufragés à récupérer sur la piste).

De la même façon on a des pistes d'atterrissages recommandées, qui
peuvent être dégagées pour l'atterrissage d'avions ou d'hélicos. Pas
de matérialisation autre que quelques drapeaux et lampes posées
temporairement (mais qui ne passeront pas les terribles tempêtes de
l'hiver antarctique : chaque année il faut redégager les accès
détruits et rendus inutilisables immédiatement).

Si ça figure sur les cartes c'est pour justement permettre d'informer
les autres signataires du Traité des activités en cours en Antarctique
(car ils ont droit de contrôler la nature des activités suivies et que
l'utilisation n'importe pas de pollutions et préserve l'habitat des
espèces animales protégées, aussi bien sur le continent sur sous la
banquise et dans les eaux antarctiques).

De la même façon on localise les bâtiments servant d'abris aux
recherches scientifiques et aux observatoires, ainsi que les lieux
d'hivernage et les equipements de survie nécessaires (dépôts de
carburants inclus, ainsi que les lieux de collecte des ordures qu'il
faudra dégager chaque année, l'enfouissage dans les glaces ou la
création de décharges permanentes étant normalement interdit : la
dépollution est obligatoire, les « eaux usées » doivent être traitées
si elles ne sont pas naturelles, etc. mais il peut être admis de
laisser des déchets alimentaires à la disposition de la faune locale,
tant que cela reste « raisonnable » au plan de leur métabolisme
naturel, par exemple des graisses alimentaires).

Les incinérateurs sont aussi très restreints (ils polluent les glaces
environnantes et peuvent à terme empoisonner la fragile faune
locale...). Les véhicules accidentés ou devenus inutilisables ne
peuvent non plus être abandonnés (au minimum on impose de dégager les
moteurs dès que possible). De même que les éléments de construction
qui se seraient trouvés abîmés ou partiellement emportés par une
tempête, et laissant des déchets alentour pendant l'hiver : nettoyage
demandé dès que possible.

Les différents signataires du traité veillent les uns sur les autres à
ce que ces mesures de protection soient appliquées, moyennant quoi
chacun peut mener ses propres occupations scientifiques et disposer
d'un droit d'occupation quasi-permanent (même si les personnels ne
sont pas des résidents permanents) et d'un droit de propriété sur les
installations (qui restent accessibles au contrôle par les autres, via
une procédure prévue et ratifiée dans le Traité).

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

Re: [OSM-talk-fr] Erreur Osmose 1070 (highway vs. building)

[Philippe Verdy]

Le 1 juin 2012 06:43, Vincent de Chateau-Thierry  a écrit :
> Bonjour,
>
> Le 01/06/2012 01:04, Philippe Verdy a écrit :
>
>
>> La solution consiste à découper ce way fermé en tronçon, le tout dans
>> une relation, pour que les parties partagées par le bâtiment ne posent
>> pas de problème.
>
> Certes, mais pour quel bénéfice ? Ne plus faire détecter ce cas à Osmose ?
> C'est le seul intérêt que je vois, et de mon point de vue ça ne fait pas une
> bonne raison.
>
>
> Dans ce cas on reportera area=yes sur la relation
>>
>> définissant la place, et on l'enlève des ways membres à ne pas oublier
>> sinon la relation dessinera une rue circulaire et ne remplira pas
>> toute la place.
>
>
> Je ne dis pas que techniquement ta modélisation ne fonctionne pas (quoique
> reporter un tag area=yes sur un multipolygon, c'est un peu cocasse) mais je
> ne lui vois aucun intérêt côté résultat par rapport à ce qui se fait avec de
> simples ways fermés. En revanche au niveau complexité, on monte un échelon,
> et c'est dommage.

Malheureusement devoir indiquer un tag ara=yes est nécessaire pour
tous les highway=* qui sont partout interprétés par défaut comme des
routes linéaires sans tenir compte du fait qu'elles sont fermées.

Les highway=* sont une exception à la règle normale qui veut que par
défaut tout chemin fermé décrit une surface, que ce chemin soit un way
unique ou que ce soit une suite de chemins dans une même relation.

L'idéal serait de généraliser le type=multilinestring, mais le tag
type=* sert à plein d'autres choses. Et on trouve tout autant des
type=highway dans la base qui dès lors seront interprétés comme des
routes circulaires et non comme des surfaces partout où ses chemins
membres sont fermés.

Il faudrait donc, pour le cas des routes découpés dans des relations,
plutôt envisager de ne PAS leur laisser le rôle vide par défaut (il
est normalement interprété par défaut comme le rôle "outer") mais
utiliser un rôle indiquant clairement que même si le chemin est fermé
(ou pas), le way membre ne sert pas à fermer le contour d'une surface.
Dans ce cas le tag area=* pourrait être rendu obsolète ou déprécié.

L'autre solution serait de généraliser le fait que TOUT chemin fermé,
quel qu'il soit désigne la surface incluses dans ce contour fermé
(l'avantage étant qu'on n'est plus restreint dans certains types de
relation avec la valeur donnée au tag "type=*"). Et dans ce cas c'est
"area=yes" qui deviendrait inutile partout, et il faudrait alors
explicitement marquer "area=no" **seulement** pour les cas où cette
interprétation en tant que surface est fausse. En pratique cela
concerne les relations de rues nommées autour d'une place, ou les
rond-points découpés en morceaux (pour pouvoir ensuite taguer
correctement les lignes de transport sans ambiguïté d'interprétation
du chemin suivi, surtout quand la même ligne passe plusieurs fois par
le même rond-point mais en suivant des rues d'arrivée et de départ
différentes à chaque passage au sein du même circuit).

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

[OSM-talk-fr] Earth electrode line of HVDC SACOI near Lucciana on Corse

[Harald Lutz]

I write this message in English, as I can the matter better explain in English 
than in France:

according to 
http://web.archive.org/web/20051115115248/www.transmission.bpa.gov/cigresc14/Compendium/SACOI.htm
 , there should exist a 9 kilometres long overhead line, constructed like a 20 
kV line, but using two conductors, which connects the Corse ground electrode of 
HVDC SACOI ( location unknown) with the converter station of Lucciana ( 
coordinates: 42°31′40″N 9°26′59″E ).

However on no satellite pictures available in the internet, this line, which is 
in spite of its smallness as part of HVDC SACOI ( 
http://en.wikipedia.org/wiki/SACOI ) from great importance, is not visible. 

Why? Are all available pictures so bad? Or was the line in the proximity of 
Lucciana converter station undergrounded?

Has someone more information? It would be great, if a mapper on Corse could 
find out the location of the ground electrode of HVDC SACOI and map the 
electrode line, which connects it with the Lucciana converter station.


-- 
NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!  

Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

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

Re: [OSM-talk-fr] Earth electrode line of HVDC SACOI near Lucciana on Corse

[Philippe Verdy]

Look at the aerial photographies of the French official Geoportail:

Near Bonifacio :

http://www.geoportail.fr/visu2D.do?cg=djoxLjEqYzptZXRyb3BvbGUqY3Y6MS4wKnZ2OjEuMSp4eTo5LjIwMjc3OHw0MS4zNzExMTEqczo0KnB2OjEuMCpwOmRlY291dmVydGUqbDpQaG90b3wxfDEwMHw=

You can easily see the electric stations. But no cables getting out of
it to the coast.

So most probably the lines are underground through the coastal
mountains up to the sea. Note also that you can see the result of
underground works on the coast. I don't know if this vertical line
joining the ground to the small rocky beach is the effective location
where the cables have been placed, but I suspect the line you also see
under the coastal water level is the presence of the cable, burried
and by some protecting infrastructure.

The locations given in Wikipedia are then loking correct for me. But
may be a Corsican resident may try to look at this location if this is
really an electric station (with DC/AC converters to interconnect it
to the regional French grid).

You may also check the other location to the North of Corsica with the
aerial photos given by the French Géoportail.

2012/6/1 Harald Lutz :
> I write this message in English, as I can the matter better explain in 
> English than in France:
>
> according to 
> http://web.archive.org/web/20051115115248/www.transmission.bpa.gov/cigresc14/Compendium/SACOI.htm
>  , there should exist a 9 kilometres long overhead line, constructed like a 
> 20 kV line, but using two conductors, which connects the Corse ground 
> electrode of HVDC SACOI ( location unknown) with the converter station of 
> Lucciana ( coordinates: 42°31′40″N 9°26′59″E ).
>
> However on no satellite pictures available in the internet, this line, which 
> is in spite of its smallness as part of HVDC SACOI ( 
> http://en.wikipedia.org/wiki/SACOI ) from great importance, is not visible.
>
> Why? Are all available pictures so bad? Or was the line in the proximity of 
> Lucciana converter station undergrounded?
>
> Has someone more information? It would be great, if a mapper on Corse could 
> find out the location of the ground electrode of HVDC SACOI and map the 
> electrode line, which connects it with the Lucciana converter station.
>
>
> --
> NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone!
> Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a
>
> ___
> 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] osmose - Repères géodésique hors commune ??

[Matthias Dietrich]

Le 30 mai 2012 12:55, Frédéric Rodrigo  a écrit :

> Bonjour,
>
> Non, non, j'ai corrigé le problème. Il s'agit d'un problème sur les
> communes composées de plusieurs polygones. Ça se remarque particulièrement
> en Corse à cause des île rattachées aux communes.
>
> Frédéric.
>
> Le 30/05/2012 11:38, Christian Quest a écrit :
>
>  Ne serait-ce pas lié au ref:INSEE qui contient une lettre (2A/2B pour
>> la Corse) ?
>>
>>
>> Le 30 mai 2012 06:36, Nicolas Croiset (Campus Grenoble 90,8)
>>   a écrit :
>>
>>> Bonjour,
>>>
>>> ce jour est apparu une nouvelle erreur sur les points géodésique "Repère
>>> géodésique hors de sa commune" Celui-ci semble pourtant bien dans
>>> celle-ci,
>>> cf par exemple :
>>> http://osmose.openstreetmap.**fr/map/?zoom=16&lat=42.42518&**
>>> lon=8.77391&item=6070
>>>
>>
>
>
Je ne sais pas quel est le retour d'expérience actuel sur cette nouvelle
analyse, alors dans le doute je vais encore signaler des cas particuliers
;-)

Il arrive que des sites géodésiques rattachés à une commune aient tout ou
partie de leurs points en dehors de cette commune. Évidemment, cela va être
difficile à traiter par Osmose, mais au cas où, je préfère le signaler.

Exemples :
- http://geodesie.ign.fr/fiches/pdf/68066A.pdf : site rattaché à Colmar,
mais situé totalement sur la commune de Wintzenheim
- http://geodesie.ign.fr/fiches/pdf/6837203.pdf : site de Willer sur Thur,
les points "a" et "b" sont bien sur le territoire de la commune, le point
"c" ne l'est pas

J'ai marqué les erreurs Osmose correspondantes en faux positifs. Je n'ai
aucune idée du nombre de ces exceptions à l'échelle de ma France.

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

Re: [OSM-talk-fr] Au sud ? Plus au sud...

[Ab_fab]

Ca alors ...

Le 1 juin 2012 19:52, Philippe Verdy  a écrit :

> Ces "routes" en Antarctique n'en sont pas, protection de
> l(environnement oblige (et aussi à cause du Traité de l'Antarctique
> qui limite les constructions qui peuvent être faites).
>
> Au mieux on devrait les taguer en tant que "pistes". Elles ne sont le
> fruit d'aucun travaux, ce sont juste des passages utilisables par les
> véhicules de transport pour les expéditions, car le relief le permet.
>
> Elles n'ont pas de réelles matérialisation, sauf éventuellement un
> dégagement des congères et amas de neiges par des engins qui n'amènent
> rien d'autre sur le terrain, et se contentent de traver une voie qui
> disparaitra vite aux prochaines chutes de neige, ou parce que cela
> passe sur des couloirs de glaciers en mouvement qui se fracturent sous
> leur propre poussée en route vers l'océan.
>
> Bref ce ne sont que des passages "recommandés" permettant de prévoir
> les routes suivies (et aussi de prévoir les éventuels moyens de
> secours aériens au cas où on reste en panne dessus, pour pouvoir
> relocaliser facilement les naufragés à récupérer sur la piste).
>
> De la même façon on a des pistes d'atterrissages recommandées, qui
> peuvent être dégagées pour l'atterrissage d'avions ou d'hélicos. Pas
> de matérialisation autre que quelques drapeaux et lampes posées
> temporairement (mais qui ne passeront pas les terribles tempêtes de
> l'hiver antarctique : chaque année il faut redégager les accès
> détruits et rendus inutilisables immédiatement).
>
> Si ça figure sur les cartes c'est pour justement permettre d'informer
> les autres signataires du Traité des activités en cours en Antarctique
> (car ils ont droit de contrôler la nature des activités suivies et que
> l'utilisation n'importe pas de pollutions et préserve l'habitat des
> espèces animales protégées, aussi bien sur le continent sur sous la
> banquise et dans les eaux antarctiques).
>
> De la même façon on localise les bâtiments servant d'abris aux
> recherches scientifiques et aux observatoires, ainsi que les lieux
> d'hivernage et les equipements de survie nécessaires (dépôts de
> carburants inclus, ainsi que les lieux de collecte des ordures qu'il
> faudra dégager chaque année, l'enfouissage dans les glaces ou la
> création de décharges permanentes étant normalement interdit : la
> dépollution est obligatoire, les « eaux usées » doivent être traitées
> si elles ne sont pas naturelles, etc. mais il peut être admis de
> laisser des déchets alimentaires à la disposition de la faune locale,
> tant que cela reste « raisonnable » au plan de leur métabolisme
> naturel, par exemple des graisses alimentaires).
>
> Les incinérateurs sont aussi très restreints (ils polluent les glaces
> environnantes et peuvent à terme empoisonner la fragile faune
> locale...). Les véhicules accidentés ou devenus inutilisables ne
> peuvent non plus être abandonnés (au minimum on impose de dégager les
> moteurs dès que possible). De même que les éléments de construction
> qui se seraient trouvés abîmés ou partiellement emportés par une
> tempête, et laissant des déchets alentour pendant l'hiver : nettoyage
> demandé dès que possible.
>
> Les différents signataires du traité veillent les uns sur les autres à
> ce que ces mesures de protection soient appliquées, moyennant quoi
> chacun peut mener ses propres occupations scientifiques et disposer
> d'un droit d'occupation quasi-permanent (même si les personnels ne
> sont pas des résidents permanents) et d'un droit de propriété sur les
> installations (qui restent accessibles au contrôle par les autres, via
> une procédure prévue et ratifiée dans le Traité).
>
> ___
> 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] Au sud ? Plus au sud...

[Philippe Verdy]

Et puis ?

Le 1 juin 2012 22:16, Ab_fab  a écrit :
> Ca alors ...

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

Re: [OSM-talk-fr] Moteurs de rendu de cartes utilisant le modèle public_transport ?

[Tetsuo Shima]

Le tri est pas tres au point surtout avec les route un peu compliqué
celle qui qui emprunte plusieurs fois le meme chemin par exemple. Le
plugin de JOSM public transport a aussi un systeme de tri qui marche a
mon avis pas mieux. Personnellement je trie a la main.

Cordialement

2012/6/1 Christian Quest :
> Réponse très partielle ;)
>
> Le 1 juin 2012 12:04,   a écrit :
>> PS. Quelqu'un sait s'il est possible de réordonner les membres d'une 
>> relation ? Avec quel outil ?
>>
>
>
> L'éditeur de relation de JOSM permet de trier les membres (icone
> "A..Z" à gauche).
>
> --
> 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] Moteurs de rendu de cartes utilisant le modèle public_transport ?

[Philippe Verdy]

Personnellement j'utilise le bouton dans un premier temps (on gagne du
temps par rapport au désordre complet) ce qui n'empêche pas de
vérifier la pertinence de ce tri.

En plus j'avais mentionné le problème des lignes de transports qui
passent au même nœud (quand ce nœud est l'extrémité des ways membres
d'une relation : tri non garanti de respecter l'ordre des arrêts ni de
créer un seul circuit), et quand un même way ou tronçon doit être
parcouru dans les 2 sens sur la même direction entre deux terminus, ou
pour les lignes en circuit fermé sans terminus.

Le 1 juin 2012 23:53, Tetsuo Shima  a écrit :
> Le tri est pas tres au point surtout avec les route un peu compliqué
> celle qui qui emprunte plusieurs fois le meme chemin par exemple. Le
> plugin de JOSM public transport a aussi un systeme de tri qui marche a
> mon avis pas mieux. Personnellement je trie a la main.
>
> Cordialement

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

Re: [OSM-talk-fr] Au sud ? Plus au sud...

[teuxe]

Ce qui est dingue, c'est que ça ne ressemble jamais à de la confiture* :)

(* Ceci est un test d'intelligence, chronométrez-vous :D )

- Mail Original -
De: "Philippe Verdy" 
À: "Ab_fab" 
Cc: "Discussions sur OSM en français" 
Envoyé: Vendredi 1 Juin 2012 22h17:09 GMT +01:00 Amsterdam / Berlin / Berne / 
Rome / Stockholm / Vienne
Objet: Re: [OSM-talk-fr] Au sud ? Plus au sud...

Et puis ?

Le 1 juin 2012 22:16, Ab_fab  a écrit :
> Ca alors ...

___
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