Re: [OSM-talk-fr] Osmose - École non intégrée

[Christian Quest]

Ces mentions sont normales (même si elles datent un peu) et correspondent à
la Licence Ouverte, c'est donc tout à fait réutilisable pour OSM.

Qu'est-ce qui est ventilé façon puzzle sur data.gouv ? Des liens seraient
utiles...

Le mer. 17 oct. 2018 à 22:55, deuzeffe  a écrit :

> On 10/17/18 12:44 PM, adr.an...@laposte.net wrote:
>
> > Cependant ces établissements sont absents de
> > l'Application de consultation et cartographie des établissements du
> système éducatif français
> > http://www.education.gouv.fr/acce_public/index.php
>
> Au passage la (les ?) base interrogée par l'appli. est ventilée façon
> puzzle sur data.gouv et avec des manques. Les mentions légales de acce
> disent :
>
> "En application de la loi du 17 juillet 1978 modifiée par l'ordonnance
> n°2005-650 du 6 juin 2005 relative à la liberté d'accès aux documents
> administratifs et à la réutilisation des informations publiques, ces
> informations peuvent être réutilisées à d'autres fins que celles pour
> lesquelles elles ont été produites. Les documents publics ou officiels
> peuvent être reproduits librement.
> Sauf accord de l’administration, la réutilisation des informations
> publiques est soumise à la condition que ces dernières ne soient pas
> altérées, que leur sens ne soit pas dénaturé et que leurs sources et la
> date de leur dernière mise à jour soient mentionnées."
>
> Ce qui mélange un peu CADA et OD, si je ne m'abuse.
>
> Si on pouvait avoir sinon la base en un seul morceau au moins toute la
> base en plusieurs, ça éviterait à osmose de hurler que le ref:UAI
> n'existe pas (dans la base OD qu'il utilise) alors que la ref:UAI existe
> bien, mais ailleurs...
>
> --
> deuzeffe, qui a bien envie de contacter acce pour savoir de quoi il
> retourne.
>
> ___
> 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] Chantier sur les Champs, one way

[Christian Quest]

Le côté puriste je comprends, mais toute bonne règle peut avoir des
exceptions ;)

A part se faire plaisir sur la pureté de la modélisation, ça va apporter
quoi ?

Le mer. 17 oct. 2018 à 23:01, marc marc  a
écrit :

> Oui c'est une bonne chose (tant la maj du au travaux que la fusion
> des 2 groupes de bande)
> mais il y aura bien un puriste pire que moi pour dire (ou refaire) qu'il
> faut 2 bandes vu l'obstacle entre les bandes à chaque passage piéton.
> Même si techniquement c'est exact qu'il y a une coupure de routing à cet
> endroit là, je trouve que c'est excessif (ultra micro mapping)... mais
> comme c'est pas faux, dur de faire un revert sur cela...
> et avoir une alternance de 1 et 2 way est techniquement juste mais
> horrible pour le rendu (même si on tag pas pour le rendu, faut quand
> même pas pousser un rendu horrible pour un ultra micro mapping)
>
> ceci dit faudrait juste attendre que les nouvelles bandes en travaux
> soient une réalité
>
> pour les itinéraires de bus, fusionner les 2 way pour ensuite supprimer
> les nœuds d'un des 2 ways est un moyen facile pour que les itinéraires
> de lignes de bus se mettent à jour sans effort (un bon plan est de
> résoudre leur éventuel anomalies avant de démarrer le gros chantier)
>
> Le 17. 10. 18 à 22:05, Thomas Ruchin a écrit :
> > Bonsoir
> >
> > Dans l'absolu, pas d’objection puisque c'est effectivement une unique
> > chaussée avec des refuges piétons qui sont démontés à chaque défilé
> > militaire.
> > Mais la manipulation n'est pas aussi simple à effectuer qu'il n'en
> > paraît, notamment en ce qui concerne la conservation des relations
> > (lignes de bus,..).
> > Et puisqu'on en parle, les files de circulation générale passeront de 4
> > à 3 dans chaque sens. La bande technique (taxis, livraisons, etc) dans
> > la partie haute ou le couloir de bus dans la partie basse des Champs
> > prennent déjà une une file.
> >
> > Thomas
> >
> > Le mer. 17 oct. 2018 à 13:43, Florimond Berthoux
> > mailto:florimond.berth...@gmail.com>> a
> > écrit :
> >
> > Bonjour,
> >
> > Aujourd'hui les Champs Élysée (Paris, France :) est cartographié par
> > deux highway=primary.
> > Ce qui est pour moi une erreur, l'avenue est certes large, mais
> > aucune délimitation physique ne sépare les deux sens de circulation.
> >
> > En ce moment se déroule un chantier visant la création de pistes
> > cyclables latérale séparé de la chaussée motorisé par un espace de
> > stationnement, livraison, taxis, arrêt de bus.
> > Les voies motorisés vont passer de 5 voies à 3 dans chaque sens.
> > Pour une idée, voici une vue d'artiste :
> >
> https://www.cnews.fr/france/2018-10-07/paris-les-travaux-de-la-piste-cyclable-des-champs-elysees-vont-debuter-796190
> >
> > D'où mon idée d'en profiter pour passer les voies motorisés en un
> > seul segment.
> > Je demande pour m'éviter les cris d'orfraie d'avoir osé touché à la
> > plus "belle avenue du monde".
> >
> > --
> > Florimond Berthoux
> > ___
> > 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
>


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

Re: [OSM-talk-fr] Arceaux partagés motos / vélos

[Florimond Berthoux]

Je n'avais pas remarqué qu'il y avait eu un résultat satisfaisant :
« motorcycle (noun) a vehicle with two wheels and an engine » Cambridge
Dictionary

« *Mal nommer un objet, c'est ajouter au malheur de ce monde.* » Albert
Camus.

C'est bien d'avoir une base de données cartographique libre, mais si la
donnée est de mauvaise qualité elle en devient difficile à exploiter.


Le mer. 17 oct. 2018 à 12:35, marc marc  a
écrit :

> Le 17. 10. 18 à 12:28, Florimond Berthoux a écrit :
> > on a quand un gros problème à Paris avec ça
>
> quel est le problème avec le résultat de la discussion précédente ?
>
> > Nouvelle proposition :
> > amenity=bicycle_parking;motorcycle_parking
> > Qu'en pensez-vous ?
>
> supporté par 0% des apps et rendu actuellement
> comme je sais pas ce que tu essayes de résoudre,
> j'ai pas de solution autre que ce qui a déjà été dit :)
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Chantier sur les Champs, one way

[Vincent de Château-Thierry]

Bonjour,

> De: "Christian Quest" 
> 
> Le côté puriste je comprends, mais toute bonne règle peut avoir des
> exceptions ;)
> 
> A part se faire plaisir sur la pureté de la modélisation, ça va
> apporter quoi ?

J'ai aussi du mal à voir le bénéfice. Il y a largement de quoi s'occuper sur 
Paris pour mettre à jour et densifier (les POIs par exemple) sans s'épuiser 
pour remanier un existant qui fonctionne.
Il y a par ailleurs un aspect qui n'a pas été abordé : les quartiers 
(admin_level=10). De l’Étoile au Rond-Point des Champs-Élysées - Marcel 
Dassault, la voie descendante est dans le Quartier des Champs-Élysées, la voie 
montante dans le Quartier du Faubourg-du-Roule. La frontière entre ces 2 
quartiers est l'axe central de l'avenue. Avec un tracé pour chaque sens, 
l'appartenance de chaque tronçon est non ambigüe. En fusionnant les tronçons, 
on se retrouve à superposer limites de quartier et axes routiers, ce qui 
apporte de la complexité et, à mon sens, appauvrit le niveau de détail 
géométrique, si on songe aux réutilisateurs. 

vincent

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

[OSM-talk-fr] Changesets étranges

[François Lacombe]

Bonjour à tous,

Je pense que ces changesets sont à reverter, les names sont assez subjectifs
https://www.openstreetmap.org/changeset/52265291
https://www.openstreetmap.org/changeset/52265046#map=13/44.0609/6.1159

Qu'en pensez-vous ?

Bonne journée

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chantier sur les Champs, one way

[Rpnpif]

Bonjour,

Le 18 octobre 2018, Vincent de Château-Thierry a écrit :

> Bonjour,
> 
> > De: "Christian Quest" 
> > 
> > Le côté puriste je comprends, mais toute bonne règle peut avoir des
> > exceptions ;)
> > 
> > A part se faire plaisir sur la pureté de la modélisation, ça va
> > apporter quoi ?  
> 
> J'ai aussi du mal à voir le bénéfice. Il y a largement de quoi s'occuper sur 
> Paris pour mettre à jour et densifier (les POIs par exemple) sans s'épuiser 
> pour remanier un existant qui fonctionne.
> Il y a par ailleurs un aspect qui n'a pas été abordé : les quartiers 
> (admin_level=10). De l’Étoile au Rond-Point des Champs-Élysées - Marcel 
> Dassault, la voie descendante est dans le Quartier des Champs-Élysées, la 
> voie montante dans le Quartier du Faubourg-du-Roule. La frontière entre ces 2 
> quartiers est l'axe central de l'avenue. Avec un tracé pour chaque sens, 
> l'appartenance de chaque tronçon est non ambigüe. En fusionnant les tronçons, 
> on se retrouve à superposer limites de quartier et axes routiers, ce qui 
> apporte de la complexité et, à mon sens, appauvrit le niveau de détail 
> géométrique, si on songe aux réutilisateurs. 

Puriste pour puriste, vu la largeur de cette avenue et sa célébrité, un
traçage en mode surfacique ne vous paraîtrait-il pas intéressant
area:hisghway en y ajoutant éventuellement un way pour la navigation ?

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Changesets étranges

[Julien Lepiller]

L'auteur de ces changements (il y a un an !) a commencé a supprimer son 
œuvre :


https://www.openstreetmap.org/changeset/63639151#map=14/44.0520/6.0675

Le 2018-10-18 11:56, François Lacombe a écrit :

Bonjour à tous,

Je pense que ces changesets sont à reverter, les names sont assez
subjectifs
https://www.openstreetmap.org/changeset/52265291
https://www.openstreetmap.org/changeset/52265046#map=13/44.0609/6.1159

Qu'en pensez-vous ?

Bonne journée

FRANÇOIS LACOMBE

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com [1]
@InfosReseaux [2]

Links:
--
[1] http://www.infos-reseaux.com
[2] http://www.twitter.com/InfosReseaux
___
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] Chantier sur les Champs, one way

[Florimond Berthoux]

Je pensais le monde de la cartographie plus rigoureux.

Pour ce qui concerne le surfacique, 40m de la largeur sur les 70m sont déjà
en surfacique : les grands trottoirs. ;]

La chaussée motorisée va devenir une 2x3 voies, comme rue royale ou avenue
de l'Opéra, la passer en un seul way c'est harmoniser la modélisation.
C'était clairement du tag to render, "ce sont les champs, il faut que ça
paraisse gros sur la carte", ridicule, il y a lanes pour ça.

Pour l'instant la perte qu'on risque d'avoir c'est la ligne blanche
continue médiane (hors intersection) interdisant notamment le demi tour,
j'ai cru voir une clés pour ça, mais je ne la retrouve plus.

Le jeu. 18 oct. 2018 à 12:09, Rpnpif  a écrit :

> Bonjour,
>
> Le 18 octobre 2018, Vincent de Château-Thierry a écrit :
>
> > Bonjour,
> >
> > > De: "Christian Quest" 
> > >
> > > Le côté puriste je comprends, mais toute bonne règle peut avoir des
> > > exceptions ;)
> > >
> > > A part se faire plaisir sur la pureté de la modélisation, ça va
> > > apporter quoi ?
> >
> > J'ai aussi du mal à voir le bénéfice. Il y a largement de quoi s'occuper
> sur Paris pour mettre à jour et densifier (les POIs par exemple) sans
> s'épuiser pour remanier un existant qui fonctionne.
> > Il y a par ailleurs un aspect qui n'a pas été abordé : les quartiers
> (admin_level=10). De l’Étoile au Rond-Point des Champs-Élysées - Marcel
> Dassault, la voie descendante est dans le Quartier des Champs-Élysées, la
> voie montante dans le Quartier du Faubourg-du-Roule. La frontière entre ces
> 2 quartiers est l'axe central de l'avenue. Avec un tracé pour chaque sens,
> l'appartenance de chaque tronçon est non ambigüe. En fusionnant les
> tronçons, on se retrouve à superposer limites de quartier et axes routiers,
> ce qui apporte de la complexité et, à mon sens, appauvrit le niveau de
> détail géométrique, si on songe aux réutilisateurs.
>
> Puriste pour puriste, vu la largeur de cette avenue et sa célébrité, un
> traçage en mode surfacique ne vous paraîtrait-il pas intéressant
> area:hisghway en y ajoutant éventuellement un way pour la navigation ?
>
> --
> Alain Rpnpif
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] Chantier sur les Champs, one way

[Rpnpif]

Le 18 octobre 2018, Florimond Berthoux a écrit :

> Pour l'instant la perte qu'on risque d'avoir c'est la ligne blanche
> continue médiane (hors intersection) interdisant notamment le demi tour,
> j'ai cru voir une clés pour ça, mais je ne la retrouve plus.

C'est une relation sur une jonction (facile sous Id).

type=restriction
restriction=no_u_turn

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Osmose - École non intégrée

[deuzeffe]

On 10/18/18 9:56 AM, Christian Quest wrote:

Ces mentions sont normales (même si elles datent un peu) et correspondent à
la Licence Ouverte, c'est donc tout à fait réutilisable pour OSM.


Merci pour la confirmation :)


Qu'est-ce qui est ventilé façon puzzle sur data.gouv ? Des liens seraient
utiles...


Les bases "enseignement" qu'osmose utilise pour l'OD. Par exemple :
- producteur MEN :
-- enseignement primaire (écoles maternelles et élémentaire), ici : 
https://www.data.gouv.fr/fr/datasets/adresse-et-geolocalisation-des-etablissements-denseignement-du-premier-et-second-degres/

-- enseignement secondaire (collèges et lycées) : même base

Jusque là, tout va bien.

- producteur : ONISEP
-- Enseignement supérieur : "établissements" (entre quote parce qu'il y 
manque les établissements au sens administratif du terme, voir le 
descriptif du jeu de données) : 
https://www.data.gouv.fr/fr/datasets/etablissements-denseignement-superieur-2 
()


Ce que n'utilise pas osmose :
- source MESRI
-- les rectorats : 
https://www.data.gouv.fr/fr/datasets/les-rectorats-dacademies-et-vice-rectorats/ 

-- les BU (2 jeux) : 
https://www.data.gouv.fr/fr/datasets/bibliotheques-de-lenseignement-superieur/ 
et 
https://www.data.gouv.fr/fr/datasets/services-de-documentation-et-sieges-des-bibliotheques-de-lenseignement-superieur/
-- les implantations des établissement publics d'ens. sup. avec les UFR 
(entre autres) : 
https://www.data.gouv.fr/fr/datasets/implantations-des-etablissements-denseignement-superieur-publics/
-- les principaux établissements d'ens. sup. : 
https://www.data.gouv.fr/fr/datasets/principaux-etablissements-denseignement-superieur/


Et plein d'autres bases que je n'ai pas eu le temps de chercher.

Cependant, une rapide recherche sur acce 
(http://www.education.gouv.fr/acce_public/index.php ) montre que tout ça 
y est déjà plus plein d'autres services/établissements/UA du domaine 
éducation. Soit il n'y a qu'une seule base, soit une métabase, soit...


Bref, dommage qu'on ne puisse pas intégrer (intégrer, j'ai dit !) plus 
de choses plus finement par manque d'interopérabilité (?). Même s'il 
faut de la découpe pour les fines analyses réalisées par osmose.


--
deuzeffe, archiviste ou bibliothécaire, suivant les heures.

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

Re: [OSM-talk-fr] accueil des nouveaux : la suite

[deuzeffe]

On 10/17/18 11:34 PM, Jérôme Villafruela wrote:

En attendant on peut renvoyer vers https://learnosm.org/fr/beginner qui 
a l'avantage d'expliquer l'utilisation d'iD.


Bonne idée !
--
deuzeffe

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

Re: [OSM-talk-fr] Chantier sur les Champs, one way

[Philippe Verdy]

L'interdiction du demi-tour et la ligne blanche sont implicites si on a des
ways "oneway=yes" parallèles (certes il y a un franchissement exceptionnel
possible en cas d'urgence mais c'est le cas un peu partout avec des
séparateurs qui ne sont pas totalement étanches et peuvent facilement être
ouverts, par exemple sur autoroute ou voies express il y a des zones
régulières où le terre-plain est interrompu, pas la barrière de sécurité
qui cependant peut être retirée pour les chantiers d'entretien ou en cas
d'accident).

Cela ne devrait pas empêcher pour autant de tracer du surfacique (les
Champs Elysées, ou la Place de l'Etoile sont bien assez larges pour voir
ça, ils sont bien plus larges que bon nombre de détails), à condition de ne
pas supprimer le linéaire dedans pour le routage.

A noter que les éditeurs signalent si un chemin highway=* aboutit au bord
d'une surface sans se connecter à un chemin. Si on trace une surface fermée
de type highway=* (avec area=yes) et que pour une raison ou une autre elle
est découpée, cela va perturber les routeurs: ces chemins fermés devraient
donc ne pas être tagués comme highway=* mais rester sur des traits membres
de relations surfaciques highway=* (toujours avec area=yes, c'est
normalement ce qui doit se produire quand on découpe un chemin fermé en
plusieurs chemins: les tags de l'ancien chemin fermé sont transférés dans
la nouvelle relation créée et supprimés des chemins non fermés restants.

Cependant ce découpage crée par défaut une relation de "type=multipolygon",
et y supprime "area=yes" (redondant, pourtant nécessaire pour les zones
piétonnes avec highway=pedestrian). On aura un multipolygone (de surface)
avec le tag "highway=*" mais "area=yes" devrait y être conservé pour éviter
l'ambiguité avec les highways linéaires qui les traverse (de la même façon
que le linéaire des cours d'eau waterway=* traversent le surfacique des
"water=riverbank").

Avant de faire ça sur une zone aussi utilisée et détaillée que les Champs
Elysées, je pense qu'il vaut mieux tester dans des zones moins sensibles et
voir comment se comportent les outils (car il faudra faire des ajustements
multiples), et pas seulement le rendu (qui lui ne devrait poser aucun
problème), dont notamment les outils d'analyse qualité, le routage, les
restrictions d'accès et de direction, etc.

Mais un jour ou l'autre on devra y venir à cette représentation surfacique
et gérer en douceur la compatibilité avec le linéaire. Le premier besoin
sera justement pour les rues les plus larges et ayant une foule de détails
(de plus en plus difficiles à représenter correctement même avec les
"lanes" uniquement, ce qui conduit à un surdécoupage du linéaire et une
complexité croissante, mais on ne pourra pas facilement modéliser les
limites de vitesse et interdictions de tourner via le surfacique, ni non
plus les directions des voies à moins de tracer un linéaire aussi pour
chaque voie et faire comprendre à un algorithme de navigation qu'il peut
passer d'une voie à l'autre... sans franchir une ligne continue entre les
voies !).

Le jeu. 18 oct. 2018 à 14:44, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

> Je pensais le monde de la cartographie plus rigoureux.
>
> Pour ce qui concerne le surfacique, 40m de la largeur sur les 70m sont
> déjà en surfacique : les grands trottoirs. ;]
>
> La chaussée motorisée va devenir une 2x3 voies, comme rue royale ou avenue
> de l'Opéra, la passer en un seul way c'est harmoniser la modélisation.
> C'était clairement du tag to render, "ce sont les champs, il faut que ça
> paraisse gros sur la carte", ridicule, il y a lanes pour ça.
>
> Pour l'instant la perte qu'on risque d'avoir c'est la ligne blanche
> continue médiane (hors intersection) interdisant notamment le demi tour,
> j'ai cru voir une clés pour ça, mais je ne la retrouve plus.
>
> Le jeu. 18 oct. 2018 à 12:09, Rpnpif  a écrit :
>
>> Bonjour,
>>
>> Le 18 octobre 2018, Vincent de Château-Thierry a écrit :
>>
>> > Bonjour,
>> >
>> > > De: "Christian Quest" 
>> > >
>> > > Le côté puriste je comprends, mais toute bonne règle peut avoir des
>> > > exceptions ;)
>> > >
>> > > A part se faire plaisir sur la pureté de la modélisation, ça va
>> > > apporter quoi ?
>> >
>> > J'ai aussi du mal à voir le bénéfice. Il y a largement de quoi
>> s'occuper sur Paris pour mettre à jour et densifier (les POIs par exemple)
>> sans s'épuiser pour remanier un existant qui fonctionne.
>> > Il y a par ailleurs un aspect qui n'a pas été abordé : les quartiers
>> (admin_level=10). De l’Étoile au Rond-Point des Champs-Élysées - Marcel
>> Dassault, la voie descendante est dans le Quartier des Champs-Élysées, la
>> voie montante dans le Quartier du Faubourg-du-Roule. La frontière entre ces
>> 2 quartiers est l'axe central de l'avenue. Avec un tracé pour chaque sens,
>> l'appartenance de chaque tronçon est non ambigüe. En fusionnant les
>> tronçons, on se retrouve à superposer limites de quartier et axes routiers,
>> ce qui apporte de la complex

[OSM-talk-fr] Relation de riviere, Le Rhone

[François Lacombe]

Bonsoir,

Une petite question sur les deux relations qui qualifient Le Rhône :
La 1ere pour sur le filaire river :
https://www.openstreetmap.org/way/34907146
La 2nd sur le riverbank, un multipolygon sur tout le court du fleuve :
https://www.openstreetmap.org/relation/660056

Je ne comprends pas l'intérêt de la deuxième.
Ne faudrait-il pas mettre le wikidata sur la 1ere relation et supprimer la
2nde pour ne laisser que des polygones riverbanks continus sans relation ?

On dirait que ça met le bazar sur des rendus comme Positron :
https://www.maptiler.com/maps/#positron//vector/15.12/5.81699/46.054843
(même si on ne tag pas pour le rendu)

Merci par avance pour vos retours, bonne soirée

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

Re: [OSM-talk-fr] Changesets étranges

[Jean-Christophe Becquet]

Le 18/10/2018 11:56, François Lacombe a écrit :
> Je pense que ces changesets sont à reverter, les names sont assez subjectifs
> https://www.openstreetmap.org/changeset/52265291
> https://www.openstreetmap.org/changeset/52265046#map=13/44.0609/6.1159
> 
> Qu'en pensez-vous ?

Bonjour,

François, tu as raison bien sûr.

Comme je suis sur place, je peux donner un peu de contexte. Il y a
actuellement une réflexion (des élus, des associations...) sur l'avenir
de cette voie ferrée désaffectée depuis plusieurs années. Certains
souhaitent une remise en service du train. D'autres l’aménagement d'une
voie verte pour les cyclistes. Ceux qui soutiennent le train craignent
que la voie verte acte le renoncement à la réouverture de la voie pour
le train.

Quoi qu'il en soit, cretinus alpinae utilise OSM comme espace
d'expression "citoyenne" et je suis d'accord que c'est à reverter.

J'ai le même problème dans une moindre mesure avec les contributeurs qui
nomment les sentiers "accaparé", je suppose pour signifier qu'il y a des
obstacles pour les emprunter. C'est ce que fait cretinus alpinae mais
aussi troghoutsk. J'avais laissé un message sur un des changesets mais
je ne sais pas le retrouver.

Y a t-il un moyen de retrouver les changesets sur lesquels j'ai laissé
un message ?

Je précise que je ne connais malheureusement pas ces contributeurs.
troghoutsk, notamment fait un  travail conséquent et souvent pertinent
autour de Digne.

Bonne journée

JCB
-- 
Un courrier de sensibilisation des acteurs locaux par jour dans les
Alpes du sud
http://www.apitux.org/index.php?2008/03/01/215-un-courrier-de-sensibilisation-des-acteurs-locaux-par-jour-dans-les-alpes-du-sud

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===


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

Re: [OSM-talk-fr] Piscine municipale vs piscine privée

[Paul Desgranges]

Bonjour,
Je n'avais peut-être pas compris le sens du mail de Noémie, et je 
cherche ci-dessous à le ré-exprimer, voir si on est d'accord :


L'idée principale consiste à transformer les "amenity=swimming_pool"
    soit en "leisure=sports_centre + sport=swimming",
    soit en "leisure=swimming_pool"

Et ceci suivant les heuristiques suivantes :

1) Par exemple on peut transformer
    les "amenity=swimming_pool + name=*" 
 en "leisure=sports_centre + 
sport=swimming"
et les "amenity=swimming_pool + name!=*" 
 en "leisure=swimming_pool"
car effectivement quand il y a un nom, c'est un "sports_centre" et quand 
il n'y a pas de nom, c'est un simple bassin.


2) Autre exemple on peut transformer
    les "amenity=swimming_pool + building=yes" 
 en "leisure=sports_centre + 
sport=swimming + building=yes"
car quand il y a aussi un building, c'est un "sports_centre". A noter 
que 1) et 2) vont se recouvrir en partie.


3) Il y a des heuristiques sur la taille aussi comme disait Jérôme:
 Quand c'est "petit", c'est plutôt un bassin.
 Quand c'est "grand", c'est plutôt  un sports_centre
Mais là, a-t-on la possibilité de faire une requête overpass turbo pour 
les sélectionner sur ce critère de taille?



D'autre part, si les "amenity=swimming_pool" sont à éliminer, on peut 
aussi transformer :
    les "leisure=swimming_pool + building=yes" 
 en "leisure=sports_centre + 
sport=swimming + building=yes"
 car les piscines qui sont aussi des buildings sont en fait des 
"sports_centre". Les contributeurs ont taggué par erreur en "bassin" ce 
qui plutôt des "sports_centre".



Et les transformations ci-dessus seraient à faire avant de faire celles 
relatives à "covered" (et qui qui sont discutées dans l'autre mail ?)


Voilà, y-a-t-il des erreurs ? Est-ce plus clair ?

Paul




Le 15/10/2018 à 23:04, Paul Desgranges a écrit :

Bonsoir,

>Le 14. 10. 18 à 22:12, Paul Desgranges a écrit :
>>/Un truc en plus, le terme 'piscine' de manière générale peut signifier à />>/la fois le bassin, le bâtiment, mais aussi le 
complexe sportif : />>/ - "leisure=swimming_pool" seul, donc ça serait le bassin, mais 
/>>/"leisure=swimming_pool" + "building=yes" là on parlerait du 'bâtiment />>/piscine'  (le bassin est alors 
parfois à l'extérieur) />
>cette interprétation me semble erronée.
>leisure=swimming_pool est selon moi clairement définit comme étant le bassin.
>"leisure=swimming_pool" + "building=yes c'est donc un bassin "couvert" 
>par un bâtiment. c'est assez rare mais j'en connais un : je suis passé 
>plusieurs fois devant en me demandant si c'était un garage entière vitré 
>ou une serre en dur... avant d'un jour apercevoir que l'intérieur est 
>entièrement constitué d'un bassin d'eau (piscine privé).

> si le bassin n'est pas dans le bâtiment, il faut selon moi 2 objets.

Ce n'est pas rare du tout :-) il y en a des centaines, si je l'ai dit c'est que 
j'avais regardé avant.
Je ne suis pas passé devant ;-) j'ai regardé icihttps://overpass-turbo.eu/s/CMB   
Les contributeurs ont assez largement utilisé cette façon pour mapper les piscines-bâtiments (bâtiments qui contiennent une piscine).

C'est effectivement une interprétation erronée, mais certainement pas de moi, 
des contributeurs plutôt
qui auraient dû mapper ça comme ça : "leisure=sports_centre" + "sport=swimming"
Ce que je voulais dire par => on a souvent le cas : "leisure=sports_centre" + "sport=swimming" = 
"leisure=swimming_pool" + "building=yes"


>Salut,
>
>Du coup, je pense qu'on peut imaginer un plan d'action comme ça :
>- modification massive de amenity=swimming_pool vers 
> leisure=swimming_pool comme proposé par Marc
>- analyse Osmose qui vérifie la taille des leisure=swimming_pool et 
>remonte un signalement quand c'est vraiment trop grand (en utilisant la 
>formule de Jérôme)
>- mission maproulette pour identifier des leisure=swimming_pool qui 
>devraient en fait être des leisure=sports_centre

>
>Pour le dernier point, j'ai l'impression qu'en cherchant les 
>leisure=swimming_pool qui ont un tag name, on tombe principalement sur 
>des éléments mal taggés qui devraient être des sports_centre, on doit 
>pouvoir broder autour de ça pour Maproulette, même si on aura quelques 
>faux positifs.

Oui, dans les trois cas ci-dessus on peut en trouver beaucoup déjà avec 
"leisure=swimming_pool" + "building=yes"

>
>Qu'en dites-vous ?

Bien d'accord !
  
  --

Noémie Lehuby
Donc l'idée




___
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] Piscine municipale vs piscine privée

[Paul Desgranges]

Oui, une façon de tagguer ces piscines tournesols ou à toits 
rétractables (qui sont ni location=indoor et ni location=outdoor) est en 
plus nécessaire, mais
 ceci ne doit pas nous empêcher de mapper la très grande majorité de 
piscines qui sont soit des piscines indoor, soit des piscines outdoor ...


Il faut voir si on arrive à se mettre d'accord sur le sens de "covered" 
pour les piscines ?
La proposition serait de réserver l'attribut "covered" aux bassins de 
piscines, et de lui faire signifier la présence ou pas d'un abri-piscine:
 c'est à dire qu'on réserverait ça aux piscines-bassins 
(leisure=swimming_pool),
  et donc que ça n'aurait pas lieu d'être sur les piscines-bâtiments 
(leisure=sports_centre + sport=swimming)

Dans cette logique, il faudrait transformer :
    les "leisure=sports_centre + sport=swimming + covered=yes" 
 en "leisure=sports_centre + 
sport=swimming + location=indoor"
et les "leisure=sports_centre + sport=swimming + covered=no" 
  en "leisure=sports_centre + 
sport=swimming + location=outdoor"



Mais ceci serait à faire après la transformation (discutée par Noémie, 
Marc, Jérôme, ...) qui consisterait à transformer les 
"amenity=swimming_pool" soit en "leisure=sports_centre + 
sport=swimming", soit en "leisure=swimming_pool" suivant quelques 
heuristiques, voir l'autre fil de discussion ...


Paul


Le 16/10/2018 à 13:50, Philippe Verdy a écrit :
C'est un modèle assez courant de piscine fermé à toit mobile. J'en 
avais déjà parlé avant


Le mar. 16 oct. 2018 à 09:35, Christian Quest > a écrit :


Désolé, je vais casser l'ambiance en sortant ma "piscine tournesol":


https://2.bp.blogspot.com/-mhCVrMV3K-8/UX2VXYXJUgI/A0g/fwvAWxZV4rI/s1600/Nangis_2.jpg

;)


Le mar. 16 oct. 2018 à 09:17, Paul Desgranges
mailto:desgranges.p...@laposte.net>>
a écrit :

Là-aussi je me suis mal fait comprendre peut-être alors je
vais essayer de faire mieux (puisqu'on est dans les piscines
)

A propos de indoor/outdoor et covered=yes/no, il y a aussi
plusieurs façons de faire actuellement. En tout cas si on
parle de "leisure=swimming_pool" (donc pour les piscines de
type "bassin")
    1. le bassin peut être à l'intérieur ou à l'extérieur, pas
trop de confusion possible
    - bassin intérieur => "location=indoor" : pas visible par
photo aérienne, on est dans un bâtiment, c'est du mapping
indoor, (mais il y en a des mappés comme ça )
    - bassin extérieur => "location=outdoor" : visible par
photo aérienne, ça pourrait être la valeur par défaut, mais
c'est plus explicite qd ça y est

   2. le bassin peut être "couvert" ou pas. De manière
générale, en dehors d'OSM, quand on dit "bassin couvert" on
veut dire "bassin intérieur" et "bassin découvert" on veut
dire bassin extérieur, donc il y a une confusion possible et
on peut la constater dans les faits.
    Actuellement "covered=yes" a été employé manifestement
dans différents cas :
    - Soit le contributeur a voulu signifier que la piscine
était "couverte" au sens bassin intérieur
    - Soit le contributeur a voulu signifier que la piscine
était "couverte" au sens la piscine dispose d'un "abri
piscine" (on distingue bien ces abris en photographie
aérienne), les piscines privées dans les jardins, avec un abri
pour : sécurité chute, déperdition d'énergie, feuilles mortes,
etc.
    Et "covered=no" est assez employé, mais dans quelle
intention a été utilisé ce tag, s'agit-il d'un bassin
extérieur, ou s'agit-il d'un bassin ne disposant pas d'abri ?
Pas forcément clair.

  Alors comment documenter ces 2 attributs
("location=indoor/outdoor" et "covered=yes/no") pour que
l'usage en soit clair ?

Bonne journée
Paul


-- 
Christian Quest - OpenStreetMap France

___
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] Changesets étranges

[Antoine Riche]

Le 19/10/2018 à 07:25, Jean-Christophe Becquet a écrit :

Y a t-il un moyen de retrouver les changesets sur lesquels j'ai laissé
un message ?


Le site https://hdyc.neis-one.org/ de Pascal Neis inclut une rubrique 
"Changeset discussions", avec un lien qui liste les commentaires créés.


Antoine.


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

Re: [OSM-talk-fr] Changesets étranges

[Jean-Christophe Becquet]

Le 19/10/2018 08:48, Antoine Riche a écrit :
> Le 19/10/2018 à 07:25, Jean-Christophe Becquet a écrit :
>> Y a t-il un moyen de retrouver les changesets sur lesquels j'ai laissé
>> un message ?
> 
> Le site https://hdyc.neis-one.org/ de Pascal Neis inclut une rubrique
> "Changeset discussions", avec un lien qui liste les commentaires créés.

Merci Antoine !

Il s'agissait donc du changeset suivant, commentaire resté sans réponse
https://www.openstreetmap.org/changeset/55099941

JCB
-- 
Debian GNU-Linux
http://www.apitux.org/index.php?2006/07/10/15-debian-gnu-linux

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
BP 32 - 04001 Digne-les-Bains Cedex
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===

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