Re: [OSM-talk-fr] Solution pour surveiller les "gros" changeset ou "potentiellement problématiques"

[Marc SIBERT]

 Le 24/01/2013 20:50, partir-en-vtt a écrit :

Ou alors que le peu de personnes débattant sur le sujet ont tous la même
conception du sujet débattu sauf un...


 Dans tous les cas, on va devoir attendre que le fil s'étoffe un peu...
L'espoir fait vivre.

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

Re: [OSM-talk-fr] Modifications en cours sur le tag Power

[Pieren]

2013/1/25 François Lacombe :

> Toute autre clé est dépréciée (notamment power=station) et sont donc
> appelées à être remplacées au fil de l'eau.
> http://wiki.openstreetmap.org/wiki/Tag:power%3Dsub_station

Je ne veux pas casser ce bel enthousiasme mais cette décision a déjà
été prise une première fois en janvier 2010 ;-)

http://lists.openstreetmap.org/pipermail/tagging/2010-January/001146.html

Mais c'est comme ça dans OSM. Retirer un ancien tag est toujours une
tâche de longue haleine. Le tag power=station est un bon exemple de
tag introduit par une communauté locale (les allemands) qui n'avaient
pas saisis l'ambiguité de cette mauvaise traduction. D'où l'utilité de
passer autant que possible par ces phases de discussions
internationales.

Pieren

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

Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway

[Christian Quest]

Le 25 janvier 2013 07:33, Art Penteur  a écrit :

>
> Sans ironie, cette fois :
> Vaut-il mieux un oneway=no généralisé, ou un "oneway=unkown" (ou
> fixme:oneway=unknow") pour les cas de "chair mapping" ?
>
>
oneway=no -> risque d'être faux
oneway=unknown -> ça devrait être une absence de tag oneway
fixme:oneway=unknown -> pourquoi pas, c'est le moins pire je pense

-- 
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] Modifications en cours sur le tag Power

[François Lacombe]

Bonjour Pieren :)

C'est une bonne indication ça, merci.
Une définition assez sérieuse est donnée dans le message suivant.
http://lists.openstreetmap.org/pipermail/tagging/2010-January/001148.html

En fait, je me demande du coup pourquoi ça n'a pas disparu du wiki à partir
de ce moment là (pour la carte on est d'accord que c'est autre chose).

On a eu un avis contraire hier soir encore, alors que l'affaire semblait
effectivement réglée depuis un certain temps.
http://lists.openstreetmap.org/pipermail/tagging/2013-January/012733.html

Le modèle ayant déjà quelques années derrière lui, je me suis pour
l'instant concentré sur l'actuel. Reprendre tout l'historique reste
fastidieux même si chaque tag à sa raison d'être (ou l'a eu à un moment
donné).


J'en profite également pour signaler l'ajout tu tag circuits=* par
polderrunner plus tôt cette semaine.
Il permet de lever l’ambiguïté entres cables=* et wires=* en donnant
directement le nombre de circuits d'une ligne à haute tension.
C'est surtout utile dans le cas de lignes enterrées, où le nombre apparent
de câble ne laisse pas voir le nombre de conducteurs et donc le nombre
éventuel de circuits. L'information est alors accessible dans les dossiers
de d'enquête publique (consultables en mairie en France) ainsi que les
tracés précis d'ailleurs.
http://wiki.openstreetmap.org/wiki/Key:circuits

Cables est là pour donner le nombre de câbles de phase alors que wires
donne le nombre de conducteur par phase.
http://wiki.openstreetmap.org/wiki/Key:cables
http://wiki.openstreetmap.org/wiki/Key:wires

Bonne journée,

Le 25 janvier 2013 09:51, Pieren  a écrit :

> 2013/1/25 François Lacombe :
>
> > Toute autre clé est dépréciée (notamment power=station) et sont donc
> > appelées à être remplacées au fil de l'eau.
> > http://wiki.openstreetmap.org/wiki/Tag:power%3Dsub_station
>
> Je ne veux pas casser ce bel enthousiasme mais cette décision a déjà
> été prise une première fois en janvier 2010 ;-)
>
> http://lists.openstreetmap.org/pipermail/tagging/2010-January/001146.html
>
> Mais c'est comme ça dans OSM. Retirer un ancien tag est toujours une
> tâche de longue haleine. Le tag power=station est un bon exemple de
> tag introduit par une communauté locale (les allemands) qui n'avaient
> pas saisis l'ambiguité de cette mauvaise traduction. D'où l'utilité de
> passer autant que possible par ces phases de discussions
> internationales.
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Référencer les "entreprises" & autres consultants sur le site openstreetmap.fr

[Sylvain Maillard]

+1

c'est toujours une bonne chose et une preuve de "sérieux" que de voir des
entreprise utiliser les données OSM de manière professionnelle !

Comme déjà dis il existe plusieurs pages qui listent déjà ce genre
d'entreprises, mais l'avantage clair d'en avoir une sur le site osm-fr,
c'est qu'elle ne listera que des gens qui travaillent avec les données osm
(donc moins de dilution par rapport à l'annuaire du georézo), et à priori
qui sont sur la zone géographique "france" (donc plus ciblé que la liste du
wiki) ...


Sylvain



Le 24 janvier 2013 15:47, partir-en-vtt  a écrit :

> Si je comprends bien c'est promouvoir les entreprises qui
> utilisent/améliorent... les données OSM ?
>
> Ça me paraît être une bonne idée étant donné que la licence permet de faire
> de business. Ce répertoire sera pratique pour les personnes ou instances
> ayants besoin de ce genre de services. Et vu que le site openstreetmap.fr
> parle de tout ce qui gravite autour du projet OSM, cela me semble d'autant
> plus opportun.
>
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Referencer-les-entreprises-autres-consultants-sur-le-site-openstreetmap-fr-tp5746101p5746224.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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique

[Pieren]

2013/1/24 Arnaud :

> Néanmoins, avez-vous déjà vu des propositions allant en ce sens (ou autres)?

Il y a une méthode encore plus simple : représenter le pont lui-même
sans toucher à la route. Il y a la méthode du simple way superposé à
la route mais c'est mal suporté par les éditeurs (et les contributeurs
qui ne les voient pas).
Il y a alors la méthode de tracer le tablier du pont avec un polygone.
C'est plus facile depuis qu'on dispose d'images aériennes en haute
résolution. Mais ça n'est pas le cas partout.

L'inconvénient de toutes ces modélisations, c'est qu'elles s'adaptent
mal aux tunnels qui, eux, nécessitent pratiquement toujours une
segmentation du highway pour identifier les changements d'attributs
comme "maxspeed" et/ou "maxheight".

Pieren

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

Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway

[Pieren]

2013/1/25 Art Penteur :

> Vaut-il mieux un oneway=no généralisé, ou un "oneway=unkown" (ou
> fixme:oneway=unknow") pour les cas de "chair mapping" ?

Si on ajoute des "oneway=unknown", je pense qu'il faut aussi un
"horse=unknown" et "snowmobile=unknown". Il n'y a pas de raison que le
doute ne soit permis que pour les sens de circulation.
Sans ironie ;-)

Pieren

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

Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway

[Christian Quest]

"Dans le doute, abstiens-toi... de mettre un tag"  Pythagore aurait pu
terminer ses phrases, non ? ;)


Le 25 janvier 2013 10:46, Pieren  a écrit :

> 2013/1/25 Art Penteur :
>
> > Vaut-il mieux un oneway=no généralisé, ou un "oneway=unkown" (ou
> > fixme:oneway=unknow") pour les cas de "chair mapping" ?
>
> Si on ajoute des "oneway=unknown", je pense qu'il faut aussi un
> "horse=unknown" et "snowmobile=unknown". Il n'y a pas de raison que le
> doute ne soit permis que pour les sens de circulation.
> Sans ironie ;-)
>


-- 
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] OpenStreetMap modélisation et segmentation dynamique

[François Lacombe]

Le 25 janvier 2013 10:37, Pieren  a écrit :

> L'inconvénient de toutes ces modélisations, c'est qu'elles s'adaptent
> mal aux tunnels qui, eux, nécessitent pratiquement toujours une
> segmentation du highway pour identifier les changements d'attributs
> comme "maxspeed" et/ou "maxheight".
>

Tout comme certains ponts nécessitent une segmentation pour un changement
de PTAC max ou un changement de largeur de la chaussée (généralement un
rétrécissement).

Je suis plutôt de l'avis de Philippe, utiliser des relations pour mettre en
correspondance plusieurs éléments me semble plus accessible que de mettre
plusieurs segments l'un sur l'autre.
Il faut qu'il y ai une liaison entre ces composants au niveau de la base de
données, sinon rien n'indiquera que la route passe effectivement sur le
pont.

-- 
*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway

[Art Penteur]

OK.

  Donc je n'aurais pas du associer le "oneway=no" au "acces=yes".

Pour oneway, on arrive au consensus:
   oneway= yes : sens unique vérifié.
   oneway= no : double sens vérifié.
   pas de "oneway" : en général, doute. Exception pour "roundabout" et
"motorway",: sens unique pas défaut sans spécifier oneway=yes.

   Doit-on, peut-on aller en discuter sur d'autres mailing-listes,
modifier la page wiki/Key:oneway pour que cela soit plus clairement
dit, et traduire cette page en Français ?

Art.


Le 25 janvier 2013 10:50, Christian Quest  a écrit :
> "Dans le doute, abstiens-toi... de mettre un tag"  Pythagore aurait pu
> terminer ses phrases, non ? ;)
>
>
> Le 25 janvier 2013 10:46, Pieren  a écrit :
>
>> 2013/1/25 Art Penteur :
>>
>> > Vaut-il mieux un oneway=no généralisé, ou un "oneway=unkown" (ou
>> > fixme:oneway=unknow") pour les cas de "chair mapping" ?
>>
>> Si on ajoute des "oneway=unknown", je pense qu'il faut aussi un
>> "horse=unknown" et "snowmobile=unknown". Il n'y a pas de raison que le
>> doute ne soit permis que pour les sens de circulation.
>> Sans ironie ;-)
>
>
>
> --
> 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] OpenStreetMap modélisation et segmentation dynamique

[Pieren]

2013/1/25 François Lacombe :

> Il faut qu'il y ai une liaison entre ces composants au niveau de la base de
> données, sinon rien n'indiquera que la route passe effectivement sur le
> pont.

Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de
données géospatiale. Tous les noeuds et ways sont déjà positionnés les
uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou
des relations que lorsqu'il y a ambiguité.
Quant à la remarque de Philippe, je suis désolé, je n'ai pas compris
(comme souvent). Ou alors, c'est lui qui n'a toujours pas compris la
distinction entre 'roles' et 'tags' dans les relations. Les roles
'from', 'to' sont déjà couramment utilisés dans les
turn_restrictions...

Pieren

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

Re: [OSM-talk-fr] Référencer les "entreprises" & autres consultants sur le site openstreetmap.fr

[Marc SIBERT]

Bon, vu les avis unanimes, je commence une page pour les Partenaires d'OSM.
Je proposerais au CA d'indiquer le soutient à l'asso dans un second temps.
Par défaut, je classe par ordre alphabétique.
Il s'agit d'une démarche volontaire de la part des partenaires intéressés,
je n'irais pas gonfler la page avec des info prises sur vos sites pro ou
sur le wiki.

Si vous êtes d'accord, merci de me transmettre,
Nom de l'entreprise (le libellé de l'activité ou autres)
L'adresse postale
tel / fax / mail (publics)
site web
un logo pas trop gros (env 100 à 200/300 px de coté)
Une profession de foi (si possible en html de base pour l'intégration)

Envoyez moi tout ça à msib...@openstreetmap.fr que j'intègre.

A+

Le 24 janvier 2013 10:52, Marc SIBERT  a écrit :

> Bonjour,
>
> Je profite de ma propre création d'activité pro (EIRL) pour lancer la
> question de la publicité des entrepreneurs français autour d'OSM.
>
> En clair : peut-on ajouter une page sur le site openstreetmap.fr avec la
> liste des professionnels qui travaillent avec/autour d'OSM avec pour chacun
> d'eux une sorte de "profession de foi".
>
> Je sais que pour certains, le mélange asso / pro, projet libre / business
> peut soulever des questions, je préféré donc lancer un mini débat sur le
> sujet.
>
> Note : je suis à même de maintenir la page.
>
> A+
>
> --
> Marc Sibert
> m...@sibert.fr
>



-- 
Marc Sibert
msib...@openstreetmap.fr (en plus ça marche, hé, hé, merci Christian)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway

[Pieren]

2013/1/25 Art Penteur :

> Pour oneway, on arrive au consensus:
>oneway= yes : sens unique vérifié.
>oneway= no : double sens vérifié.
>pas de "oneway" : en général, doute. Exception pour "roundabout" et
> "motorway",: sens unique pas défaut sans spécifier oneway=yes.

On revient à la discussion d'il y a 9 mois (avec le même initiateur ;-)
Pour motorway, il n'y a pas consensus. C'est pourquoi le wiki donne le
"oneway=yes" comme valeur implicite ET comme 'usefull combination'
(résultat d'une guerre d'édition sur le wiki et aux particularismes de
certains pays). En fait, il n'y a consensus que pour les roundabout.
L'absence de tag crée un doute mais le doute doit profiter à l'accusé.
On part du principe général que tout ce qui n'est pas interdit est
autorisé (principe qui ne s'applique pas dans quelques pays
malheureusement). Et en général, les panneaux routiers s'appliquent
surtout à nous indiquer ce qui est interdit (il y a très peu de
panneaux 'oneway=no' ou 'motor_vehicle=yes').

Pieren

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

Re: [OSM-talk-fr] [osm-fr CA] Re: Référencer les "entreprises" & autres consultants sur le site openstreetmap.fr

[Christian Quest]

Je pense qu'il faut avoir une liste très neutre et light.

Pour moi;
- nom, coordonnées (avec lien site web/mail)
- éventuellement le type de presta proposée et encore

Ni logo, ni profession de foi ou autre, ça c'est à mettre sur le site de
l'entreprise.
Ca serait tomber plus ou moins dans de la publicité alors que je pense
qu'il faut rester au niveau de l'information: il y a des entreprises, les
voici, contactez-les pour plus de renseignements.


Le 25 janvier 2013 11:38, Marc SIBERT  a écrit :

> Bon, vu les avis unanimes, je commence une page pour les Partenaires
> d'OSM. Je proposerais au CA d'indiquer le soutient à l'asso dans un second
> temps. Par défaut, je classe par ordre alphabétique.
> Il s'agit d'une démarche volontaire de la part des partenaires intéressés,
> je n'irais pas gonfler la page avec des info prises sur vos sites pro ou
> sur le wiki.
>
> Si vous êtes d'accord, merci de me transmettre,
> Nom de l'entreprise (le libellé de l'activité ou autres)
> L'adresse postale
> tel / fax / mail (publics)
> site web
> un logo pas trop gros (env 100 à 200/300 px de coté)
> Une profession de foi (si possible en html de base pour l'intégration)
>
> Envoyez moi tout ça à msib...@openstreetmap.fr que j'intègre.
>
> A+
>
> Le 24 janvier 2013 10:52, Marc SIBERT  a écrit :
>
> Bonjour,
>>
>> Je profite de ma propre création d'activité pro (EIRL) pour lancer la
>> question de la publicité des entrepreneurs français autour d'OSM.
>>
>> En clair : peut-on ajouter une page sur le site openstreetmap.fr avec la
>> liste des professionnels qui travaillent avec/autour d'OSM avec pour chacun
>> d'eux une sorte de "profession de foi".
>>
>> Je sais que pour certains, le mélange asso / pro, projet libre / business
>> peut soulever des questions, je préféré donc lancer un mini débat sur le
>> sujet.
>>
>> Note : je suis à même de maintenir la page.
>>
>> A+
>>
>> --
>> Marc Sibert
>> m...@sibert.fr
>>
>
>
>
> --
> Marc Sibert
> msib...@openstreetmap.fr (en plus ça marche, hé, hé, merci Christian)
>



-- 
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] OpenStreetMap modélisation et segmentation dynamique

[Francescu GAROBY]

Le 25 janvier 2013 05:31, Philippe Verdy  a écrit :

> Le 24 janvier 2013 21:20, Arnaud  a écrit :
> > Peut-être qu'il pourrait être intéressant d'utiliser le potentiel des
> > relations?
> > Je m'explique, en gardant le modèle précédent :
> >
> > N1 - N2 - N3  N4
> > Relation > tunnel : yes
> > from : N2
> > to : N3
> >
> > Les avantages sont une cohérence des attributs génériques à la route
> (nom,
> > type, etc.), un objet géographique unique (plus grande rapidité de
> > traitement?), une maintenance attributaire et géographique facilitée.
> > Les inconvénients sont, je pense, un modèle peu compréhensible pour les
> > débutants ainsi que logiquement une augmentation des relations.
>
> L'ennui c'est comment représenter et *stabiliser* les deux "tags"
> "from=N2" et "to=N3" : comment désigner les noeuds si ce ne peut pas
> être un rang dans le chemin ? Il faudrait alors nommer les noeuds ou
> utiliser leurs IDs. Et il n'y aura aucune vérification de cela.
> La segmentation n'est pas réellement un problème : on a des relations
> pour rassembler les fragments de chemin ensembles et de façon stable.
>
> Je n'ai peut-être pas bien compris tes remarques, mais tu penses qu'il
faudrait utiliser l'ID des nodes pour les désigner aux tags from et to ?
C'est pas déjà ce qu'on fait dans je-ne-sais-combien de types de relations
? Comme 
stop_area,
où des nodes sont utilisés pour indiquer le stop_position (pour ne citer
qu'un exemple).

Après, tu parles de stabilisation. Si tu veux dire par là qu'un tel système
est à la merci d'une suppression du node qui servait de 'from' ou de 'to',
je suis d'accord avec toi, mais le même problème se pose avec des relations
composées de bouts de ways : il suffit quelqu'un fusionne 2 ways contiguës
pour que la relation soit cassée (cas fréquent pour les "frontières").

Francescu



> ___
> 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] Présentation de 2u, un rendu alternatif déstiné aux contributeurs

[sly (sylvain letuffe)]

Le vendredi 25 janvier 2013 08:51:56, Fabien a écrit :
> Bonjour,

Salut,
 
> Je ne sais pas si c'est le bon endroit pour demander mais j'aurais
> bien vu les tags tourism=artwork affichés sur cette carte.

Si on fait ça sur cette liste, ça pourrait devenir ingérable et surtout, je 
vais les oublier ;-)

Le mieux c'est donc d'aller ici pour le faire :
https://github.com/osm-fr/2u/issues
(la création d'un compte est rapide)

Puis d'être assez précis+aider pour que ça ait des chances d'être fait :
- lien vers le wiki qui décrit le truc
- proposition d'une icone s'il y a lieu
(même type de format/taille que trouvé ici : https://github.com/osm-
fr/2u/tree/master/symbols )
- lien vers la carte où se trouve un élément pour que le développeur puisse 
tester le résultat avant de le valider

En clair, plus on simplifie le travail du développeur, et plus on a de chance 
qu'il le fasse, car le développeur est un feignant !


-- 
sly (sylvain letuffe)

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

Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique

[François Lacombe]

Le 25 janvier 2013 11:22, Pieren  a écrit :

> 2013/1/25 François Lacombe :
> Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de
> données géospatiale. Tous les noeuds et ways sont déjà positionnés les
> uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou
> des relations que lorsqu'il y a ambiguité.
>
Il ne faut pas s'étrangler, ca n'en vaut pas la peine.

Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance
entre une route et un pont sur lequel elle passe dans la réalité sans
relation entre les objets.
Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la
route est bien positionnée par rapport au pont, ce dernier peut se trouver
100m en dessous (il y a le tag ele=* mais ca ne compte pas).

-- 
*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique

[Francescu GAROBY]

Et actuellement, un tel comportement est considéré comme une erreur : soit
pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de
node à l'intersection (d'où le tag 'layer').

Francescu

Le 25 janvier 2013 11:55, François Lacombe <
francois.laco...@telecom-bretagne.eu> a écrit :

>
>
> Le 25 janvier 2013 11:22, Pieren  a écrit :
>
>> 2013/1/25 François Lacombe :
>>
>> Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de
>> données géospatiale. Tous les noeuds et ways sont déjà positionnés les
>> uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou
>> des relations que lorsqu'il y a ambiguité.
>>
> Il ne faut pas s'étrangler, ca n'en vaut pas la peine.
>
> Néanmoins, je vois mal comment peut-être exprimée une quelconque
> dépendance entre une route et un pont sur lequel elle passe dans la réalité
> sans relation entre les objets.
> Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la
> route est bien positionnée par rapport au pont, ce dernier peut se trouver
> 100m en dessous (il y a le tag ele=* mais ca ne compte pas).
>
> --
> *François Lacombe*
>
> francois dot lacombe At telecom-bretagne dot eu
> http://www.infos-reseaux.com
>
> ___
> 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] Proposition(s) pour un petit coup de balais dans les tags access/oneway

[Christian Quest]

Comme le rappelle Pieren, le seul oneway implicite est sur les round_about

D'ailleurs, dans JOSM, celui-ci est bien signalé par les flèches du sens de
circulation, alors que sur une motorway sans tag oneway il n'y a pas les
flèches du sens de circulation vu que ce n'est pas implicite.

En France, on a des oneway=yes sur tout les tracés d'autoroute (sauf
erreur), ça permet d'ailleurs de faire des calculs de cumul en tenant
compte des doubles tracés.


Suite de discussion dans tagging@ ou sur la page de discussion du wiki
(anglaise) ?

Je vois aussi sur le wiki les valeurs 0/1... ça vaudrait le coup
d'harmoniser avec les no/yes, non ?


Le 25 janvier 2013 11:14, Art Penteur  a écrit :

> OK.
>
>   Donc je n'aurais pas du associer le "oneway=no" au "acces=yes".
>
> Pour oneway, on arrive au consensus:
>oneway= yes : sens unique vérifié.
>oneway= no : double sens vérifié.
>pas de "oneway" : en général, doute. Exception pour "roundabout" et
> "motorway",: sens unique pas défaut sans spécifier oneway=yes.
>
>Doit-on, peut-on aller en discuter sur d'autres mailing-listes,
> modifier la page wiki/Key:oneway pour que cela soit plus clairement
> dit, et traduire cette page en Français ?
>
> Art.
>


-- 
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] Proposition(s) pour un petit coup de balais dans les tags access/oneway

[JB]

 

Je suis le seul à râler contre le sur-taggage ? 

Innocemment, il
n'y a pas très longtemps, j'ai supprimé sans penser mal faire des
oneway=no sur des tronçons où ça me semblait évident, et en pensant
qu'ils avaient été ajoutés par l'utilisation des cases à cocher JOSM
(celles que je n'utilise jamais…). 

Oneway=no, je le réserve à quelques
cas particuliers (la seule voie de parking à double sens de tout un
parking, certaines pistes cyclables présentes des deux cotés de la
route, dont une bidirectionnelle…). Ailleurs, ça me semble être du
bruit, et fait ressortir comme louche le cas des voies sans oneway*.
EST-CE QU'ON VISE RÉELLEMENT À TERME D'AVOIR UN TAG ONEWAY* POUR TOUTES
LES HIGHWAY ?? 

Après, les fixme:oneway (apparemment pas les
oneway=unknown, mais je l'ai peut-être commis…), je plussoie, c'est top…


JB. 

Le 25.01.2013 11:14, Art Penteur a écrit : 

> OK.
> 
> Donc je
n'aurais pas du associer le "oneway=no" au "acces=yes".
> 
> Pour
oneway, on arrive au consensus:
> oneway= yes : sens unique vérifié.
>
oneway= no : double sens vérifié.
> pas de "oneway" : en général, doute.
Exception pour "roundabout" et
> "motorway",: sens unique pas défaut
sans spécifier oneway=yes.
> 
> Doit-on, peut-on aller en discuter sur
d'autres mailing-listes,
> modifier la page wiki/Key:oneway pour que
cela soit plus clairement
> dit, et traduire cette page en Français ?
>

> Art.
> 
> Le 25 janvier 2013 10:50, Christian Quest
 a écrit :
> 
>> "Dans le doute,
abstiens-toi... de mettre un tag" Pythagore aurait pu terminer ses
phrases, non ? ;) Le 25 janvier 2013 10:46, Pieren  a
écrit : 
>> 
>>> 2013/1/25 Art Penteur : 
>>>

 Vaut-il mieux un oneway=no généralisé, ou un "oneway=unkown" (ou
fixme:oneway=unknow") pour les cas de "chair mapping" ?
>>> Si on ajoute
des "oneway=unknown", je pense qu'il faut aussi un "horse=unknown" et
"snowmobile=unknown". Il n'y a pas de raison que le doute ne soit permis
que pour les sens de circulation. Sans ironie ;-)
>> -- Christian Quest
- OpenStreetMap France - http://openstreetmap.fr/u/cquest [1]
___ Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr [2]
> 
>
___
> Talk-fr mailing list
>
Talk-fr@openstreetmap.org
>
http://lists.openstreetmap.org/listinfo/talk-fr [2]




Links:
--
[1] http://openstreetmap.fr/u/cquest
[2]
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] Présentation de 2u, un rendu alternatif déstiné aux contributeurs

[Fabien]

Le 25 janvier 2013 11:52, sly (sylvain letuffe)  a écrit :
> Le vendredi 25 janvier 2013 08:51:56, Fabien a écrit :
>> Bonjour,
>
> Salut,
>
>> Je ne sais pas si c'est le bon endroit pour demander mais j'aurais
>> bien vu les tags tourism=artwork affichés sur cette carte.
>
> Si on fait ça sur cette liste, ça pourrait devenir ingérable et surtout, je
> vais les oublier ;-)
>
> Le mieux c'est donc d'aller ici pour le faire :
> https://github.com/osm-fr/2u/issues
> (la création d'un compte est rapide)
>
> Puis d'être assez précis+aider pour que ça ait des chances d'être fait :
> - lien vers le wiki qui décrit le truc
> - proposition d'une icone s'il y a lieu
> (même type de format/taille que trouvé ici : https://github.com/osm-
> fr/2u/tree/master/symbols )
> - lien vers la carte où se trouve un élément pour que le développeur puisse
> tester le résultat avant de le valider
>
> En clair, plus on simplifie le travail du développeur, et plus on a de chance
> qu'il le fasse, car le développeur est un feignant !
>
>
> --
> sly (sylvain letuffe)
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr

J'avais pas percuté que c'était sur un github, j'avais juste le lien
layers qui ressortait en lisant...
Soumis : https://github.com/osm-fr/2u/issues/2

Fabien

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

Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway

[Francescu GAROBY]

Le 25 janvier 2013 12:57, JB  a écrit :

> **
>
> Je suis le seul à râler contre le sur-taggage ?
>

Non, je te rejoins sur ce point.

> Innocemment, il n'y a pas très longtemps, j'ai supprimé sans penser mal
> faire des oneway=no sur des tronçons où ça me semblait évident, et en
> pensant qu'ils avaient été ajoutés par l'utilisation des cases à cocher
> JOSM
>
(celles que je n'utilise jamais…).
>
Je fais pareil, quand je tombe dessus : je supprime le oneway=no, parce
qu'il me parait redondant avec la valeur implicite. Et pourquoi pas des
'lane=1' partout ? On peut aller loin, comme ça...
Autre argument : quelle quantité de données supplémentaire cela
représenterait-il de mettre des 'oneway=no' partout (ou des lane=1, ou...)
? Pour un gain absolument nul, au final.
Sachant qu'il y en a déjà 851.000,  pour 60.000.000 de highway...

Francescu

> Oneway=no, je le réserve à quelques cas particuliers (la seule voie de
> parking à double sens de tout un parking, certaines pistes cyclables
> présentes des deux cotés de la route, dont une bidirectionnelle…).
> Ailleurs, ça me semble être du bruit, et fait ressortir comme louche le cas
> des voies sans oneway*. *Est-ce qu'on vise réellement à terme d'avoir un
> tag oneway* pour toutes les highway ??*
>
> Après, les fixme:oneway (apparemment pas les oneway=unknown, mais je l'ai
> peut-être commis…), je plussoie, c'est top…
>
> JB.
>
>
>
> Le 25.01.2013 11:14, Art Penteur a écrit :
>
> OK.
>
>   Donc je n'aurais pas du associer le "oneway=no" au "acces=yes".
>
> Pour oneway, on arrive au consensus:
>oneway= yes : sens unique vérifié.
>oneway= no : double sens vérifié.
>pas de "oneway" : en général, doute. Exception pour "roundabout" et
> "motorway",: sens unique pas défaut sans spécifier oneway=yes.
>
>Doit-on, peut-on aller en discuter sur d'autres mailing-listes,
> modifier la page wiki/Key:oneway pour que cela soit plus clairement
> dit, et traduire cette page en Français ?
>
> Art.
>
>
> Le 25 janvier 2013 10:50, Christian Quest  a écrit :
>
> "Dans le doute, abstiens-toi... de mettre un tag" Pythagore aurait pu
> terminer ses phrases, non ? ;) Le 25 janvier 2013 10:46, Pieren <
> pier...@gmail.com> a écrit :
>
> 2013/1/25 Art Penteur :
>
> Vaut-il mieux un oneway=no généralisé, ou un "oneway=unkown" (ou
> fixme:oneway=unknow") pour les cas de "chair mapping" ?
>
> Si on ajoute des "oneway=unknown", je pense qu'il faut aussi un
> "horse=unknown" et "snowmobile=unknown". Il n'y a pas de raison que le
> doute ne soit permis que pour les sens de circulation. Sans ironie ;-)
>
> -- 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 
> listTalk-fr@openstreetmap.orghttp://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] Proposition(s) pour un petit coup de balais dans les tags access/oneway

[Fabien]

Le 25 janvier 2013 13:12, Francescu GAROBY  a écrit :
>
>
> Le 25 janvier 2013 12:57, JB  a écrit :
>
>> Je suis le seul à râler contre le sur-taggage ?
>
>
> Non, je te rejoins sur ce point.
>>
>> Innocemment, il n'y a pas très longtemps, j'ai supprimé sans penser mal
>> faire des oneway=no sur des tronçons où ça me semblait évident, et en
>> pensant qu'ils avaient été ajoutés par l'utilisation des cases à cocher JOSM
>>
>> (celles que je n'utilise jamais…).
>
> Je fais pareil, quand je tombe dessus : je supprime le oneway=no, parce
> qu'il me parait redondant avec la valeur implicite. Et pourquoi pas des
> 'lane=1' partout ? On peut aller loin, comme ça...
> Autre argument : quelle quantité de données supplémentaire cela
> représenterait-il de mettre des 'oneway=no' partout (ou des lane=1, ou...) ?

Perso, j'ai déjà mis des lane=1 à des endroits pour spécifier que
c'est une seule voie contrairement à ce que montre Bing. Par exemple
là : http://www.openstreetmap.org/?mlat=43.303285&mlon=5.39749&zoom=18&layers=Q
Après il est vrai que dès que Bing aura fait sa mise à jour après
travaux de la rue on verra bien le une seule voie mais en attendant...

> Pour un gain absolument nul, au final.
> Sachant qu'il y en a déjà 851.000,  pour 60.000.000 de highway...
>
> Francescu
>>
>> Oneway=no, je le réserve à quelques cas particuliers (la seule voie de
>> parking à double sens de tout un parking, certaines pistes cyclables
>> présentes des deux cotés de la route, dont une bidirectionnelle…). Ailleurs,
>> ça me semble être du bruit, et fait ressortir comme louche le cas des voies
>> sans oneway*. Est-ce qu'on vise réellement à terme d'avoir un tag oneway*
>> pour toutes les highway ??
>>
>> Après, les fixme:oneway (apparemment pas les oneway=unknown, mais je l'ai
>> peut-être commis…), je plussoie, c'est top…
>>
>> JB.
>>
>>
>>
>> Le 25.01.2013 11:14, Art Penteur a écrit :
>>
>> OK.
>>
>>   Donc je n'aurais pas du associer le "oneway=no" au "acces=yes".
>>
>> Pour oneway, on arrive au consensus:
>>oneway= yes : sens unique vérifié.
>>oneway= no : double sens vérifié.
>>pas de "oneway" : en général, doute. Exception pour "roundabout" et
>> "motorway",: sens unique pas défaut sans spécifier oneway=yes.
>>
>>Doit-on, peut-on aller en discuter sur d'autres mailing-listes,
>> modifier la page wiki/Key:oneway pour que cela soit plus clairement
>> dit, et traduire cette page en Français ?
>>
>> Art.
>>
>>
>> Le 25 janvier 2013 10:50, Christian Quest  a
>> écrit :
>>
>> "Dans le doute, abstiens-toi... de mettre un tag" Pythagore aurait pu
>> terminer ses phrases, non ? ;) Le 25 janvier 2013 10:46, Pieren
>>  a écrit :
>>
>> 2013/1/25 Art Penteur :
>>
>> Vaut-il mieux un oneway=no généralisé, ou un "oneway=unkown" (ou
>> fixme:oneway=unknow") pour les cas de "chair mapping" ?
>>
>> Si on ajoute des "oneway=unknown", je pense qu'il faut aussi un
>> "horse=unknown" et "snowmobile=unknown". Il n'y a pas de raison que le doute
>> ne soit permis que pour les sens de circulation. Sans ironie ;-)
>>
>> -- 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
>>
>>
>>
>> ___
>> 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] Proposition(s) pour un petit coup de balais dans les tags access/oneway

[sly (sylvain letuffe)]

Le vendredi 25 janvier 2013 12:57:15, JB a écrit :
> Je suis le seul à râler contre le sur-taggage ?

non non, moi aussi. Bien que je sois moins catégorique sur certains cas.
Exemple : Au centre ville par chez moi, dont 80% des voies sont en sens 
unique, je place un oneway=no sur les 20% restants, ça me permet de 
différencier le : 
- je n'ai pas encore vérifié
de
- oui, c'est bien double sens

> Après, les fixme:oneway, je plussoie, c'est top…

? Allons bon ? contre le sur tagging de oneway, mais no problem pour rajouter 
un "fixme:oneway=à vérifier" ?

ça me semble contradictoire non ? ou alors je n'ai pas bien compris à quel 
usage cela était destiné



-- 
sly (sylvain letuffe)

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

Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique

[Arnaud]

Bonjour à tous,

Je vais essayer de compléter mon argumentation.

Afin d'éviter de partir sur des problèmes de représentation liés a des 
éléments matériels (pont, tunnel, etc.), prenons l'exemple des 
limitation de vitesse.
Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage 
et la création d'un tronçon.


L'idée de départ, étant d'utiliser un concept existant, celui de la 
segmentation dynamique, mais adapté à OSM.
Je précise que ce concept de segmentation dynamique, ne sort pas de ma 
caboche mais existe déjà dans les bases de donnes routières [ex 1].
La segmentation dynamique permet d'avoir un réseau routier non segmenté 
auquel est associé une (ou plusieurs) table complémentaire d'événements 
(limitation de vitesse, pont, etc.).
En fonction de la demande (limitation de vitesse, pont, etc.) le réseau 
est segmenté dynamiquement (d'où le nom du concept).
Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement 
pensé aux potentialités des relations.
En effet, dans un SIG classique les tables étant séparées, la seule 
relation entre la route et les événements sont leur positions géographiques.
Or, les relations nous permettent de conserver à la fois une cohérence 
géographique et sémantique.
Bon voila pour la théorie, maintenant j'ai bien conscience de la 
difficulté de compréhension d'un tel modèle pour un nouveau contributeur.
Mais il a aussi un gain certain en terme de gestion des données, 
performance et stockage !



Arnaud

1 - 
https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm



On 13-01-25 07:29 AM, Francescu GAROBY wrote:
Et actuellement, un tel comportement est considéré comme une erreur : 
soit pour cause de doublon soit, lorsque 2 ways se croisent, pour 
absence de node à l'intersection (d'où le tag 'layer').


Francescu

Le 25 janvier 2013 11:55, François Lacombe 
> a écrit :




Le 25 janvier 2013 11:22, Pieren mailto:pier...@gmail.com>> a écrit :

2013/1/25 François Lacombe
mailto:francois.laco...@telecom-bretagne.eu>>:

Urg, je m'étrangle à chaque fois que je lis ça. OSM est une
base de
données géospatiale. Tous les noeuds et ways sont déjà
positionnés les
uns par rapport aux autres. On ne doit (devrait) ajouter des
tags ou
des relations que lorsqu'il y a ambiguité.

Il ne faut pas s'étrangler, ca n'en vaut pas la peine.

Néanmoins, je vois mal comment peut-être exprimée une quelconque
dépendance entre une route et un pont sur lequel elle passe dans
la réalité sans relation entre les objets.
Je crois que l'API d'OSM ne gère pas les altitudes et que donc
même si la route est bien positionnée par rapport au pont, ce
dernier peut se trouver 100m en dessous (il y a le tag ele=* mais
ca ne compte pas).

-- 
*François Lacombe*


francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com

___
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] Proposition(s) pour un petit coup de balais dans les tags access/oneway

[Pieren]

2013/1/25 sly (sylvain letuffe) :

> non non, moi aussi.

haha. Je me souviens d'un petit nouveau qui voulait mettre des oneway
partout :-)) Comme quoi, il n'y a que les imbéciles qui ne changent
pas d'avis.

Au fait, comment fonctionne le calque "Pas de oneway" sur layers.osm.fr ?

http://layers.openstreetmap.fr/?zoom=15&lat=48.86862&lon=2.38446&layers=BFTFF

C'est l'absence totale de oneway ou juste "oneway=yes" ?

Pieren

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

Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique

[Christian Quest]

C'est une modélisation très intéressante, mais malheureusement sûrement
complexe à appréhender par une majorité de contributeurs.

Elle me semble intéressante car elle permet d'avoir une sorte de mise en
hiérarchie des détails, alors qu'aujourd'hui on a tendance à multiplier les
objets pour permettre d'indiquer de plus en plus de détails et du coup il y
a un gros manque de hiérarchie dans les données OSM ce qui oblige à
repartir dans l'autre sens: regrouper des objets pour avoir une vue plus
globale.

Je pense que quel que soit le modèle adopté, ce sont aux outils d'édition
de masquer le modèle de donné utilisé ce qui n'est pas le cas aujourd'hui.

Le modèle se complique petit à petit dans pas mal de domaines (le premier
qui me vient à l'esprit est le "public_transport"), et les outils
d'éditions ne sont pas vraiment là. Du coup, on casse facilement des
relations surtout quand elles sont complexes.

Serait-il possible d'avoir des extensions à JOSM qui s'occuperaient de
maintenir la cohérence de tel ou tel modèle ?

Imaginez une extension "frontière" qui feraient automatiquement les
vérifications et effectuerai les éventuelles remises en cohérence dès qu'on
touche à une limite administrative...
Imaginez une extension "landuse" qui dès qu'on coupe en deux un polygone
créerait un multipolygone et y reporterai les tags...
Imaginez une extension "coastline" qui empêcherai de casser par mégarde la
pointe bretonne ;)

C'est au moment même d'une édition qu'il faut faire les vérifications et
signaler les problèmes éventuels créés, peut être qu'une petite
modification du fonctionnement du validator pour qu'il agisse plus en
"live" pourrait être un premier pas.

Ca vaut peut être un autre sujet de discussion...


Le 25 janvier 2013 13:39, Arnaud  a écrit :

>  Bonjour à tous,
>
> Je vais essayer de compléter mon argumentation.
>
> Afin d’éviter de partir sur des problèmes de représentation liés a des
> éléments matériels (pont, tunnel, etc.), prenons l'exemple des limitation
> de vitesse.
> Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage
> et la création d'un tronçon.
>
> L’idée de départ, étant d'utiliser un concept existant, celui de la
> segmentation dynamique, mais adapté à OSM.
> Je précise que ce concept de segmentation dynamique, ne sort pas de ma
> caboche mais existe déjà dans les bases de donnes routières [ex 1].
> La segmentation dynamique permet d'avoir un réseau routier non segmenté
> auquel est associé une (ou plusieurs) table complémentaire d’événements
> (limitation de vitesse, pont, etc.).
> En fonction de la demande (limitation de vitesse, pont, etc.) le réseau
> est segmenté dynamiquement (d’où le nom du concept).
> Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement
> pensé aux potentialités des relations.
> En effet, dans un SIG classique les tables étant séparées, la seule
> relation entre la route et les événements sont leur positions géographiques.
> Or, les relations nous permettent de conserver à la fois une cohérence
> géographique et sémantique.
> Bon voila pour la théorie, maintenant j'ai bien conscience de la
> difficulté de compréhension d'un tel modèle pour un nouveau contributeur.
> Mais il a aussi un gain certain en terme de gestion des données,
> performance et stockage !
>
>
> Arnaud
>
> 1 -
> https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm
>
>
>
> On 13-01-25 07:29 AM, Francescu GAROBY wrote:
>
> Et actuellement, un tel comportement est considéré comme une erreur : soit
> pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de
> node à l'intersection (d'où le tag 'layer').
>
> Francescu
>
> Le 25 janvier 2013 11:55, François Lacombe <
> francois.laco...@telecom-bretagne.eu> a écrit :
>
>>
>>
>> Le 25 janvier 2013 11:22, Pieren  a écrit :
>>
>>> 2013/1/25 François Lacombe :
>>>
>>> Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de
>>> données géospatiale. Tous les noeuds et ways sont déjà positionnés les
>>> uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou
>>> des relations que lorsqu'il y a ambiguité.
>>>
>> Il ne faut pas s'étrangler, ca n'en vaut pas la peine.
>>
>> Néanmoins, je vois mal comment peut-être exprimée une quelconque
>> dépendance entre une route et un pont sur lequel elle passe dans la réalité
>> sans relation entre les objets.
>> Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la
>> route est bien positionnée par rapport au pont, ce dernier peut se trouver
>> 100m en dessous (il y a le tag ele=* mais ca ne compte pas).
>>
>>   --
>> *François Lacombe*
>>
>> francois dot lacombe At telecom-bretagne dot eu
>> http://www.infos-reseaux.com
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Cordialement,
> Francescu GAROBY
>
>
> ___
> Talk-fr

Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique

[Arnaud]

Oui tout à fait, on pourrait ainsi mieux gérer certains éventements 
ponctuels (ex, travaux en cours, immobilisation temporaire de la rue, etc.).
Le désavantage de cette solution étant une modélisation très fortement 
basée sur les relations.


Or celles-ci sont encore assez mal représentées dans les éditeurs. Mais 
rien n'empêche de les faire évoluer.
Ex, dans JOSM, un point de couleur (ex, vert, rouge) pour identifier les 
noeuds d'un from -> to.
Ou même une représentation spécifique quand une partie, ou un objet 
complet est associe a une relation.

Mais bon, la je m'écarte du sujet...

Après, je n'ai pas une vision aussi complete que certains d'entre vous 
sur les concepts d'OSM.
Il se peut donc que le modèle proposé, soit partiel ou contraire à 
certains préceptes d'OSM.


Arnaud



On 13-01-25 09:36 AM, Francescu GAROBY wrote:



Le 25 janvier 2013 13:39, Arnaud > a écrit :


Bonjour à tous,

Je vais essayer de compléter mon argumentation.

Afin d'éviter de partir sur des problèmes de représentation liés a
des éléments matériels (pont, tunnel, etc.), prenons l'exemple des
limitation de vitesse.
Chaque changement (ex, passage de 50 à 70) occasionne alors un
découpage et la création d'un tronçon.

L'idée de départ, étant d'utiliser un concept existant, celui de
la segmentation dynamique, mais adapté à OSM.
Je précise que ce concept de segmentation dynamique, ne sort pas
de ma caboche mais existe déjà dans les bases de donnes routières
[ex 1].
La segmentation dynamique permet d'avoir un réseau routier non
segmenté auquel est associé une (ou plusieurs) table
complémentaire d'événements (limitation de vitesse, pont, etc.).
En fonction de la demande (limitation de vitesse, pont, etc.) le
réseau est segmenté dynamiquement (d'où le nom du concept).

Si je comprends bien, on pourrait même imaginer activer des évènements 
du point N1 au point N2 , sans avoir du coup besoin de redécouper le 
tronçon à ces 2 points ? Juste en ajoutant une ligne dans la table 
complémentaire d'évènements ? Et inversement lors de la désactivation 
de l'évènement ?
Ceci limiterait en effet grandement le "hachage" que subissent 
certaines ways (entre le nombre de voies qui changent, les bouts 
empruntés par un itinéraire de bus, les bouts qui servent de 
frontières, ...).


Ce qui permettrait de prendre en compte des évènements ponctuels, 
courts et à très brève échéance (voire déjà en cours), tels qu'un 
accident sur une autoroute, qui immobilise une voie.


Francescu

Quand j'ai commencé à me renseigner sur ce domaine, j'ai
immédiatement pensé aux potentialités des relations.
En effet, dans un SIG classique les tables étant séparées, la
seule relation entre la route et les événements sont leur
positions géographiques.
Or, les relations nous permettent de conserver à la fois une
cohérence géographique et sémantique.
Bon voila pour la théorie, maintenant j'ai bien conscience de la
difficulté de compréhension d'un tel modèle pour un nouveau
contributeur.
Mais il a aussi un gain certain en terme de gestion des données,
performance et stockage !


Arnaud

1 -

https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm




On 13-01-25 07:29 AM, Francescu GAROBY wrote:

Et actuellement, un tel comportement est considéré comme une
erreur : soit pour cause de doublon soit, lorsque 2 ways se
croisent, pour absence de node à l'intersection (d'où le tag
'layer').

Francescu

Le 25 janvier 2013 11:55, François Lacombe
mailto:francois.laco...@telecom-bretagne.eu>> a écrit :



Le 25 janvier 2013 11:22, Pieren mailto:pier...@gmail.com>> a écrit :

2013/1/25 François Lacombe
mailto:francois.laco...@telecom-bretagne.eu>>:

Urg, je m'étrangle à chaque fois que je lis ça. OSM est
une base de
données géospatiale. Tous les noeuds et ways sont déjà
positionnés les
uns par rapport aux autres. On ne doit (devrait) ajouter
des tags ou
des relations que lorsqu'il y a ambiguité.

Il ne faut pas s'étrangler, ca n'en vaut pas la peine.

Néanmoins, je vois mal comment peut-être exprimée une
quelconque dépendance entre une route et un pont sur lequel
elle passe dans la réalité sans relation entre les objets.
Je crois que l'API d'OSM ne gère pas les altitudes et que
donc même si la route est bien positionnée par rapport au
pont, ce dernier peut se trouver 100m en dessous (il y a le
tag ele=* mais ca ne compte pas).

-- 
*François Lacombe*


francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com

___
Talk-fr mailing list
Talk-fr@openstreetmap.org 

Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique

[Romain MEHUT]

Le 25 janvier 2013 14:06, Francescu GAROBY  a écrit :

>
>   les bouts qui servent de frontières, ...).
>

Non, pas coller ;)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition(s) pour un petit coup de balais dans les tags access/oneway

[sly (sylvain letuffe)]

Le vendredi 25 janvier 2013 13:41:23, Pieren a écrit :
> 2013/1/25 sly (sylvain letuffe) :
> > non non, moi aussi.
> 
> haha. Je me souviens d'un petit nouveau qui voulait mettre des oneway
> partout :-))

Arf, y'avais que toi d'assez *vieux* (dans osm) pour me prendre en flagrant 
délit de changement d'avis.
En effet, j'ai revu mon idée de petit jeune de l'époque ;-)

Si certains veulent faire un retour de 4 ans dans le passé :
https://wiki.openstreetmap.org/wiki/Trying_to_find_a_solution_for_country_specific_and_defaults_values

On notera donc que le débat en cours est loin d'être nouveau, que de 
nombreuses tentatives ont existées, et que dès fin 2008 j'avais déjà changé 
d'avis ;-p

> Au fait, comment fonctionne le calque "Pas de oneway" sur layers.osm.fr ?
> 
> http://layers.openstreetmap.fr/?zoom=15&lat=48.86862&lon=2.38446&layers=B00
> 00FTFF
> 
> C'est l'absence totale de oneway ou juste "oneway=yes" ?

l'absence de oneway.
Si on a oneway=no ou oneway=yes alors le chemin ne s'affiche pas.

Ce qui sous-entends que je reste le cul entre deux chaises et que, dès la 
présentation de ce calque, j'avais insisté sur son utilité en ville, et pas 
sur une départementale de campagne


-- 
sly (sylvain letuffe)

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

[OSM-talk-fr] Carte OuVerte dans 60 millions de consommateurs

[Romain MEHUT]

Bonjour,

Le numéro de janvier 2013 du magazine 60 millions de consommateurs consacre
un article à la Carte OuVerte de Rennes réalisée grâce au logiciel Chimère.

D'ailleurs, on n'a pas beaucoup de news autour du projet Chimère? C'est
pourtant un excellent exemple de mise en valeur d'OSM...

L'article est en partage
ici
.

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

Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique

[HELFER Denis]

Je commence à m'intéresser sérieusement à la segmentation dynamique dans le 
domaine de l'infra ferroviaire où l'on raisonne essentiellement en termes de PK 
(pour les événements ponctuels ex. Passage à niveau, appareil de voie)ou PK 
début/Pk fin pour les événements linéaires (ouvrages d'art, chantiers, 
électrification, ...). Je confirme mon intérêt pour cette démarche !
Idéalement, on devrait avoir une consistance topologique au niveau du tracé, la 
consistance sémantique serait assurée par des relations.
Exemple pour un pont-rail
Relation X
Required Type=ouvrage_art
Required Description=pont-rail
Optional source=RFF
Optional material=metal
Optional length=xxx
Optional height=xxx
Optional name=blabla
Required Members : a rôle « from »
Required Members : b rôle « to »
Required Members : c rôle « on »
Optional members : d rôle « under »
a=id du point  début du pont  (son PK debut)
b=id du point fin du pont (son PK fin)
c=id du tronçon de voie supportant la relation
d=id du tronçon de la voie traversée (rivière, chemin, route, ...)
C'est clair qu'il y a du boulot pour des applications pour transformer ces 
relations en objets découpés suivant les pointillés.

Denis

De : Arnaud [mailto:arnaud@gmail.com]
Envoyé : vendredi 25 janvier 2013 13:40
À : talk-fr@openstreetmap.org
Objet : Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique

Bonjour à tous,

Je vais essayer de compléter mon argumentation.

Afin d'éviter de partir sur des problèmes de représentation liés a des éléments 
matériels (pont, tunnel, etc.), prenons l'exemple des limitation de vitesse.
Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage et la 
création d'un tronçon.

L'idée de départ, étant d'utiliser un concept existant, celui de la 
segmentation dynamique, mais adapté à OSM.
Je précise que ce concept de segmentation dynamique, ne sort pas de ma caboche 
mais existe déjà dans les bases de donnes routières [ex 1].
La segmentation dynamique permet d'avoir un réseau routier non segmenté auquel 
est associé une (ou plusieurs) table complémentaire d'événements (limitation de 
vitesse, pont, etc.).
En fonction de la demande (limitation de vitesse, pont, etc.) le réseau est 
segmenté dynamiquement (d'où le nom du concept).
Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement pensé 
aux potentialités des relations.
En effet, dans un SIG classique les tables étant séparées, la seule relation 
entre la route et les événements sont leur positions géographiques.
Or, les relations nous permettent de conserver à la fois une cohérence 
géographique et sémantique.
Bon voila pour la théorie, maintenant j'ai bien conscience de la difficulté de 
compréhension d'un tel modèle pour un nouveau contributeur.
Mais il a aussi un gain certain en terme de gestion des données, performance et 
stockage !


Arnaud

1 - 
https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm

On 13-01-25 07:29 AM, Francescu GAROBY wrote:
Et actuellement, un tel comportement est considéré comme une erreur : soit pour 
cause de doublon soit, lorsque 2 ways se croisent, pour absence de node à 
l'intersection (d'où le tag 'layer').

Francescu
Le 25 janvier 2013 11:55, François Lacombe 
mailto:francois.laco...@telecom-bretagne.eu>>
 a écrit :

Le 25 janvier 2013 11:22, Pieren mailto:pier...@gmail.com>> 
a écrit :
2013/1/25 François Lacombe 
mailto:francois.laco...@telecom-bretagne.eu>>:

Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de
données géospatiale. Tous les noeuds et ways sont déjà positionnés les
uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou
des relations que lorsqu'il y a ambiguité.
Il ne faut pas s'étrangler, ca n'en vaut pas la peine.

Néanmoins, je vois mal comment peut-être exprimée une quelconque dépendance 
entre une route et un pont sur lequel elle passe dans la réalité sans relation 
entre les objets.
Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la route 
est bien positionnée par rapport au pont, ce dernier peut se trouver 100m en 
dessous (il y a le tag ele=* mais ca ne compte pas).
--
François Lacombe

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com

___
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] Carte OuVerte dans 60 millions de consommateurs

[Christian Quest]

Et hop: http://openstreetmap.fr/60millions-janvier-2013

Le 25 janvier 2013 15:42, Romain MEHUT  a écrit :

> Bonjour,
>
> Le numéro de janvier 2013 du magazine 60 millions de consommateurs
> consacre un article à la Carte OuVerte de Rennes réalisée grâce au logiciel
> Chimère.
>
> D'ailleurs, on n'a pas beaucoup de news autour du projet Chimère? C'est
> pourtant un excellent exemple de mise en valeur d'OSM...
>
> L'article est en partage 
> ici
> .
>
> Romain
>
> ___
> 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] Carte OuVerte dans 60 millions de consommateurs

[Pierre Béland]

Il gobe tout ce mek. Il faudrait lui trouver un nom approprié  :)


Cette carte communautaire est un exemple très concret de l'utilité de OSM, de 
comment l'utiliser localement.  Par contre, il semble y avoir un gros moteur 
turbo à maitriser avec le logiciel Chimère.
 
Pierre 



>
> De : Christian Quest 
>Et hop: http://openstreetmap.fr/60millions-janvier-2013
>
>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] [forum-osm-fr] Bonsoir Bonsoir !

[forum]

Le message suivant de :
##
Bonjour,



Je m'appel MrBibendum je vous ai découvert grace à un ami vététiste et j'ai 
plein de questions parce que il y a plein de choses compliquées pour quelqu'un 
qui n'est pas très doué comme moi :D 



Je vais d'abord chercher et ensuite interroger



Merci à bientot

a été posté sur le forum http://forum.openstreetmap.fr/viewtopic.php?f=10&t=483
Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part
Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une 
concertation sur la liste avant de recopier 
la/les meilleures réponses sur le forum.
Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre.
--
Les questions sur ce robot de transfert forum->liste
peuvent être posées à sylvainaletuffe.org

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

Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique

[Vincent de Chateau-Thierry]

Bonsoir,

Le 25/01/2013 15:44, HELFER Denis a écrit :

Je commence à m’intéresser sérieusement à la segmentation dynamique dans
le domaine de l’infra ferroviaire où l’on raisonne essentiellement en
termes de PK (pour les événements ponctuels ex. Passage à niveau,
appareil de voie)ou PK début/Pk fin pour les événements linéaires
(ouvrages d’art, chantiers, électrification, …). Je confirme mon intérêt
pour cette démarche !

Idéalement, on devrait avoir une consistance topologique au niveau du
tracé, la consistance sémantique serait assurée par des relations.

Exemple pour un pont-rail

Relation X

Required Type=ouvrage_art

Required Description=pont-rail

Optional source=RFF

Optional material=metal

Optional length=xxx

Optional height=xxx

Optional name=blabla

Required Members : a rôle « from »

Required Members : b rôle « to »

Required Members : c rôle « on »

Optional members : d rôle « under »

a=id du point  début du pont  (son PK debut)

b=id du point fin du pont (son PK fin)

c=id du tronçon de voie supportant la relation

d=id du tronçon de la voie traversée (rivière, chemin, route, …)

C’est clair qu’il y a du boulot pour des applications pour transformer
ces relations en objets découpés suivant les pointillés.



Dans ton exemple, la portion de voie ferrée de type pont-rail est 
définie par ses bornes, sous forme de nodes : a et b. Une autre manière, 
même sans node, consiste à définir le pont avec 2 abscisses curvilignes, 
à partir d'un way dont une extrémité serait le "PK 0". Dans ce cas, on 
pourrait dire : le pont rail commence au PK 7.5 et se termine au PK 7.6, 
c'est à dire : le pont rail commence à 7.5km du début du way et mesure 100m.
Ces 2 manières de dire la même chose souffrent du même bémol : il ne 
faut pas que la référence (le way) bouge, sinon l'objet pont-rail bouge 
aussi.
Dans le premier modèle, il suffit de bouger par exemple le node a pour 
déplacer le début du pont-rail. Dans le second, si je raffine la 
courbure de la voie ferrée, j'augmente la longueur du way, et je déplace 
l'endroit situé à 7.5 km du début.
Dans les deux cas on est face à, j'ai l'impression, une contradiction : 
la segmentation dynamique requiert une stabilité du référentiel 
géométrique pour que les objets définis relativement à cette géométrie 
soient stables, et à l'inverse, dans OSM, chacun est libre de modifier 
tous les objets, rien n'est figé/vérouillé.
Du coup est-ce compatible, au stade des contributions ? C'est différent 
au stade de la réutilisation, où chacun est libre de définir des objets 
(des 'évènements') relativement au graphe OSM, dès lors que celui-ci a 
été extrait une fois et figé pour servir de référence.


vincent

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

Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique

[Philippe Verdy]

Le 25 janvier 2013 11:51, Francescu GAROBY  a écrit :
> Comme stop_area, où des nodes sont utilisés pour indiquer le stop_position
> (pour ne citer qu'un exemple).

Non c'est différent car les noeuds des stop-position sont ceux qui
portent le tag du stop-position. On ne tague pas la relation ou le
chemin référençant le noeud en mettant un tag "stop_position=id". Les
ids sont destinés à servir de références internes à la base pas dans
des valeurs de tags qui seront exportés : les ids d'OSM n'ont aucune
signification par eux-mêmes et ne sont jamais stables (ce qui est
stable ce sont les ref:*=*).

Et non je n'ai rien confondu entre "tag" (couple d'un nom et d'une
valeur formant un attribut/une propriété de n'importe quel objet) et
"rôle" (les rôles permettent de créer des listes de membres multiples
ayant des usages différents, le même rôle servant à un ou plusieurs
membres en principe, sauf que souvent on a un rôle par défaut qui est
équivalent à l'absence de rôle indiqué pour un membre). Relis bien ce
que j'ai écris tu comprendras, je penses que c'est bien toi qui
interprète mal ou veut interpréter ma phrase comme si j'avais fait la
confusion des termes.

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

Re: [OSM-talk-fr] OpenStreetMap modélisation et segmentation dynamique

[Francescu GAROBY]

Le 25 janvier 2013 21:36, Philippe Verdy  a écrit :

> Le 25 janvier 2013 11:51, Francescu GAROBY  a écrit :
> > Comme stop_area, où des nodes sont utilisés pour indiquer le
> stop_position
> > (pour ne citer qu'un exemple).
>
> Non c'est différent car les noeuds des stop-position sont ceux qui
> portent le tag du stop-position. On ne tague pas la relation ou le
> chemin référençant le noeud en mettant un tag "stop_position=id". Les
> ids sont destinés à servir de références internes à la base pas dans
> des valeurs de tags qui seront exportés : les ids d'OSM n'ont aucune
> signification par eux-mêmes et ne sont jamais stables (ce qui est
> stable ce sont les ref:*=*).
>
> Mais quand Arnaud dit "from : N2,  to : N3", il faut (je suppose)
comprendre que ces 2 rôles pointeront vers les nodes dont l'id est
respectivement N2 et N3. Pas sur la valeur de ces id proprement dits (donc
comme dans mon exemple de stop_area).


> Et non je n'ai rien confondu entre "tag" (couple d'un nom et d'une
> valeur formant un attribut/une propriété de n'importe quel objet) et
> "rôle" (les rôles permettent de créer des listes de membres multiples
> ayant des usages différents, le même rôle servant à un ou plusieurs
> membres en principe, sauf que souvent on a un rôle par défaut qui est
> équivalent à l'absence de rôle indiqué pour un membre). Relis bien ce
> que j'ai écris tu comprendras, je penses que c'est bien toi qui
> interprète mal ou veut interpréter ma phrase comme si j'avais fait la
> confusion des termes.
>
> ___
> 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] OpenStreetMap modélisation et segmentation dynamique

[Philippe Verdy]

Ce ne sera possible qu'à condition de donner un attribut stable aux
noeuds (un nom, une ref, sous la forme d'un tag explicite, mais pas en
se contentant de leur ID.

Si on veut donc désigner une paire de noeud on pourrait indiquer que
sur une route les sections entre les noeuds A et B, ou C et D sont un
pont. L'ennui c'est comment s'assurer que les noms utilisés dans le
chemin resteront uniques : à la première fusion de deux chemins ce
n'est plus garanti. On pourrait utiliser la numérotation du bornage
kilométrique (ou hectométrique) sur les routes longues, mais on n'en
trouve pas dans les zones urbaines avec des carrefours. En revacnhe en
ville on peut mettre les numéros des adresses.

Ensuite alors on peut mettre un maxspeed=50; maxspeed:exception=30
pour la limitation temporaire des sections indiquées par
"exceptions:maxspeed=A B;C D" (les espaces sont pour les intervalles,
les point-virgules séparent les entrées ponctuelles ou intervalles).
L'ennui c'est que le moteur de navigation va devoir chercher les
références indiqu"es dans des listes assez longues...
Finalement ce sont les relations qui évitent les complications et
ambiguités, et problèmes d'homonymies). Les relations n'offrent pas
plus de complication, mais elles sont stables et on peut facilement
retrouver dans une relation un intervalle de membres entre deux
bornes, pour faire des sélections multiples servant à construire
d'autres relations.

Le 25 janvier 2013 14:06, Francescu GAROBY  a écrit :
>
>
> Le 25 janvier 2013 13:39, Arnaud  a écrit :
>
>> Bonjour à tous,
>>
>> Je vais essayer de compléter mon argumentation.
>>
>> Afin d’éviter de partir sur des problèmes de représentation liés a des
>> éléments matériels (pont, tunnel, etc.), prenons l'exemple des limitation de
>> vitesse.
>> Chaque changement (ex, passage de 50 à 70) occasionne alors un découpage
>> et la création d'un tronçon.
>>
>> L’idée de départ, étant d'utiliser un concept existant, celui de la
>> segmentation dynamique, mais adapté à OSM.
>> Je précise que ce concept de segmentation dynamique, ne sort pas de ma
>> caboche mais existe déjà dans les bases de donnes routières [ex 1].
>> La segmentation dynamique permet d'avoir un réseau routier non segmenté
>> auquel est associé une (ou plusieurs) table complémentaire d’événements
>> (limitation de vitesse, pont, etc.).
>> En fonction de la demande (limitation de vitesse, pont, etc.) le réseau
>> est segmenté dynamiquement (d’où le nom du concept).
>
> Si je comprends bien, on pourrait même imaginer activer des évènements du
> point N1 au point N2 , sans avoir du coup besoin de redécouper le tronçon à
> ces 2 points ? Juste en ajoutant une ligne dans la table complémentaire
> d'évènements ? Et inversement lors de la désactivation de l'évènement ?
> Ceci limiterait en effet grandement le "hachage" que subissent certaines
> ways (entre le nombre de voies qui changent, les bouts empruntés par un
> itinéraire de bus, les bouts qui servent de frontières, ...).
>
> Ce qui permettrait de prendre en compte des évènements ponctuels, courts et
> à très brève échéance (voire déjà en cours), tels qu'un accident sur une
> autoroute, qui immobilise une voie.
>
> Francescu
>
>>
>> Quand j'ai commencé à me renseigner sur ce domaine, j'ai immédiatement
>> pensé aux potentialités des relations.
>> En effet, dans un SIG classique les tables étant séparées, la seule
>> relation entre la route et les événements sont leur positions géographiques.
>> Or, les relations nous permettent de conserver à la fois une cohérence
>> géographique et sémantique.
>> Bon voila pour la théorie, maintenant j'ai bien conscience de la
>> difficulté de compréhension d'un tel modèle pour un nouveau contributeur.
>> Mais il a aussi un gain certain en terme de gestion des données,
>> performance et stockage !
>>
>>
>> Arnaud
>>
>> 1 -
>> https://ceprofs.civil.tamu.edu/folivera/txaggis/Spring2004/von_Holdt/CVH_project_report.htm
>>
>>
>>
>> On 13-01-25 07:29 AM, Francescu GAROBY wrote:
>>
>> Et actuellement, un tel comportement est considéré comme une erreur : soit
>> pour cause de doublon soit, lorsque 2 ways se croisent, pour absence de node
>> à l'intersection (d'où le tag 'layer').
>>
>> Francescu
>>
>> Le 25 janvier 2013 11:55, François Lacombe
>>  a écrit :
>>>
>>>
>>>
>>> Le 25 janvier 2013 11:22, Pieren  a écrit :

 2013/1/25 François Lacombe :

 Urg, je m'étrangle à chaque fois que je lis ça. OSM est une base de
 données géospatiale. Tous les noeuds et ways sont déjà positionnés les
 uns par rapport aux autres. On ne doit (devrait) ajouter des tags ou
 des relations que lorsqu'il y a ambiguité.
>>>
>>> Il ne faut pas s'étrangler, ca n'en vaut pas la peine.
>>>
>>> Néanmoins, je vois mal comment peut-être exprimée une quelconque
>>> dépendance entre une route et un pont sur lequel elle passe dans la réalité
>>> sans relation entre les objets.
>>> Je crois que l'API d'OSM ne gère pas les altitudes et que donc même si la
>>> route est bie

Re: [OSM-talk-fr] http://www.tuugo.fr semble ne pas respecter la licence osm

[Philippe Verdy]

Tuugo.fr m'a répondu et a fait les changements demandés.

Par exemple:
http://www.tuugo.fr/Companies/marylene31/0120004890035
(bref c'est bon aussi bien pour les carte OSM... qui ne sont plus
utilisées ! que pour les cartes Google Maps qui les ont remplacées et
qui mentionnent les attributions et licences requises par Google)

Problème réglé. Avant de remettre OSM, il va falloir qu'il se monte
d'abord son serveur de tuiles car il a compris le problème du SLA non
garanti par le serveur de tuiles d'OSM (d'autant plus qu'il n'en
mesure pas l'usage alors que Google Maps lui fournit les outils : il
pourra faire une mesure d'usage et d'audience s'il monte son serveur
de tuiles avec un frontal Squid, qui a déjà tout ce qu'il faut comme
outils d'analyse de ses jouranux pour mesurer les bandes passantes et
accès).

Le 24 janvier 2013 03:32, Philippe Verdy  a écrit :
> Je lai ai contacté via leur formulaire de contact en bas de page en
> mentionnant les deux points (attributions et licence obligatoires, et
> serveur de tuiles autonome hautement recommandé pour ne pas abuser les
> accès et la bande passante sur le TMS d'OSM)
>
> Le 24 janvier 2013 03:06, Philippe Verdy  a écrit :
>> Le 24 janvier 2013 03:04, Philippe Verdy  a écrit :
>>> Et pas seulement pour géolocaliser les visiteurs dans leur compte
>>> personnel local, mais pour les minicartes des entrerprises référencées
>>> (ce n'est pas encore le plus méchant en bande passante), mais surtout
>>> pour la recherche géographique avec une grande carte on peut commencer
>>> à l'échelle de la région ou département et zoomer/glisser partout
>>> avant de cliquer un lieu de recherche, et là ce n'est plus un usage
>>> anecdotique).
>>
>> Sur certaines pages cependant ils utilisent GoogleMap (avec les
>> attributions et copyrights de Google et de ses fournisseurs). Pourquoi
>> ils ne le font pas quand ils utilisent OSM ? Visiblement ils ont trop
>> utilisé Google Maps et ne veulent plus payer pour les affichages ; du
>> coup ils passent à OSM en partie, mais ne veulent pas mentionner
>> l'attribution affichée sur les minicartes ou dessous, c'est donc une
>> démarche volontaire clairement abusive).

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

[OSM-talk-fr] région de Kidal au nord du Mali

[Jean-François Gaffard]

salut à tous

je me suis mis à participer à la cartographie de la région de Kidal au
nord du Mali (je me demande pourquoi!)
il existe une couverture Bing HR assez intéressante bien que partielle
mais la couverture basse résolution montre vraisemblablement les zones
de paturages en saison des pluies ce qui est pas mal pour l'occupation
du sol
j'ai fait un test sur la zone
http://www.openstreetmap.org/?lat=19.505&lon=0.976&zoom=10&layers=M

je me pose 2 questions
-heath est il le bon tag, je n'ai rien trouvé pour des paturages
temporaires (la haute résol qui est très certainement prise en saison
sèche montre bien qu'il n'y a quasiment plus rien. meadow pe semble un
peu inadapté)
-pour les oueds c'est un peu pareil faut-il cartographier waterway=river
ou stream avec intermittent=yes sachant qu'il est fort possible que
l'intermitence dure plusieurs années.
quant à leurs noms n'en parlons pas, quelques villages m'ont déjà donné
du fil à retordre.

enfin une dernière question a propos des routes qu'il n'y a pas. je
constate que de nombreux contributeurs surclasse (à mon sens) des routes
qui ne sont que des pistes.
est-ce logique ou simplement un effet collatéral du moteur de rendu. si
on taggue en track,  aux grandes  échelles rien n'apparait alors on
taggue en highway primary ou secondary pour dire de voir apparaitre
qqchose sur la carte.

 I. Pour info un lien avec un pdf dans lequel il y a quelques
mauvaises images de cartes mais qui permet cependant de
comprendre cette région
http://www.region-kidal.org/spip.php?article16

peut-être qu'au passage l'ONG Action contre la Faim libèrerait ces jeux
de données ?

en tout cas avant de continuer davantage j'aimerais quelques avis de la
communauté
jeff





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

Re: [OSM-talk-fr] Présentation de 2u, un rendu alternatif déstiné aux contributeurs

[Black Myst]

Hello,

J'ai plein d'idées.

Le 24 janvier 2013 14:39, sly (sylvain letuffe)  a écrit
:

> Les idées sont bien sûr les bienvenues, mais clairement, les patchs avec
> la correction qui
> ne reste plus qu'a intégrer sont largement plus bienvenus et ont plus
> de chance d'être intégrées direct


Ca me dirait bien de bidouiller le rendu, mais comment est-ce qu'on peut
faire des tests ?
Quel logiciel installé ? Est-ce qu'on doit passé par l'installation d'un
serveur de tuile ou il y a plus simple ?

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

Re: [OSM-talk-fr] région de Kidal au nord du Mali

[Christian Quest]

Une piste si elle est la route principale a de bonnes raison d'être tagguée
en primary, non ?
Ensuite les tag de surface, grade ou autre peuvent expliciter son état
autant qu'on puisse en juger "vu du dessus".

Le 26 janvier 2013 00:05, Jean-François Gaffard <
jean-francois.gaff...@laposte.net> a écrit :

> enfin une dernière question a propos des routes qu'il n'y a pas. je
> constate que de nombreux contributeurs surclasse (à mon sens) des routes
> qui ne sont que des pistes.
> est-ce logique ou simplement un effet collatéral du moteur de rendu. si
> on taggue en track,  aux grandes  échelles rien n'apparait alors on
> taggue en highway primary ou secondary pour dire de voir apparaitre
> qqchose sur la carte.
>

-- 
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] Présentation de 2u, un rendu alternatif déstiné aux contributeurs

[Etienne Trimaille]

Avec Tilemill et une connexion à une base osm2pgsql, tu peux avoir le rendu
en "live" de tes modifs sur le style.
http://mapbox.com/tilemill/


Le 26 janvier 2013 00:12, Black Myst  a écrit :

> Hello,
>
> J'ai plein d'idées.
>
> Le 24 janvier 2013 14:39, sly (sylvain letuffe)  a
> écrit :
>
> Les idées sont bien sûr les bienvenues, mais clairement, les patchs avec
>> la correction qui
>> ne reste plus qu'a intégrer sont largement plus bienvenus et ont plus
>> de chance d'être intégrées direct
>
>
> Ca me dirait bien de bidouiller le rendu, mais comment est-ce qu'on peut
> faire des tests ?
> Quel logiciel installé ? Est-ce qu'on doit passé par l'installation d'un
> serveur de tuile ou il y a plus simple ?
>
> Cdt
> Black Myst
>
> ___
> 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] Présentation de 2u, un rendu alternatif déstiné aux contributeurs

[Black Myst]

Le 26 janvier 2013 00:22, Etienne Trimaille  a
écrit :

> Avec Tilemill et une connexion à une base osm2pgsql, tu peux avoir le
> rendu en "live" de tes modifs sur le style.
> http://mapbox.com/tilemill/
>

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

[OSM-talk-fr] OSM-Watch a disparu

[Pierre Béland]

Ce lien est actuellement inopérant. Le sous-répertoire watch a disparu de 
l'écran radar.
http://osm102.openstreetmap.fr/~zorglub/watch/

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

Re: [OSM-talk-fr] région de Kidal au nord du Mali

[Pierre Béland]

Bonsoir Jean-François,

Tes coordonnées pointent sur la ville d'Aguelock où il que de l'imagerie Bing 
basse définition. Je suis incapable de tirer des conclusions sur l'état des 
lieux à partir d'une imagerie de basse résolution. Dans le delta du Niger, les 
contributeurs avaient identifiés d'immenses lacs à partir de l'imagerie basse 
résolution. Avec l'imagerie haute résolution, nous devons maintenant corriger 
cette information et indiquer les fermes, villages et routes qui sont en zone 
inondée à la période des pluies.

Je t'invite plutôt à venir collaborer avec l'équipe humanitarie HOT. Frédéric 
Bonifas et moi coordonnons actuellement la cartographie pour l'ensemble du Mali 
à partir des priorités des humanitaires au Mali. Nous identifions les endroits 
où il y a de l'imagerie Haute définition disponible et donnons les instructions 
pour cartographier ces endroits. 

Je t'invites aussi à suivre le fil de discussion HOT pour avoir des infos sur 
la coordination des activités de cartographie au Mali. Si les contributeurs 
français le désirent, nous pourrons aussi donner ces instructions en français 
sur la liste talk-fr.
http://lists.openstreetmap.org/listinfo/hot

page de coordination http://wiki.openstreetmap.org/wiki/2012_Mali_Crisis

Gestionnaire de tâches http://tasks.hotosm.org/#all/Mali

 
Pierre 



>
> De : Jean-François Gaffard 
>À : Discussions sur OSM en français  
>Envoyé le : Vendredi 25 janvier 2013 18h05
>Objet : [OSM-talk-fr] région de Kidal au nord du Mali
> 
>salut à tous
>
>je me suis mis à participer à la cartographie de la région de Kidal au
>nord du Mali (je me demande pourquoi!)
>il existe une couverture Bing HR assez intéressante bien que partielle
>mais la couverture basse résolution montre vraisemblablement les zones
>de paturages en saison des pluies ce qui est pas mal pour l'occupation
>du sol
>j'ai fait un test sur la zone
>http://www.openstreetmap.org/?lat=19.505&lon=0.976&zoom=10&layers=M
>
>je me pose 2 questions
>-heath est il le bon tag, je n'ai rien trouvé pour des paturages
>temporaires (la haute résol qui est très certainement prise en saison
>sèche montre bien qu'il n'y a quasiment plus rien. meadow pe semble un
>peu inadapté)
>-pour les oueds c'est un peu pareil faut-il cartographier waterway=river
>ou stream avec intermittent=yes sachant qu'il est fort possible que
>l'intermitence dure plusieurs années.
>quant à leurs noms n'en parlons pas, quelques villages m'ont déjà donné
>du fil à retordre.
>
>enfin une dernière question a propos des routes qu'il n'y a pas. je
>constate que de nombreux contributeurs surclasse (à mon sens) des routes
>qui ne sont que des pistes.
>est-ce logique ou simplement un effet collatéral du moteur de rendu. si
>on taggue en track,  aux grandes  échelles rien n'apparait alors on
>taggue en highway primary ou secondary pour dire de voir apparaitre
>qqchose sur la carte.
>
>     I. Pour info un lien avec un pdf dans lequel il y a quelques
>        mauvaises images de cartes mais qui permet cependant de
>        comprendre cette région
>http://www.region-kidal.org/spip.php?article16
>
>peut-être qu'au passage l'ONG Action contre la Faim libèrerait ces jeux
>de données ?
>
>en tout cas avant de continuer davantage j'aimerais quelques avis de la
>communauté
>jeff
>
>
>
>
>
>___
>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] Tr : [OSM-talk] overpass turbo - a web GUI for Overpass-API

[Pierre Béland]

Martin Raifer annonce une version graphique de Overpass-API. C'est super. 


Il a ajouté une carte d'où il est possible de sélectionner le bbox délimitant 
la zone de recherche. Pour les nodes, le résultat est retourné directement sur 
cette carte. Pour les autres éléments, seul le fichier OSM est accessible. De 
plus, lors de mes tests le délai d'attente étaient très courts. 
Pierre 


- Mail transféré -
>De : Martin Raifer 
>À : t...@openstreetmap.org 
>Envoyé le : Vendredi 25 janvier 2013 17h10
>Objet : [OSM-talk] overpass turbo - a web GUI for Overpass-API
> 
>Hello,
>
>I'm happy to present you *overpass turbo* [1], a web based graphical user 
>interface for Overpass API.
>
>I've always thought, that the Overpass API can be a great tool for mappers and 
>developers (for example for its powerfulness in data filtering). However, 
>there was no easy way to quickly run an Overpass query and inspect the results 
>in a user friendly manner, until now: With overpass turbo you can run Overpass 
>API queries and analyze the resulting OpenStreetMap data interactively on a 
>map.
>
>Here are some use cases where overpass turbo can come in handy:
>* Searching for (rare) spelling mistakes or breaks with naming conventions, 
>which are not yet covered by any QA tool.
>* Showing and inspecting spacially large features (boundaries, rivers, 
>complete motorways, PT-networks, ...).
>* Always when you only need a filtered portion of OSM data.
>* Testing and developing more or less complicated Overpass API queries.
>* Creating mock-ups of clickable or static maps highlighting selected OSM 
>features.
>
>http://overpass-turbo.eu
>
>This is the url where you can find overpass turbo [1] (alternatively, there is 
>also an installation on overpass-api.de [2]). You need a somewhat recent web 
>browser for using overpass turbo. Opera, Chrome and Firefox have been tested 
>and work (IE 10 should be fine, too).
>
>More information, screenshots, examples, etc. can be found on the OSM-wiki [3] 
>or on its github repository [4].
>
>Have fun :)
>Martin / tyr_asd
>
>[1] http://overpass-turbo.eu
>[2] http://overpass-api.de/turbo/
>[3] http://wiki.openstreetmap.org/wiki/Overpass_turbo
>[4] https://github.com/tyrasd/overpass-ide
>
>___
>talk mailing list
>t...@openstreetmap.org
>http://lists.openstreetmap.org/listinfo/talk
>
>
>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr