Re: [OSM-talk-fr] Lot Talk-fr, Vol 94, Parution 99

[Philippe Verdy]

Le 19 mai 2014 23:28, dom bertho  a écrit :

>  Je voudrais ajouter le cas des parcelles et des adresses avec 2 accès.
> Un sur une rue et l' autre de l' autre coté donnant sur une autre rue.
> L'adressage ne correspond pas a une logique définie mais parfois a des
> choix de propriétaires...
>
> De nombreux cas prouvent que s'il semble avoir des règles permettant cette
> "systématisation" de nombreux cas particuliers existent.. D'ou l'idée d'
> une certification datée par exemple.
>

"Certification" ? Par qui ? La source BANO est-elle plus officielle que
tout autre chose pour déterminer laquelle parmi deux adresses possibles est
"la" bonne ?

Les cas de double adresse sont légions, et même dans la même rue avec des
adresses incluant plusieurs numéros associés (par ex., 10-12 rue Xyz).
L'entrée depuis la voie publique en fin de compte pourrait ne plus exister
que depuis un des numéros et plus l'autre, ou le propriétaire peut avoir
gardé deux entrées mais changé celle qui est "principale" selon lui (par
exemple en fermant celle traversant un jardin par une porte fermée et
utilisée uniquement par le propriétaire qui en garde la clé, alors qu'il a
déplacé sa boite près de l'autre entrée qu'il garde fermée et ne franchit
pas lui-même.

Dans les peties villes portuaires, il est courant que les maisons soient
assez serrées entre elles avec des passages où elles ont des accès sur
plusieurs façades. Il n'y a pourtant pas plusieurs propriétés, mais
l'enregistrement initial de l'adresse peut ne plus correspondre à l'accès
utilisé aujourd'hui. Les boites à lettres peuvent être déplacées aussi. Une
entrée de garage peut avoir été aménagée sur un accès plus pratique pour le
véhicule de l'occupant. Le numéro de l'ancien accès peut être resté affiché
en façade même s'il ne sert plus, l'aute accès n'ayant pas de numéro
toujours visible mais pourtant bien réel. En fin de compte c'est l'occupant
qui détermine lui-même (ou sa copropriété) quel accès privilégier.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Evaluer les kms de voies cyclables

[Vincent de Château-Thierry]

Le 26/05/2014 22:22, Éric Gillet a écrit :

Bonsoir,

Pouvez-vous expliquer pourquoi il faut faire ces calculs sur l'id de la
relation ?


Le mécanisme est évoqué ici :
http://api.openstreetmap.fr/#section.download_area

L'exemple est celui d'une ville, mais (de mémoire) la possibilité a été 
étendue aux relations des communautés de communes.


vincent

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

Re: [OSM-talk-fr] Evaluer les kms de voies cyclables

[Éric Gillet]

Bonsoir,

Pouvez-vous expliquer pourquoi il faut faire ces calculs sur l'id de la
relation ?

Merci


2014-05-26 22:16 GMT+02:00 Vincent de Château-Thierry :

> Bonsoir
>
> Le 26/05/2014 22:01, domi a écrit :
>
>  Merci pour ces informations.
>> J'ai testé la seconde méthode qui me semble plus simple pour moi.
>>
>> En exécutant la requête donnée en exemple, j'ai réussi effectivement à
>> exporter les gpx et à obtenir la distance totale de Perpignan.
>>
>> Comme j'exécute "bêtement" j'ai remplacé le 18000 par 2177407 car dans
>> le wiki d'OSM j'ai trouvé ce qui me semble être l'id du grand Angoulême
>> mais là cela ne retourne rien.
>>
>>
>> Relation : Grand Angoulème (2177407)
>>
>
> Il faut remplacer en soustrayant 18000 puis additionnant 2177407
> => avec 3602177407 on a bien au final des données sur le Grand Angoulême.
>
> Bons tests,
>
> vincent
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] tile.openstreetmap.fr en "pause"

[Christian Quest]

layers est en cours de ré-importation de sa base monde


Le 25 mai 2014 08:44, Philippe Verdy  a écrit :

> Le 25 mai 2014 07:51, Christian Quest  a écrit :
>
>> Ne vous étonnez pas si "c'est pas à jour" ;)
>>
>> Problème aussi sur layers... mais qui est moins critique en terme d'usage
>> que tile (rendu FR+HOT)
>>
>
> Au fait sur les couches de layers, c'est volontaires qu'on n'y voit plus
> que les découpages admin et politiques QUE sur la France métropolitaine et
> plus les pays voisins (Royaume-Uni, Belgique, Luxembourg, Allemagne,
> Suisse, Italie, Espagne) ni au delà Afrique, Amérique, Asie et même notre
> outre-mer ?
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] Evaluer les kms de voies cyclables

[Vincent de Château-Thierry]

Bonsoir

Le 26/05/2014 22:01, domi a écrit :

Merci pour ces informations.
J'ai testé la seconde méthode qui me semble plus simple pour moi.

En exécutant la requête donnée en exemple, j'ai réussi effectivement à
exporter les gpx et à obtenir la distance totale de Perpignan.

Comme j'exécute "bêtement" j'ai remplacé le 18000 par 2177407 car dans
le wiki d'OSM j'ai trouvé ce qui me semble être l'id du grand Angoulême
mais là cela ne retourne rien.


Relation : Grand Angoulème (2177407)


Il faut remplacer en soustrayant 18000 puis additionnant 2177407
=> avec 3602177407 on a bien au final des données sur le Grand Angoulême.

Bons tests,

vincent

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

Re: [OSM-talk-fr] Evaluer les kms de voies cyclables

[domi]

Merci pour ces informations.
J'ai testé la seconde méthode qui me semble plus simple pour moi.

En exécutant la requête donnée en exemple, j'ai réussi effectivement à 
exporter les gpx et à obtenir la distance totale de Perpignan.


Comme j'exécute "bêtement" j'ai remplacé le 18000 par 2177407 car dans 
le wiki d'OSM j'ai trouvé ce qui me semble être l'id du grand Angoulême 
mais là cela ne retourne rien.



   Relation : Grand Angoulème (2177407)

Bref, merci de tes lumières.
Dominique Lachgar


Le 26/05/2014 17:26, rainerU a écrit :

On 26.05.2014 10:28, domi wrote:

> je fais partie de vélocité de l'Angoumois et depuis 1 an nous
> contribuons à OSM pour répertorier les équipements cyclables de 
l'agglo,

> rajouter les rues manquantes ...
> Nous aimerions avoir une idée du kilométrage de voies cyclables de
> l'agglomération d'Angoulême
>
> Est- ce qu'il y a une méthode pour cela ?

Je vois deux méthodes pour le faire. On peut importer les données OSM 
dans une base PostGis et faire une ou plusieurs requêtes spatiales du 
genre :


select sum(st_length(l.way)) from planet_osm_line l, 
planet_osm_polygon p where l.highway='cycleway' and p.osm_id=-18000 
and st_intersects(l.way,p.way)


où 18000 est l'id de la relation boundary.

Ou bien on utilise overpass / overpass-turbo pour selectionner les 
voies en question, puis on les eporte au format GPX, par exemple, et 
on aura la longueur avec un outil d'analyse GPX.


Avec Overpass Turbo on obtient par exemple les pistes cyclables pour 
la ville de Perpignan avec http://overpass-turbo.eu/s/3xL Il suffit de 
remplacer 18000 par l'id de la relation boundary de ton agglo.


Je préfére la méthode PostGis car elle permet un filtrage plus 
complexe et fournit directement la longueur. La méthode overpass a 
l'avantage de marcher sans base PostGis.


Et il doit y avoir d'autres methodes.

Rainer



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


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

Re: [OSM-talk-fr] Sur le modèle des adresses (était "Rendu BANO")

[Philippe Verdy]

Le 26 mai 2014 11:27, Pieren  a écrit :

> 2014-05-24 15:04 GMT+02:00 DH :
>
> > Ainsi, par exemple, je n'avais pas assimilé l'intérêt des
> > relations AssociatedStreet, maintenant si.
>
> Au risque de me répéter, il y aurait un grand danger à vouloir
> généraliser les relations associatedStreet dans OSM pour des raisons
> que j'ai déjà expliqué par ailleurs mais que je vais résumer ici:
> - c'est plus difficile à modifier. Ceux qui les ajoutent utilisent
> josm et c'est vrai que c'est facile d'emploi avec cet éditeur. Mais je
> les défie de modifier ces relations avec iD ou P2, ne serait-ce que de
> déplacer un numéro d'une rue à sa voisine. C'est très difficile et
> chia.. même pour les habitués. Et ne parlons pas des nouveaux
> contributeurs ou irréguliers.
> - l'argument sur l'intégrité est correct dans l'immédiat mais ne tient
> pas au long cours. On le voit avec toutes les relations comme les
> limites administratives, toutes les relations de type "route" ou même
> les multipolygones (pensez landuse corine), elles sont plus difficiles
> à maintenir parce qu'elles sont souvent cassées par les néophites. Ou
> pire, si l'éditeur est préventif à l'égard de toute modification comme
> dans JOSM, elle bloquera la bonne volonté du débutant.
>

Contrairement à toi je pense qu'il faut aller vers ce modèle même s'il est
plus complexe pour le débutant. Mais cette complexité vient des défauts des
outils en question qui ne font pas assez de validation, pas du modèle
lui-même.
Je n'aime pas du tout iD à cause de ça: on lui en demande trop, il présente
aux débutants une idée fausse de ce qu'est la cartographie.
Si on veut utiliser iD, à mon avis il ne devrait même pas être utilisé pour
alimenter directement la base OSM principale mais alimenter une autre base
plus simple pouvant ensuite servir de source d'intégration.

Le modèle de la base unique dans OSM a vécu il va falloir qu'OSM s'ouvre à
des bases multiples plus spécialisées, plus faciles à maintenir et plus
facile à rapprocher et intégrer avec de plus en plus d'outils d'intégration
multiniveau.
Et sans doute la base OSM principale devra ne plus être que le produit de
l'intégration d'un certain nombre de couches maintenues séparément. Et à
terme ne sera plus qu'une API présentant l'union de plusieurs sources
qualifiées.
L'intégration devra être de plus en plus automatique pour que le
contributeur humain, lui s'occupe de ce qui est le plus intéressant:
travailler sur des sous-bases plus homogènes, plus cohérentes, plus faciles
à maintenir.
On peut même aller vers des intégrations bidirectionnelles.
Pour ça on peut développer des tas de sites ou d'applis et militer pour que
toutes ces solutions puissent coexister et faire des échanges et
comparaisons
b
Je pense qu'ID est trop mal fichu pour notre base commune et devra aller
vers un travail sur une base séparée utilisant un jeu réduit de données et
une modélisation plus spécifique. L'utilisateur lambda est trop noyé sous
des tas d'infos qu'il ne peut plus maitriser et qui rendent ses
contributions de pus en plus difficile.

Je pense même qu'à terme OSM devrait aller vers un modèle GIS natif et
abandonner son modèle qui ne sera plus que virtuel dans une API
d'interrogation destiné aux rendus et analyses mais plus du tout en mode
écriture: l'utilisateur lui pourra tout voir dans des claques transparents,
mais travaillera sur des sous-calques spécialisés.

Et OSM devra supporte un système de versionnement collaboratif, façon Git,
permettant aussi des innovations par l'expérimentation sans casser le
reste. Et on pourrait s'épargner totalement les imports en permettant
d'accéder directement aux bases sources et à leur propre API de
contribution collaborative, même si on utilise un même outil visuel où on
aura choisi les couches qui nous intéressent et qu'on peu maitriser. Très
vite, plus personne ne sera en mesure de tout maitriser dans ces données et
cela devient de plus en plus complqué de maintenir la cohérence et gérer
les mises à jour car on manque d'états de synthèse.

Alors que faire ? En finir avec l'id d'objet unique et passer aux objets
liés par des URNs, autrement dit des ids spécialisés par source, et vers
une solution où OSM au lieu de stocker les objets deviendra plutôt un
"résolveur" permettant de référencer des tas de bases ouvertes, ou un
moteur de recherche permettant de les découvrir. C'est tout le modèle de
données d'OSM qui est à revoir, il montre aujourd'hui clairement ses
limites et coûte trop cher à maintenir (tant en moyens nécessaires qu'en
terme de moyens humains), cette base étnt de plus en plus compliquée à
aborder par des humains, même experts dans leurs domaines de compétence.

OSM pourrait s'inspirer des projets comme Wikidata (qui commence à devenir
aussi une base de données cartographiques en tant que tel tout en étant
ouvert à plus d'utilisations). Le gros du travail de Wikidata est encore
fait par des bots d'import, mais cela va se tarir et c'est vers de
nouvelles interfaces utilisa

Re: [OSM-talk-fr] Feuilleton sur la carto

[Philippe Verdy]

Sue un coin de carte affiché sur un écran on lisait parfaitement
"OpenStreetmap" dans cet épisode.
Mais c'est vrai que seul l'IGN a été mentionné...

Pas grand chose de très convaincant dans ce premier épisode sur la
"naissance d'une carte", et même sur ce qui devrait nous intéresser tous :
quelles sont les missions publiques de l'IGN et comment cette mission peut
évoluer dans un contexte de concurrence internationale avec toutes sortes
de projets et d'offres, ouvertes ou commerciales.
Si l'IGN doit se réformer c'est en tant que prestataire conseil pour aider
les collectivités et le développement d'applications intéessantes pour le
public dans des usages très différents. Aussi dans une démarche de
supervision qualité: la quantité des données disponibles ne va aller qu'en
croissant, il se pose déjà la question de la qualification des données,
leur suivi, leur intégration, la gestion des historiques, les méthodes
d'accès et de sélection des données selon les usages, l'identification des
besoins, l'évaluation de l'efficacité des méthodes, la gestion des coûts,
les économies possibles par des coopérations.
Le temps des cartes avec une seule source est fini : le reportage le dit
bien: la 4e génération des cartes IGN a encore un cycle de développement de
6 ans, c'est peut-être 10 fois plus rapide que la génération précédente
mais c'est encore beaucoup trop long pour les usages actuels et ce n'est
pas avec 240 personnes à l'IGN pour préparer un carroyage de 400km2 revu
tous les 6 ans que l'IGN pourra suivre seule la demande et les besoins.
Même Google avec des outils automatiques et une équipe de 600 personnes ne
pourra pas suivre.
Plus que jamais les collaborations sont nécessaires et seule la voie des
données ouvertes permettra d'aller plus vite, personne ne pourra suivre
avec une solution propriétaire où les "trous" de couverture seront de plus
en plus flagrants et de moins en moins acceptable.
L'IGN ne doit plus se positionner en tant que fournisseur de données mais
en tant que fournisseur de solutions qualité et expert pour rendre les
processus de mises à jour plus efficaces et avec une meilleure qualité
finale.
Même sur OSM, on doit aller non plus sur la seule accumulation de données
mais aller vers une démarche qualitative utilisant des outils de plus en
plus automatiques pour effectuer des rapprochements et détecter rapidement
les différences, par une meilleure classification plus systématique des
données où la contribution humaine individuelle des "fourmis" (toujours
indispensable) sera mieux exploitée, que pour des tâches de plus en plus
répétitives n'apportant rien en terme de réutilisabilité et de valeur
ajoutée (si on n'est pas capable de faire des rapprochements avec des
sources de plus en plus nombreuses d'informations nécessaires pour les
besoins.



Le 26 mai 2014 14:50, Jean-Baptiste Holcroft  a
écrit :

> À 32 minutes et 45 secondes sur :
>
> http://www.francetvinfo.fr/replay-jt/france-2/13-heures/jt-de-13h-du-lundi-26-mai-2014_603905.html
> Par contre je n'ai pas vu d'osm, ou alors je suis passé à côté ...
>
> --
> Jean-Baptiste Holcroft
>
>
> Le 26 mai 2014 13:43, Eric  a écrit :
>
> Salut ! Je suis tombé en cours de route sur un reportage du journal 13h de
>> F2 sur la carto. Comme c'est un feuilleton du journal, ca doit etre diffusé
>> en 5 épisodes sur la semaine. J'y ai croisé rapidement un logo OSM mais pas
>> de mention explicite, que de l'IGN. Esperons que ca sera le cas sur les 4
>> autres épisodes de la semaine... A revoir sur PLUZZ [1]
>>
>> Eric [Blueberry]
>>
>> [1] http://pluzz.francetv.fr/france2
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Utilisation d'une carte OSM pour suivre une course par relais

[Christian Rogel]

Depuis samedi dernier se court la « Redadeg », autrement dit une course de 1500 
km dans toute la Bretagne
pour collecter de l’argent afin de soutenir l’enseignement du breton, sa 
production audiovisuelle et
l’initiation des adultes.

Pour ceux que cela intéresse, j’ai résumé les buts et l’organisation, ici  : 
http://www.agencebretagnepresse.com/fetch.php?id=33879


Le point intéressant est que cette course peut être suivie sur un site Internet 
avec un pointage satellite  qui montre que les coureurs arrivent à Nantes
en ce moment  et la carte est basée sur MapQuest ouverte.

http://www.ar-redadeg.org  (cliquez sur la version française ou anglaise, au 
choix)

J’avais écrit (en breton) )à l’organisation pour signaler que les cartes 
n’avaient pas la bonne attribution.
Là, c’est quasi parfait (il me semble que le CC-By-SA n’est pas nécessaire).


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

Re: [OSM-talk-fr] Evaluer les kms de voies cyclables

[rainerU]

On 26.05.2014 10:28, domi wrote:

> je fais partie de vélocité de l'Angoumois et depuis 1 an nous
> contribuons à OSM pour répertorier les équipements cyclables de l'agglo,
> rajouter les rues manquantes ...
> Nous aimerions avoir une idée du kilométrage de voies cyclables de
> l'agglomération d'Angoulême
>
> Est- ce qu'il y a une méthode pour cela ?

Je vois deux méthodes pour le faire. On peut importer les données OSM 
dans une base PostGis et faire une ou plusieurs requêtes spatiales du 
genre :


select sum(st_length(l.way)) from planet_osm_line l, planet_osm_polygon 
p where l.highway='cycleway' and p.osm_id=-18000 and 
st_intersects(l.way,p.way)


où 18000 est l'id de la relation boundary.

Ou bien on utilise overpass / overpass-turbo pour selectionner les voies 
en question, puis on les eporte au format GPX, par exemple, et on aura 
la longueur avec un outil d'analyse GPX.


Avec Overpass Turbo on obtient par exemple les pistes cyclables pour la 
ville de Perpignan avec http://overpass-turbo.eu/s/3xL Il suffit de 
remplacer 18000 par l'id de la relation boundary de ton agglo.


Je préfére la méthode PostGis car elle permet un filtrage plus complexe 
et fournit directement la longueur. La méthode overpass a l'avantage de 
marcher sans base PostGis.


Et il doit y avoir d'autres methodes.

Rainer



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

[OSM-talk-fr] Première rencontre mensuelle OpenStreetMap à la Cantine

[Louis-Julien de la Bouëre]

*Rencontres mensuelles OpenStreetMap à Brest, rejoignez-nous !*

Depuis 2009, une belle dynamique s'est installé au Pays de Brest autour 
des cartes collaboratives OpenStreetMap avec des réalisations comme les 
plans de Plouarzel, Plouider, le développement de Chimère, le groupe 
"cartes ouvertes" et des ateliers à Plabennec, Plouzané, Guilers...


Pour découvrir le projet OpenStreetMap et ses enjeux du moment, faire le 
point sur les projets en cours en France et autour de Brest, rencontrer 
la communauté de contributeurs, nous vous invitons à une première 
rencontre mensuelle :


le mardi 03 juin 2014 à la Cantine brestoise à partir de 18h.

Au menu de la soirée en fonction des appétits :

- Présentation générale OSM et OSM France
- Les projets nationaux
- Les projets au Pays de Brest (accessibilité de BMO, hackathon, 
carto-Afrique, Chimère...)
- et tout ce que vous souhaitez partager, grignoter, décortiquer 
ensemble autour des cartes...


Et bien sûr repas partagé...

Au plaisir de se (re)-croiser...

 - Lien pour accéder à la Cantine : 
http://osm.org/go/erDxrP8jf?m=&node=2261538499
 - Contact : Louis-Julien de la Bouëre, ljbou...@openstreetmap.fr , 06 
58 79 80 56


/Message envoyé aux listes OSM-fr, OSM-bzh, cartes ouvertes pays de 
Brest, centre de ressources et wiki-brest/


--
Louis-Julien de la Bouëre
Association Tiriad
ljbou...@tiriad.org
www.tiriad.org
Portable : 06 58 79 80 56
Twitter : @assotiriad
Skype : tiloul29
Instagram : ljbouere29
TumblR : http://ljbouere.tumblr.com/

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

Re: [OSM-talk-fr] Feuilleton sur la carto

[Régis Bouguin]

Bonjour

À 36mn 10s, un morceau d'écran avec bing et une route qui coupe une 
pelouse ou je ne sais quoi, pas forcément une bonne pub :-D



Cordialement


Le 26/05/2014 14:50, Jean-Baptiste Holcroft a écrit :

À 32 minutes et 45 secondes sur :
http://www.francetvinfo.fr/replay-jt/france-2/13-heures/jt-de-13h-du-lundi-26-mai-2014_603905.html
Par contre je n'ai pas vu d'osm, ou alors je suis passé à côté ...

--
Jean-Baptiste Holcroft


Le 26 mai 2014 13:43, Eric mailto:eric...@sfr.fr>> a 
écrit :


Salut ! Je suis tombé en cours de route sur un reportage du
journal 13h de F2 sur la carto. Comme c'est un feuilleton du
journal, ca doit etre diffusé en 5 épisodes sur la semaine. J'y ai
croisé rapidement un logo OSM mais pas de mention explicite, que
de l'IGN. Esperons que ca sera le cas sur les 4 autres épisodes de
la semaine... A revoir sur PLUZZ [1]

Eric [Blueberry]

[1] http://pluzz.francetv.fr/france2

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




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


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

Re: [OSM-talk-fr] BANO: 100% des départements traités !

[Jean-Baptiste Holcroft]

Ou encore les lettres majuscules accentuées : Erable -> Érable
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/48.753964/7.853557

--
Jean-Baptiste Holcroft


Le 25 mai 2014 02:56, Pierre Knobel  a écrit :

> >
> > Je ne crois pas que cela ait déjà été signalé, pour le rapprochement :
> > "oe" et "œ" (exemple : sœur).
> >
>
> Peut-être aussi "ae" et "ä" (exemple
> http://www.openstreetmap.org/way/41940309).
>
> Pour le problème des communes fusionnées avec le nom de l'ancienne
> commune rajouté après le nom des rues, on doit aussi pouvoir faire
> quelque chose. On pourrait compter le nombre d'occurences pour le
> dernier mot de chaque nom de voie qui n'a pas pu être rapprochée, et
> pour ceux qui apparaissent plusieurs fois retenter le rapprochement
> après avoir supprimé ce dernier mot. Si ça marche, rajouter un
> addr:place="dernier mot" et un fixme:"vérifier addr:place" dans le
> résultat de l'outil d'intégration.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Feuilleton sur la carto

[Jean-Baptiste Holcroft]

À 32 minutes et 45 secondes sur :
http://www.francetvinfo.fr/replay-jt/france-2/13-heures/jt-de-13h-du-lundi-26-mai-2014_603905.html
Par contre je n'ai pas vu d'osm, ou alors je suis passé à côté ...

--
Jean-Baptiste Holcroft


Le 26 mai 2014 13:43, Eric  a écrit :

> Salut ! Je suis tombé en cours de route sur un reportage du journal 13h de
> F2 sur la carto. Comme c'est un feuilleton du journal, ca doit etre diffusé
> en 5 épisodes sur la semaine. J'y ai croisé rapidement un logo OSM mais pas
> de mention explicite, que de l'IGN. Esperons que ca sera le cas sur les 4
> autres épisodes de la semaine... A revoir sur PLUZZ [1]
>
> Eric [Blueberry]
>
> [1] http://pluzz.francetv.fr/france2
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Feuilleton sur la carto

[Eric]

Salut ! Je suis tombé en cours de route sur un reportage du journal 13h 
de F2 sur la carto. Comme c'est un feuilleton du journal, ca doit etre 
diffusé en 5 épisodes sur la semaine. J'y ai croisé rapidement un logo 
OSM mais pas de mention explicite, que de l'IGN. Esperons que ca sera le 
cas sur les 4 autres épisodes de la semaine... A revoir sur PLUZZ [1]


Eric [Blueberry]

[1] http://pluzz.francetv.fr/france2

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

Re: [OSM-talk-fr] Sur le modèle des adresses (était "Rendu BANO")

[Grégoire Surrel]

Dans ce cas, ne serait-il pas intéressant "d'aplatir" les données des
relations lors de l'édition, et de refactoriser le tout lors de
l'enregistrement dans la base de données ?

Je ne sais pas s'il faudrait mieux faire ça du côté des clients ou du
serveur, mais la saisie reste simple car la complexité des relation est
masquée par l'absence d'édition directe desdites relations.

Je ne pense pas que ce système peut fonctionner pour tout (multipolygones),
mais je ne vois pas de problèmes pour les lignes de bus ou pour les
adresses.




Greg


2014-05-26 12:57 GMT+02:00 Pieren :

> 2014-05-26 11:57 GMT+02:00 Christophe Merlet :
>
> > OpenStreetMap fonctionne ne manière itérative. Le neocontributeur ira au
> > plus simple avec un simple noeud qui sera ensuite intégré a la relation
> > idoine par un contributeur plus expérimenté.
>
> Ou l'inverse...
>
> > Chaque type de relation a son propre cycle de vie. Les relations
> > adresses ne dérogeront pas à la règle. Il n'y a aucune raison qu'elles
> > soient plus cassées que les autres, bien au contraire à mon avis dans la
> > mesure ou elles ont une emprise beaucoup plus petite.
>
> La raison en serait leur nombre. Même plus petites, si elles sont
> systématiques, elles seront plus souvent cassée...
>
> > Les autres pays ont ils un ref:FANTOIR ? Les autres pays cherchent t'ils
> > simplement à afficher un numéro de rue sur un fond de carte ou a
> > travailler efficacement avec leurs collectivités territoriales ?
>
> Le ref:FANTOIR ne peut, ne doit pas être la raison de créer des
> relations associatedStreet. Les autres pays peuvent avoir leurs refs
> ou même leurs wikidata. Concernant le travail avec les collectivités
> locales, c'est bien entendu un sujet partagé. La discussion sur le
> "share alike" de la license et les CT est directement inspirée d'une
> collaboration avec des collectivités locales. Partout, on voit bien
> que l'ajout des adresses par des contributeurs isolés prendrait de
> nombreuses années voir décennies et que si l'import d'une base
> publique est possible, il sera systématiquement préféré.
>
>
> > Heu, sur les doublons je ne te suis pas, il y en a beaucoup moins avec
> > les relations qu'a répéter un addr:street pour chaque addr:housenumber
> > Cela permet d'éviter de multiplier les erreurs de toponymes et
> > d'augmenter la qualité des données.
>
> Sauf que comme des appli genre OsmAnd ne reconnaissent pas ces
> relations, on voit fleurir ici et là des rues tagguées avec les deux
> modèles. Sauf que même avec une relation, le toponyme reste sur le
> highway parce que mapnik ne connait pas cette relation. Sauf que
> certains ont une interprétation différente du tag name sur la relation
> et mettent déjà un nom différent de la rue. Sauf que certains font
> deux ou plus relations par rues. Sauf que rien n'empêche quelqu'un de
> mettre la rue dans plusieurs relations...
>
> > On peut associer un code FANTOIR unique à une seule relation plutôt qu'a
> > chaque tronçon de la même voie.
>
> Comme le tag 'ref' ou le tag 'name' qu'il est bien plus simple de
> retrouver sur le way lui-même. On peut aussi décider de tout déplacer
> dans des relations : une pour le nom, une pour le 'ref', une pour le
> maxspeed, etc...
>
> > Avec les relation on factorise les redondance d'informations. c'est
> > bénéfique pour la base.
>
> Alors il faut pousser la logique jusqu'au bout et tout mettre dans des
> relations.
>
> > Bizarre de ne pas vouloir faire évoluer les pratiques d'OSM vers un
> > niveau plus "industriels". Le but c'est de voir les données réutilisé le
> > plus massivement possible, pour cela il faut un certain formalisme, même
> > si cela augmente un peu le niveau de compétences requis pour contribuer.
> > Encore que dans le même temps, les outils de contribution vont masquer
> > cette difficulté dans des cliquodromes appropriés.
>
> C'est l'autre risque du projet, le "syndrome wikipedia" qui fait que
> seuls des experts pourront modifier la carte. Et après ils viendront
> pleurer qu'il n'y a pas assez de contributeurs locaux pour actualiser
> les données. Quant à l'éditeur qui modifie les relations discrètement
> et en toute facilité, on le cherche encore...
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Sur le modèle des adresses (était "Rendu BANO")

[Pieren]

2014-05-26 11:57 GMT+02:00 Christophe Merlet :

> OpenStreetMap fonctionne ne manière itérative. Le neocontributeur ira au
> plus simple avec un simple noeud qui sera ensuite intégré a la relation
> idoine par un contributeur plus expérimenté.

Ou l'inverse...

> Chaque type de relation a son propre cycle de vie. Les relations
> adresses ne dérogeront pas à la règle. Il n'y a aucune raison qu'elles
> soient plus cassées que les autres, bien au contraire à mon avis dans la
> mesure ou elles ont une emprise beaucoup plus petite.

La raison en serait leur nombre. Même plus petites, si elles sont
systématiques, elles seront plus souvent cassée...

> Les autres pays ont ils un ref:FANTOIR ? Les autres pays cherchent t'ils
> simplement à afficher un numéro de rue sur un fond de carte ou a
> travailler efficacement avec leurs collectivités territoriales ?

Le ref:FANTOIR ne peut, ne doit pas être la raison de créer des
relations associatedStreet. Les autres pays peuvent avoir leurs refs
ou même leurs wikidata. Concernant le travail avec les collectivités
locales, c'est bien entendu un sujet partagé. La discussion sur le
"share alike" de la license et les CT est directement inspirée d'une
collaboration avec des collectivités locales. Partout, on voit bien
que l'ajout des adresses par des contributeurs isolés prendrait de
nombreuses années voir décennies et que si l'import d'une base
publique est possible, il sera systématiquement préféré.


> Heu, sur les doublons je ne te suis pas, il y en a beaucoup moins avec
> les relations qu'a répéter un addr:street pour chaque addr:housenumber
> Cela permet d'éviter de multiplier les erreurs de toponymes et
> d'augmenter la qualité des données.

Sauf que comme des appli genre OsmAnd ne reconnaissent pas ces
relations, on voit fleurir ici et là des rues tagguées avec les deux
modèles. Sauf que même avec une relation, le toponyme reste sur le
highway parce que mapnik ne connait pas cette relation. Sauf que
certains ont une interprétation différente du tag name sur la relation
et mettent déjà un nom différent de la rue. Sauf que certains font
deux ou plus relations par rues. Sauf que rien n'empêche quelqu'un de
mettre la rue dans plusieurs relations...

> On peut associer un code FANTOIR unique à une seule relation plutôt qu'a
> chaque tronçon de la même voie.

Comme le tag 'ref' ou le tag 'name' qu'il est bien plus simple de
retrouver sur le way lui-même. On peut aussi décider de tout déplacer
dans des relations : une pour le nom, une pour le 'ref', une pour le
maxspeed, etc...

> Avec les relation on factorise les redondance d'informations. c'est
> bénéfique pour la base.

Alors il faut pousser la logique jusqu'au bout et tout mettre dans des
relations.

> Bizarre de ne pas vouloir faire évoluer les pratiques d'OSM vers un
> niveau plus "industriels". Le but c'est de voir les données réutilisé le
> plus massivement possible, pour cela il faut un certain formalisme, même
> si cela augmente un peu le niveau de compétences requis pour contribuer.
> Encore que dans le même temps, les outils de contribution vont masquer
> cette difficulté dans des cliquodromes appropriés.

C'est l'autre risque du projet, le "syndrome wikipedia" qui fait que
seuls des experts pourront modifier la carte. Et après ils viendront
pleurer qu'il n'y a pas assez de contributeurs locaux pour actualiser
les données. Quant à l'éditeur qui modifie les relations discrètement
et en toute facilité, on le cherche encore...

Pieren

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

Re: [OSM-talk-fr] Sur le modèle des adresses (était "Rendu BANO")

[Christophe Merlet]

Le 26/05/2014 11:27, Pieren a écrit :
> 2014-05-24 15:04 GMT+02:00 DH :
> 
>> Ainsi, par exemple, je n'avais pas assimilé l'intérêt des
>> relations AssociatedStreet, maintenant si.
> 
> Au risque de me répéter, il y aurait un grand danger à vouloir
> généraliser les relations associatedStreet dans OSM pour des raisons
> que j'ai déjà expliqué par ailleurs mais que je vais résumer ici:
> - c'est plus difficile à modifier. Ceux qui les ajoutent utilisent
> josm et c'est vrai que c'est facile d'emploi avec cet éditeur. Mais je
> les défie de modifier ces relations avec iD ou P2, ne serait-ce que de
> déplacer un numéro d'une rue à sa voisine. C'est très difficile et
> chia.. même pour les habitués. Et ne parlons pas des nouveaux
> contributeurs ou irréguliers.

Généraliser les associatedStreet ne rend pas obsolètes les autres
manières de tagguer les adresses.

OpenStreetMap fonctionne ne manière itérative. Le neocontributeur ira au
plus simple avec un simple noeud qui sera ensuite intégré a la relation
idoine par un contributeur plus expérimenté.


> - l'argument sur l'intégrité est correct dans l'immédiat mais ne tient
> pas au long cours. On le voit avec toutes les relations comme les
> limites administratives, toutes les relations de type "route" ou même
> les multipolygones (pensez landuse corine), elles sont plus difficiles
> à maintenir parce qu'elles sont souvent cassées par les néophites. Ou
> pire, si l'éditeur est préventif à l'égard de toute modification comme
> dans JOSM, elle bloquera la bonne volonté du débutant.

Chaque type de relation a son propre cycle de vie. Les relations
adresses ne dérogeront pas à la règle. Il n'y a aucune raison qu'elles
soient plus cassées que les autres, bien au contraire à mon avis dans la
mesure ou elles ont une emprise beaucoup plus petite.

> - nous serions le seul pays à utiliser à une telle échelle une
> relation par rue dans OSM. Si aucun autre pays n'a fait ce choix, il
> faudrait au moins se demander pourquoi (alors qu'ils sont nombreux à
> faire des imports du même type et à se poser les mêmes questions que
> nous). L'habitude du village gaullois qui a raison seul contre tous ?

Les autres pays ont ils un ref:FANTOIR ? Les autres pays cherchent t'ils
simplement à afficher un numéro de rue sur un fond de carte ou a
travailler efficacement avec leurs collectivités territoriales ?

> - l'argument d'éviter les redondances ne tient pas. C'est même le
> contraire. Faute de support dans les outils externes autres que
> nominatim, les noms de rues sont de toute façon répétés sur la rue et
> la relation, si ce n'est pire, sur la rue et chaque numéro. Sans
> parler de l'internationalisation, des alt_name ou autres liens
> externes, on verra au final tous les tags doublonner. Certains ici
> prônent même la redondance comme solution à leurs problèmes lorsqu'ils
> doivent rédiger des règles de rendu pour mapnik et qu'ils trouvent au
> final la gestion des relations bien lourdes au niveau logiciel.

Heu, sur les doublons je ne te suis pas, il y en a beaucoup moins avec
les relations qu'a répéter un addr:street pour chaque addr:housenumber
Cela permet d'éviter de multiplier les erreurs de toponymes et
d'augmenter la qualité des données.

On peut associer un code FANTOIR unique à une seule relation plutôt qu'a
chaque tronçon de la même voie.


> - sur la modélisation elle-même, tout ce qui peut s'identifier par une
> relation peut se faire sans elle. Des solutions existent déjà pour les
> name, ref ou ref:FR:FANTOIR, même pour des rues appartenant à deux
> communes.

Avec les relation on factorise les redondance d'informations. c'est
bénéfique pour la base.

> - l'argument du changement de nom de rue qui serait plus facile est,
> là encore, discutable. Comme on l'a vu, les noms sont déjà répétés et
> il y faudra de toute façon surveiller la cohérence entre noms et
> numéros avec des outils QA (ce que fait déjà l'outil de geofabrik, par
> exemple). Et de toute façon, les changements de noms sont assez rares
> et on sera d'avantage confronté à du vandalisme ou des interprétations
> orthographiques divergentes.
> - finalement, le principal avantage des relations se trouve du côté
> des utilisateurs des données. Pour eux, il est effectivement plus
> facile de travailler avec une relation par rue que de chercher à
> assembler des morceaux de rues pas toujours attachés entre eux avec
> des noeuds ou des polygones éparses. Mais dans OSM, il y a une règle
> de base : c'est le terrain qui prime, et 90% des contributeurs sont
> des contributeurs uniques ou de très faible niveau. Même si ça n'est
> pas eux qui produisent le plus de données en quantité, ce sont eux qui
> sont les plus proches du terrain et qui fournissent les meilleures
> données en qualité. S'il faut donc choisir entre faciliter la vie des
> consommateurs des données OSM (les développeurs) et celle des
> contributeurs néophites, il faudra toujours essayer de priviligier
> autant que possible les seconds, quitte à do

[OSM-talk-fr] Sur le modèle des adresses (était "Rendu BANO")

[Pieren]

2014-05-24 15:04 GMT+02:00 DH :

> Ainsi, par exemple, je n'avais pas assimilé l'intérêt des
> relations AssociatedStreet, maintenant si.

Au risque de me répéter, il y aurait un grand danger à vouloir
généraliser les relations associatedStreet dans OSM pour des raisons
que j'ai déjà expliqué par ailleurs mais que je vais résumer ici:
- c'est plus difficile à modifier. Ceux qui les ajoutent utilisent
josm et c'est vrai que c'est facile d'emploi avec cet éditeur. Mais je
les défie de modifier ces relations avec iD ou P2, ne serait-ce que de
déplacer un numéro d'une rue à sa voisine. C'est très difficile et
chia.. même pour les habitués. Et ne parlons pas des nouveaux
contributeurs ou irréguliers.
- l'argument sur l'intégrité est correct dans l'immédiat mais ne tient
pas au long cours. On le voit avec toutes les relations comme les
limites administratives, toutes les relations de type "route" ou même
les multipolygones (pensez landuse corine), elles sont plus difficiles
à maintenir parce qu'elles sont souvent cassées par les néophites. Ou
pire, si l'éditeur est préventif à l'égard de toute modification comme
dans JOSM, elle bloquera la bonne volonté du débutant.
- nous serions le seul pays à utiliser à une telle échelle une
relation par rue dans OSM. Si aucun autre pays n'a fait ce choix, il
faudrait au moins se demander pourquoi (alors qu'ils sont nombreux à
faire des imports du même type et à se poser les mêmes questions que
nous). L'habitude du village gaullois qui a raison seul contre tous ?
- l'argument d'éviter les redondances ne tient pas. C'est même le
contraire. Faute de support dans les outils externes autres que
nominatim, les noms de rues sont de toute façon répétés sur la rue et
la relation, si ce n'est pire, sur la rue et chaque numéro. Sans
parler de l'internationalisation, des alt_name ou autres liens
externes, on verra au final tous les tags doublonner. Certains ici
prônent même la redondance comme solution à leurs problèmes lorsqu'ils
doivent rédiger des règles de rendu pour mapnik et qu'ils trouvent au
final la gestion des relations bien lourdes au niveau logiciel.
- sur la modélisation elle-même, tout ce qui peut s'identifier par une
relation peut se faire sans elle. Des solutions existent déjà pour les
name, ref ou ref:FR:FANTOIR, même pour des rues appartenant à deux
communes.
- l'argument du changement de nom de rue qui serait plus facile est,
là encore, discutable. Comme on l'a vu, les noms sont déjà répétés et
il y faudra de toute façon surveiller la cohérence entre noms et
numéros avec des outils QA (ce que fait déjà l'outil de geofabrik, par
exemple). Et de toute façon, les changements de noms sont assez rares
et on sera d'avantage confronté à du vandalisme ou des interprétations
orthographiques divergentes.
- finalement, le principal avantage des relations se trouve du côté
des utilisateurs des données. Pour eux, il est effectivement plus
facile de travailler avec une relation par rue que de chercher à
assembler des morceaux de rues pas toujours attachés entre eux avec
des noeuds ou des polygones éparses. Mais dans OSM, il y a une règle
de base : c'est le terrain qui prime, et 90% des contributeurs sont
des contributeurs uniques ou de très faible niveau. Même si ça n'est
pas eux qui produisent le plus de données en quantité, ce sont eux qui
sont les plus proches du terrain et qui fournissent les meilleures
données en qualité. S'il faut donc choisir entre faciliter la vie des
consommateurs des données OSM (les développeurs) et celle des
contributeurs néophites, il faudra toujours essayer de priviligier
autant que possible les seconds, quitte à donner un peu plus de
travail aux premiers.

Pieren

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

[OSM-talk-fr] Evaluer les kms de voies cyclables

[domi]

Bonjour,

je fais partie de vélocité de l'Angoumois et depuis 1 an nous 
contribuons à OSM pour répertorier les équipements cyclables de l'agglo, 
rajouter les rues manquantes ...
Nous aimerions avoir une idée du kilométrage de voies cyclables de 
l'agglomération d'Angoulême


Est- ce qu'il y a une méthode pour cela ?

Merci d'avance
Dominique

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