Re: [OSM-talk-fr] PLU et copie des informations

[Christian Quest]

Un peu de droit ;)

1) les PLU sont des documents administratifs, car produits par les
collectivités
2) les informations qu'ils contiennent sont réutilisables, librement... il
faut citer source et millésime
3) ils peuvent comporter des éléments non réutilisables (par exemple à
cause de propriété intellectuelle détenue par des tiers), dans ce cas ceci
doit être indiqué
(cas typique, les fonds de carte IGN utilisés)

ça c'est la loi qui le dit... et pas obligatoire de le préciser via une
politique opendata affichée, mais c'est vrai que c'est plus clair
d'indiquer une licence pour clarifier les choses.

Je ne vois vraiment pas d'obstacle à utiliser les informations présentes
dans les PLU, sauf là où il est clair qu'il y a un copyright.

Le mar. 18 sept. 2018 à 14:49, FR  a écrit :

> Mais de quelles données s'agit-il ?
> Celles fournies par les planches du PLU, ou celles des annexes texte ?
>
> Mes doutes portent en l’occurrence sur le PLU de Marseille, qui dans son
> annexe 3 liste une série de bâtiments remarquables issues d'une compilation
> d'ouvrages en citant ses sources:  ouvrages d'historiens de l'architecture,
> études de la DRAC PACA et de l'atelier du patrimoine de Marseille, ces 2
> institutions n'étant pas précisément réputées dans le domaine de l'Open
> Data
> [1].
> Par ailleurs le site Marseille-Provence qui permet d’accéder au PLU ne fait
> nulle part mention d'une politique d'Open Data...
>
> On serait dans Wikipedia on pourrait s'en sortir avec le droit de citation.
> Mais dans OSM 
>
> D'autres avis ?
>
> FR
>
>  [1]
>
> http://www.marseille-provence.fr/index.php/documents/docplu/mrs/opposable-mrs-1/reglement-mrs-1/3255-reglement-tome-3-mrs/file
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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] Camion pizza

[Christian Quest]

marketplace n'est vraiment pas fait pour ça, on détournerai beaucoup trop
le sens de ce tag.

amenity=fast_food m'a l'air bien plus cohérent, avec un opening_hours


Le mar. 18 sept. 2018 à 13:10, Eric Brosselin - Osm 
a écrit :

> *Le 18/09/2018 à 08:30, Jean-Christophe Becquet a écrit :*
>
> *Est-ce que :
>
> amenity=fast_food
> cuisine=pizza
>
> vous semble la bonne description pour un camion qui vend des pizzas à
> emporter ?*
>
> Bonjour,
>
> Pourquoi ne pas utiliser "amenity=marketplace" ?
> Ce tag décrit lorsqu'il est associé à "building" un bâtiment "en dur",
> mais aussi un emplacement où certains jours à certaines heures
> des commerces mobiles sont présents.
>
> Cela donnerait:
>
> - amenity=marketplace
> - foodtruck=yes  => là il faudrait inventer quelque chose pour
> préciser le type de commerce
> - cuisine=pizza   => type de cuisine
> - opening_hours=* => pour préciser les jours et heures de présence
> - takeaway=yes  => yes pourrait apparaître implicite mais il
> est parfois possible de manger sur place
> Dans ce cas on pourrait rajouter
> - outdoor_seating=yes=> qui indiquerait que l'on peut manger sur place
> - takeaway=only => s'il n'y a pas de possibilités de manger
> sur place et qu'on puisse uniquement emporter ce que l'on achète
>
> Après il suffit de placer le POI au bon endroit sur un parking ou bord de
> route et de cartographier les alentours ;-)
> ___
> 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] nouveau champ takeaway:lunchbox

[Christian Quest]

Un tag pour les ventes de vrac: bonne idée et bulk_purchase semble déjà
documenté

Un tag pour les "doggy bag": bonne idée, proposition à faire sur le wiki,
car c'est vraiment international

Un doggy_bag=no/yes/fee/free me semblerai plus universel que "lunchbox"
(d'où le besoin de discussion internationale).
fee/free car dans certains restaurants on fait payer l'emballage (j'ai au
moins un exemple).

Le mar. 18 sept. 2018 à 12:53, marc marc  a
écrit :

> autant lunchbox a une connotation "boite à tartine" (je m'attend à ce
> que cela parle d'une épicerie qui vend des sandwich à emporter)
> autant bulk_purchase a un côté "bulk" cad de masse, je m'attends
> à ce que la magasin de boisson vende le bvin en tonneau.
> hors les magasins zéro déchet n'ont souvent aucun lien ni avec le type
> de produit (il y en a bien sur qui vende de la nourriture mais il y a
> aussi des cosmétiques, des produits d’entretien, ...) ni avec le volume
> (tu peux acheter 50gr de noix ou 5l de produit de vaisselle)
>
> Le 18. 09. 18 à 12:07, Julien Coupey a écrit :
> > Bonjour,
> >
> > Je ne sais pas si c'est exactement ce que tu souhaites décrire, mais il
> > y a déjà bulk_purchase[1] qui semble approprié.
> >
> > Il est déjà utilisé pour les épiceries « en vrac » qui fleurissent
> > ici[2] ou là[3].
> >
> > À +
> > Julien
> >
> > [1] : https://wiki.openstreetmap.org/wiki/Key:bulk_purchase
> > [2] : https://www.openstreetmap.org/node/5618249615
> > [3] : https://www.openstreetmap.org/node/5867522816
> >
> > On 18/09/2018 11:20, Vivien MICHON wrote:
> >> Bonjour,
> >>
> >> Je propose la possibilité d’indiquer les commerces acceptant que le
> >> client vienne avec son propre contenant (de type boîte fermable et
> >> réutilisable).
> >>
> >> Cette pratique est de plus en plus courante, afin d’éviter
> >> l’utilisation de boîtes ou papiers jetables (zéro déchet).
> >>
> >> Elle est possible en vente à emporter dans un nombre croissant de
> >> restaurants, traiteurs, boucheries, fromageries…
> >>
> >> Je propose ainsi le nouveau champ « takeaway:lunchbox », indiqué en
> >> YES ou NO.
> >>
> >> Le terme « lunchbox » fait référence à la boîte contenant le déjeuner,
> >> qui peut être utilisée à toute heure, pour tout type d’achat. Le terme
> >> indique également qu’il s’agit de nourriture.
> >>
> >> exemple : https://www.openstreetmap.org/node/5130551429
> >>
> >> Merci d’avance pour vos commentaires.
> >>
> >>
> >>
> >> ___
> >> 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] Les bretelles

[Philippe Verdy]

encore une fois OSM n'est pas un bac à sable où on peut décider tout seul
de changer des tags abondamment utilisés et briser les règles
d'uniformisation. Si le but est de changer le rendu il vaut mieux en
discuter avec ceux qui maintiennent ces rendus pour modifier quelques
règles d'analyse des données. Cette analyse est possible et déjà faite par
exemple dans Osmose qui signale les incohérences.

Le mer. 19 sept. 2018 à 00:23, djakk djakk  a écrit :

> Bon link_to et link_from ça ne marche pas, j’ai essayé !
>
> J’ai voulu tagger les bretelles autrement car je vois chaque bretelle
> faisant partie d’un itinéraire “trunk”, “primary” ou “secondary” - la
> valeur de la route croisée par la route principale, dans les cas les plus
> simples. De ce point de vue, la bretelle ne fait pas partie de la route
> principale.
>
> Je remarque que les bretelles d’accès aux centres commerciaux sont taggées
> de ce point de vue (avec highway=service) par les contributeurs. Exemples :
> https://www.openstreetmap.org/#map=18/48.13893/-1.69541
> Https://www.openstreetmap.org/#map=17/48.14052/-1.76931
> https://www.openstreetmap.org/#map=18/47.69694/-0.87364
>
>
> djakk
>
>
> Le mar. 18 sept. 2018 à 11:20, djakk djakk  a
> écrit :
>
>> Oui, aussi.
>>
>>
>> djakk
>>
>> Le mar. 18 sept. 2018 à 11:17, Rpnpif  a écrit :
>>
>>> Le 18 septembre 2018, djakk djakk a écrit :
>>>
>>> > Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu
>>> > n'écrives ce mail :
>>> > https://www.openstreetmap.org/changeset/62524278
>>> >  :O
>>> >
>>>
>>> Une explication ne signifie pas accord de celui qui la reçoit.
>>>
>>> --
>>> Alain Rpnpif
>>>
>>> ___
>>> 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] Changement unilatéral de la définition de tags

[Philippe Verdy]

Je lui ai déjà demandé d'expérimenter ses propositions dans uMap où il peut
importer facilement des listes de noeuds communaux et les classer dans une
feuille de calcul, où il pourra aussi utiliser rapprocher les données des
zonages urbains, d'emploi et de vie de l'INSEE, ajouter les populations
INSEE, créer des catégories, et importer ces listes par groupes
sélectionnables dans uMap (avec quelques attributs "maison")

Cela permet alors de faire des sous-sélections facilement sélectionnables
dans uMap pour avoir une idée de la densité et des seuils à adopter pour la
visibilité, et éeventuellementr alors proposer une révision de nos seuils
(on note que l'INSEE a respecté les conditions minimales de classification
européenne mais a du distinguer non pas 2 mais 4 catégories d'urbanisation
pour la France qui sinon aurait plus de 90% de son territoire couvert
d'espace rural sans aucune "ville" au sens européen où la densité est très
différente, notamment entre Europe centrale et du Nord, et celle du "sud"
où la population est très inégalement répartie avec des très grosses
agglomérations centrales comme en Grèce, en France et en Espagne et Italie,
seulement limitées par le relief qui tend à les densifier davantage sur un
territoire parfois exigu cerné de longs rayons le long de quelques
corridors étroits et sinon à créer de très grands bassins quasi circulaires
absorbant le monde rural avec des banlieues de plus en plus grandes)

Le zonage INSEE fourni dans ses chapitres d'introduction des cartes
sommaires qui donnent une idée de ce zonage (et de l'historique de leur
conception et évolutions) avant même de rentrer dans le détail communal
(parfois aussi infracommunal pour les communes multicentrées qui se sont
multipliées maintenant avec les "communes nouvelles" qui ne sont pas
devenues pourtant par magie des "villes" par le fait que leur population a
atteint ou dépassé les 15 000 habitants sur un territoire démesurément
élargi).


Sujet complémentaire:

Ce zonage fournit aussi des données assez surprenantes, notamment pour la
Guyane avec un gros espace classé comme "urbain" dans la moitié ouest de
l'immense zone forestière et fluviale, dans une zone classée comme "réserve
naturelle": sur une base stricte de décompte de population par le
recensement, il a du être tenu compte des populations indigènes itinérantes
et des nombreux migrants (illégaux) venant du Surinam, de ceux qui vivent
dans les exploitations forestières ou minières ou de la population
d'entrainement des armées, ainsi que des nouveaux migrants légaux qui y ont
trouvé refuge pour réadopter localement une vie agricole en villages
communautaires (par exemples les réfugiés venus d'Asie du Sud-Est).
Cependant cela révèle qu'OSM est presque désert en données dans ce coin, et
le classement "urbain" ne dégage aucune concentration urbaine et pas plus
le découpage administratrif qui semble être très insuffisant pour couvrir
ces populations très mobiles qui vivent et bougent constamment le long des
fleuves (qui remplacent largement nos routes en métropole et dans les
autres DOM-ROM) et ne pas prendre en compte les communautés villageoises
traditionnelles pourtant très peuplées et sans doute trop peu représentées
dans la hiérarchie administrative: il y a sans doute des tas de communes à
créer en subdivisant les communes existantes, et à doter de structures de
fonctionnement et une économie adaptées à leur mode de vie plus coutumier,
autrement que par la seule visite épisodique de l'armée ou la gendarmerie
et de quelques élus restés sur le littoral guyanais et méconnaissent le
territoire dont ils ont théoriquement la charge des populations.

L'actuelle "commune" guyanaise de Maripasoula ne semble visiblement pas du
tout adaptée à prendre en compte ces populations visiblement bien plus
nombreuses que ce à quoi on s'attend et à les protéger ou les doter en
services adéquats et devrait être divisée en villages, au moins le long des
axes fluviaux et la question se pose aussi pour sa voisine Camopi (côté est
longeant le Brésil mais dans une région amazonienne encore plus difficile
d'accès), quitte à les transformer chacune en communes nouvelles mais avec
des conseils locaux représentatifs dans les communes déléguées fonctionnant
avec des conseils locaux plus traditionnels, et des aides pour les doter de
services minimums autres qu'un petit aérodrome, d'un service public de
transport fluvial à défaut de routes maintenables, et de services de santé
et d'éducation de proximité, et une justice coutumière reconnue avec des
formations adaptées au terrain et à la médiation commerciale et agricole,
et aussi reconnaitre un mode d'urbanisation très différent par des cases ou
des habitations flottantes autour de quelques ports d'amarrage reliés aux
rares aérodromes par des pistes un peu entretenues circulables au moins en
moto ou véhicules forestiers (il ne s'agit sans doute pas de balafrer la
forêt par la construction de grands axes routiers et mettre en cause le
mode 

Re: [OSM-talk-fr] Josm, imagerie aérienne, lenteur ou bug

[Vincent Privat]

Ah ben c'est déjà corrigé, vous pouvez le remercier :)
Effectivement ça avait été introduit en mai dernier.
Détails ici: https://josm.openstreetmap.de/ticket/14562

Le mar. 18 sept. 2018 à 23:01, Vincent Privat  a
écrit :

> Y'a trois tickets en cours sur ce sujet:
> https://josm.openstreetmap.de/ticket/16734
> https://josm.openstreetmap.de/ticket/16743
> https://josm.openstreetmap.de/ticket/16747
>
> Wiktor est dessus.
>
> A+
> Vincent
>
> Le mar. 18 sept. 2018 à 13:19, Julien Lepiller  a écrit :
>
>> Le 2018-09-18 12:12, Stéphane Péneau a écrit :
>> > Hello !
>> >
>> > Depuis quelques semaines, ou mois, j'ai la sensation que l'affichage
>> > des images aériennes dans Josm a un comportement un peu bizarre.
>> >
>> > J'ai l'impression qu'il y a 2 problèmes, 1 dans Josm, et 1 autre avec
>> > la BD Ortho de l'Ign :
>> >
>> > - Dans Josm, je peux avoir un affichage correct, puis pendant un
>> > déplacement de l'affichage, me retrouver avec des tuiles pixelisées
>> > qui s'affichent par dessus d'autres tuiles en bonne qualité.
>>
>> Je confirme ce point, et pas uniquement sur la bdortho : ça me le fait
>> sur toutes les imageries, ce qui est particulièrement pénible en 4G dans
>> un train, puisqu'il faut attendre d'avoir une connexion pour que JOSM
>> télécharge de nouveau les tuiles alors qu'il les connaissait.
>>
>> > - En parallèle, et ce n'est pas permanent, la console de Josm
>> > m'affiche un nombre assez conséquent d'erreurs 404 et/ou 509 avec
>> > proxy-ign.openstreetmap.fr. Par exemple, hier matin.
>>
>> Là je ne sais pas.
>>
>> >
>> > Oui, ça fait beaucoup de conditionnel et de ressenti. Avant de creuser
>> > plus loin, j'aimerais savoir si je suis le seul dans cette situation,
>> > ou si c'est assez généralisé.
>> >
>> >
>> > Stf
>> >
>> >
>> > ___
>> > 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] Les bretelles

[djakk djakk]

Bon link_to et link_from ça ne marche pas, j’ai essayé !

J’ai voulu tagger les bretelles autrement car je vois chaque bretelle
faisant partie d’un itinéraire “trunk”, “primary” ou “secondary” - la
valeur de la route croisée par la route principale, dans les cas les plus
simples. De ce point de vue, la bretelle ne fait pas partie de la route
principale.

Je remarque que les bretelles d’accès aux centres commerciaux sont taggées
de ce point de vue (avec highway=service) par les contributeurs. Exemples :
https://www.openstreetmap.org/#map=18/48.13893/-1.69541
Https://www.openstreetmap.org/#map=17/48.14052/-1.76931
https://www.openstreetmap.org/#map=18/47.69694/-0.87364


djakk


Le mar. 18 sept. 2018 à 11:20, djakk djakk  a écrit :

> Oui, aussi.
>
>
> djakk
>
> Le mar. 18 sept. 2018 à 11:17, Rpnpif  a écrit :
>
>> Le 18 septembre 2018, djakk djakk a écrit :
>>
>> > Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu
>> > n'écrives ce mail :
>> > https://www.openstreetmap.org/changeset/62524278
>> >  :O
>> >
>>
>> Une explication ne signifie pas accord de celui qui la reçoit.
>>
>> --
>> Alain Rpnpif
>>
>> ___
>> 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] bac a sable pour les tests

[marc marc]

Le 18. 09. 18 à 23:25, Jérôme Seigneuret a écrit :
 > J'ai demandé si l'on pouvait en mettre un en place
 >  pour des projets et des tests de comparaison sur la liste dev
 > peut être tech est plus approprié.

tech est plus approprié si tu penses que l'asso osm-fr
devrait le faire ou te renseigner pour le faire :)
mais la ml dev aurait du normalement fournir des infos utiles :(

 > @marc marc on a la possibilité de mettre ça en place ou
 > vous avez une doc pour mettre un serveur en place "from scratch"

il y a 2 solutions :
- soit utiliser l'existant :) dev.api permet déjà l'utilisation bac
à sable. le seul soucis c'est que le bac est quasi vide et donc
pour faire un test de renommage d'une clef sur le réseau routier 
français, il faut commencer par importer le dit-réseau
(sélection avec overpass dans josm, dupliquer les données dans une 
nouvelle couche, envoyer le tout vers "dev.api").
c'est facile pour les données de taille limitée mais galère
si tu veux tester à l'échelle du pays.
- soit une créer une nouvelle bdd ou on pourrait imaginer importer
une extract france par ex.
pour cela 2 solutions : soit utiliser les config chef utilisé par 
osm.org soit les refaire en mode ansible utilisé par osm.fr

 > et ainsi s'en servir pour présenter aussi des cas d'étude
 > sur du routing ou du géocodage.

c'est là que cela coince : dev.api n'est rien d'autre que la bdd
et le script web qui interagit avec.
mettre UN serveur en place c'est facile mais il n'y a pas de rendu
de cette base, pas de routing, de nominatim, pas d'overpass.
hors osm c'est pas UN c'est plein d'outils annexes parfois nécessaire.
cela voudrait dire mettre en place ces outils annexes avec
les données du bac à sable.
et là le soucis, avis purement personnel, c'est les bras :
osm.fr a tellement d'outil qui attendent des bras pour progresser,
ce n'est peut-être pas prioritaire de faire un bac à sable.
Mais si des bras sont motivés pour le faire, je suis dispo pour aider.
C'est évidement conditionné à l'avis positif de l'asso,
je parle en mon nom propre, j'aide un peu l'asso au niveau technique
mais je ne parle pas en son nom.
ceci dit d'autres demandes semblable ont été acceptée,
sous réserve de bras pour le faire :)

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

Re: [OSM-talk-fr] Changement unilatéral de la définition de tags

[djakk djakk]

Le sourire était plutôt crispé j’aurai dû mettre :-] !

djakk

Le mar. 18 sept. 2018 à 23:26, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

>
>
> Le mar. 18 sept. 2018 à 23:03, marc marc  a
> écrit :
>
>> djakk n'est pas un bleu même s'il est rarement aussi actif ici :)
>>
> Maoui! Il est même plus ancien contributeur que moi! Ben désolé mais en
> effet c'est pas un novice ce qui n'étonne d'autant plus.
>
> @djakk fait de l'humour dans ces changeset
> *(ne pas expérimenter ici en fait :) )*
> 
>
> Ben c'est pas un bac à sable donc non... J'ai demandé si l'on pouvait en
> mettre un en place pour des projets et des tests de comparaison sur la
> liste dev mais je pense pas avoir ciblé la bonne liste peut être tech est
> plus approprié.
> @marc marc  on a la possibilité de mettre ça
> en place ou vous avez une doc pour mettre un serveur en place "from
> scratch". Le but c'est d'avoir une image et de faire les test dessus.
> Pouvoir faire des modif dessus sans impacté le système en place et ainsi
> s'en servir pour présenter aussi des cas d'étude sur du routing ou du
> géocodage.
>
> Merci
>
>
>
>
> Cordialement,
> Jérôme Seigneuret
> ___
> 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] Changement unilatéral de la définition de tags

[djakk djakk]

Oui Marc j’ai pensé sournoisement à la mauvaise fois mais l’envie de
travailler sérieusement prend le dessus très très vite :) Explications
après le prochain paragraphe. (Oui la valeur trunk est pourrie il faudrait
peut être dire huge)

Normalement j’avais mis la bonne source pour la clé traffic (données venant
de chaque département - j’ai supposé que c’est copiable pour osm, ai-je bon
?)

Voilà ce que j’ai répondu à Stereo du Data Working group qui m’interpellait
sur un changeset récent :

« Traffic » était une première piste, la clé a toujours son intérêt (à
condition que les donnés soient copiables : la donnée vient des
départements, alors j’ai supposé que c’était compatible avec osm).
L’analyse des données du comptage routier permet d'ébaucher un réseau
routier pas forcément évident. On voit l’impact des quatre-voies : les
automobilistes ne prennent plus l’ancienne grande route naturellement la
plus directe mais la quatre-voies puis une route secondaire pas forcément
adaptée. Ça donne un réseau en arêtes de poisson autour de la quatre-voies.
La clé « traffic » ne suffit pas car le trafic interurbain (c’est-à-dire :
entre deux aires urbaines) est en général faible, du coup il faut une clé
pour classifier un itinéraire interurbain (highway_class). Alors : faut-il
une clé spéciale pour les itinéraires à l’intérieur d’une aire urbaine
(routes périurbaines, autoroutes uniquement urbaines ou Grands Boulevards
dans une ville ayant un périphérique pour le trafic de transit ?), ç’a à
l’air tentant, je vais réfléchir.
L’aspect de la route rentre aussi en compte : ça ressemble à une autoroute,
à une semi-autoroute, à une grande route classique ? (-> clé looks_like)
Je n’oublie pas l’aspect administratif : officiellement une autoroute ou
une « route pour automobiles » (clé legal).
Pour finir (pour le moment ?), il y a la performance de la route :
l’aménagement routier par rapport à son trafic (carrefour à feu connu pour
être générateur de bouchon, échangeur autoroutier dit « mal foutu » ...)
(clé performance)

@+ djakk

Ce que je pense traduire pour taggin’ mondial.
Bonus : la clé footway_class et la clé cycleway_class pour les itinéraires
pédestres et cyclables.


djakk


Le mar. 18 sept. 2018 à 23:04, Philippe Verdy  a écrit :

> Pour info une lecture pertiennte concernant le zonage urbain de l'INSEE
>
> https://www.insee.fr/fr/information/2115011
>
> Plus de concepts sur
>
> https://www.insee.fr/fr/information/2114631
>
> qui présente les données d'études proposées sur
>
> https://www.insee.fr/fr/recherche/recherche-geographique?debut=0
>
> L'INSEE n'est pas non plus la seule institution française à faire du
> zonage en France.
>
> Le mar. 18 sept. 2018 à 22:40, François Lacombe 
> a écrit :
>
>> Le mar. 18 sept. 2018 à 22:31, Jérôme Seigneuret <
>> jerome.seigneu...@gmail.com> a écrit :
>>
>>> Certains sujets sont portés par peu de personnes car cela nécessite des
>>> connaissances métier (réseaux électriques, eau, télécom) et dont certaines
>>> informations de schématisation sont trop complexes
>>> Je parle pour  InfosReseaux  qui s'est occupé de compléter les pages
>>> concernant les réseaux électriques.
>>> D'autres touches beaucoup plus de gens et sont aussi contrôlé par
>>> beaucoup plus de personnes et retouché aussi par bien plus de monde.
>>>
>>
>> Merci :)
>>
>> Je me souviens aussi avoir commencé maladroitement en éditant directement
>> une page de features en 2012, la considérant peu à mon gout.
>> C'est le métier qui rentre.
>>
>> Penser que si on atteint le consensus même partiel, sa contribution a
>> plus de chances d'être adoptée et utilisée.
>> Il faut de l’endurance
>>
>> Bonne soirée
>>
>> François
>> ___
>> 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] Changement unilatéral de la définition de tags

[Jérôme Seigneuret]

Le mar. 18 sept. 2018 à 23:03, marc marc  a
écrit :

> djakk n'est pas un bleu même s'il est rarement aussi actif ici :)
>
Maoui! Il est même plus ancien contributeur que moi! Ben désolé mais en
effet c'est pas un novice ce qui n'étonne d'autant plus.

@djakk fait de l'humour dans ces changeset
*(ne pas expérimenter ici en fait :) )*


Ben c'est pas un bac à sable donc non... J'ai demandé si l'on pouvait en
mettre un en place pour des projets et des tests de comparaison sur la
liste dev mais je pense pas avoir ciblé la bonne liste peut être tech est
plus approprié.
@marc marc  on a la possibilité de mettre ça en
place ou vous avez une doc pour mettre un serveur en place "from scratch".
Le but c'est d'avoir une image et de faire les test dessus. Pouvoir faire
des modif dessus sans impacté le système en place et ainsi s'en servir pour
présenter aussi des cas d'étude sur du routing ou du géocodage.

Merci




Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Changement unilatéral de la définition de tags

[Philippe Verdy]

Pour info une lecture pertiennte concernant le zonage urbain de l'INSEE

https://www.insee.fr/fr/information/2115011

Plus de concepts sur

https://www.insee.fr/fr/information/2114631

qui présente les données d'études proposées sur

https://www.insee.fr/fr/recherche/recherche-geographique?debut=0

L'INSEE n'est pas non plus la seule institution française à faire du zonage
en France.

Le mar. 18 sept. 2018 à 22:40, François Lacombe 
a écrit :

> Le mar. 18 sept. 2018 à 22:31, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>> Certains sujets sont portés par peu de personnes car cela nécessite des
>> connaissances métier (réseaux électriques, eau, télécom) et dont certaines
>> informations de schématisation sont trop complexes
>> Je parle pour  InfosReseaux  qui s'est occupé de compléter les pages
>> concernant les réseaux électriques.
>> D'autres touches beaucoup plus de gens et sont aussi contrôlé par
>> beaucoup plus de personnes et retouché aussi par bien plus de monde.
>>
>
> Merci :)
>
> Je me souviens aussi avoir commencé maladroitement en éditant directement
> une page de features en 2012, la considérant peu à mon gout.
> C'est le métier qui rentre.
>
> Penser que si on atteint le consensus même partiel, sa contribution a plus
> de chances d'être adoptée et utilisée.
> Il faut de l’endurance
>
> Bonne soirée
>
> François
> ___
> 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] Changement unilatéral de la définition de tags

[marc marc]

djakk n'est pas un bleu même s'il est rarement aussi actif ici :)
pour la proposition au niveau mondial, je t'y encourage.
ceci dit rien n’empêche d'en parler ici, c'est, je pense, même très 
utile car l'impression qui en ressort c'est que les premiers retours 
n'ont pas été une discussion mais à sens unique.
je suis aussi personnellement très ennuyé de voir des éditions 
mécaniques contestée et en plus faite avec source=survey
genre renseigner la volumétrie du traffic avec 
https://wiki.openstreetmap.org/wiki/Key:traffic
tu as vraiment été mesurer le trafic de plein de route ?
au final cette clef ne veux plus rien dire si on y trouve
tout autant des infos objectives que des infos "je suis en désaccord 
avec highway=trunk alors je met traffic=trunk source=survey"
ou l'ajout de nouveau tag dans un revert cela sent la mauvais foi :(

pour repartir sur des bases plus saine, il faudrait (re)commencer
dans un nouveau sujet par expliquer l'un des problèmes que tu 
rencontres, voir si on peux le résoudre avec l'existant et ensuite 
seulement PROPOSER une modif, puis après un temps raisonnable la mettre 
en place si cela fait consensus.
il faut aussi tenir compte des objections précédentes (par exemple 
dupliquer toutes les clefs highway dans une autre clef parce que c'est 
plus facile pour ton rendu n'est pas très censé et in-maintenable).

Cordialement,
Marc

Le 18. 09. 18 à 22:30, Jérôme Seigneuret a écrit :
> Merci,
> Sache qu'on ne remet pas ton implication en cause.
> J'ai fait une annulation de la dernière partie du wiki car c'est 
> l'élément de référence pour l'ensembles des contributeurs. Même si les 
> modifications sont possibles (car c'est du mediawiki) on en parle avant 
> que cela ai un impacte considérable et de devoir faire les modifications 
> à 10 pour revenir en arrière.
> 
> J'ai aussi été gourmand au début et voulu bousculer les choses ... Cela 
> ne se fait pas par la force en ajout massif de données (tu peux faire de 
> l'ajout massif en respectant ce qui est déjà mis en place) mais en 
> communicant et en ayant des arguments assez convainquant pour faire 
> adhérer la communauté que nous sommes. On y trouve tous des intérêts qui 
> sont très variables et avec des niveaux de définition et de précisions 
> et une granulométries qui reflètent les niveaux de compréhension de 
> l'espace propre à chacun d'entre nous. Ce qui peut paraître futile pour 
> certains et une nécessité pour d'autre.
> 
> Certains sujets sont portés par peu de personnes car cela nécessite des 
> connaissances métier (réseaux électriques, eau, télécom) et dont 
> certaines informations de schématisation sont trop complexes
> Je parle pour InfosReseaux  qui s'est occupé de compléter les pages 
> concernant les réseaux électriques.
> D'autres touches beaucoup plus de gens et sont aussi contrôlé par 
> beaucoup plus de personnes et retouché aussi par bien plus de monde.
> 
> Es-tu affilié à un groupe local? Je pense que c'est déjà un bon début 
> pour échanger se présenter et communiquer aussi sa vision, les 
> thématiques de travail souhaitées et le territoire (même si j'ai pas 
> commencé mes édition ainsi)
> 
> Dans presque chaque département il y a une liste locale et plusieurs 
> groupes de travail car les intercommunalités s'intéressent au crowsoursing.
> 
> Bonne soirée.
> 
> Le mar. 18 sept. 2018 à 18:24, djakk djakk  > a écrit :
> 
> Ok ok j’ai tout « revert » y compris sur le wiki (sauf l’annulation
> de Jérôme qui n’a pas fait de « undo » dans le wiki - j’ai pas
> vérifié si le contenu est cohérent).
> L’argument qui a fait mouche chez moi : l’absence de
> retro-compatibilité.
> 
> Je présenterai sur la mailing-list tagging (mondiale) un moyen
> d’arriver à une définition commune dans le monde entier pour la
> définition des routes, en contournant l’actuelle clé highway au lieu
> de changer brutalement la définition de ses valeurs. Je trouve que
> c’est améliorer Openstreetmap de gommer (autant que possible) les
> différences entre pays sur les définitions de valeurs.
> (Comment ? en décomposant ce qui fait une route, de l’aspect visuel
> à la définition administrative à l’utilisation plus ou moins
> intensive, pour du trajet interurbain ou du trajet intra-urbain).
> 
> 
> @+
> djakk
> 
> 
> Le mar. 18 sept. 2018 à 09:31, Christian Quest
> mailto:cqu...@openstreetmap.fr>> a écrit :
> 
> Le dim. 16 sept. 2018 à 15:43, djakk djakk
> mailto:djakk.dj...@gmail.com>> a écrit :
> 
> Je pense que je rajoute de l’information sans en supprimer
> ... ? Bon certes je chamboule l’existant ...
> 
> djakk
> 
> Dommage de procéder ainsi "en force".
> 
> Le tagging sur OSM fonctionne grâce à un consensus, il faut le
> respecter ou ouvrir une discussion (large) pour faire naître un
> nouveau consensus et ne pas "chambouler" ainsi l'existant, 

Re: [OSM-talk-fr] Josm, imagerie aérienne, lenteur ou bug

[Vincent Privat]

Y'a trois tickets en cours sur ce sujet:
https://josm.openstreetmap.de/ticket/16734
https://josm.openstreetmap.de/ticket/16743
https://josm.openstreetmap.de/ticket/16747

Wiktor est dessus.

A+
Vincent

Le mar. 18 sept. 2018 à 13:19, Julien Lepiller  a écrit :

> Le 2018-09-18 12:12, Stéphane Péneau a écrit :
> > Hello !
> >
> > Depuis quelques semaines, ou mois, j'ai la sensation que l'affichage
> > des images aériennes dans Josm a un comportement un peu bizarre.
> >
> > J'ai l'impression qu'il y a 2 problèmes, 1 dans Josm, et 1 autre avec
> > la BD Ortho de l'Ign :
> >
> > - Dans Josm, je peux avoir un affichage correct, puis pendant un
> > déplacement de l'affichage, me retrouver avec des tuiles pixelisées
> > qui s'affichent par dessus d'autres tuiles en bonne qualité.
>
> Je confirme ce point, et pas uniquement sur la bdortho : ça me le fait
> sur toutes les imageries, ce qui est particulièrement pénible en 4G dans
> un train, puisqu'il faut attendre d'avoir une connexion pour que JOSM
> télécharge de nouveau les tuiles alors qu'il les connaissait.
>
> > - En parallèle, et ce n'est pas permanent, la console de Josm
> > m'affiche un nombre assez conséquent d'erreurs 404 et/ou 509 avec
> > proxy-ign.openstreetmap.fr. Par exemple, hier matin.
>
> Là je ne sais pas.
>
> >
> > Oui, ça fait beaucoup de conditionnel et de ressenti. Avant de creuser
> > plus loin, j'aimerais savoir si je suis le seul dans cette situation,
> > ou si c'est assez généralisé.
> >
> >
> > Stf
> >
> >
> > ___
> > 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] Changement unilatéral de la définition de tags

[Philippe Verdy]

Ce n'est pas un simple revert, mais djakk tu en a profité pour ajouter
encore de nouveau tags (après plusieurs inventions successives elles aussi
non proposées et discutées avant).

https://www.openstreetmap.org/changeset/62695271

ici "capital:INSEE=bassin de vie",  très incongru; dont il n'existe une
définition que pour l'INSEE relativement une étude ou une série d'études
statistiques particulières, datées mais pas renouvelées ensuite, ou
destinées à des commissions parlementaires ou avoir des chiffres à peu près
fiable (sur une date et zone d'étude limitée) permettant de mener des
négociations qui à terme finiront dans la réglementation ou la loi sous une
autre forme après divers arbitrages... ou jusqu'au changement de ministres
ou de majorité parlementaire ou à cause d'arbitrages légaux en justice
(administrative française ou internationale) ou par l'adoption d'une
nouvelle norme et sa recommandation (mais pas nécessairement une obligation
pour toutes les administrations publiques ou parapubliques/paritaires non
plus ni pour le secteur privé).

L'INSEE ne définit pas de telles "capitales" et il y a plusieurs zonages
INSEE possibles (zonages urbains, zonages d'emploi, etc...) Je ne vois pas
en quoi il faut privilégier "bassin de vie". Et des tas de zonages sont
définis pour des études particulières demandées par des collectivités ou
pour faire une étude avant des réformes, mais ne sont pas maintenus
ensuite. La notion de "bassin de vie" est très lâche et sensible au
contexte légal qui définit de nouveaux objectifs dont certains s'appliquent
aux collectivités et leurs organes de coopération (avec diverses formes
juridiques), d'autres à des agences (pas toutes françaises, il y a des
demandes européennes aussi).

OSM n'est pas un fourre-tout et demande un peu de recherche et de
concertation pour voir ce qui pourrait coller aussi à l'existant.

A mon avis ton tag aurait pu juste être "note=centre d'un bassin de vie"
(les notes sont un avis informatif à discuter et voir comment normaliser
plus tard, elles ont un suivi spécial dédié) ou une "description=*"; les
deux offrent un court espace de texte libre mais permettent des recherches
(floues sur texte libre) pour évaluer ensuite le besoin réel et les
solutions possibles.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre

[Jérôme Seigneuret]

@Phyks C'est q'une clause de bon sens mais certains parking sont affiché
avec des vitesses de circulation à 10 20 ou 30 km.

La loi dit:

*  Article R. 413-18. Lorsque des parcs de stationnement de véhicules sont
aménagés sur des trottoirs ou terre-pleins, les conducteurs ne doivent
circuler sur ceux-ci qu'à une allure très réduite et en prenant toute
précaution pour ne pas nuire aux piétons. *

D'ailleurs la notion de nuire n'existe plus et à été remplacé par  « ne pas
constituer un danger pour les piétons »

Maintenant si tu roule dans un parking de supermarché tu peux avoir des
disposition qui font que tu peux rouler sans être confronté à de la
circulation piétonne
Exemple un stop à chaque ailes de parking. Dans le cas contraire il te sera
difficile voir même risqué de prendre de la vitesse si toutes les voies à
droite sont des priorités.

La loi nous laisse un peu réfléchir et ne fixe pas de limite stricte
contrairement à ce qui est dit au permis... Mais difficile de faire un
évitement à plus de 10km ou un frainage d'urgence avec un volant déporté
dans une voiture d'autoécole...

En clair si la police estime que tu mets en danger les usagers tu risques
une amande:
*Une vitesse excessive par rapport à la configuration des lieux est
sanctionnée au même titre qu’un excès de vitesse par une contravention de
4ème classe (amende forfaitaire de 135 €), mais il n’y a pas de retrait de
point.  *

C'est comme si t'es poursuivi par les motards de la gendarmerie alors que
tu roule 50km/h au dessus de la moyenne et qu'il n'ont pas de radars.

Donc au final, si il n'y a pas de piétons et pas de panneaux et que tu es
en ville dans un parking avec des voies qui te permettent de rouler à cette
vitesse sans faire du drift, tu peux rouler à 50km/h si ça te chante.

Bonne soirée




Le mar. 18 sept. 2018 à 22:19, Phyks  a écrit :

> Salut,
>
>
> > En soit rien de franchement étonnant dans beaucoup de voie de service
> et de
> > parking de supermarché les voies sont déjà limité à 20 voir à 10km. Pour
> > info les voies de services n'ont pas de vitesse par défaut (ce sont les
> > logiciel de routing qui les déduises en fonction des voies de
> connexions).
> > En France les voies privés ouvertes à la circulation ne sont pas limité
> de
> > manière implicite c'est le même code donc les même conditon de
> circulation.
> > Elles reprennent la vitesse de la zone dans laquelle tu es. En clair si
> > t'es en ville sans panneaux c'est 50km/h... Pareil pour les parking de
> > centre commerciaux.
>
> Mes deux centimes là-dessus, quand je passais le permis on m'avait
> explicitement dit qu'il fallait passer la première et y rester sur un
> parking de centre commercial, sinon c'était éliminatoire.
>
> J'ai aucune idée de si c'est retranscrit tel quel dans le code de la
> route ou si c'est une pratique exigée en plus des obligations légales,
> mais ça me semble difficile de rouler à plus que 10km/h en première :)
> --
> Phyks
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Changement unilatéral de la définition de tags

[François Lacombe]

Le mar. 18 sept. 2018 à 22:31, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> Certains sujets sont portés par peu de personnes car cela nécessite des
> connaissances métier (réseaux électriques, eau, télécom) et dont certaines
> informations de schématisation sont trop complexes
> Je parle pour  InfosReseaux  qui s'est occupé de compléter les pages
> concernant les réseaux électriques.
> D'autres touches beaucoup plus de gens et sont aussi contrôlé par beaucoup
> plus de personnes et retouché aussi par bien plus de monde.
>

Merci :)

Je me souviens aussi avoir commencé maladroitement en éditant directement
une page de features en 2012, la considérant peu à mon gout.
C'est le métier qui rentre.

Penser que si on atteint le consensus même partiel, sa contribution a plus
de chances d'être adoptée et utilisée.
Il faut de l’endurance

Bonne soirée

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

Re: [OSM-talk-fr] Changement unilatéral de la définition de tags

[Jérôme Seigneuret]

Merci,
Sache qu'on ne remet pas ton implication en cause.
J'ai fait une annulation de la dernière partie du wiki car c'est l'élément
de référence pour l'ensembles des contributeurs. Même si les modifications
sont possibles (car c'est du mediawiki) on en parle avant que cela ai un
impacte considérable et de devoir faire les modifications à 10 pour revenir
en arrière.

J'ai aussi été gourmand au début et voulu bousculer les choses ... Cela ne
se fait pas par la force en ajout massif de données (tu peux faire de
l'ajout massif en respectant ce qui est déjà mis en place) mais en
communicant et en ayant des arguments assez convainquant pour faire adhérer
la communauté que nous sommes. On y trouve tous des intérêts qui sont très
variables et avec des niveaux de définition et de précisions et une
granulométries qui reflètent les niveaux de compréhension de l'espace
propre à chacun d'entre nous. Ce qui peut paraître futile pour certains et
une nécessité pour d'autre.

Certains sujets sont portés par peu de personnes car cela nécessite des
connaissances métier (réseaux électriques, eau, télécom) et dont certaines
informations de schématisation sont trop complexes
Je parle pour  InfosReseaux  qui s'est occupé de compléter les pages
concernant les réseaux électriques.
D'autres touches beaucoup plus de gens et sont aussi contrôlé par beaucoup
plus de personnes et retouché aussi par bien plus de monde.

Es-tu affilié à un groupe local? Je pense que c'est déjà un bon début pour
échanger se présenter et communiquer aussi sa vision, les thématiques de
travail souhaitées et le territoire (même si j'ai pas commencé mes édition
ainsi)

Dans presque chaque département il y a une liste locale et plusieurs
groupes de travail car les intercommunalités s'intéressent au crowsoursing.

Bonne soirée.

Le mar. 18 sept. 2018 à 18:24, djakk djakk  a écrit :

> Ok ok j’ai tout « revert » y compris sur le wiki (sauf l’annulation de
> Jérôme qui n’a pas fait de « undo » dans le wiki - j’ai pas vérifié si le
> contenu est cohérent).
> L’argument qui a fait mouche chez moi : l’absence de retro-compatibilité.
>
> Je présenterai sur la mailing-list tagging (mondiale) un moyen d’arriver à
> une définition commune dans le monde entier pour la définition des routes,
> en contournant l’actuelle clé highway au lieu de changer brutalement la
> définition de ses valeurs. Je trouve que c’est améliorer Openstreetmap de
> gommer (autant que possible) les différences entre pays sur les définitions
> de valeurs.
> (Comment ? en décomposant ce qui fait une route, de l’aspect visuel à la
> définition administrative à l’utilisation plus ou moins intensive, pour du
> trajet interurbain ou du trajet intra-urbain).
>
>
> @+
> djakk
>
>
> Le mar. 18 sept. 2018 à 09:31, Christian Quest 
> a écrit :
>
>> Le dim. 16 sept. 2018 à 15:43, djakk djakk  a
>> écrit :
>>
>>> Je pense que je rajoute de l’information sans en supprimer ... ? Bon
>>> certes je chamboule l’existant ...
>>>
>>> djakk
>>>
>>
>> Dommage de procéder ainsi "en force".
>>
>> Le tagging sur OSM fonctionne grâce à un consensus, il faut le respecter
>> ou ouvrir une discussion (large) pour faire naître un nouveau consensus et
>> ne pas "chambouler" ainsi l'existant, au risque d'un douloureux retour de
>> flamme.
>>
>>
>> --
>> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre

[Phyks]

Salut,


> En soit rien de franchement étonnant dans beaucoup de voie de service
et de
> parking de supermarché les voies sont déjà limité à 20 voir à 10km. Pour
> info les voies de services n'ont pas de vitesse par défaut (ce sont les
> logiciel de routing qui les déduises en fonction des voies de connexions).
> En France les voies privés ouvertes à la circulation ne sont pas limité de
> manière implicite c'est le même code donc les même conditon de
circulation.
> Elles reprennent la vitesse de la zone dans laquelle tu es. En clair si
> t'es en ville sans panneaux c'est 50km/h... Pareil pour les parking de
> centre commerciaux.

Mes deux centimes là-dessus, quand je passais le permis on m'avait
explicitement dit qu'il fallait passer la première et y rester sur un
parking de centre commercial, sinon c'était éliminatoire.

J'ai aucune idée de si c'est retranscrit tel quel dans le code de la
route ou si c'est une pratique exigée en plus des obligations légales,
mais ça me semble difficile de rouler à plus que 10km/h en première :)
-- 
Phyks

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

Re: [OSM-talk-fr] Besoin d'avis sur cette pratique

[marc marc]

Pour proposer qlq chose + utile que la suppression : 
man_made=wheel_trace + description : trace de la machine d'irrigation
histoire que le prochaine qui regarde l'ortho ne se pose pas la question
de ce que c'est et rajoute erronément un highway

Le 18. 09. 18 à 21:35, Romain MEHUT a écrit :
> Bon on est tous d'accord qu'il ne s'agit pas d'un highway.
> 
> Merci.
> 
> Romain
> 
> Le jeu. 13 sept. 2018 à 00:27, Jérôme Seigneuret 
> mailto:jerome.seigneu...@gmail.com>> a écrit :
> 
> Il faut juger du caractère temporaire, du faite qu'ell soit utiliser
> pour aller vers une destination et non pour exploiter l'inérieur de
> la parcelle. Une route enherbée ne laisse pas spécifique de trace
> mais ça reste une route si elle est traversé au même endroit
> régulièrement. dans ce cas on gère ça avec tracktype et on utilise
> le grade correspondant.
> Il y a une notion d'entretien également. Même un sentier piéton est
> entretenu.
> Un sillon de passage d'un tracteur au milieu d'un champs n'a pas de
> sens. Par contre ça pourrait en avoir au mieux d'une vigne et
> pourtant on ne fait pas un highway=track pour les inter-rang  je
> mais cependant le chemin autour car cela permet de traversé des
> coteaux et en plus comme c'est privé il faut définir
> access=permissive ou private suivant les indications. C'est la même
> chose en forestier: On ne crée pas une route entre chaque alignement
> d'arbres... Une question de temps, de lisibilité et de bon-sens
> 
> Bonne soirée
> Bonne soirée
> 
> Le mer. 12 sept. 2018 à 23:38, Gwenaël Jouvin
> mailto:gwenael.jou...@laposte.net>> a
> écrit :
> 
> Bonsoir,
> 
> Sans connaître le contexte, à la lecture des commentaires il est
> dommage que ça parte d’un si mauvais pied par des phrases
> courtes inévitablement mal interprétées à l’écrit.
> 
> Après, je comprends la réaction épidermique du contributeur
> initial qui voit son travail supprimé : il aurait, je crois, été
> plus prudent de le contacter au préalable ou de mettre une note.
> Je pense que je serais également pas très content si quelqu’un
> passait derrière mes contributions de terrain en cassant tout…
> c’est récemment arrivé à un collègue et il est obligé de tout
> refaire (chemins coupés, toponymes mélangés, historiques
> perdus…), y a de quoi enrager.
> 
> Évidemment, il est également confortable de bosser sur une carte
> où il existe déjà plein d’éléments mis par d’autres personnes
> qui maîtrisent les imports de jeux de données.
> 
> Contributeurs d’intérieur et d’extérieurs sont complémentaires !
> 
> 
> Sur l’objet en lui-même, ce n’est clairement pas un 
> puisque ce n’est pas une voie de circulation mais la trace
> laissée par une machine.
> 
> 
> Gwenj
> 
> 
> Le 12/09/2018 à 22:46, Romain MEHUT a écrit :
>  > Bonsoir,
>  >
>  > Sur la base d'un commentaire "J'ai une question à la con :
> c'est quoi ce truc ?" dans ce changeset
> https://www.openstreetmap.org/changeset/62500260 j'ai supprimé
> tous les highway=footway qui à mon sens n'en sont pas.
>  >
>  > Le contributeur à l'origine des contributions proteste contre
> mes suppressions comme vous pourrez le lire dans la suite de
> commentaires du changeset.
>  >
>  > Quel est votre avis ?
>  >
>  > Merci.
>  >
>  > Romain
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Besoin d'avis sur cette pratique

[Jérôme Seigneuret]

A mais oui mais j'étais carrément pas allé voir l'ortho! C'est le passage
des roues d'une rampe d'irrigation XD. Donc faut virer ça ça n'a pas de
sens



Le mar. 18 sept. 2018 à 21:36, Romain MEHUT  a
écrit :

> Bon on est tous d'accord qu'il ne s'agit pas d'un highway.
>
> Merci.
>
> Romain
>
> Le jeu. 13 sept. 2018 à 00:27, Jérôme Seigneuret <
> jerome.seigneu...@gmail.com> a écrit :
>
>> Il faut juger du caractère temporaire, du faite qu'ell soit utiliser pour
>> aller vers une destination et non pour exploiter l'inérieur de la parcelle.
>> Une route enherbée ne laisse pas spécifique de trace mais ça reste une
>> route si elle est traversé au même endroit régulièrement. dans ce cas on
>> gère ça avec tracktype et on utilise le grade correspondant.
>> Il y a une notion d'entretien également. Même un sentier piéton est
>> entretenu.
>> Un sillon de passage d'un tracteur au milieu d'un champs n'a pas de sens.
>> Par contre ça pourrait en avoir au mieux d'une vigne et pourtant on ne fait
>> pas un highway=track pour les inter-rang  je mais cependant le chemin
>> autour car cela permet de traversé des coteaux et en plus comme c'est privé
>> il faut définir access=permissive ou private suivant les indications. C'est
>> la même chose en forestier: On ne crée pas une route entre chaque
>> alignement d'arbres... Une question de temps, de lisibilité et de bon-sens
>>
>> Bonne soirée
>> Bonne soirée
>>
>> Le mer. 12 sept. 2018 à 23:38, Gwenaël Jouvin 
>> a écrit :
>>
>>> Bonsoir,
>>>
>>> Sans connaître le contexte, à la lecture des commentaires il est dommage
>>> que ça parte d’un si mauvais pied par des phrases courtes inévitablement
>>> mal interprétées à l’écrit.
>>>
>>> Après, je comprends la réaction épidermique du contributeur initial qui
>>> voit son travail supprimé : il aurait, je crois, été plus prudent de le
>>> contacter au préalable ou de mettre une note.
>>> Je pense que je serais également pas très content si quelqu’un passait
>>> derrière mes contributions de terrain en cassant tout… c’est récemment
>>> arrivé à un collègue et il est obligé de tout refaire (chemins coupés,
>>> toponymes mélangés, historiques perdus…), y a de quoi enrager.
>>>
>>> Évidemment, il est également confortable de bosser sur une carte où il
>>> existe déjà plein d’éléments mis par d’autres personnes qui maîtrisent les
>>> imports de jeux de données.
>>>
>>> Contributeurs d’intérieur et d’extérieurs sont complémentaires !
>>>
>>>
>>> Sur l’objet en lui-même, ce n’est clairement pas un  puisque ce
>>> n’est pas une voie de circulation mais la trace laissée par une machine.
>>>
>>>
>>> Gwenj
>>>
>>>
>>> Le 12/09/2018 à 22:46, Romain MEHUT a écrit :
>>> > Bonsoir,
>>> >
>>> > Sur la base d'un commentaire "J'ai une question à la con : c'est quoi
>>> ce truc ?" dans ce changeset
>>> https://www.openstreetmap.org/changeset/62500260 j'ai supprimé tous les
>>> highway=footway qui à mon sens n'en sont pas.
>>> >
>>> > Le contributeur à l'origine des contributions proteste contre mes
>>> suppressions comme vous pourrez le lire dans la suite de commentaires du
>>> changeset.
>>> >
>>> > Quel est votre avis ?
>>> >
>>> > Merci.
>>> >
>>> > Romain
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> --
>> Cordialement,
>> Jérôme Seigneuret
>> ___
>> 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre

[Gwenaël Jouvin]

Merci pour l’info sur la hiérarchisation des voies. J’y ferai attention (et 
j’aurai certainement des choses à corriger) car par habitude, j’ai également 
commis l’erreur.


Ma remarque précédente concernait le choix de l’aménageur : il faut garder à 
l’esprit que la zone de rencontre est une adaptation française, maladroite et 
incomplète, des concepts de shared space ou de woonerf [1] que l’on trouve dans 
d’autres pays européens et qui est très adapté, comme indiqué, aux abords 
d’écoles (quoique, ça se discute : la zone 30 avec fermeture périodique est 
certainement plus cohérente avec une activité très hétérogène) mais surtout aux 
rues à faible circulation motorisée de centre-ville, à forte dominante 
piétonne, mais nécessitant tout de même un minimum de circulation qui empêche 
de les classer en aire piétonne.

Bref, l’idée générale est : des enfants peuvent y courir après un ballon sans 
danger. Tout le contraire d’un parc de stationnement…

Je crois que beaucoup se font berner par le panneau de la zone de rencontre 
avec son « 20 » et le confondent avec une « zone 20 », dénomination que l’on 
lit malheureusement trop souvent. Seuls 2 panneaux en Europe présentent une 
limite de vitesse… [2] … et dans une zone de rencontre, ce n’est pas la vitesse 
qui est centrale, mais l’usage de la chaussée. 20 est indiqué car il faut 
croire qu’en France, on ne raisonne qu’en termes de vitesse.
La bonne pratique est que lorsque l’on souhaite limiter la vitesse à 20 km/h, 
on met un panneau « 20 ». Quand on souhaite indiquer une zone à circulation 
fortement restreinte où la vie locale est prépondérante, on crée une zone de 
rencontre, mais un panneau n’y suffit pas.

Bon, on s’éloigne de la carto, mais il est bon parfois de faire le point sur ce 
que l’on ajoute ;-)

Gwenaël


[1] 
https://rouelibreblog.wordpress.com/2016/01/17/zone-de-rencontre-et-shared-space-un-meme-esprit-3-nuances/
[2] 
https://fr.wikipedia.org/wiki/Comparaison_des_panneaux_de_signalisation_routi%C3%A8re_en_Europe


Le 18/09/2018 à 21:27, Jérôme Seigneuret a écrit :
> @gwenael.jou...@laposte.net   Les voies de 
> stationnement n'ont pas à toute être mise en service=parking_aisle. Si c'est 
> une voies majeur servant à diriger le traffic sur le parking c'est juste un 
> highway=service. C'est aussi ce qui permet de conditionner le routing. On ne 
> met pas parking_aisle sur les voies servant à diriger le flux vers les 
> entrées ou sorties des parkings ni vers des accès à des routes supérieurs. 
> Seul exception acceptable à mon sens c'est la voie voie de parking unique 
> sans sortie.
> 
> L'erreur est souvant faite et c'est aussi ID qui est en cause car il met 
> automatiquement cette balise service=parking_aisle
> Pour moi il manque la décomposition sur ID voie majeur de parking et voie 
> secondaire de parking
> 
> https://www.openstreetmap.org/#map=17/43.58307/3.93005
> D'ailleurs quand je voie le lien je me rends compte qu'il y a des erreurs sur 
> certaines voies :|  J'ai raté des bouts de voies
>
> […]

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

Re: [OSM-talk-fr] Besoin d'avis sur cette pratique

[Romain MEHUT]

Bon on est tous d'accord qu'il ne s'agit pas d'un highway.

Merci.

Romain

Le jeu. 13 sept. 2018 à 00:27, Jérôme Seigneuret <
jerome.seigneu...@gmail.com> a écrit :

> Il faut juger du caractère temporaire, du faite qu'ell soit utiliser pour
> aller vers une destination et non pour exploiter l'inérieur de la parcelle.
> Une route enherbée ne laisse pas spécifique de trace mais ça reste une
> route si elle est traversé au même endroit régulièrement. dans ce cas on
> gère ça avec tracktype et on utilise le grade correspondant.
> Il y a une notion d'entretien également. Même un sentier piéton est
> entretenu.
> Un sillon de passage d'un tracteur au milieu d'un champs n'a pas de sens.
> Par contre ça pourrait en avoir au mieux d'une vigne et pourtant on ne fait
> pas un highway=track pour les inter-rang  je mais cependant le chemin
> autour car cela permet de traversé des coteaux et en plus comme c'est privé
> il faut définir access=permissive ou private suivant les indications. C'est
> la même chose en forestier: On ne crée pas une route entre chaque
> alignement d'arbres... Une question de temps, de lisibilité et de bon-sens
>
> Bonne soirée
> Bonne soirée
>
> Le mer. 12 sept. 2018 à 23:38, Gwenaël Jouvin 
> a écrit :
>
>> Bonsoir,
>>
>> Sans connaître le contexte, à la lecture des commentaires il est dommage
>> que ça parte d’un si mauvais pied par des phrases courtes inévitablement
>> mal interprétées à l’écrit.
>>
>> Après, je comprends la réaction épidermique du contributeur initial qui
>> voit son travail supprimé : il aurait, je crois, été plus prudent de le
>> contacter au préalable ou de mettre une note.
>> Je pense que je serais également pas très content si quelqu’un passait
>> derrière mes contributions de terrain en cassant tout… c’est récemment
>> arrivé à un collègue et il est obligé de tout refaire (chemins coupés,
>> toponymes mélangés, historiques perdus…), y a de quoi enrager.
>>
>> Évidemment, il est également confortable de bosser sur une carte où il
>> existe déjà plein d’éléments mis par d’autres personnes qui maîtrisent les
>> imports de jeux de données.
>>
>> Contributeurs d’intérieur et d’extérieurs sont complémentaires !
>>
>>
>> Sur l’objet en lui-même, ce n’est clairement pas un  puisque ce
>> n’est pas une voie de circulation mais la trace laissée par une machine.
>>
>>
>> Gwenj
>>
>>
>> Le 12/09/2018 à 22:46, Romain MEHUT a écrit :
>> > Bonsoir,
>> >
>> > Sur la base d'un commentaire "J'ai une question à la con : c'est quoi
>> ce truc ?" dans ce changeset
>> https://www.openstreetmap.org/changeset/62500260 j'ai supprimé tous les
>> highway=footway qui à mon sens n'en sont pas.
>> >
>> > Le contributeur à l'origine des contributions proteste contre mes
>> suppressions comme vous pourrez le lire dans la suite de commentaires du
>> changeset.
>> >
>> > Quel est votre avis ?
>> >
>> > Merci.
>> >
>> > Romain
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
> --
> Cordialement,
> Jérôme Seigneuret
> ___
> 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] Parc de stationnement en Zone de rencontre

[Jérôme Seigneuret]

@gwenael.jou...@laposte.net   Les voies de
stationnement n'ont pas à toute être mise en service=parking_aisle. Si
c'est une voies majeur servant à diriger le traffic sur le parking c'est
juste un highway=service. C'est aussi ce qui permet de conditionner le
routing. On ne met pas parking_aisle sur les voies servant à diriger le
flux vers les entrées ou sorties des parkings ni vers des accès à des
routes supérieurs.
Seul exception acceptable à mon sens c'est la voie voie de parking unique
sans sortie.

L'erreur est souvant faite et c'est aussi ID qui est en cause car il met
automatiquement cette balise service=parking_aisle
Pour moi il manque la décomposition sur ID voie majeur de parking et voie
secondaire de parking

https://www.openstreetmap.org/#map=17/43.58307/3.93005
D'ailleurs quand je voie le lien je me rends compte qu'il y a des erreurs
sur certaines voies :|  J'ai raté des bouts de voies

@dark as-tu des photos ou un lien permettant de visualiser la zone

En soit rien de franchement étonnant dans beaucoup de voie de service et de
parking de supermarché les voies sont déjà limité à 20 voir à 10km. Pour
info les voies de services n'ont pas de vitesse par défaut (ce sont les
logiciel de routing qui les déduises en fonction des voies de connexions).
En France les voies privés ouvertes à la circulation ne sont pas limité de
manière implicite c'est le même code donc les même conditon de circulation.
Elles reprennent la vitesse de la zone dans laquelle tu es. En clair si
t'es en ville sans panneaux c'est 50km/h... Pareil pour les parking de
centre commerciaux. Donc les panneaux réglementaires disent clairement que
c'est les piétons et vélo qui ont la priorité et dans n'importe quel sens
et que la limitation est à 20km/h. A mon avis ces panneaux devraient même
être mis sur toutes les voies à proximité directe des supermarchés car avec
le caddie plein et les gosses c'est quand même chaud des fois et en plus tu
sors jamais juste au niveau du passage piéton.

Pour info on voit aussi la naissance de zones de rencontre autour des
places et des écoles. C'est un moyen comme un autre de sécuriser à moindre
coût une zone ou le traffic piéton est dense. Et puis pas de feu donc en
soit ça fluidifie le traffic.

On en revient quand même à la problématique des tags spéciaux qui dans ce
cas précis n'ont pas de sens car on cherche à affecter du règlementaire (en
priorité) avant même la fonction de la voirie

La voirie sert pour un parking. Les tags spéciaux ne sont que des templates
avec des valeurs par défaut.

Si la voie est une voie majeur et sort sur une voie piétonne ou autre type
OK highway=living_street.

Toutes les voies secondaires sont des
highway=service+service=parking_aisle+maxspeed=20 + une clé pour la notion
règlementaire (source:maxpeed ou autre)

Après je suis pour ajouter une clé spécifique à ces notions réglementaires
car ça casse les continuités dans les schémas de routing...








Le mar. 18 sept. 2018 à 20:20, Gwenaël Jouvin 
a écrit :

> Mettre un parc de stationnement en zone de rencontre, on aura vraiment
> tout vu !
> Ces aménageurs sont vraiment prêts à tout pour qu’on n’y comprenne plus
> rien… à se demander si eux-mêmes y comprennent quoi que ce soit.
>
> Bref, à mon avis, les voies d’un parc de stationnement n’ont pas à être
> classées en  mais en .
>
> Dans ce cas, on est confronté à une incompétence en matière de voirie qui
> détourne la signalisation abusivement.
> Que faire ? Respecter aveuglément le terrain ou, par discernement,
> déformer un peu la réalité et rester rationnel ?
>
> Personnellement, je choisirai sans hésiter la seconde option, en mettant
> une note explicative et un .
>
>
> Gwenaël
>
>
> Le 18/09/2018 à 20:05, Axelos a écrit :
> > Bonjour,
> >
> > Devant mon lieu de travail, il y a un parc de stationnement de plusieurs
> > centaines de places qui est passé intégralement en zone de rencontre il
> > y quelques mois.
> > Les voies pour y accéder au parc en général, mais aussi les voies pour
> > accéder aux places de stationnements.
> >
> > Les données ont été que partiellement implémenté pour le moment, mais je
> > me pose la question si la balise highway=living_street est suffisante
> > sur les voies accédants aux places de stationnements ? N'est-il pas
> > judicieux d'ajouter une autre balise en plus ?
> >
> > Cordialement, Axel.
> >
> > ___
> > 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouvelle-Calédonie : référendum du 4 novembre

[Philippe Verdy]

Désolé mais je ne peux pas changer le titre d'un message qui contient les
deux sujets, le second sur les villes abordé séparément.

A ce sujet, les statuts en nouvelle-Calédonie sont aussi à part et le
référendum d'autodétermination approche, le 4 novembre 2018.

https://www.francetvinfo.fr/politique/referendum-en-nouvelle-caledonie/

Dommage qu'on en parle pas du tout dans l'actu nationale, il faut chercher
pour trouver l'info !

Est-ce qu'OSM France sera encore compétent si l'indépendance passe ? On
aidera sans doute encore la prochaine communauté, mais on n'aura plus la
même compétence car la législation risque de chenr fortement (y compris le
découpage administratif territorial et diverses règles de classification
qu'on ne trouvera plus expliqué et détaillé sur LégiFrance).

Cela ne sera pas immédiat, il y aura une phase de négociation et de
transfert des compétences, et aussi pour former la nouvelle législation
nationale et mettre en place l'autorité complète du gouvernement, notamment
en matière de défense, sécurité, justice, citoyenneté et revoir la
politique de migrations et des visas et la représentation diplomatique
internationale que le gouvernement néocalédonien choisirait alors lui-même,
ainsi que transfert des compétences en terme de traités internationaux,
avec l'option pour le nouveau gouvernement de ne plus nécessairement suivre
la politique française ou ajouter des modifications avant d'en devenir
lui-même partie, il devra aussi nécessairement adopter une loi primaire,
une constitution, et la faire approuver par référendum, et mettre à jour
ses listes d'électeurs en tenant compte des résidents français qui seront
encore habilités à garder leur nationalité ou adopter une seconde
nationalité, ou abandonner leur nationalité française, cela ne pourrait
guère intervenir sans un appel général aux électeurs manquants à s'inscrire
pour adopter la nouvelle constitution qui sera provisoire et sans doute
rapidement revue plus tard après les élections générales ayant lieu sans
doute au mieux au printemps 2019, le temps ensuite de fonder une assemblée
constituante légitime et permettre des candidatures valides).

Le mar. 18 sept. 2018 à 20:28, marc marc  a
écrit :

> version courte :
> si tu veux tager les panneaux “voie sans issue”
> c'est un traffic_sign=* qu'il te faut à l'endroit du panneau.
> Tu peux le lier au way concerné par proximité ou, pq pas le faire
> appartenir au way concerné comme on le fait pour les stop.
> mais un tag de panneau sur un way c'est spécial même si JB a déjà trouvé
> dans le passé un précédent dans cette façon tordue de faire)
>
> version longue pour le tag noexit :
> le wiki, dans sa version anglaise et française, ne donne aucune
> interdiction de l'utiliser sur les way, mais il donne un sens précis:
> c'est une information qui dit que le nœud d'un way n'est volontairement
> PAS connecté/connectable à l'autre way tout proche.
> son principal usage est la qualité : il permet de faire la différence
> entre un way ajouté et dont on a aucune idée si l'extrémité continue ou
> pas soit parce qu'il y a des arbres ou des immeubles qui masque le way
> sur l'image sat, soit parce que tu n'as pas pris la route jusqu'au bout
> et que tu l'as juste renseigné en passant sur la route perpendiculaire.
> en sens les alertes osmose par ex sont tres utile avec ce tag, ils te
> disent les endroits ou le travail n'est pas finit.
> pour le routages, ce tag est complètement inutile, que la rue soie
> réellement une impasse, le routage ne sait de toute façon pas l'utiliser
> si son extrémité n'est pas connecté à autre chose
> cela explique aussi bien pq sans être faux, c'est totalement vide
> de sens sur un way, je me demande s'il y a un outil qui l'utilise.
>
> le détail sur https://wiki.openstreetmap.org/wiki/Key%3Anoexit
> https://wiki.openstreetmap.org/wiki/Talk:Key:noexit#More_usage_instructions
>
> le seul gros défaut, c'est le nom de la clef : validate:noexit aurait
> été parfaitement clair que c'est ni le panneau qui est renseigné
> ni une information pour le routage.
>
> PS: j'ai coupé le hors sujet... essayons de garder un titre = un sujet
> c'est déjà assez dur à suivre ainsi.
>
> Le 18. 09. 18 à 19:05, djakk djakk a écrit :
> > Un tribunal, ou une université, ou une sous-préfecture, je le résumerai
> > à des emplois de bureau ...
> >
> > Mais, ça n’est pas le bon sujet ! ;P
> >
> > Pour les impasses, en faisant une requête overpass-turbo, je me rend
> > compte que le noexit sur les ways est pas mal utilisé malgré
> > “l’interdiction” du wiki ...
> >
> >
> > djakk
> >
> >
> > Le lun. 17 sept. 2018 à 15:04, JB  > > a écrit :
> >
> > Euh,
> > On pourrait avoir une vue d'ensemble, de conflits d'intérêts
> > possibles, de projets perso/professionnels derrière tout ça ?
> > Ça ressemble de plus en plus à un taggage « pour mon projet
> ».
> > D'abord on redéfinit les villes (tiens, ça 

Re: [OSM-talk-fr] zones de parcmètres

[Jérôme Seigneuret]

Bonjour,

Je suis allé vérifier mes saisies (ou dernière modif)
*/**
*Overpass*
**/*
*[out:json][timeout:25];*
*(*
*  // query part for: “"distributeur automatique" and user:jseigneuret”*
*  node["amenity"="vending_machine"](user:"jseigneuret")({{bbox}});*
*);*
*// print results*
*out body;*
*>;*
*out skel qt;*


Voilà ce qui est mis sur Marseille

"amenity": "vending_machine",
"operator": "Ville de Marseille",
"parking_tickets:zone:FR": "Longue durée",
"parking_tickets:zone:colour": "yellow",
"vending": "parking_tickets"

Sur la Grande-Motte

"amenity": "vending_machine",
"operator": "Ville de La Grande Motte",
"vending": "parking_tickets",
"vending_machine:zone": "green"

"amenity": "vending_machine",
"operator": "Ville de La Grande Motte",
"vending": "parking_tickets",
"vending_machine:zone": "orange"

Il peut exister des référence aussi

ref = 500 ...

J'ai vu aussi des note=Pastille Orange
Il y a aussi les modes de paiement à ajouter et les types d'abonnement

Je n'y connais rien en wikidata mais on peut peux être mettre le détail et
descriptif des offres sur un lien de ce type pour les info d'abonnement et
les conditions d'utilisation comme on peut les trouver sur les bornes.

Avez vous des exemples en ce sens?




Le mar. 18 sept. 2018 à 19:33, Florian LAINEZ  a écrit :

> Merci pour votre aide, j'ai mis à jour la plupart des parcmètres de
> Montrouge en prenant en compte vos suggestions
> https://www.openstreetmap.org/changeset/62704821
>
> Le mar. 18 sept. 2018 à 19:12, djakk djakk  a
> écrit :
>
>> Ok :)
>>
>> Le mar. 18 sept. 2018 à 19:07, Philippe Verdy  a
>> écrit :
>>
>>> C'est pas si hors sujet que ça ! Les stationnements isolés en slalom
>>> sont aussi un problème dans OSM, difficiles à modéliser correctement sans
>>> découper très fortement les rues: on doit les marquer individuellement, le
>>> modèle des parking lanes ne marche pas bien pour eux. Et on constate là où
>>> ils ont été mis en place que les riverains sont finalement très mécontents
>>> de la physionomie que prend leur quartier mis à l'écart du reste de la
>>> ville. Et ça se voit rapidement.
>>>
>>> On a réduit de façon mineure un problème pour en créer d'autres bien
>>> plus graves qui se font sentir rapidement (fermeture des commerces,
>>> désertion des services publics, suppression/détournement des lignes de
>>> transport, baisse de la valeur en revente des résidences. Difficultés
>>> d'accès pour les livraisons, temps de parcours allongés, même augmentation
>>> du danger pour les cyclistes, coût des accidents, absence de présence de la
>>> police (sauf pour verbaliser les résidents!), hausse des assurances et des
>>> incivilités et de la criminalité...
>>>
>>> Ces rues n'étant plus très visibles, les municipalités arrêtent aussi
>>> d'entretenir les espaces verts, la collecte et le recyclage des ordures
>>> ménagères devient compliquée. Ces quartiers devenus des ilots isolés se
>>> dégradent vite et vite se transforment en ghettos délaissés. Les
>>> propriétaires cessent aussi l'entretien régulier des locations ou leurs
>>> locations ne trouvent plus preneur et les tarifs baissent alors que la
>>> pression immobilière s'accroît encore plus dans les centres-villes qui
>>> restent bien desservis par les transports même quand il y a des zones
>>> piétonnes (qui ne concernent pas ces zones résidentielles mises à l'écart).
>>>
>>> Je ne suis pas du tout convaincu que ce système a même renforcé la
>>> sécurité routière et que cela a accu encore plus le prix des places de
>>> stationnement ailleurs: cela accroit le saupoudrage résidentiel périurbain
>>> et la pression publique pour des lignes périurbaines supplémentaires, et de
>>> façon générale le besoin accru en transports publics (de plus en plus
>>> couteux pour les intercommunalités) et les temps de transports. Au final,
>>> on déplace le problème et renforce la pression des espaces dédiés aux
>>> voitures dans les zones périurbaines "rurbanisées" (pas mieux loties an
>>> services publics, mais avec plus de constructions de parkings et une
>>> artificialisation accrue des sols et un gaspillage des espaces ruraux
>>> naturels et agricoles).
>>>
>>> Je ne pense pas que c'est comme ça qu'on va réduire l'usage global de la
>>> voiture particulière ni apporter une réelle "tranquilité" pour les
>>> résidents de ces rues transformées en îles-ghettos. Au final on force des
>>> populations à aller plus loin alors que la ville devrait au contraire se
>>> densifier et se mixifier davantage.
>>>
>>> Le mar. 18 sept. 2018 à 17:30, djakk djakk  a
>>> écrit :
>>>
 Houlà sur le dernier paragraphe tu es parti dans un sacré hors-sujet je
 trouve :)

 Il faut effectivement ne pas avoir à découper le polygone sinon c’est
 pas la peine.


 djakk


 Le mar. 18 sept. 2018 à 17:26, Philippe Verdy  a
 écrit :

> note : les polygones s'appliquent essentiellement au stationnement le
> 

Re: [OSM-talk-fr] Impasse

[marc marc]

version courte :
si tu veux tager les panneaux “voie sans issue”
c'est un traffic_sign=* qu'il te faut à l'endroit du panneau.
Tu peux le lier au way concerné par proximité ou, pq pas le faire 
appartenir au way concerné comme on le fait pour les stop.
mais un tag de panneau sur un way c'est spécial même si JB a déjà trouvé 
dans le passé un précédent dans cette façon tordue de faire)

version longue pour le tag noexit :
le wiki, dans sa version anglaise et française, ne donne aucune 
interdiction de l'utiliser sur les way, mais il donne un sens précis:
c'est une information qui dit que le nœud d'un way n'est volontairement 
PAS connecté/connectable à l'autre way tout proche.
son principal usage est la qualité : il permet de faire la différence 
entre un way ajouté et dont on a aucune idée si l'extrémité continue ou 
pas soit parce qu'il y a des arbres ou des immeubles qui masque le way 
sur l'image sat, soit parce que tu n'as pas pris la route jusqu'au bout 
et que tu l'as juste renseigné en passant sur la route perpendiculaire.
en sens les alertes osmose par ex sont tres utile avec ce tag, ils te 
disent les endroits ou le travail n'est pas finit.
pour le routages, ce tag est complètement inutile, que la rue soie 
réellement une impasse, le routage ne sait de toute façon pas l'utiliser 
si son extrémité n'est pas connecté à autre chose
cela explique aussi bien pq sans être faux, c'est totalement vide
de sens sur un way, je me demande s'il y a un outil qui l'utilise.

le détail sur https://wiki.openstreetmap.org/wiki/Key%3Anoexit
https://wiki.openstreetmap.org/wiki/Talk:Key:noexit#More_usage_instructions

le seul gros défaut, c'est le nom de la clef : validate:noexit aurait 
été parfaitement clair que c'est ni le panneau qui est renseigné
ni une information pour le routage.

PS: j'ai coupé le hors sujet... essayons de garder un titre = un sujet
c'est déjà assez dur à suivre ainsi.

Le 18. 09. 18 à 19:05, djakk djakk a écrit :
> Un tribunal, ou une université, ou une sous-préfecture, je le résumerai 
> à des emplois de bureau ...
> 
> Mais, ça n’est pas le bon sujet ! ;P
> 
> Pour les impasses, en faisant une requête overpass-turbo, je me rend 
> compte que le noexit sur les ways est pas mal utilisé malgré 
> “l’interdiction” du wiki ...
> 
> 
> djakk
> 
> 
> Le lun. 17 sept. 2018 à 15:04, JB  > a écrit :
> 
> Euh,
> On pourrait avoir une vue d'ensemble, de conflits d'intérêts
> possibles, de projets perso/professionnels derrière tout ça ?
> Ça ressemble de plus en plus à un taggage « pour mon projet ».
> D'abord on redéfinit les villes (tiens, ça aiderait bien
> pour de la moyenne/petite échelle), puis les trunk (idem),
> puis les bretelles (chouette, encore pareil), les impasses
> (on les supprimera du graphe routier). Ça râle un peu, alors
> on utilise un tag en plus «looks_like» pour ne pas modifier
> les autres. La suite, ce sera d'ajouter color=* sur les ways
> pour ne pas le coder dans la feuille de style ?
> De mauvais poil,
> JB.
> 
> Le 16/09/2018 à 15:37, djakk djakk a écrit :
>> Salut !
>> Je souhaiterai tagger des impasses (panneau “voie sans
>> issue”) afin d’avoir l’information sur toutes les way de
>> l’impasse. But = transmettre l’info au moteur de rendu.
>> Je croyais que noexit était fait pour mais apparement
>> c’est plutôt pour ne pas affoler les éditeurs sur une
>> éventuelle mauvaise connexion avec une autre way.
>> Dois-je continuer à utiliser noexit=yes sur les ways, ou
>> trouver une autre clé ?
>>
>> PS : difficile de calculer ça, pensez au réseau routier de
>> Belle-Île ;)
>>
>> djakk
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Parc de stationnement en Zone de rencontre

[Gwenaël Jouvin]

Mettre un parc de stationnement en zone de rencontre, on aura vraiment tout vu !
Ces aménageurs sont vraiment prêts à tout pour qu’on n’y comprenne plus rien… à 
se demander si eux-mêmes y comprennent quoi que ce soit.

Bref, à mon avis, les voies d’un parc de stationnement n’ont pas à être 
classées en  mais en .

Dans ce cas, on est confronté à une incompétence en matière de voirie qui 
détourne la signalisation abusivement.
Que faire ? Respecter aveuglément le terrain ou, par discernement, déformer un 
peu la réalité et rester rationnel ?

Personnellement, je choisirai sans hésiter la seconde option, en mettant une 
note explicative et un .


Gwenaël


Le 18/09/2018 à 20:05, Axelos a écrit :
> Bonjour,
> 
> Devant mon lieu de travail, il y a un parc de stationnement de plusieurs
> centaines de places qui est passé intégralement en zone de rencontre il
> y quelques mois.
> Les voies pour y accéder au parc en général, mais aussi les voies pour
> accéder aux places de stationnements.
> 
> Les données ont été que partiellement implémenté pour le moment, mais je
> me pose la question si la balise highway=living_street est suffisante
> sur les voies accédants aux places de stationnements ? N'est-il pas
> judicieux d'ajouter une autre balise en plus ?
> 
> Cordialement, Axel.
> 
> ___
> 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] Parc de stationnement en Zone de rencontre

[marc marc]

Le 18. 09. 18 à 20:05, Axelos a écrit :
> la balise highway=living_street est suffisante
> sur les voies accédants aux places de stationnements ? 

cela me semble suiffant si c'est ainsi qu'est la réalité
de la signalisation en place.

> N'est-il pas judicieux d'ajouter une autre balise en plus ?

il y a plein de tag possible en plus (surface smothness lit lanes)
mais aucune d'eux n'est indispensable, c'est des infos supplémentaires
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SOTM-FR 2019 et Fotoquest GO

[Philippe Verdy]

Je pense même que la granularité kilométrique de ce projet est même moins
bonne que l'ancien projet européen CORINE Landuse de 2006, qui n'est plsu
réellement maintenu et a tenu ses objectifs initiaux, suivis maintenant par
d'autres projets plus précis et plus utiles (dans OSM comme ailleurs).

En fin de compte, CORINE Landuse 2006 fournit déjà une meilleure base de
recherche que ce que va générer ce projet dont on sait juste précisément ce
qu'il ne veut pas collecter mais ne décrit pas du toutles usages de ce quoi
sera en fin de compte collecté et utilisé par des tiers non décrits (on
voit déjà des tiers commerciaux impliqués, dont Google)

Je pense qu'il vaut mieux faire confiance aux projets germanophones
concertés par FOSSGIS autour d'OSM même pour l'Autriche. Et sinon Mapillary
pour l'aspect photo collaborative du terrain, et les contributions
d'imageries aériennes fournies par les collectivités et distribuées sur
leur SIG ou via Bing qui les utilise et aide aussi à les financer.

L'appli me semble directement inspirée par le succès temporaire de Pokemon
Go (jusque dans son nom !) mais aussi avec ses travers. Et ce n'est pas 10
000 euros de primes, déjà épuisée pour un résultat somme toute faible et
pas utilisable pour quoi que ce soit) qui vont changer la donne. Ces 10 000
euros c'est surtout un "coup de pub" pour se faire connaitre, avant même
d'expliquer les objectifs et les méthodes et créer une réelle "communauté"
(les contributions sont surtout individuelles avec très peu d'espaces
d'échanges possibles, chacun fait dans son coin et note ce qu'il veut, et
je pense qu'au final ceux qui feront le plus et auront joué le plus se sont
précipité pour aller vite avec une qualité médiocre ou faire les endroits
les plus faciles et les mieux connus sur lesquels on avait moins besoin de
données).

Les primes versées me semble d'ailleurs excessives (1 euro minimum par
position, à l'échelle kilométrique on ne couvre pas l'Europe entière et
même pas juste l'Autriche) et vont conduire à des données fantaisistes
inventées par des gamers voulant aller le plus vite possible tant qu'il
reste des primes disponibles, et qui ne feront ensuite plus rien après si
le but c'est juste la course à cette prime et le classement dans les
meilleurs joueurs. Les objectifs ne sont pas clairs. Ca finit dans 12
jours, après on verra ce qu'il en reste.

La prime somme toute modeste, aurait été mieux versée en commençant par des
objectifs plus modestes sur une zone moins grande mais mieux décrits (et
suivis d'une phase d'évaluation) puis la création d'une communauté et
l'évaluation des besoins réels (les zones blanches où une incitation peut
être utile et aider à faire venir plus de monde dans une communauté déjà
formée et organisée et connaissant les méthodes et ayant déjà commencé à
obtenir quelques résultats significatifs): ce sont ces zones blanches qu'il
fallait primer, pas toute l'Europe et si son montant est limité, il fallait
la répartir mieux que sur seulement 10 000 points maximum épuisés sur des
zones faciles déjà bien (et même mieux) couvertes en données. Pour l'Europe
entière cette prime aurait du être à peine quelques centimes par point (ce
qui aurait aussi évité la course des gamers, qui de toute façon
retourneront vite à Pokemon Go, mieux doté en primes).

Les projets de recherche réels peuvent maintenant s'appuyer sur OSM
directement qui est un projet plus neutre et couvrant des tas de publics et
de collectivités et de besoins réels insoupçonnés mais discutés et pouvant
faire l'objet d'études plus systématiques par les collectivités ou
instituts de recherche qui vont le faire de façon plus méthodique et
systématique là où un besoin est ressenti, puis verser cela dans l'Open
Data général et dans la politique publique et celles des ONG qui
participent ou soutiennent ce développement.


Le mar. 18 sept. 2018 à 19:29, marc marc  a
écrit :

> Bonjour et bienvenu !
>
> Le 18. 09. 18 à 16:04, seb...@laposte.net a écrit :
> > Montpellier était seule candidate pour le State
> > Of The Map FR de l'année prochaine
> > je n'ai pas vu de confirmation...
>
> de mémoire cela a été annoncé sur la ml de l'association.
> Vu que l'asso a un ca ce soir, j'imagine que ce point
> est à l'ordre du jour.
>
> > Connaissez vous http://fotoquest-go.org/en/map/ ou
> > http://fotoquest-go.org/en ?
> > C'est une initiative autrichien de sciences participatives relatives
> > à l'occupation du sol.
>
> c'est dommage que cela ne soie ni collaboratif ni opendata ni même clair
> Pas convaincu non plus que cela ai la moindre utilité d'aller voir sur
> place qu'un champ est devenu un parking comme visible sur l'image sat.
> Le seul intérêt c'est que le jeune du coin peux se faire 1€/15min
> en ayant l'impression de faire avancer la science tandis que l’auteur
> pourra se faire un article sur la science participative sans rien
> y connaître ou presque, supposition de ma part vu l'aspect
> non collaboratif non ouvert.. en gros c'est un uber de la 

[OSM-talk-fr] Parc de stationnement en Zone de rencontre

[Axelos]

Bonjour,

Devant mon lieu de travail, il y a un parc de stationnement de plusieurs
centaines de places qui est passé intégralement en zone de rencontre il
y quelques mois.
Les voies pour y accéder au parc en général, mais aussi les voies pour
accéder aux places de stationnements.

Les données ont été que partiellement implémenté pour le moment, mais je
me pose la question si la balise highway=living_street est suffisante
sur les voies accédants aux places de stationnements ? N'est-il pas
judicieux d'ajouter une autre balise en plus ?

Cordialement, Axel.

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

Re: [OSM-talk-fr] Impasse

[Philippe Verdy]

Le wiki n'interdit rien. Il décrit ce qui existe ou a existé et donne des
recommandations d'usage parce que cela a été discuté. Garder ces
descriptions est utile pour savoir comment faire ensuite évoluer les choses
et quoi faire de l'existant qui était d'anciennes pratiques (en un temps où
OSM était beaucoup moins riche en infos et le réseau routier encore
balbutiant et ne s'intéressant pas encore aux modes de déplacement
alternatifs.
Ca évolue, mais lentement, et en attendant on ne casse rien brutalement.

Le mar. 18 sept. 2018 à 19:05, djakk djakk  a écrit :

> Un tribunal, ou une université, ou une sous-préfecture, je le résumerai à
> des emplois de bureau ...
>
Non ce sont des services essentiels pour la population et tous les autres
services et activités.
Et ils sont moteurs de l'attractivité d'un territoire, conditionnent
l'arrivée ou le maintien de plein d'activités (notamment les universités
qui ont un rayonnement large et ont un effet assuré sur l'habitat et les
prix des loyers).

OK les sous-préfectures (et même les préfectures de départements ou de
région) c'est très mineur (d'autant plus que les services de l'état passent
en ligne et sinon sont relayés par les mairies et services sociaux): les
arrondissements départementaux n'ont plus de réelle raison d'être, c'est
une cuisine interne de l'organisation des ressources humaines des services
de l'Etat et les délégations de signatures pour les actes officiels et le
contrôle des collectivités locales.

Elles n'ont pas d'impact réel sur le développement d'une ville, elles
emploient en fait de moins en moins de monde. De plus ce ne sont pas que
des emplois de "bureau" (les emplois administratifs sont même souvent
délocalisés, il reste juste un accueil avec une ou deux personnes une
direction et deux ou trois employés secrétaires. Mais les besoins
matériels, les services informatiques sont gérés ailleurs ou par des
prestataires externes. Les sous-préfets sont bien plus occupés à visiter
les collectivités, services de police, et des tas d'autres services
officiels décentralisés de l'état (cours des comptes, tribunaux
administratifs et d'instance) ou services parapublics (services sociaux,
chambres professionnelles...) pour lesquels ils doivent faire des
concertation ou prendre des décisions, les expliquer, les justifier, ou
arbitrer des choix budgétaires difficiles. Les personnels sous leur
responsabilité sont déployés un peu partout, car ils doivent déléguer
beaucoup localement; ils confient et délèguent sous leur contrôle des
missions à d'autres acteurs publics. Les mairies et intercommunalités ou
services publics échangent via des boites à lettre électroniques et des
systèmes informatiques, et sinon via le courrier administratif (qui est
géré et réparti aussi par divers services pas localisés tous au siège de la
préfecture ou sous-préfecture) et certains de leurs propre personnel
délégué à plusieurs missions ou choisi nominativement comme intermédiaire
après une formation et un engagement contractuel (et un accord budgétaire
pour ces délégations communes), sans que cela change leur statut vis à vis
de leur employeur public réel (car ces missions sont temporaires et
changent ou sont abandonnées constamment tandis que d'autres apparaissent,
ils veulent garder leur emploi public...).

Bref, définir ce qu'est et fait une "ville" c'est très difficile (encore
plus internationalement). cela n'a plus rien à voir avec le découpage
adminsitratif officiel qui persiste beaucoup plus que le découpage urbain,
tant il est figé par la législation et les réglementations compliquées à
modifier, adapter et faire supporter. On a besoin de critères mais un seul
ne suffit pas et surtout pas à un seul usage, on ne peut pas le réduire à
un seul tag place=* quand OSM veut permettre des usages très différents.

On a un relatif consensus international que ce tag suit à peu près la
polulation de l'unité adminsitrative autonome la plus petite représentée
par l'emplacement plus ou moins "central" du noeud portant son nom. Mais
pour aller au delà de ce critère simple, il faut un consensus et en France
ce consensus doit être national (y compris les régions d'outre-mer, hormis
les collectivités d'outre-mer qui ont chacune leur système à part et
s'insèrent en fonction aussi de leurs voisins internationaux pour garder
une certaine cohérence globale).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] zones de parcmètres

[Florian LAINEZ]

Merci pour votre aide, j'ai mis à jour la plupart des parcmètres de
Montrouge en prenant en compte vos suggestions
https://www.openstreetmap.org/changeset/62704821

Le mar. 18 sept. 2018 à 19:12, djakk djakk  a écrit :

> Ok :)
>
> Le mar. 18 sept. 2018 à 19:07, Philippe Verdy  a
> écrit :
>
>> C'est pas si hors sujet que ça ! Les stationnements isolés en slalom sont
>> aussi un problème dans OSM, difficiles à modéliser correctement sans
>> découper très fortement les rues: on doit les marquer individuellement, le
>> modèle des parking lanes ne marche pas bien pour eux. Et on constate là où
>> ils ont été mis en place que les riverains sont finalement très mécontents
>> de la physionomie que prend leur quartier mis à l'écart du reste de la
>> ville. Et ça se voit rapidement.
>>
>> On a réduit de façon mineure un problème pour en créer d'autres bien plus
>> graves qui se font sentir rapidement (fermeture des commerces, désertion
>> des services publics, suppression/détournement des lignes de transport,
>> baisse de la valeur en revente des résidences. Difficultés d'accès pour les
>> livraisons, temps de parcours allongés, même augmentation du danger pour
>> les cyclistes, coût des accidents, absence de présence de la police (sauf
>> pour verbaliser les résidents!), hausse des assurances et des incivilités
>> et de la criminalité...
>>
>> Ces rues n'étant plus très visibles, les municipalités arrêtent aussi
>> d'entretenir les espaces verts, la collecte et le recyclage des ordures
>> ménagères devient compliquée. Ces quartiers devenus des ilots isolés se
>> dégradent vite et vite se transforment en ghettos délaissés. Les
>> propriétaires cessent aussi l'entretien régulier des locations ou leurs
>> locations ne trouvent plus preneur et les tarifs baissent alors que la
>> pression immobilière s'accroît encore plus dans les centres-villes qui
>> restent bien desservis par les transports même quand il y a des zones
>> piétonnes (qui ne concernent pas ces zones résidentielles mises à l'écart).
>>
>> Je ne suis pas du tout convaincu que ce système a même renforcé la
>> sécurité routière et que cela a accu encore plus le prix des places de
>> stationnement ailleurs: cela accroit le saupoudrage résidentiel périurbain
>> et la pression publique pour des lignes périurbaines supplémentaires, et de
>> façon générale le besoin accru en transports publics (de plus en plus
>> couteux pour les intercommunalités) et les temps de transports. Au final,
>> on déplace le problème et renforce la pression des espaces dédiés aux
>> voitures dans les zones périurbaines "rurbanisées" (pas mieux loties an
>> services publics, mais avec plus de constructions de parkings et une
>> artificialisation accrue des sols et un gaspillage des espaces ruraux
>> naturels et agricoles).
>>
>> Je ne pense pas que c'est comme ça qu'on va réduire l'usage global de la
>> voiture particulière ni apporter une réelle "tranquilité" pour les
>> résidents de ces rues transformées en îles-ghettos. Au final on force des
>> populations à aller plus loin alors que la ville devrait au contraire se
>> densifier et se mixifier davantage.
>>
>> Le mar. 18 sept. 2018 à 17:30, djakk djakk  a
>> écrit :
>>
>>> Houlà sur le dernier paragraphe tu es parti dans un sacré hors-sujet je
>>> trouve :)
>>>
>>> Il faut effectivement ne pas avoir à découper le polygone sinon c’est
>>> pas la peine.
>>>
>>>
>>> djakk
>>>
>>>
>>> Le mar. 18 sept. 2018 à 17:26, Philippe Verdy  a
>>> écrit :
>>>
 note : les polygones s'appliquent essentiellement au stationnement le
 long des voies publiques, mais excluent les aires de staionnement avec
 entrées/sorties de parking dédiées qui ont leurs propres règles.
 Ils doivent aussi exclure les parkings privés, les voies privées. Je me
 demande l'intérêt de ces zones difficiles à délimiter sans couper des tas
 de bâtiments et propriétés et à exploiter quand il y a aura de nombreux
 trous disséminés.
 Je pense que cela devrait plutôt être tagué le long des voies, en même
 temps que les "parking lanes" et où sont disposés (à vue) aussi les
 horodateurs ou les panneaux de restriction d'usage ("sauf jours de marché à
 certaines heures", stationnement alterné par quinzaine, gratuit mais disque
 obligatoire, dépose-minute gratuite avec arrêt autorisé mais pas le
 stationnement sans conducteur visible à proximité immédiate ou encore au
 volant de plus de 5 minutes, 2 minutes dans les aéroports où on passe une
 barrière avec un ticket qui facturera en sortie les premières secondes de
 dépassement, car dans ce cas cela devient payant dès la première minute aux
 horodateurs).
 En gros les zones de stationnement sont peut-être affichées
 sommairement sur les sites des municipalités, à titre informatif, mais le
 terrain détaille les conditions réelles avec une précision bien supérieure
 et un équipement ou marquage détaillé.

 Taguer au niveau des voies publiques 

Re: [OSM-talk-fr] SOTM-FR 2019 et Fotoquest GO

[marc marc]

Bonjour et bienvenu !

Le 18. 09. 18 à 16:04, seb...@laposte.net a écrit :
> Montpellier était seule candidate pour le State 
> Of The Map FR de l'année prochaine
> je n'ai pas vu de confirmation...

de mémoire cela a été annoncé sur la ml de l'association.
Vu que l'asso a un ca ce soir, j'imagine que ce point
est à l'ordre du jour.

> Connaissez vous http://fotoquest-go.org/en/map/ ou 
> http://fotoquest-go.org/en ?
> C'est une initiative autrichien de sciences participatives relatives 
> à l'occupation du sol.

c'est dommage que cela ne soie ni collaboratif ni opendata ni même clair
Pas convaincu non plus que cela ai la moindre utilité d'aller voir sur 
place qu'un champ est devenu un parking comme visible sur l'image sat.
Le seul intérêt c'est que le jeune du coin peux se faire 1€/15min
en ayant l'impression de faire avancer la science tandis que l’auteur 
pourra se faire un article sur la science participative sans rien
y connaître ou presque, supposition de ma part vu l'aspect
non collaboratif non ouvert.. en gros c'est un uber de la photo.

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

Re: [OSM-talk-fr] zones de parcmètres

[djakk djakk]

Ok :)

Le mar. 18 sept. 2018 à 19:07, Philippe Verdy  a écrit :

> C'est pas si hors sujet que ça ! Les stationnements isolés en slalom sont
> aussi un problème dans OSM, difficiles à modéliser correctement sans
> découper très fortement les rues: on doit les marquer individuellement, le
> modèle des parking lanes ne marche pas bien pour eux. Et on constate là où
> ils ont été mis en place que les riverains sont finalement très mécontents
> de la physionomie que prend leur quartier mis à l'écart du reste de la
> ville. Et ça se voit rapidement.
>
> On a réduit de façon mineure un problème pour en créer d'autres bien plus
> graves qui se font sentir rapidement (fermeture des commerces, désertion
> des services publics, suppression/détournement des lignes de transport,
> baisse de la valeur en revente des résidences. Difficultés d'accès pour les
> livraisons, temps de parcours allongés, même augmentation du danger pour
> les cyclistes, coût des accidents, absence de présence de la police (sauf
> pour verbaliser les résidents!), hausse des assurances et des incivilités
> et de la criminalité...
>
> Ces rues n'étant plus très visibles, les municipalités arrêtent aussi
> d'entretenir les espaces verts, la collecte et le recyclage des ordures
> ménagères devient compliquée. Ces quartiers devenus des ilots isolés se
> dégradent vite et vite se transforment en ghettos délaissés. Les
> propriétaires cessent aussi l'entretien régulier des locations ou leurs
> locations ne trouvent plus preneur et les tarifs baissent alors que la
> pression immobilière s'accroît encore plus dans les centres-villes qui
> restent bien desservis par les transports même quand il y a des zones
> piétonnes (qui ne concernent pas ces zones résidentielles mises à l'écart).
>
> Je ne suis pas du tout convaincu que ce système a même renforcé la
> sécurité routière et que cela a accu encore plus le prix des places de
> stationnement ailleurs: cela accroit le saupoudrage résidentiel périurbain
> et la pression publique pour des lignes périurbaines supplémentaires, et de
> façon générale le besoin accru en transports publics (de plus en plus
> couteux pour les intercommunalités) et les temps de transports. Au final,
> on déplace le problème et renforce la pression des espaces dédiés aux
> voitures dans les zones périurbaines "rurbanisées" (pas mieux loties an
> services publics, mais avec plus de constructions de parkings et une
> artificialisation accrue des sols et un gaspillage des espaces ruraux
> naturels et agricoles).
>
> Je ne pense pas que c'est comme ça qu'on va réduire l'usage global de la
> voiture particulière ni apporter une réelle "tranquilité" pour les
> résidents de ces rues transformées en îles-ghettos. Au final on force des
> populations à aller plus loin alors que la ville devrait au contraire se
> densifier et se mixifier davantage.
>
> Le mar. 18 sept. 2018 à 17:30, djakk djakk  a
> écrit :
>
>> Houlà sur le dernier paragraphe tu es parti dans un sacré hors-sujet je
>> trouve :)
>>
>> Il faut effectivement ne pas avoir à découper le polygone sinon c’est pas
>> la peine.
>>
>>
>> djakk
>>
>>
>> Le mar. 18 sept. 2018 à 17:26, Philippe Verdy  a
>> écrit :
>>
>>> note : les polygones s'appliquent essentiellement au stationnement le
>>> long des voies publiques, mais excluent les aires de staionnement avec
>>> entrées/sorties de parking dédiées qui ont leurs propres règles.
>>> Ils doivent aussi exclure les parkings privés, les voies privées. Je me
>>> demande l'intérêt de ces zones difficiles à délimiter sans couper des tas
>>> de bâtiments et propriétés et à exploiter quand il y a aura de nombreux
>>> trous disséminés.
>>> Je pense que cela devrait plutôt être tagué le long des voies, en même
>>> temps que les "parking lanes" et où sont disposés (à vue) aussi les
>>> horodateurs ou les panneaux de restriction d'usage ("sauf jours de marché à
>>> certaines heures", stationnement alterné par quinzaine, gratuit mais disque
>>> obligatoire, dépose-minute gratuite avec arrêt autorisé mais pas le
>>> stationnement sans conducteur visible à proximité immédiate ou encore au
>>> volant de plus de 5 minutes, 2 minutes dans les aéroports où on passe une
>>> barrière avec un ticket qui facturera en sortie les premières secondes de
>>> dépassement, car dans ce cas cela devient payant dès la première minute aux
>>> horodateurs).
>>> En gros les zones de stationnement sont peut-être affichées sommairement
>>> sur les sites des municipalités, à titre informatif, mais le terrain
>>> détaille les conditions réelles avec une précision bien supérieure et un
>>> équipement ou marquage détaillé.
>>>
>>> Taguer au niveau des voies publiques sera nettement supérieur (et on
>>> pourra aussi délimiter les véritables "parking lanes" ont il y a
>>> effectivement des places, ou des emplacements individuels qu'on peut taguer
>>> directement
>>>
>>> Les emplacements individuels sont dans des rues résidentielles de plus
>>> en plus nombreuses où les 

Re: [OSM-talk-fr] zones de parcmètres

[Philippe Verdy]

C'est pas si hors sujet que ça ! Les stationnements isolés en slalom sont
aussi un problème dans OSM, difficiles à modéliser correctement sans
découper très fortement les rues: on doit les marquer individuellement, le
modèle des parking lanes ne marche pas bien pour eux. Et on constate là où
ils ont été mis en place que les riverains sont finalement très mécontents
de la physionomie que prend leur quartier mis à l'écart du reste de la
ville. Et ça se voit rapidement.

On a réduit de façon mineure un problème pour en créer d'autres bien plus
graves qui se font sentir rapidement (fermeture des commerces, désertion
des services publics, suppression/détournement des lignes de transport,
baisse de la valeur en revente des résidences. Difficultés d'accès pour les
livraisons, temps de parcours allongés, même augmentation du danger pour
les cyclistes, coût des accidents, absence de présence de la police (sauf
pour verbaliser les résidents!), hausse des assurances et des incivilités
et de la criminalité...

Ces rues n'étant plus très visibles, les municipalités arrêtent aussi
d'entretenir les espaces verts, la collecte et le recyclage des ordures
ménagères devient compliquée. Ces quartiers devenus des ilots isolés se
dégradent vite et vite se transforment en ghettos délaissés. Les
propriétaires cessent aussi l'entretien régulier des locations ou leurs
locations ne trouvent plus preneur et les tarifs baissent alors que la
pression immobilière s'accroît encore plus dans les centres-villes qui
restent bien desservis par les transports même quand il y a des zones
piétonnes (qui ne concernent pas ces zones résidentielles mises à l'écart).

Je ne suis pas du tout convaincu que ce système a même renforcé la sécurité
routière et que cela a accu encore plus le prix des places de stationnement
ailleurs: cela accroit le saupoudrage résidentiel périurbain et la pression
publique pour des lignes périurbaines supplémentaires, et de façon générale
le besoin accru en transports publics (de plus en plus couteux pour les
intercommunalités) et les temps de transports. Au final, on déplace le
problème et renforce la pression des espaces dédiés aux voitures dans les
zones périurbaines "rurbanisées" (pas mieux loties an services publics,
mais avec plus de constructions de parkings et une artificialisation accrue
des sols et un gaspillage des espaces ruraux naturels et agricoles).

Je ne pense pas que c'est comme ça qu'on va réduire l'usage global de la
voiture particulière ni apporter une réelle "tranquilité" pour les
résidents de ces rues transformées en îles-ghettos. Au final on force des
populations à aller plus loin alors que la ville devrait au contraire se
densifier et se mixifier davantage.

Le mar. 18 sept. 2018 à 17:30, djakk djakk  a écrit :

> Houlà sur le dernier paragraphe tu es parti dans un sacré hors-sujet je
> trouve :)
>
> Il faut effectivement ne pas avoir à découper le polygone sinon c’est pas
> la peine.
>
>
> djakk
>
>
> Le mar. 18 sept. 2018 à 17:26, Philippe Verdy  a
> écrit :
>
>> note : les polygones s'appliquent essentiellement au stationnement le
>> long des voies publiques, mais excluent les aires de staionnement avec
>> entrées/sorties de parking dédiées qui ont leurs propres règles.
>> Ils doivent aussi exclure les parkings privés, les voies privées. Je me
>> demande l'intérêt de ces zones difficiles à délimiter sans couper des tas
>> de bâtiments et propriétés et à exploiter quand il y a aura de nombreux
>> trous disséminés.
>> Je pense que cela devrait plutôt être tagué le long des voies, en même
>> temps que les "parking lanes" et où sont disposés (à vue) aussi les
>> horodateurs ou les panneaux de restriction d'usage ("sauf jours de marché à
>> certaines heures", stationnement alterné par quinzaine, gratuit mais disque
>> obligatoire, dépose-minute gratuite avec arrêt autorisé mais pas le
>> stationnement sans conducteur visible à proximité immédiate ou encore au
>> volant de plus de 5 minutes, 2 minutes dans les aéroports où on passe une
>> barrière avec un ticket qui facturera en sortie les premières secondes de
>> dépassement, car dans ce cas cela devient payant dès la première minute aux
>> horodateurs).
>> En gros les zones de stationnement sont peut-être affichées sommairement
>> sur les sites des municipalités, à titre informatif, mais le terrain
>> détaille les conditions réelles avec une précision bien supérieure et un
>> équipement ou marquage détaillé.
>>
>> Taguer au niveau des voies publiques sera nettement supérieur (et on
>> pourra aussi délimiter les véritables "parking lanes" ont il y a
>> effectivement des places, ou des emplacements individuels qu'on peut taguer
>> directement
>>
>> Les emplacements individuels sont dans des rues résidentielles de plus en
>> plus nombreuses où les municipalités les installent avec sens de
>> circulation prioritaire alterné en "slalom" , pour ne garder qu'une voie à
>> côté des emplacements, la deuxième formant des zones d'attente. Le but de
>> ces 

Re: [OSM-talk-fr] Impasse

[djakk djakk]

Un tribunal, ou une université, ou une sous-préfecture, je le résumerai à
des emplois de bureau ...

Mais, ça n’est pas le bon sujet ! ;P

Pour les impasses, en faisant une requête overpass-turbo, je me rend compte
que le noexit sur les ways est pas mal utilisé malgré “l’interdiction” du
wiki ...


djakk


Le lun. 17 sept. 2018 à 20:57, Philippe Verdy  a écrit :

> J'en reviens donc à l'idée d'ajouter dans OSM les limites des unités
> urbaines (au sens de l'INSEE) maintenant fixées plus ou moins sur les
> "pays" (anciens pays Voynet, réformés par les lois depuis 2014, dont la loi
> SRU et maintenant composés d'intercommunalités entières).
>
> Ca limite l'impact : le Pays de Rennes par exemple comprend Rennes
> Métropole dont Rennes est la "ville" centre. mais les autres
> intercommunalités autour n'ont pas de "ville" ("city") centre. Mais au
> mieux des "town".  ET on évite des trucs classés par djakk comme "city"
> tels que, en Bretagne: Callac, Merdrignac, Collinée, Plélan-le-Grand. En
> revanche, Redon et Fougères passent le critère en tant que ville centre de
> leur pays... mais pas Vitré (exception due cependant à la dualité de
> l'arrondissement de Fougères-Vitré où l'Etat a accepté de maintenir des
> services délocalisés à Vitré).
>
> On pourrait avoir d'autres critères comme la présence d'un tribunal
> d'instance ou un tribunal du commerce mais la réforme profonde de
> l'institution judiciaire en fait fermer beaucoup...
>
> La présence d'une université est discutable (les universités bretonnes ont
> ouvert diverses "antennes" hors de leur siège) mais est pourtant un signe
> de dynamisme économique des commerces et services. La présence d'un lycée
> ne me parait pas pertinente ou suffisante (des lycées déménagent aussi pour
> s'installer en périphérie des villes). Mais pour les universités (publiques
> ou reconnues d'intéret public comme lm'université catholique d'Angers...
> une exception qu'on n'a pas besoin de gérer car Angers est clairement déjà
> une ville sans ce critère et a aussi une université publique) on a une
> liste complète facilement atteignable.
>
>
>
>
> Le lun. 17 sept. 2018 à 20:44, Philippe Verdy  a
> écrit :
>
>> Je vois que djakk continue de changer les villes en Bretagne, Pays de la
>> Loire, Normandie. Apparemmetn il a pris le parti pris d'upgrader les
>> communes centre des intercommunalités, mais attention elles bougent
>> beaucoup, et leur siège n'est pas toujours dans la ville centre (au sens du
>> zonage urbain de l'INSEE).
>>
>> Je pense que l'upgrade ne devrait concerner QUE les villes centre des
>> "pays" (ayant un ou plusieurs SCOTs, il y en a plusieurs généralement quand
>> un des EPCI est une métropole ou une communauté urbaine, pas une simple
>> communauté d'agglomération), et que les pays sont plus ou moins calqué sur
>> les "unités urbaines" de l'INSEE, ou sinon les villes centre des aires
>> urbaines de population suffisante.
>>
>> Mais on n'a pas encore défini les seuils, pour se passer de la règle
>> actuelle de la population municipale (où on garde certaines exptions pour
>> les seuils quasiment atteints ou qui ont été atteints il y a encore peu de
>> temps, pas plus de 20 ans AMHA, même si la population a légèrement baissé
>> depuis, ou si c'est une ville chef-lieu de département, en excluant les
>> chef-lieux d'arrondissements en phase de désuétude, et upgradant en "city"
>> les villes chef-lieux de régions (celles d'avant la réforme de fusion des
>> régions) y compris les régions d'autre-mer, mais pas les petites
>> collectivités d'outre-mer insulaires (elles ont déjà un capital=3 mais si
>> on parle de Saint-Pierre à CPM, c'est clairement pas une "city" au
>> détriment des villes canadiennes voisines comme Halifax)
>>
>> On a des données objectives sur les unités urbaines et les aires urbaines.
>>
>> Le lun. 17 sept. 2018 à 15:04, JB  a écrit :
>>
>>> Euh,
>>> On pourrait avoir une vue d'ensemble, de conflits d'intérêts possibles,
>>> de projets perso/professionnels derrière tout ça ?
>>> Ça ressemble de plus en plus à un taggage « pour mon projet ».
>>> D'abord on redéfinit les villes (tiens, ça aiderait bien pour de la
>>> moyenne/petite échelle), puis les trunk (idem), puis les bretelles
>>> (chouette, encore pareil), les impasses (on les supprimera du graphe
>>> routier). Ça râle un peu, alors on utilise un tag en plus «looks_like» pour
>>> ne pas modifier les autres. La suite, ce sera d'ajouter color=* sur les
>>> ways pour ne pas le coder dans la feuille de style ?
>>> De mauvais poil,
>>> JB.
>>>
>>> Le 16/09/2018 à 15:37, djakk djakk a écrit :
>>>
>>> Salut !
>>> Je souhaiterai tagger des impasses (panneau “voie sans issue”) afin
>>> d’avoir l’information sur toutes les way de l’impasse. But = transmettre
>>> l’info au moteur de rendu.
>>> Je croyais que noexit était fait pour mais apparement c’est plutôt pour
>>> ne pas affoler les éditeurs sur une éventuelle mauvaise connexion avec une
>>> autre way.
>>> Dois-je continuer à utiliser noexit=yes 

Re: [OSM-talk-fr] Changement unilatéral de la définition de tags

[djakk djakk]

Ok ok j’ai tout « revert » y compris sur le wiki (sauf l’annulation de
Jérôme qui n’a pas fait de « undo » dans le wiki - j’ai pas vérifié si le
contenu est cohérent).
L’argument qui a fait mouche chez moi : l’absence de retro-compatibilité.

Je présenterai sur la mailing-list tagging (mondiale) un moyen d’arriver à
une définition commune dans le monde entier pour la définition des routes,
en contournant l’actuelle clé highway au lieu de changer brutalement la
définition de ses valeurs. Je trouve que c’est améliorer Openstreetmap de
gommer (autant que possible) les différences entre pays sur les définitions
de valeurs.
(Comment ? en décomposant ce qui fait une route, de l’aspect visuel à la
définition administrative à l’utilisation plus ou moins intensive, pour du
trajet interurbain ou du trajet intra-urbain).


@+
djakk


Le mar. 18 sept. 2018 à 09:31, Christian Quest  a
écrit :

> Le dim. 16 sept. 2018 à 15:43, djakk djakk  a
> écrit :
>
>> Je pense que je rajoute de l’information sans en supprimer ... ? Bon
>> certes je chamboule l’existant ...
>>
>> djakk
>>
>
> Dommage de procéder ainsi "en force".
>
> Le tagging sur OSM fonctionne grâce à un consensus, il faut le respecter
> ou ouvrir une discussion (large) pour faire naître un nouveau consensus et
> ne pas "chambouler" ainsi l'existant, au risque d'un douloureux retour de
> flamme.
>
>
> --
> 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

Re: [OSM-talk-fr] SOTM-FR 2019 et Fotoquest GO

[djakk djakk]

Bonjour sebseb ! Bienvenue !

Oh, le fond de carte de fotoquest est openstreetmap :) Il y aura peut être
un entrefilet dans weeklyosm à ce sujet ?


djakk


Le mar. 18 sept. 2018 à 17:43, Philippe Verdy  a écrit :

> En gros c'est une sorte de Pokemon Go pour trouver un trésor (1 ou 2 euros
> par photo géolocalisée au point prédéfini, les points étant disposés sur un
> maillage carré quasi régulier tous les kilomètres, cela fait juste une
> photo par kilomètre carré. Mais les points désignés sont choisis un peu au
> hasard et pas accessibles (les photos les plus valorisées sont au milieu de
> lacs ou étangs ou dans des zones privées).
>
> Je ne vois pas trop ce que va faire l'aspect scientifique du projet avec
> des photos sur un maillage aussi lâche. Si toutes les emplacements proposés
> sont visités, cela coûterait une fortune et je doute de la rentabilité
> réelle. Pour moi c'est plus un jeu mobile comme Pokemon Go, mais on ne peut
> pas y jouer longtemps ou on oblige les joueurs à prendre des risques et
> bafouer la loi et le droit privé, et aussi dépenser beaucoup en déplacement
> (bien plus que la rémunération proposée au final chaque joueur ne fera
> qu'un cliché ou deux et l'appli ensuite ne sert plus à grand chose, sauf
> comme support de diffusion publicitaire).
>
> Je me demande même si l'appli n'est pas là non pas pour obtenir les
> photos, mais plutôt les parcours géolocalisés utilisés pour parvenir aux
> points proposés, et mesurer les temps d'accès, bref collecter les traces
> GPS (plus ou moins précises sur les mobiles) encore très utilisées en
> Allemagne.
>
> Si l'appli ne décolle pas en France (sauf quelques points visités ça et là
> sans doute par des visiteurs germanophones) c'est parce qu'elle n'a aucune
> description en français, et la page "à propos" en allemand mélange tout y
> compris des clauses de vie privée (pour le RGPD sans doute) assez obscures.
> J'ai donc du mal à être convaincu du bénéfice qu'on aurait en France, en
> comparaison de Mapillary qui a des buts plus clairs, et sinon de l'imagerie
> aérienne (maintenant de très bonne qualité en France métropolitaine) et des
> données open data des services publics et exploitants privés de concessions
> publiques.
>
>
>
> Le mar. 18 sept. 2018 à 16:06,  a écrit :
>
>>
>>
>> Bonjour à tous,
>> je suis nouveau sur la liste mais je suis un peu OSM depuis quelques mois.
>> J'avais 2 sujets à aborder, je ne sais pas trop si l'endroit s'y prête
>> mais à tout hasard ;)
>>
>> J'ai vu que la ville de Montpellier était seule candidate pour le State
>> Of The Map FR de l'année prochaine
>> et sauf erreur de ma part la date de proclamation des résultats est
>> dépassée mais je n'ai pas vu de confirmation...
>> J'ai loupé quelque chose ?
>>
>> Autre sujet qui cette fois ne concerne pas vraiment OSM mais que je
>> souhaite évoquer ;)
>> Connaissez vous http://fotoquest-go.org/en/map/ ou
>> http://fotoquest-go.org/en ?
>> C'est une initiative autrichien de sciences participatives relatives à
>> l'occupation du sol.
>> A priori ça n'a pas trop de succès, notamment sur le territoire français
>> mais je trouve le sujet intéressant.
>>
>> Bien cordialement
>> S. Silvestre
>>
>> ___
>> 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] SOTM-FR 2019 et Fotoquest GO

[Philippe Verdy]

Note : le jeu payant est déjà presque terminé, la limite était fixée à fin
septembre et 10 000 € en tout.  Bref cette "prime" n'est pas destinée à
faire "gagner de l'argent" comme le site l'annonce ("earn money"), mais à
lancer le jeu et assurer sa promotion. La prime est certainement déjà
épuisée en Autriche où le jeu a été lancé, si on regarde la densité des
"points rouges" des missions proposées accomplies. Et on est loin de
couvrir l'Europe entière.

Il reste que le but scientifique est mal détaillé, et les clauses de vie
privée pour le RGPD sont assez obscures. De plus pas de garantie de
produire la moindre donnée open data utilisable. Ce n'est pas bien clair,
même si pouir fonctionner cette appli mobile utilise les données OSM et ses
cartes dérivées.

Comment ont été attribuées les valorisations des missions ? Apparemment en
favorisant les parcs naturels. Pourtant l'appli cherche à recenser des
zones habitées et des zones de culture et identifier ces cultures et même
en Autriche (où ces surfaces sont très morcelées à cause du relief), je
doute qu'ils puissent obtenir quelquechose d'utilisable autre que les
traces GPS, même avec leur questionnaire à remplir à l'arrivée.
Même statistiquement cette collecte aléatoire ne sera pas significative, la
distribution finale des points visités (et rémunérés) étant très orientée,
elle ne permettra pas d'obtenir des résultats significatifs sur une zone
aussi grande que l'Europe entière.

Est-ce une façon de relancer la mise à jour de l'ancien CORINE par une
implications participative? Est-ce que finalement OSM lui-même ne fait pas
déjà cela en mieux et de façon globalement plus uniforme? L'appli est-elle
finalement adaptée à ce qui est réellement cherché ?

Le mar. 18 sept. 2018 à 17:42, Philippe Verdy  a écrit :

> En gros c'est une sorte de Pokemon Go pour trouver un trésor (1 ou 2 euros
> par photo géolocalisée au point prédéfini, les points étant disposés sur un
> maillage carré quasi régulier tous les kilomètres, cela fait juste une
> photo par kilomètre carré. Mais les points désignés sont choisis un peu au
> hasard et pas accessibles (les photos les plus valorisées sont au milieu de
> lacs ou étangs ou dans des zones privées).
>
> Je ne vois pas trop ce que va faire l'aspect scientifique du projet avec
> des photos sur un maillage aussi lâche. Si toutes les emplacements proposés
> sont visités, cela coûterait une fortune et je doute de la rentabilité
> réelle. Pour moi c'est plus un jeu mobile comme Pokemon Go, mais on ne peut
> pas y jouer longtemps ou on oblige les joueurs à prendre des risques et
> bafouer la loi et le droit privé, et aussi dépenser beaucoup en déplacement
> (bien plus que la rémunération proposée au final chaque joueur ne fera
> qu'un cliché ou deux et l'appli ensuite ne sert plus à grand chose, sauf
> comme support de diffusion publicitaire).
>
> Je me demande même si l'appli n'est pas là non pas pour obtenir les
> photos, mais plutôt les parcours géolocalisés utilisés pour parvenir aux
> points proposés, et mesurer les temps d'accès, bref collecter les traces
> GPS (plus ou moins précises sur les mobiles) encore très utilisées en
> Allemagne.
>
> Si l'appli ne décolle pas en France (sauf quelques points visités ça et là
> sans doute par des visiteurs germanophones) c'est parce qu'elle n'a aucune
> description en français, et la page "à propos" en allemand mélange tout y
> compris des clauses de vie privée (pour le RGPD sans doute) assez obscures.
> J'ai donc du mal à être convaincu du bénéfice qu'on aurait en France, en
> comparaison de Mapillary qui a des buts plus clairs, et sinon de l'imagerie
> aérienne (maintenant de très bonne qualité en France métropolitaine) et des
> données open data des services publics et exploitants privés de concessions
> publiques.
>
>
>
> Le mar. 18 sept. 2018 à 16:06,  a écrit :
>
>>
>>
>> Bonjour à tous,
>> je suis nouveau sur la liste mais je suis un peu OSM depuis quelques mois.
>> J'avais 2 sujets à aborder, je ne sais pas trop si l'endroit s'y prête
>> mais à tout hasard ;)
>>
>> J'ai vu que la ville de Montpellier était seule candidate pour le State
>> Of The Map FR de l'année prochaine
>> et sauf erreur de ma part la date de proclamation des résultats est
>> dépassée mais je n'ai pas vu de confirmation...
>> J'ai loupé quelque chose ?
>>
>> Autre sujet qui cette fois ne concerne pas vraiment OSM mais que je
>> souhaite évoquer ;)
>> Connaissez vous http://fotoquest-go.org/en/map/ ou
>> http://fotoquest-go.org/en ?
>> C'est une initiative autrichien de sciences participatives relatives à
>> l'occupation du sol.
>> A priori ça n'a pas trop de succès, notamment sur le territoire français
>> mais je trouve le sujet intéressant.
>>
>> Bien cordialement
>> S. Silvestre
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
___
Talk-fr mailing list

Re: [OSM-talk-fr] SOTM-FR 2019 et Fotoquest GO

[Philippe Verdy]

En gros c'est une sorte de Pokemon Go pour trouver un trésor (1 ou 2 euros
par photo géolocalisée au point prédéfini, les points étant disposés sur un
maillage carré quasi régulier tous les kilomètres, cela fait juste une
photo par kilomètre carré. Mais les points désignés sont choisis un peu au
hasard et pas accessibles (les photos les plus valorisées sont au milieu de
lacs ou étangs ou dans des zones privées).

Je ne vois pas trop ce que va faire l'aspect scientifique du projet avec
des photos sur un maillage aussi lâche. Si toutes les emplacements proposés
sont visités, cela coûterait une fortune et je doute de la rentabilité
réelle. Pour moi c'est plus un jeu mobile comme Pokemon Go, mais on ne peut
pas y jouer longtemps ou on oblige les joueurs à prendre des risques et
bafouer la loi et le droit privé, et aussi dépenser beaucoup en déplacement
(bien plus que la rémunération proposée au final chaque joueur ne fera
qu'un cliché ou deux et l'appli ensuite ne sert plus à grand chose, sauf
comme support de diffusion publicitaire).

Je me demande même si l'appli n'est pas là non pas pour obtenir les photos,
mais plutôt les parcours géolocalisés utilisés pour parvenir aux points
proposés, et mesurer les temps d'accès, bref collecter les traces GPS (plus
ou moins précises sur les mobiles) encore très utilisées en Allemagne.

Si l'appli ne décolle pas en France (sauf quelques points visités ça et là
sans doute par des visiteurs germanophones) c'est parce qu'elle n'a aucune
description en français, et la page "à propos" en allemand mélange tout y
compris des clauses de vie privée (pour le RGPD sans doute) assez obscures.
J'ai donc du mal à être convaincu du bénéfice qu'on aurait en France, en
comparaison de Mapillary qui a des buts plus clairs, et sinon de l'imagerie
aérienne (maintenant de très bonne qualité en France métropolitaine) et des
données open data des services publics et exploitants privés de concessions
publiques.



Le mar. 18 sept. 2018 à 16:06,  a écrit :

>
>
> Bonjour à tous,
> je suis nouveau sur la liste mais je suis un peu OSM depuis quelques mois.
> J'avais 2 sujets à aborder, je ne sais pas trop si l'endroit s'y prête
> mais à tout hasard ;)
>
> J'ai vu que la ville de Montpellier était seule candidate pour le State Of
> The Map FR de l'année prochaine
> et sauf erreur de ma part la date de proclamation des résultats est
> dépassée mais je n'ai pas vu de confirmation...
> J'ai loupé quelque chose ?
>
> Autre sujet qui cette fois ne concerne pas vraiment OSM mais que je
> souhaite évoquer ;)
> Connaissez vous http://fotoquest-go.org/en/map/ ou
> http://fotoquest-go.org/en ?
> C'est une initiative autrichien de sciences participatives relatives à
> l'occupation du sol.
> A priori ça n'a pas trop de succès, notamment sur le territoire français
> mais je trouve le sujet intéressant.
>
> Bien cordialement
> S. Silvestre
>
> ___
> 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] zones de parcmètres

[djakk djakk]

(Je répondais à Philippe)

Le mar. 18 sept. 2018 à 17:30, djakk djakk  a écrit :

> Houlà sur le dernier paragraphe tu es parti dans un sacré hors-sujet je
> trouve :)
>
> Il faut effectivement ne pas avoir à découper le polygone sinon c’est pas
> la peine.
>
>
> djakk
>
>
> Le mar. 18 sept. 2018 à 17:26, Philippe Verdy  a
> écrit :
>
>> note : les polygones s'appliquent essentiellement au stationnement le
>> long des voies publiques, mais excluent les aires de staionnement avec
>> entrées/sorties de parking dédiées qui ont leurs propres règles.
>> Ils doivent aussi exclure les parkings privés, les voies privées. Je me
>> demande l'intérêt de ces zones difficiles à délimiter sans couper des tas
>> de bâtiments et propriétés et à exploiter quand il y a aura de nombreux
>> trous disséminés.
>> Je pense que cela devrait plutôt être tagué le long des voies, en même
>> temps que les "parking lanes" et où sont disposés (à vue) aussi les
>> horodateurs ou les panneaux de restriction d'usage ("sauf jours de marché à
>> certaines heures", stationnement alterné par quinzaine, gratuit mais disque
>> obligatoire, dépose-minute gratuite avec arrêt autorisé mais pas le
>> stationnement sans conducteur visible à proximité immédiate ou encore au
>> volant de plus de 5 minutes, 2 minutes dans les aéroports où on passe une
>> barrière avec un ticket qui facturera en sortie les premières secondes de
>> dépassement, car dans ce cas cela devient payant dès la première minute aux
>> horodateurs).
>> En gros les zones de stationnement sont peut-être affichées sommairement
>> sur les sites des municipalités, à titre informatif, mais le terrain
>> détaille les conditions réelles avec une précision bien supérieure et un
>> équipement ou marquage détaillé.
>>
>> Taguer au niveau des voies publiques sera nettement supérieur (et on
>> pourra aussi délimiter les véritables "parking lanes" ont il y a
>> effectivement des places, ou des emplacements individuels qu'on peut taguer
>> directement
>>
>> Les emplacements individuels sont dans des rues résidentielles de plus en
>> plus nombreuses où les municipalités les installent avec sens de
>> circulation prioritaire alterné en "slalom" , pour ne garder qu'une voie à
>> côté des emplacements, la deuxième formant des zones d'attente. Le but de
>> ces places étant de réduire la vitesse et forcer les véhicules à rouler au
>> pas (pas évident quand on en trouve même dans des rues où circulent des bus
>> et camions: ce sont des places pour jouer à l'auto-tamponneuse, les
>> véhicules stationnés sont régulièrement heurtés ou leurs ailes froissées
>> par les véhicules longs comme les bus...) et aussi détourner le trafic vers
>> d'autres avenues et vers la périphérie. ils ont remplacé les côtés de
>> stationnement (le stationnement par côté alterné disparait un peu partout)
>> et réduit largement le nombre de places disponibles, pour forcer les
>> résidents ou visiteurs à utiliser les parkings extérieurs et les transports
>> en commun dans le centre. Ces places isolées en slalom sont souvent
>> gratuites (au risque et péril du propriétaire du véhicule) car la
>> municipalité ne veut pas prendre le risque d'une responsabilité en cas de
>> pépin. Les résidents qui n'ont pas de garage sont bien en peine de se garer
>> ou doivent payer cher des stationnements loin de chez eux ou louer des
>> garages privés, ils hésitent à y garer leur véhicule la nuit car ces
>> emplacements sont dangereux, les accidents nombreux surtout en hiver. Les
>> livraisons à domicile sont également difficiles, comme les déménagements.
>>
>> Si le but était de réduire la vitesse ou le traffic, il était suffisant
>> de mettre des coussins ou dos d'âne, mais ce sont les cyclistes et motards
>> qui se plaignent de leur dangerosité. Ces slaloms sont égalemetn dangereux
>> en toute saison et à toute heure pour les cyclistes  qui ne bénéficient pas
>> d'une vraie piste cyclable. J'ai du mal à comprendre la justification de
>> ces stationnements isolés qui transforment une rue résidentielle en piste
>> de slalom géant (à bosses avec les dos d'âne) qui ne sert même plus ses
>> propres résidents et ne réduit pas les accidents (mais favorisent le
>> chiffre d'affaire des carrossiers, et l'augmentation des tarifs des
>> assurances...). Au final cela coûte cher à tout le monde et cela isole des
>> quartiers qui se voient vidés aussi d'activités, de commerces et services
>> pour les transformer en banlieues ou ghettos sociaux.
>>
>>
>> Le mar. 18 sept. 2018 à 16:05, djakk djakk  a
>> écrit :
>>
>>> Yo !
>>>
>>> Est-ce que tu penses tagger la zone payante avec un polygone ?
>>> Vu que les zones sont souvent concentriques, au lieu de « faire un trou
>>> » dans des polygones, faire des polygones qui se superposent et donner un
>>> indice pour choisir le bon polygone à un point donné.
>>>
>>>
>>> djakk
>>>
>>> Le mar. 18 sept. 2018 à 15:41, Julien Lepiller  a
>>> écrit :
>>>
 Le 2018-09-18 15:30, Florian LAINEZ a écrit :
 > Hello,

Re: [OSM-talk-fr] zones de parcmètres

[djakk djakk]

Houlà sur le dernier paragraphe tu es parti dans un sacré hors-sujet je
trouve :)

Il faut effectivement ne pas avoir à découper le polygone sinon c’est pas
la peine.


djakk


Le mar. 18 sept. 2018 à 17:26, Philippe Verdy  a écrit :

> note : les polygones s'appliquent essentiellement au stationnement le long
> des voies publiques, mais excluent les aires de staionnement avec
> entrées/sorties de parking dédiées qui ont leurs propres règles.
> Ils doivent aussi exclure les parkings privés, les voies privées. Je me
> demande l'intérêt de ces zones difficiles à délimiter sans couper des tas
> de bâtiments et propriétés et à exploiter quand il y a aura de nombreux
> trous disséminés.
> Je pense que cela devrait plutôt être tagué le long des voies, en même
> temps que les "parking lanes" et où sont disposés (à vue) aussi les
> horodateurs ou les panneaux de restriction d'usage ("sauf jours de marché à
> certaines heures", stationnement alterné par quinzaine, gratuit mais disque
> obligatoire, dépose-minute gratuite avec arrêt autorisé mais pas le
> stationnement sans conducteur visible à proximité immédiate ou encore au
> volant de plus de 5 minutes, 2 minutes dans les aéroports où on passe une
> barrière avec un ticket qui facturera en sortie les premières secondes de
> dépassement, car dans ce cas cela devient payant dès la première minute aux
> horodateurs).
> En gros les zones de stationnement sont peut-être affichées sommairement
> sur les sites des municipalités, à titre informatif, mais le terrain
> détaille les conditions réelles avec une précision bien supérieure et un
> équipement ou marquage détaillé.
>
> Taguer au niveau des voies publiques sera nettement supérieur (et on
> pourra aussi délimiter les véritables "parking lanes" ont il y a
> effectivement des places, ou des emplacements individuels qu'on peut taguer
> directement
>
> Les emplacements individuels sont dans des rues résidentielles de plus en
> plus nombreuses où les municipalités les installent avec sens de
> circulation prioritaire alterné en "slalom" , pour ne garder qu'une voie à
> côté des emplacements, la deuxième formant des zones d'attente. Le but de
> ces places étant de réduire la vitesse et forcer les véhicules à rouler au
> pas (pas évident quand on en trouve même dans des rues où circulent des bus
> et camions: ce sont des places pour jouer à l'auto-tamponneuse, les
> véhicules stationnés sont régulièrement heurtés ou leurs ailes froissées
> par les véhicules longs comme les bus...) et aussi détourner le trafic vers
> d'autres avenues et vers la périphérie. ils ont remplacé les côtés de
> stationnement (le stationnement par côté alterné disparait un peu partout)
> et réduit largement le nombre de places disponibles, pour forcer les
> résidents ou visiteurs à utiliser les parkings extérieurs et les transports
> en commun dans le centre. Ces places isolées en slalom sont souvent
> gratuites (au risque et péril du propriétaire du véhicule) car la
> municipalité ne veut pas prendre le risque d'une responsabilité en cas de
> pépin. Les résidents qui n'ont pas de garage sont bien en peine de se garer
> ou doivent payer cher des stationnements loin de chez eux ou louer des
> garages privés, ils hésitent à y garer leur véhicule la nuit car ces
> emplacements sont dangereux, les accidents nombreux surtout en hiver. Les
> livraisons à domicile sont également difficiles, comme les déménagements.
>
> Si le but était de réduire la vitesse ou le traffic, il était suffisant de
> mettre des coussins ou dos d'âne, mais ce sont les cyclistes et motards qui
> se plaignent de leur dangerosité. Ces slaloms sont égalemetn dangereux en
> toute saison et à toute heure pour les cyclistes  qui ne bénéficient pas
> d'une vraie piste cyclable. J'ai du mal à comprendre la justification de
> ces stationnements isolés qui transforment une rue résidentielle en piste
> de slalom géant (à bosses avec les dos d'âne) qui ne sert même plus ses
> propres résidents et ne réduit pas les accidents (mais favorisent le
> chiffre d'affaire des carrossiers, et l'augmentation des tarifs des
> assurances...). Au final cela coûte cher à tout le monde et cela isole des
> quartiers qui se voient vidés aussi d'activités, de commerces et services
> pour les transformer en banlieues ou ghettos sociaux.
>
>
> Le mar. 18 sept. 2018 à 16:05, djakk djakk  a
> écrit :
>
>> Yo !
>>
>> Est-ce que tu penses tagger la zone payante avec un polygone ?
>> Vu que les zones sont souvent concentriques, au lieu de « faire un trou »
>> dans des polygones, faire des polygones qui se superposent et donner un
>> indice pour choisir le bon polygone à un point donné.
>>
>>
>> djakk
>>
>> Le mar. 18 sept. 2018 à 15:41, Julien Lepiller  a
>> écrit :
>>
>>> Le 2018-09-18 15:30, Florian LAINEZ a écrit :
>>> > Hello,
>>> > En ville, le stationnement est souvent régulé avec des zones.
>>> > Celles-ci portent souvent un nom de couleur, mais ce n'est pas
>>> > toujours le cas.
>>> > Sous quel tag 

Re: [OSM-talk-fr] zones de parcmètres

[Florian LAINEZ]

Merci pour vos réponses.

@marc en effet OSM n'a pas vraiment vocation à reprendre les codes, surtout
qu'ils vont de paire avec la zone : toujours les mêmes selon la zone. je
vais retirer ça mais le laisser en doc dans le wiki.
parking:zone= me parait vraiment
génial à utiliser.

Par contre vu que les zones sont indiquées sur les parcmètres et que c'est
une info importante, je compte les y laisser.  Mais je suis d'accord avec
toi que ça a également du sens sur les places de parking elles-mêmes et ça
sera ma prochaine étape.

@djakk je ne pense pas faire de polygone dédié. Comme tu peux voir sur
cette carte  c'est
bien plus complexe à gérer qu'un simple cercle concentrique. D'une manière
générale je pense que c'est une mauvaise idée de créer des polygones dédiés
pour ce sujet. Je suis plutôt partisan de rajouter des infos sur les objets
déjà existants.

Le mar. 18 sept. 2018 à 15:53, djakk djakk  a écrit :

> Yo !
>
> Est-ce que tu penses tagger la zone payante avec un polygone ?
> Vu que les zones sont souvent concentriques, au lieu de « faire un trou »
> dans des polygones, faire des polygones qui se superposent et donner un
> indice pour choisir le bon polygone à un point donné.
>
>
> djakk
>
> Le mar. 18 sept. 2018 à 15:41, Julien Lepiller  a écrit :
>
>> Le 2018-09-18 15:30, Florian LAINEZ a écrit :
>> > Hello,
>> > En ville, le stationnement est souvent régulé avec des zones.
>> > Celles-ci portent souvent un nom de couleur, mais ce n'est pas
>> > toujours le cas.
>> > Sous quel tag signaleriez-vous ça ?
>> >
>> > Il n'y a pas beaucoup de détails pour les parcmètres sur le wiki
>> > https://wiki.openstreetmap.org/wiki/FR:Tag:vending%3Dparking_tickets
>> > Je m'intéresse pour l'instant aux parcmètres de la ville de
>> > Montrouge et j'ai documenté ça ici :
>> > https://wiki.openstreetmap.org/wiki/Montrouge#Parcm.C3.A8tres
>> >
>> > La première proposition était charge=FR:Montrouge:zone rouge mais à
>> > priori le tag "charge" indique plutôt des prix, pas des zones.
>> >
>> > overpasse m'informe qu'en France, les tags suivants sont utilisés,
>> > même s'ils sont assez peu répandus :
>> > parking:ticket:zone
>> > parking_tickets:zone:FR
>> > parking_tickets:zone:colour
>> > vending_machine:zone
>> >
>> > Le plus clair et universel me parait parking:ticket:zone=nom de la
>> > couleur
>> > Et vous ?
>> >
>> > --
>> >
>> > FLORIAN LAINEZ
>> > @overflorian [1]
>> >
>>
>> Ça serait intéressant : À Rennes on a bien indiqué les zones, mais sous
>> la forme :
>>
>> note=green zone
>>
>> par exemple...
>>
>> ___
>> 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
>


-- 

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

Re: [OSM-talk-fr] zones de parcmètres

[Philippe Verdy]

note : les polygones s'appliquent essentiellement au stationnement le long
des voies publiques, mais excluent les aires de staionnement avec
entrées/sorties de parking dédiées qui ont leurs propres règles.
Ils doivent aussi exclure les parkings privés, les voies privées. Je me
demande l'intérêt de ces zones difficiles à délimiter sans couper des tas
de bâtiments et propriétés et à exploiter quand il y a aura de nombreux
trous disséminés.
Je pense que cela devrait plutôt être tagué le long des voies, en même
temps que les "parking lanes" et où sont disposés (à vue) aussi les
horodateurs ou les panneaux de restriction d'usage ("sauf jours de marché à
certaines heures", stationnement alterné par quinzaine, gratuit mais disque
obligatoire, dépose-minute gratuite avec arrêt autorisé mais pas le
stationnement sans conducteur visible à proximité immédiate ou encore au
volant de plus de 5 minutes, 2 minutes dans les aéroports où on passe une
barrière avec un ticket qui facturera en sortie les premières secondes de
dépassement, car dans ce cas cela devient payant dès la première minute aux
horodateurs).
En gros les zones de stationnement sont peut-être affichées sommairement
sur les sites des municipalités, à titre informatif, mais le terrain
détaille les conditions réelles avec une précision bien supérieure et un
équipement ou marquage détaillé.

Taguer au niveau des voies publiques sera nettement supérieur (et on pourra
aussi délimiter les véritables "parking lanes" ont il y a effectivement des
places, ou des emplacements individuels qu'on peut taguer directement

Les emplacements individuels sont dans des rues résidentielles de plus en
plus nombreuses où les municipalités les installent avec sens de
circulation prioritaire alterné en "slalom" , pour ne garder qu'une voie à
côté des emplacements, la deuxième formant des zones d'attente. Le but de
ces places étant de réduire la vitesse et forcer les véhicules à rouler au
pas (pas évident quand on en trouve même dans des rues où circulent des bus
et camions: ce sont des places pour jouer à l'auto-tamponneuse, les
véhicules stationnés sont régulièrement heurtés ou leurs ailes froissées
par les véhicules longs comme les bus...) et aussi détourner le trafic vers
d'autres avenues et vers la périphérie. ils ont remplacé les côtés de
stationnement (le stationnement par côté alterné disparait un peu partout)
et réduit largement le nombre de places disponibles, pour forcer les
résidents ou visiteurs à utiliser les parkings extérieurs et les transports
en commun dans le centre. Ces places isolées en slalom sont souvent
gratuites (au risque et péril du propriétaire du véhicule) car la
municipalité ne veut pas prendre le risque d'une responsabilité en cas de
pépin. Les résidents qui n'ont pas de garage sont bien en peine de se garer
ou doivent payer cher des stationnements loin de chez eux ou louer des
garages privés, ils hésitent à y garer leur véhicule la nuit car ces
emplacements sont dangereux, les accidents nombreux surtout en hiver. Les
livraisons à domicile sont également difficiles, comme les déménagements.

Si le but était de réduire la vitesse ou le traffic, il était suffisant de
mettre des coussins ou dos d'âne, mais ce sont les cyclistes et motards qui
se plaignent de leur dangerosité. Ces slaloms sont égalemetn dangereux en
toute saison et à toute heure pour les cyclistes  qui ne bénéficient pas
d'une vraie piste cyclable. J'ai du mal à comprendre la justification de
ces stationnements isolés qui transforment une rue résidentielle en piste
de slalom géant (à bosses avec les dos d'âne) qui ne sert même plus ses
propres résidents et ne réduit pas les accidents (mais favorisent le
chiffre d'affaire des carrossiers, et l'augmentation des tarifs des
assurances...). Au final cela coûte cher à tout le monde et cela isole des
quartiers qui se voient vidés aussi d'activités, de commerces et services
pour les transformer en banlieues ou ghettos sociaux.


Le mar. 18 sept. 2018 à 16:05, djakk djakk  a écrit :

> Yo !
>
> Est-ce que tu penses tagger la zone payante avec un polygone ?
> Vu que les zones sont souvent concentriques, au lieu de « faire un trou »
> dans des polygones, faire des polygones qui se superposent et donner un
> indice pour choisir le bon polygone à un point donné.
>
>
> djakk
>
> Le mar. 18 sept. 2018 à 15:41, Julien Lepiller  a écrit :
>
>> Le 2018-09-18 15:30, Florian LAINEZ a écrit :
>> > Hello,
>> > En ville, le stationnement est souvent régulé avec des zones.
>> > Celles-ci portent souvent un nom de couleur, mais ce n'est pas
>> > toujours le cas.
>> > Sous quel tag signaleriez-vous ça ?
>> >
>> > Il n'y a pas beaucoup de détails pour les parcmètres sur le wiki
>> > https://wiki.openstreetmap.org/wiki/FR:Tag:vending%3Dparking_tickets
>> > Je m'intéresse pour l'instant aux parcmètres de la ville de
>> > Montrouge et j'ai documenté ça ici :
>> > https://wiki.openstreetmap.org/wiki/Montrouge#Parcm.C3.A8tres
>> >
>> > La première proposition était 

[OSM-talk-fr] SOTM-FR 2019 et Fotoquest GO

[sebseb]

Bonjour à tous, 
je suis nouveau sur la liste mais je suis un peu OSM depuis quelques mois. 
J'avais 2 sujets à aborder, je ne sais pas trop si l'endroit s'y prête mais à 
tout hasard ;) 

J'ai vu que la ville de Montpellier était seule candidate pour le State Of The 
Map FR de l'année prochaine 
et sauf erreur de ma part la date de proclamation des résultats est dépassée 
mais je n'ai pas vu de confirmation... 
J'ai loupé quelque chose ? 

Autre sujet qui cette fois ne concerne pas vraiment OSM mais que je souhaite 
évoquer ;) 
Connaissez vous http://fotoquest-go.org/en/map/ ou http://fotoquest-go.org/en ? 
C'est une initiative autrichien de sciences participatives relatives à 
l'occupation du sol. 
A priori ça n'a pas trop de succès, notamment sur le territoire français mais 
je trouve le sujet intéressant. 

Bien cordialement 
S. Silvestre 

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

Re: [OSM-talk-fr] zones de parcmètres

[djakk djakk]

Yo !

Est-ce que tu penses tagger la zone payante avec un polygone ?
Vu que les zones sont souvent concentriques, au lieu de « faire un trou »
dans des polygones, faire des polygones qui se superposent et donner un
indice pour choisir le bon polygone à un point donné.


djakk

Le mar. 18 sept. 2018 à 15:41, Julien Lepiller  a écrit :

> Le 2018-09-18 15:30, Florian LAINEZ a écrit :
> > Hello,
> > En ville, le stationnement est souvent régulé avec des zones.
> > Celles-ci portent souvent un nom de couleur, mais ce n'est pas
> > toujours le cas.
> > Sous quel tag signaleriez-vous ça ?
> >
> > Il n'y a pas beaucoup de détails pour les parcmètres sur le wiki
> > https://wiki.openstreetmap.org/wiki/FR:Tag:vending%3Dparking_tickets
> > Je m'intéresse pour l'instant aux parcmètres de la ville de
> > Montrouge et j'ai documenté ça ici :
> > https://wiki.openstreetmap.org/wiki/Montrouge#Parcm.C3.A8tres
> >
> > La première proposition était charge=FR:Montrouge:zone rouge mais à
> > priori le tag "charge" indique plutôt des prix, pas des zones.
> >
> > overpasse m'informe qu'en France, les tags suivants sont utilisés,
> > même s'ils sont assez peu répandus :
> > parking:ticket:zone
> > parking_tickets:zone:FR
> > parking_tickets:zone:colour
> > vending_machine:zone
> >
> > Le plus clair et universel me parait parking:ticket:zone=nom de la
> > couleur
> > Et vous ?
> >
> > --
> >
> > FLORIAN LAINEZ
> > @overflorian [1]
> >
>
> Ça serait intéressant : À Rennes on a bien indiqué les zones, mais sous
> la forme :
>
> note=green zone
>
> par exemple...
>
> ___
> 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] zones de parcmètres

[marc marc]

Bonjour,

Le 18. 09. 18 à 15:30, Florian LAINEZ a écrit :
> En ville, le stationnement est souvent régulé avec des zones.

Je trouve que la zone n'est pas une propriété du parcomètre
mais du parking et j'utiliserais donc parking:condition sur
les way concerné tel que documenté sur
https://wiki.openstreetmap.org/wiki/Key:parking:lane

parking:zone=
me parait + universel.
Le plus utilisé est parking:ticket:zone mais cela donne trop 
l'impression qu'il faut un ticket ce qui n'est pas le cas
dans de nombreux endroit.

pour les codes à utiliser dans l'application mobile
je suis pas convaincu de la plus-value a les dupliquer
tous les codes possibles sur chaque parcomètres.
c'est pas repris dans la doc de l'app ? c'est le role d'osm
d'être un mode d'emploi de l'app ?

je n'aurais mis aussi qu'une url website au lieu de 2.

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

Re: [OSM-talk-fr] nouveau champ takeaway:lunchbox

[Philippe Verdy]

On a aussi les boissons : le vin, le lait (y compris dans des distributeurs
automatiques).
Mais pour certains produits (notamment alimentaires pour les produits frais
comme la viande ou le poisson frais ou les surgelés, mais aussi des tas de
produits toxiques ou polluants comme la pharmacie ou les peintures et
vernis) il est encore illégal de vendre sans emballage et ces emballages
sont normés (on ne peut pas se contenter des récipients quelconques des
clients, pas adaptés).
Un effort commence à être fait pour remplacer les ventes de bouteilles
d'eau en plastique par des bonbonnes réutilisables et consignées. Pas
encore dans les supermarchés (qui au mieux vendent des bonbonnes plastique
de 5 litres, mais non réutilisables) mais dans les entreprises avec des
livraisons.

Le mar. 18 sept. 2018 à 12:53, marc marc  a
écrit :

> autant lunchbox a une connotation "boite à tartine" (je m'attend à ce
> que cela parle d'une épicerie qui vend des sandwich à emporter)
> autant bulk_purchase a un côté "bulk" cad de masse, je m'attends
> à ce que la magasin de boisson vende le bvin en tonneau.
> hors les magasins zéro déchet n'ont souvent aucun lien ni avec le type
> de produit (il y en a bien sur qui vende de la nourriture mais il y a
> aussi des cosmétiques, des produits d’entretien, ...) ni avec le volume
> (tu peux acheter 50gr de noix ou 5l de produit de vaisselle)
>
> Le 18. 09. 18 à 12:07, Julien Coupey a écrit :
> > Bonjour,
> >
> > Je ne sais pas si c'est exactement ce que tu souhaites décrire, mais il
> > y a déjà bulk_purchase[1] qui semble approprié.
> >
> > Il est déjà utilisé pour les épiceries « en vrac » qui fleurissent
> > ici[2] ou là[3].
> >
> > À +
> > Julien
> >
> > [1] : https://wiki.openstreetmap.org/wiki/Key:bulk_purchase
> > [2] : https://www.openstreetmap.org/node/5618249615
> > [3] : https://www.openstreetmap.org/node/5867522816
> >
> > On 18/09/2018 11:20, Vivien MICHON wrote:
> >> Bonjour,
> >>
> >> Je propose la possibilité d’indiquer les commerces acceptant que le
> >> client vienne avec son propre contenant (de type boîte fermable et
> >> réutilisable).
> >>
> >> Cette pratique est de plus en plus courante, afin d’éviter
> >> l’utilisation de boîtes ou papiers jetables (zéro déchet).
> >>
> >> Elle est possible en vente à emporter dans un nombre croissant de
> >> restaurants, traiteurs, boucheries, fromageries…
> >>
> >> Je propose ainsi le nouveau champ « takeaway:lunchbox », indiqué en
> >> YES ou NO.
> >>
> >> Le terme « lunchbox » fait référence à la boîte contenant le déjeuner,
> >> qui peut être utilisée à toute heure, pour tout type d’achat. Le terme
> >> indique également qu’il s’agit de nourriture.
> >>
> >> exemple : https://www.openstreetmap.org/node/5130551429
> >>
> >> Merci d’avance pour vos commentaires.
> >>
> >>
> >>
> >> ___
> >> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] zones de parcmètres

[Julien Lepiller]

Le 2018-09-18 15:30, Florian LAINEZ a écrit :

Hello,
En ville, le stationnement est souvent régulé avec des zones.
Celles-ci portent souvent un nom de couleur, mais ce n'est pas
toujours le cas.
Sous quel tag signaleriez-vous ça ?

Il n'y a pas beaucoup de détails pour les parcmètres sur le wiki
https://wiki.openstreetmap.org/wiki/FR:Tag:vending%3Dparking_tickets
Je m'intéresse pour l'instant aux parcmètres de la ville de
Montrouge et j'ai documenté ça ici :
https://wiki.openstreetmap.org/wiki/Montrouge#Parcm.C3.A8tres

La première proposition était charge=FR:Montrouge:zone rouge mais à
priori le tag "charge" indique plutôt des prix, pas des zones.

overpasse m'informe qu'en France, les tags suivants sont utilisés,
même s'ils sont assez peu répandus :
parking:ticket:zone
parking_tickets:zone:FR
parking_tickets:zone:colour
vending_machine:zone

Le plus clair et universel me parait parking:ticket:zone=nom de la
couleur
Et vous ?

--

FLORIAN LAINEZ
@overflorian [1]



Ça serait intéressant : À Rennes on a bien indiqué les zones, mais sous
la forme :

note=green zone

par exemple...

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

[OSM-talk-fr] zones de parcmètres

[Florian LAINEZ]

Hello,
En ville, le stationnement est souvent régulé avec des zones. Celles-ci
portent souvent un nom de couleur, mais ce n'est pas toujours le cas.
Sous quel tag signaleriez-vous ça ?

Il n'y a pas beaucoup de détails pour les parcmètres sur le wiki
https://wiki.openstreetmap.org/wiki/FR:Tag:vending%3Dparking_tickets
Je m'intéresse pour l'instant aux parcmètres de la ville de Montrouge et
j'ai documenté ça ici :
https://wiki.openstreetmap.org/wiki/Montrouge#Parcm.C3.A8tres

La première proposition était charge=FR:Montrouge:zone rouge mais à priori
le tag "charge" indique plutôt des prix, pas des zones.
overpasse m'informe qu'en France, les tags suivants sont utilisés, même
s'ils sont assez peu répandus :
parking:ticket:zone
parking_tickets:zone:FR
parking_tickets:zone:colour
vending_machine:zone

Le plus clair et universel me parait parking:ticket:zone=nom de la couleur
Et vous ?

-- 

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

Re: [OSM-talk-fr] PLU et copie des informations

[Philippe Verdy]

Si ce n'est pas encore accessible, il faut insister: les locaux doivent
insister pour que ces sources soient publiées; que ces données viennent à
l'origine d'autres organismes, la loi leur impose de les mettre à
disposition des collectivités et du public; on l'a fait pour obtenir des
données de la part de nombreux concessionnaires et exploitants privés de
réseaux bénéficiant de marchés publics: ils doivent libérer suffisamment de
données pour permettre aux collectivités de décider et informer le public
sur des bases plus équitables, en mettant de côté leur droit privé
largement construit sur le dos de la collectivité.

Bref aux Marseillais de se bouger et insister auprès de leurs élus et ne
pas se laisser mener par les lobbies  locaux ou l'influence des "mafias"
locales. qui ont organisé le secret et fait prendre des décisions sur le
dos des résidents.

On peut aussi insister auprès des institutions de l'état (dont la
préfecture, la CNIL, la Cour des comptes, le Procureur de la République
s'il faut des plaintes, ou encore des élus nationaux ou de la région), et
faire aussi campagne par la presse locale avec le soutien d'assos locales
(dont les assos de quartiers et ONG ou encore les syndicats professionnels
au sein des entreprises concernées), et par les réseaux sociaux (moins pour
critiquer que pour mettre en valeur les exemples positifs de ce qui a été
fait et qui devraient "faire école", notamment via les plus petites
communes autour de Marseille à qui la Métropole impose des tas de choses y
compris maintenant sur leur PLU).

Il y a des portes ouvertes, il faut les repérer et les utiliser pour faire
valoir le droit commun. Il n'y a pas de raison pour que le PLU soit
organisé en petit comité secret et sans concertation locale ni information
véritable du public de ce qui est en place et de ce qui est prévu, ni
réelle ouverture à des contre-propositions, et aucune expérimentation ni
évaluation publique des résultats

(d'ailleurs la loi oblige maintenant à faire cette évaluation des plans
d'aménagement au maximum 6 ans après leur adoption, sinon les plans publics
deviennent obsolètes et n'ont plus aucune valeur légale et ne peuvent plus
recevoir le moindre denier public pour les soutenir; et ces plans ont une
durée de vie maximale de 30 ans, après cela c'est le droit commun national
qui s'applique; pour les concessions publiques aux exploitants, il y a
aussi des durées maximales qui imposent aussi des résultats publics et de
nouveaux appels d'offres *ouverts* permettant la reprise des concessions
par des concurrents, qui doivent pouvoir tout savoir du contenu de ces
concessions pour pouvoir répondre à ces appels et faire des engagements
forts de service en permettant aussi le contrôle public des lots réalisés
et surveiller les coûts réels).

On ne doit pas laisser refaire ce qui a été fait pour les concessions
d'autoroute, celles des eaux et de l'assainissement (là les abus sont les
plus forts), celles de l'énergie, celles des grandes installations
(aéro-)portuaires (le gâchis des "ZAD" depuis des décennies), celles des
transports publics, celles du logement social, celles du contrôle routier
(et son gâchis astronomiquement coûteux quand on a voulu dénoncer certains
contrats de concession et réalisé alors que les contrats publics étaient
largement inéquitables et fondés sur des promesses vaines non contrôlables).


Le mar. 18 sept. 2018 à 14:49, FR  a écrit :

> Mais de quelles données s'agit-il ?
> Celles fournies par les planches du PLU, ou celles des annexes texte ?
>
> Mes doutes portent en l’occurrence sur le PLU de Marseille, qui dans son
> annexe 3 liste une série de bâtiments remarquables issues d'une compilation
> d'ouvrages en citant ses sources:  ouvrages d'historiens de l'architecture,
> études de la DRAC PACA et de l'atelier du patrimoine de Marseille, ces 2
> institutions n'étant pas précisément réputées dans le domaine de l'Open
> Data
> [1].
> Par ailleurs le site Marseille-Provence qui permet d’accéder au PLU ne fait
> nulle part mention d'une politique d'Open Data...
>
> On serait dans Wikipedia on pourrait s'en sortir avec le droit de citation.
> Mais dans OSM 
>
> D'autres avis ?
>
> FR
>
>  [1]
>
> http://www.marseille-provence.fr/index.php/documents/docplu/mrs/opposable-mrs-1/reglement-mrs-1/3255-reglement-tome-3-mrs/file
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> 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] Classement ville/village - city/town/village

[Philippe Verdy]

Le mar. 18 sept. 2018 à 11:07, Rpnpif  a écrit :

> L'attrait de la ville « moderne » y est fort. C'est un sentiment hérité
> du 20e siècle. Tu as raison, ce n'est pas un sentiment général.
>

Sentiment pas justifié, et plutôt maintenant contredit par la réalité de la
situation des "villes modernes" qui ont perdu leur attrait. Le
développement fort des activités en ligne, les problèmes de division des
territoires, le gaspillage des ressources rurales, le gâchis des paysages
périurbains, la gestion des risques comme l'inondabilité, la pollution, la
sécurité, les difficultés de transport ont largement revu la notion de
"ville moderne", dédiée à la voiture.
Les villes sont asphyxiées par les problèmes de distance et l'explosion des
prix des loyers et de l'immobilier et en fait la non-proximité des bassins
de vie, elles sont même devenues des freins à la mobilité (malgré le
développement des transports publics). Les urbains des grosses villes
envient la vie des villages, et certaines villes s'en tirent nettement
mieux. Une "ville moderne" ce n'est pas Paris, New York, Londres, ou
Shangaï, c'est plus Berlin avec ses nombreux villages et une grande
accessibilité pour les piétons et une mixité des zones
résidentielles/d'activité/commerciales/services, une réduction drastique de
l'espace dédié aux véhicules, et un fort développement environnemental; le
modèle est complètement multipolaire : la ville centre qui draine tout ce
qui est autour n'est plus un modèle enviable...

Des grandes villes françaises (métropoles) l'ont compris - Brest, Rennes,
Nantes, mais même aussi Marseille - dans le développement de leurs
"quartiers-villages" avec une identité forte, et la fin du vieux modèle des
ZA/ZI/ZUP hérité de la reconstruction d'après-guerre. Paris n'a encore rien
fait et reste dans l'ancien modèle de la "ville-phare" qui exclut toujours
et renvoie tous ses problèmes à ses banlieues (et la nouvelle métropole de
Paris ne change rien).

Paris était pourtant avant une ville faire de quartiers-villages (jusque
vers les années 1920), ce qui ne l'empêchait pas d'avoir un rayonnement
international fort et une grande mixité sociale, tout en permettant le
développement d'autres villages tout autour ; ce n'est plus le cas, il n'y
a plus d'identité du tout et on a des horreurs maintenant dans les
banlieues très fortement segmentées (que ce soit Levallois-Perret, ou
Nanterre) : on a poussé le centralisme et la spécialisation des quartiers
beaucoup trop loin, et c'est maintenant très difficile à inverser en
oubliant ce qui faisait la force de Paris : sa région et son développement
multipolaire. Dans les années 1960 on a cherché à reproduire le problème en
créant des "villes nouvelles" (un modèle renouvelé encore avec
l'installation d'Eurodisney à Marne-La Vallée). A mon avis, c'est un échec
cuisant: il n'y a même pas réellement de ville, mais pas plus de villages
autour et tout est ramené à Paris qui draine tout, jusque dans l'image des
cités nouvelles où Paris s'incruste dans tout, et où tout a été fait encore
pour l'automobile ou les transports internationaux, en oubliant le
développement d'une vie locale comme aussi la préservation de
l'environnement.

Et cela n'a pas permis davantage de développement de l'activité, notamment
les PME et l'artisanat. La France (contrairement à l'Allemagne qui s'en
sort nettement mieux) se laisse encore malmener et dicter sa politique
territoriale par les grands groupes internationaux pour qu'ils s'y
installent mais qui finalement n'apporte pas plus d'activité, cassent une
grande partie des autres, et non seulement ne payent pas le prix, mais en
plus échappent à la fiscalité et au final ce sont les habitants modestes
qui en payent le prix, ainsi que la démocratie locale qui s'affaiblit.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] PLU et copie des informations

[FR]

Mais de quelles données s'agit-il ?
Celles fournies par les planches du PLU, ou celles des annexes texte ?

Mes doutes portent en l’occurrence sur le PLU de Marseille, qui dans son
annexe 3 liste une série de bâtiments remarquables issues d'une compilation
d'ouvrages en citant ses sources:  ouvrages d'historiens de l'architecture,
études de la DRAC PACA et de l'atelier du patrimoine de Marseille, ces 2
institutions n'étant pas précisément réputées dans le domaine de l'Open Data
[1].
Par ailleurs le site Marseille-Provence qui permet d’accéder au PLU ne fait
nulle part mention d'une politique d'Open Data...

On serait dans Wikipedia on pourrait s'en sortir avec le droit de citation.
Mais dans OSM 

D'autres avis ? 

FR

 [1]
http://www.marseille-provence.fr/index.php/documents/docplu/mrs/opposable-mrs-1/reglement-mrs-1/3255-reglement-tome-3-mrs/file
 



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Camion pizza

[Philippe Verdy]

je trouve foodtruck=yes trop restrictif car le commerce itinérant n'est pas
limité juste à l'alimentaire. Le terme est devenu à la mode, mais c'est
même utilisé dans la cuisine prête à manger immédiatement (une forme de
restaurant) et même pas pour l'alimentaire en général (exemple : marchands
de fruits et légumes, ou épiceries).

Bref on cherche toujours une clé pour les autres commerces ou services
itinérants (note: dans certains endroits ils peuvent exister tous les jours
et sont quasi fixes toute l'année, hors jour de fermeture hebdomadaire) et
peuvent exister pendant des mois pour remplacer un autre commerce en
travaux. La notion d'itinérance et de temporalité est donc très variable.

Je pense que ce devrait être un truc du genre "parked_vehicle=yes", à
positionner sur une zone de parking (avec les opening_hours=* bien sûr pour
la temporalité) pour qu'on ne cherche pas un bâtiment absent. Et ça
couvrirait aussi bien les "bibliobus" (médiathèques itinérantes), ou les
coiffeurs itinérants, les épiceries itinérantes, les accueils de services
publics itinérants. Dans ce cas on peut tout à fait taguer un "foodtruck"
avec les même tags des restaurants mais sans que ce soit sur ou dans un
bâtiment.

Le "takeway=*" est à part, pas restreint non plus aux seuls
restaurants/fastfood ou foodtrucks. C'est une forme de distribution (comme
aussi le tag indiquant une livraison à domicile), mais ne qualifie pas le
type de produit ou service.

Le "outdoor_seating" n'est pas non plus restreint aux seuls commerces ou
services itinérants (il s'applique aussi aux
restaurants/fastfood/bars/brasseries en dur pour leurs terrasses, ou
d'autres services possibles à la place comme les cinémas/théâtres/kiosques
à musique à l'extérieur...) il désigne une extension de ce commerce ou
service au delà de son seul emplacement de base (bâtiment ou véhicule) sur
une surface extérieure plus grande.


Le mar. 18 sept. 2018 à 13:08, Eric Brosselin - Osm 
a écrit :

> *Le 18/09/2018 à 08:30, Jean-Christophe Becquet a écrit :*
>
> *Est-ce que :
>
> amenity=fast_food
> cuisine=pizza
>
> vous semble la bonne description pour un camion qui vend des pizzas à
> emporter ?*
>
> Bonjour,
>
> Pourquoi ne pas utiliser "amenity=marketplace" ?
> Ce tag décrit lorsqu'il est associé à "building" un bâtiment "en dur",
> mais aussi un emplacement où certains jours à certaines heures
> des commerces mobiles sont présents.
>
> Cela donnerait:
>
> - amenity=marketplace
> - foodtruck=yes  => là il faudrait inventer quelque chose pour
> préciser le type de commerce
> - cuisine=pizza   => type de cuisine
> - opening_hours=* => pour préciser les jours et heures de présence
> - takeaway=yes  => yes pourrait apparaître implicite mais il
> est parfois possible de manger sur place
> Dans ce cas on pourrait rajouter
> - outdoor_seating=yes=> qui indiquerait que l'on peut manger sur place
> - takeaway=only => s'il n'y a pas de possibilités de manger
> sur place et qu'on puisse uniquement emporter ce que l'on achète
>
> Après il suffit de placer le POI au bon endroit sur un parking ou bord de
> route et de cartographier les alentours ;-)
> ___
> 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] Josm, imagerie aérienne, lenteur ou bug

[Julien Lepiller]

Le 2018-09-18 12:12, Stéphane Péneau a écrit :

Hello !

Depuis quelques semaines, ou mois, j'ai la sensation que l'affichage
des images aériennes dans Josm a un comportement un peu bizarre.

J'ai l'impression qu'il y a 2 problèmes, 1 dans Josm, et 1 autre avec
la BD Ortho de l'Ign :

- Dans Josm, je peux avoir un affichage correct, puis pendant un
déplacement de l'affichage, me retrouver avec des tuiles pixelisées
qui s'affichent par dessus d'autres tuiles en bonne qualité.


Je confirme ce point, et pas uniquement sur la bdortho : ça me le fait
sur toutes les imageries, ce qui est particulièrement pénible en 4G dans
un train, puisqu'il faut attendre d'avoir une connexion pour que JOSM
télécharge de nouveau les tuiles alors qu'il les connaissait.


- En parallèle, et ce n'est pas permanent, la console de Josm
m'affiche un nombre assez conséquent d'erreurs 404 et/ou 509 avec
proxy-ign.openstreetmap.fr. Par exemple, hier matin.


Là je ne sais pas.



Oui, ça fait beaucoup de conditionnel et de ressenti. Avant de creuser
plus loin, j'aimerais savoir si je suis le seul dans cette situation,
ou si c'est assez généralisé.


Stf


___
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] Camion pizza

[Eric Brosselin - Osm]

/Le 18/09/2018 à 08:30, Jean-Christophe Becquet a écrit ://
/
/Est-ce que : amenity=fast_food cuisine=pizza vous semble la bonne 
description pour un camion qui vend des pizzas à emporter ?/


Bonjour,

Pourquoi ne pas utiliser "amenity=marketplace" ?
Ce tag décrit lorsqu'il est associé à "building" un bâtiment "en dur", 
mais aussi un emplacement où certains jours à certaines heures

des commerces mobiles sont présents.

Cela donnerait:

- amenity=marketplace
- foodtruck=yes  => là il faudrait inventer quelque chose 
pour préciser le type de commerce

- cuisine=pizza               => type de cuisine
- opening_hours=*     => pour préciser les jours et heures de présence
- takeaway=yes  => yes pourrait apparaître implicite mais il 
est parfois possible de manger sur place

Dans ce cas on pourrait rajouter
- outdoor_seating=yes    => qui indiquerait que l'on peut manger sur place
- takeaway=only => s'il n'y a pas de possibilités de manger 
sur place et qu'on puisse uniquement emporter ce que l'on achète


Après il suffit de placer le POI au bon endroit sur un parking ou bord 
de route et de cartographier les alentours ;-)


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

Re: [OSM-talk-fr] nouveau champ takeaway:lunchbox

[marc marc]

autant lunchbox a une connotation "boite à tartine" (je m'attend à ce 
que cela parle d'une épicerie qui vend des sandwich à emporter)
autant bulk_purchase a un côté "bulk" cad de masse, je m'attends
à ce que la magasin de boisson vende le bvin en tonneau.
hors les magasins zéro déchet n'ont souvent aucun lien ni avec le type 
de produit (il y en a bien sur qui vende de la nourriture mais il y a 
aussi des cosmétiques, des produits d’entretien, ...) ni avec le volume 
(tu peux acheter 50gr de noix ou 5l de produit de vaisselle)

Le 18. 09. 18 à 12:07, Julien Coupey a écrit :
> Bonjour,
> 
> Je ne sais pas si c'est exactement ce que tu souhaites décrire, mais il 
> y a déjà bulk_purchase[1] qui semble approprié.
> 
> Il est déjà utilisé pour les épiceries « en vrac » qui fleurissent 
> ici[2] ou là[3].
> 
> À +
> Julien
> 
> [1] : https://wiki.openstreetmap.org/wiki/Key:bulk_purchase
> [2] : https://www.openstreetmap.org/node/5618249615
> [3] : https://www.openstreetmap.org/node/5867522816
> 
> On 18/09/2018 11:20, Vivien MICHON wrote:
>> Bonjour,
>>
>> Je propose la possibilité d’indiquer les commerces acceptant que le 
>> client vienne avec son propre contenant (de type boîte fermable et 
>> réutilisable).
>>
>> Cette pratique est de plus en plus courante, afin d’éviter 
>> l’utilisation de boîtes ou papiers jetables (zéro déchet).
>>
>> Elle est possible en vente à emporter dans un nombre croissant de 
>> restaurants, traiteurs, boucheries, fromageries…
>>
>> Je propose ainsi le nouveau champ « takeaway:lunchbox », indiqué en 
>> YES ou NO.
>>
>> Le terme « lunchbox » fait référence à la boîte contenant le déjeuner, 
>> qui peut être utilisée à toute heure, pour tout type d’achat. Le terme 
>> indique également qu’il s’agit de nourriture.
>>
>> exemple : https://www.openstreetmap.org/node/5130551429
>>
>> Merci d’avance pour vos commentaires.
>>
>>
>>
>> ___
>> 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] nouveau champ takeaway:lunchbox

[marc marc]

Le 18. 09. 18 à 11:55, Jean-Claude Repetto a écrit :
> Il faudrait plutôt trouver un terme évoquant la notion de "sans emballage".

zerowaste ? c'est en tout cas comme cela qu'on ne nome parmis chez les 
partisants.
et cela a l'avantage de couvrir tout autant la pizzerie qui accepte de 
vendre une pizza à emporter dans le récipiant du client, que le 
restaurant qui mettra les restes du repas dans une boite du client,
ou me lagasinqui vend de l'huile de l'olive sans fourger une bouteille.

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

Re: [OSM-talk-fr] nouveau champ takeaway:lunchbox

[Eric Brosselin - Osm]

Bonjour,

A mon avis il faut séparer la restauration et les autres commerces
À part "takeaway:lunchbox" les tags existent .

Pour résumer :

_Restauration_
En plus des autres tags habituels
- takeaway=yes => il est possible d'emporter ce que l'on 
a commandé
- takeaway:lunchbox=yes  => précise que l'on peut apporter son propre 
contenant pour emporter ce que l'on a commandé


_Autres commerces_
- bulk_purchase=yes   => si le magasin vend notamment des produits sans 
emballages
- bulk_purchase=only  => si le magasin vend uniquement des produits sans 
emballages

Là on sait qu'on doit amener ses contenants.
Certains magasins vendent des contenants réutilisables pour les 
personnes qui n'en n'auraient pas.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Josm, imagerie aérienne, lenteur ou bug

[Stéphane Péneau]

Hello !

Depuis quelques semaines, ou mois, j'ai la sensation que l'affichage des 
images aériennes dans Josm a un comportement un peu bizarre.


J'ai l'impression qu'il y a 2 problèmes, 1 dans Josm, et 1 autre avec la 
BD Ortho de l'Ign :


- Dans Josm, je peux avoir un affichage correct, puis pendant un 
déplacement de l'affichage, me retrouver avec des tuiles pixelisées qui 
s'affichent par dessus d'autres tuiles en bonne qualité.
- En parallèle, et ce n'est pas permanent, la console de Josm m'affiche 
un nombre assez conséquent d'erreurs 404 et/ou 509 avec 
proxy-ign.openstreetmap.fr. Par exemple, hier matin.


Oui, ça fait beaucoup de conditionnel et de ressenti. Avant de creuser 
plus loin, j'aimerais savoir si je suis le seul dans cette situation, ou 
si c'est assez généralisé.



Stf


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

Re: [OSM-talk-fr] Rond-points à la découpe. Pourquoi ?

[lenny.libre]

Le 14/09/2018 à 09:09, Jo a écrit :



Le lendemain, un ami m'a appris (peut-être rappelé) que ce n'était
pas nécessaire, qu'on pouvait intégrer le rond-point en entier
dans la relation. Pour le coup, d'un point de vue topologique,
c'est surprenant, mais si les outils de routage s'en sortent, ça
me va tout aussi bien sachant que la tâche est alors grandement
facilitée (et que j'ai repéré d'autres « mini_roundabout » tout
aussi complexes à corriger).


Je veux bien vous démontrer que cette tache est rendu triviale avec le 
greffon PT_Assistant.
Je connais et j'utilise ce greffon mais je n'utilise que le validateur 
et le bouton qui permet de découper pour créer les bus_bay/ponts/tunnels 
(que j'ai découvert au détour d'une conversation) mais il y a des 
boutons/menus qui soit ne sont pas décrits soit s'ils sont décrits je 
n'ai pas su les traduire dans le FR:wiki.

C'est un outil d'expert.

Mais cette discussion fait suite à beaucoup d'autres sur le même sujet.
Il y a aussi des discussions sur d'autres sujets où il y a des pour et 
des contre entre plusieurs attributs ; cela complique les requêtes pour 
récupérer des objets de la base.
Mais ce qui est grave dans le cas du découpage des giratoires c'est que 
cela génère de gros problèmes sur les lignes de bus existantes : car 
beaucoup de contributeurs n'utilisent pas les outils experts comme Jo. 
Et le nombre de lignes abimées est très important.
Beaucoup n'utilisent même pas josm (J'en ai contacté pas mal et 
seulement une moitié et passé à josm) et quand ils dessinent une ligne, 
en découpant les giratoires, ils détériorent au minimum deux lignes 
existantes.


Le 14/09/2018 à 13:11, David Crochet a écrit :
Avant on intégrer l'emprise  au sol d'un ensemble de bâtiment ... 
Ensuite on modifiera les éléments pour y intégrer les élément 3D
Oui, mais la différence, c'est que là tu ajoute des attributs que les 
éléments présents en base ne permettent pas d'obtenir les infos que tu 
ajoute ; dans le cas d'un giratoire non découpé, il y a en base toutes 
les infos permettant de retrouver le trajet exact : point d'entrée, sens 
de circulation, point de sortie - d'ailleurs les calculateurs 
d'itinéraire/gps savent le faire.


cordialement
Leni


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

Re: [OSM-talk-fr] nouveau champ takeaway:lunchbox

[Julien Coupey]

Bonjour,

Je ne sais pas si c'est exactement ce que tu souhaites décrire, mais il 
y a déjà bulk_purchase[1] qui semble approprié.


Il est déjà utilisé pour les épiceries « en vrac » qui fleurissent 
ici[2] ou là[3].


À +
Julien

[1] : https://wiki.openstreetmap.org/wiki/Key:bulk_purchase
[2] : https://www.openstreetmap.org/node/5618249615
[3] : https://www.openstreetmap.org/node/5867522816

On 18/09/2018 11:20, Vivien MICHON wrote:

Bonjour,

Je propose la possibilité d’indiquer les commerces acceptant que le 
client vienne avec son propre contenant (de type boîte fermable et 
réutilisable).


Cette pratique est de plus en plus courante, afin d’éviter l’utilisation 
de boîtes ou papiers jetables (zéro déchet).


Elle est possible en vente à emporter dans un nombre croissant de 
restaurants, traiteurs, boucheries, fromageries…


Je propose ainsi le nouveau champ « takeaway:lunchbox », indiqué en YES 
ou NO.


Le terme « lunchbox » fait référence à la boîte contenant le déjeuner, 
qui peut être utilisée à toute heure, pour tout type d’achat. Le terme 
indique également qu’il s’agit de nourriture.


exemple : https://www.openstreetmap.org/node/5130551429

Merci d’avance pour vos commentaires.



___
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] nouveau champ takeaway:lunchbox

[Francescu GAROBY]

Je rejoins cet avis : de plus en plus de commerces proposent de la vente en
vrac. Les clients viennent avec leurs sacs en papier/bocaux/..., afin
d'éviter le suremballage.
Je pense que c'est dans ce cadre-là, plus généraliste, que ce nouveau tag
devrait s'inscrire.
Sur le principe, j'approuve la création d'un tel tag. Mais, vu ma remarque
précédente, doit-il alors être un sous tag de "takeaway" ? J'ai un doute...

Francescu

Le mar. 18 sept. 2018 à 11:56, Jean-Claude Repetto  a
écrit :

> Le 18/09/2018 à 11:20, Vivien MICHON a écrit :
> > Je propose la possibilité d’indiquer les commerces acceptant que le
> > client vienne avec son propre contenant (de type boîte fermable et
> > réutilisable).
> >
> > Cette pratique est de plus en plus courante, afin d’éviter l’utilisation
> > de boîtes ou papiers jetables (zéro déchet).
> >
> > Elle est possible en vente à emporter dans un nombre croissant de
> > restaurants, traiteurs, boucheries, fromageries…
> >
> >
> >
> > Je propose ainsi le nouveau champ « takeaway:lunchbox », indiqué en YES
> > ou NO.
> >
> > Merci d’avance pour vos commentaires.
>
> Bonjour,
>
> Le terme "lunchbox" ne me paraît pas approprié à tous les cas, par
> exemple si tu achètes du liquide pour vaisselle, tu ne vas pas le mettre
> dans une lunchbox.
> Exemples de produits de ce genre:
> http://www.boomerang.bio/nos-produits/32-entretien-de-la-maison
>
> Il faudrait plutôt trouver un terme évoquant la notion de "sans emballage".
>
> Jean-Claude
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


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

Re: [OSM-talk-fr] nouveau champ takeaway:lunchbox

[Jean-Claude Repetto]

Le 18/09/2018 à 11:20, Vivien MICHON a écrit :
> Je propose la possibilité d’indiquer les commerces acceptant que le
> client vienne avec son propre contenant (de type boîte fermable et
> réutilisable).
> 
> Cette pratique est de plus en plus courante, afin d’éviter l’utilisation
> de boîtes ou papiers jetables (zéro déchet).
> 
> Elle est possible en vente à emporter dans un nombre croissant de
> restaurants, traiteurs, boucheries, fromageries…
> 
>  
> 
> Je propose ainsi le nouveau champ « takeaway:lunchbox », indiqué en YES
> ou NO.
> 
> Merci d’avance pour vos commentaires.

Bonjour,

Le terme "lunchbox" ne me paraît pas approprié à tous les cas, par
exemple si tu achètes du liquide pour vaisselle, tu ne vas pas le mettre
dans une lunchbox.
Exemples de produits de ce genre:
http://www.boomerang.bio/nos-produits/32-entretien-de-la-maison

Il faudrait plutôt trouver un terme évoquant la notion de "sans emballage".

Jean-Claude



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

Re: [OSM-talk-fr] Les bretelles

[djakk djakk]

Oui, aussi.


djakk

Le mar. 18 sept. 2018 à 11:17, Rpnpif  a écrit :

> Le 18 septembre 2018, djakk djakk a écrit :
>
> > Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu
> > n'écrives ce mail :
> > https://www.openstreetmap.org/changeset/62524278
> >  :O
> >
>
> Une explication ne signifie pas accord de celui qui la reçoit.
>
> --
> Alain Rpnpif
>
> ___
> 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] nouveau champ takeaway:lunchbox

[Vivien MICHON]

Bonjour,

Je propose la possibilité d'indiquer les commerces acceptant que le client 
vienne avec son propre contenant (de type boîte fermable et réutilisable).
Cette pratique est de plus en plus courante, afin d'éviter l'utilisation de 
boîtes ou papiers jetables (zéro déchet).
Elle est possible en vente à emporter dans un nombre croissant de restaurants, 
traiteurs, boucheries, fromageries...

Je propose ainsi le nouveau champ « takeaway:lunchbox », indiqué en YES ou NO.
Le terme « lunchbox » fait référence à la boîte contenant le déjeuner, qui peut 
être utilisée à toute heure, pour tout type d'achat. Le terme indique également 
qu'il s'agit de nourriture.

exemple : https://www.openstreetmap.org/node/5130551429

Merci d'avance pour vos commentaires.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Les bretelles

[Rpnpif]

Le 18 septembre 2018, djakk djakk a écrit :

> Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu
> n'écrives ce mail :
> https://www.openstreetmap.org/changeset/62524278
>  :O
> 

Une explication ne signifie pas accord de celui qui la reçoit.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Classement ville/village - city/town/village

[Rpnpif]

Le 17 septembre 2018, Philippe Verdy a écrit :

> Alors quand tu dis "dans l'Ouest, le terme village est dévalorisant", c'est
> en fait tout l'inverse. Dévalorisant pour qui ?

C'est ce qui est encore observé ou entendu chez des élus ruraux plutôt
âgés qui sont encore assez nombreux dans les contrées isolées. J'habite
en rural et je me bats souvent pour inverser ce sentiment surtout
auprès de nombreux agriculteurs conventionnels même jeunes.

L'attrait de la ville « moderne » y est fort. C'est un sentiment hérité
du 20e siècle.

Tu as raison, ce n'est pas un sentiment général.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Les bretelles

[djakk djakk]

Ça n’est pas fait au hasard, je te l’ai pourtant expliqué avant que tu
n'écrives ce mail :
https://www.openstreetmap.org/changeset/62524278
 :O

Le mar. 18 sept. 2018 à 09:48, Philippe Verdy  a écrit :

> Note: djakk djakk s'est maintenant lancé dan la conversion de "village" en
> "town", en piochant au hasard (là encore en Bretagne et à proximité autour
> en Basse-Normandie, Maine, Anjou, Loire-Atlantique et Vendée).
> Du coup on a des villages mieux classés que les réelles villes pourtant
> pas loin.
> Et ça se voit dans le rendu final par défaut sur osm.org !
> Il n'y a pas de critère bien défini. On dirait qu'il a décidé de piocher
> non pas les bourgs-centre des bassins de vie comme il semble l'indiquer
> mais n'importe quelle commune siège d'une communauté de communes (dont
> certaines n'existent déjà plus depuis début 2017 ou sont devenues des
> communes nouvelles).
>
> Note: les intercommunalités depuis 2017 ont toutes au moins 15 000
> habitants, mais ça s'est fait de façon forcée, et pas forcément selon les
> bassins de vie (qui sont plutôt concertés au niveau des "pays" qui
> regroupaient déjà des intercommunalités mais ont été aussi redessinés un
> peu lorsque les intercommunalités ont été forcées de fusionner).
>
> Je ne pense pas que les intercommunalités soient pertinentes, d'autant
> plus que leur siège n'est pas forcément non plus dans la commune centre. La
> distribution des présences de services publics résulte d'accords locaux
> entre communes, le siège de l'intercommunalité résulte aussi de choix
> budgétaires et des ressources immobilières, ou de la présence de lignes de
> transports. Et même regroupées de force, les intercommunalités ne sont pas
> centrées sur leur ville siège dont le bassin de vie et l'attractivité
> réelle peut sortir aussi de leur propre territoire et couvrir des communes
> de l'intercommunaltié voisine.
>
> Je suggère de ne pas expérimenter ces changements dans la base OSM
> elle-même mais plutôt de mettre au point une base à part sous forme de
> liste à partir d'une feuille de calcul pour créer un CSV et générer une
> carte uMap permettant de visualiser ces listes sous forme de nuage de
> points selon plusieurs critères. Ca permet de ne pas aller trop vite dans
> la sélection, vérifier la densité des points selon le niveau de zoom,
> ajuster les critères pertinents à retenir sur chaque niveau de zoom, et
> ensuite définir éventuellement des tags OSM adaptés, et d'en discuter et
> les documenter sur une liste internationale.
>
> Et ensuite cela permettra aussi de faire les éventuels changements dans
> les clés existantes sans en oublier et non au hasard, et même de les
> vérifier automatiquement (par exemple, analyse Osmose vérifiant ces
> critères). Le rendu suivra ensuite concernant les éventuelles clés
> supplémentaires documentées sur lesquelles on aura importé correctement les
> valeurs de façon cohérente et vérifiable. Le rendu ensuite pourra suivre et
> s'adapter aux critères retenus pour chacun de ses niveaux de zoom. ou en
> fonction de la densité relative des libellés
>
> En attendant, les changements apportés sont plus une pollution et sont une
> gêne visuelle évidente pour les réutilisateurs des cartes rendues
> standards, notamment pour les rendus voisins des niveaux de zoom 9-10-11 en
> France.
>
>
>
> Le mar. 18 sept. 2018 à 09:26, Christian Quest 
> a écrit :
>
>> Le dim. 16 sept. 2018 à 13:01, Frédéric Rodrigo 
>> a écrit :
>>
>>> > Du coup je propose link_from et link_to : pour une bretelle dans le
>>> > sens autoroute vers tertiary, on aura link_from=motorway et
>>> > link_to=tertiary.
>>>
>>> Cette information peut être calculé depuis la topologie et là n'apporte
>>> rien, même pas de la cohérence.
>>>
>>
>> Je ne vois pas l'intérêt non plus.
>>
>> L'info est déjà dans la topologie des données et une requête postgis (ou
>> autre) permet de savoir à quoi est connecté un tronçon de _link si on en a
>> vraiment besoin.
>>
>> Les données OSM sont des données GEO et à ce titre, on a plein
>> d'informations latentes que nous offrent la topologie et la géo, même si
>> elle ne figurent pas sur chaque objet en tant que tel.
>> Par contre pour tirer le maximum des données OSM il faut savoir exploiter
>> topologie et géo, sinon on passe à côté de l'essentiel et on a tendance à
>> rajouter des infos redondantes sans grand intérêt (et qui, en plus, ne
>> seront pas évident à conserver à jour).
>>
>> --
>> 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] Les bretelles

[Philippe Verdy]

Note: djakk djakk s'est maintenant lancé dan la conversion de "village" en
"town", en piochant au hasard (là encore en Bretagne et à proximité autour
en Basse-Normandie, Maine, Anjou, Loire-Atlantique et Vendée).
Du coup on a des villages mieux classés que les réelles villes pourtant pas
loin.
Et ça se voit dans le rendu final par défaut sur osm.org !
Il n'y a pas de critère bien défini. On dirait qu'il a décidé de piocher
non pas les bourgs-centre des bassins de vie comme il semble l'indiquer
mais n'importe quelle commune siège d'une communauté de communes (dont
certaines n'existent déjà plus depuis début 2017 ou sont devenues des
communes nouvelles).

Note: les intercommunalités depuis 2017 ont toutes au moins 15 000
habitants, mais ça s'est fait de façon forcée, et pas forcément selon les
bassins de vie (qui sont plutôt concertés au niveau des "pays" qui
regroupaient déjà des intercommunalités mais ont été aussi redessinés un
peu lorsque les intercommunalités ont été forcées de fusionner).

Je ne pense pas que les intercommunalités soient pertinentes, d'autant plus
que leur siège n'est pas forcément non plus dans la commune centre. La
distribution des présences de services publics résulte d'accords locaux
entre communes, le siège de l'intercommunalité résulte aussi de choix
budgétaires et des ressources immobilières, ou de la présence de lignes de
transports. Et même regroupées de force, les intercommunalités ne sont pas
centrées sur leur ville siège dont le bassin de vie et l'attractivité
réelle peut sortir aussi de leur propre territoire et couvrir des communes
de l'intercommunaltié voisine.

Je suggère de ne pas expérimenter ces changements dans la base OSM
elle-même mais plutôt de mettre au point une base à part sous forme de
liste à partir d'une feuille de calcul pour créer un CSV et générer une
carte uMap permettant de visualiser ces listes sous forme de nuage de
points selon plusieurs critères. Ca permet de ne pas aller trop vite dans
la sélection, vérifier la densité des points selon le niveau de zoom,
ajuster les critères pertinents à retenir sur chaque niveau de zoom, et
ensuite définir éventuellement des tags OSM adaptés, et d'en discuter et
les documenter sur une liste internationale.

Et ensuite cela permettra aussi de faire les éventuels changements dans les
clés existantes sans en oublier et non au hasard, et même de les vérifier
automatiquement (par exemple, analyse Osmose vérifiant ces critères). Le
rendu suivra ensuite concernant les éventuelles clés supplémentaires
documentées sur lesquelles on aura importé correctement les valeurs de
façon cohérente et vérifiable. Le rendu ensuite pourra suivre et s'adapter
aux critères retenus pour chacun de ses niveaux de zoom. ou en fonction de
la densité relative des libellés

En attendant, les changements apportés sont plus une pollution et sont une
gêne visuelle évidente pour les réutilisateurs des cartes rendues
standards, notamment pour les rendus voisins des niveaux de zoom 9-10-11 en
France.



Le mar. 18 sept. 2018 à 09:26, Christian Quest  a
écrit :

> Le dim. 16 sept. 2018 à 13:01, Frédéric Rodrigo 
> a écrit :
>
>> > Du coup je propose link_from et link_to : pour une bretelle dans le
>> > sens autoroute vers tertiary, on aura link_from=motorway et
>> > link_to=tertiary.
>>
>> Cette information peut être calculé depuis la topologie et là n'apporte
>> rien, même pas de la cohérence.
>>
>
> Je ne vois pas l'intérêt non plus.
>
> L'info est déjà dans la topologie des données et une requête postgis (ou
> autre) permet de savoir à quoi est connecté un tronçon de _link si on en a
> vraiment besoin.
>
> Les données OSM sont des données GEO et à ce titre, on a plein
> d'informations latentes que nous offrent la topologie et la géo, même si
> elle ne figurent pas sur chaque objet en tant que tel.
> Par contre pour tirer le maximum des données OSM il faut savoir exploiter
> topologie et géo, sinon on passe à côté de l'essentiel et on a tendance à
> rajouter des infos redondantes sans grand intérêt (et qui, en plus, ne
> seront pas évident à conserver à jour).
>
> --
> 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

Re: [OSM-talk-fr] Le site de l'association OSM-FR fait peau neuve

[Christian Quest]

C'est sur ma tout-doux liste... faire en sorte qu'on puisse accéder à
l'ancien contenu quand il n'a pas été recréé sur le nouveau site.

Le dim. 16 sept. 2018 à 20:15, deuzeffe  a écrit :

> Hello,
>
> nheir fait remarquer que l'ancienne page
> https://openstreetmap.fr/bdortho n'existe plus. Une page similaire
> est-elle prévue ?
> (si non, je fais pointer l'url dans la page du wiki concernée vers
> l'ancienne sur Internet archive ^^).
>
> On 03/09/2018 14:10, François Lacombe wrote:
> > Bonsoir à tous,
> >
> > Cela avait été annoncé lors du dernier SOTM-Fr à Bordeaux en Juin
> > dernier, la nouvelle version du site web de l'association arrivait à
> > maturité.
> > L'été a permis de faire les dernières finitions et elle a été mise en
> > ligne dans le courant du week-end.
> > https://www.openstreetmap.fr/
> >
> > L'ergonomie a été complètement revue et une carte avec différents rendus
> > a été ajoutée à la page d'accueil.
> > L'accès aux informations utiles pour chacun est désormais plus facile,
> > avec de grandes rubriques telles que "Contribuer" ou "Utiliser" et un
> > blog pour partager vos expériences et les actualités nationales.
> > https://www.openstreetmap.fr/contribuer/
> > https://www.openstreetmap.fr/actualites/
> >
> > En remerciant Noémie, Flora et Florian pour le développement et Jocelyn
> > pour l'administration et la bascule de ce week-end
> >
> > Bonne consultation et à bientôt
> >
> > François pour le CA de l'association
> >
> >
> > ___
> > 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] Changement unilatéral de la définition de tags

[Christian Quest]

Le dim. 16 sept. 2018 à 15:43, djakk djakk  a écrit :

> Je pense que je rajoute de l’information sans en supprimer ... ? Bon
> certes je chamboule l’existant ...
>
> djakk
>

Dommage de procéder ainsi "en force".

Le tagging sur OSM fonctionne grâce à un consensus, il faut le respecter ou
ouvrir une discussion (large) pour faire naître un nouveau consensus et ne
pas "chambouler" ainsi l'existant, au risque d'un douloureux retour de
flamme.

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

Re: [OSM-talk-fr] Les bretelles

[Christian Quest]

Le dim. 16 sept. 2018 à 13:01, Frédéric Rodrigo  a
écrit :

> > Du coup je propose link_from et link_to : pour une bretelle dans le
> > sens autoroute vers tertiary, on aura link_from=motorway et
> > link_to=tertiary.
>
> Cette information peut être calculé depuis la topologie et là n'apporte
> rien, même pas de la cohérence.
>

Je ne vois pas l'intérêt non plus.

L'info est déjà dans la topologie des données et une requête postgis (ou
autre) permet de savoir à quoi est connecté un tronçon de _link si on en a
vraiment besoin.

Les données OSM sont des données GEO et à ce titre, on a plein
d'informations latentes que nous offrent la topologie et la géo, même si
elle ne figurent pas sur chaque objet en tant que tel.
Par contre pour tirer le maximum des données OSM il faut savoir exploiter
topologie et géo, sinon on passe à côté de l'essentiel et on a tendance à
rajouter des infos redondantes sans grand intérêt (et qui, en plus, ne
seront pas évident à conserver à jour).

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

Re: [OSM-talk-fr] Camion pizza

[Philippe Verdy]

Note: la remarque ne vaut pas que pour les commerces (food trucks,
boulangers-patissiers qui font des tournées sur des emplacerments fixes
certains jours dans des heures limitées).

On peut aussi inclure les emplacements des autres services itinérants
(exemple: coiffeurs, points d'accueil mobile des services publics tels que
les services des intercommunalités qui vont d'un village à l'autre avec une
présence hebdomadaire voire mensuelle, ou "bibliobus" des médiathèques), et
même des médecins ou infirmiers (le truck tient lieu de "maison de santé"
itinérante dans les communes qui n'ont pas les moyens d'en installer une
fixe et qui se mettent d'accord avec les voisines pour se partager un
service de proximité), ou des camionettes/caravanes/campingcars
multiservices qui travaillent pour plusieurs municipalités et proposent des
services multiples : relais-poste, dépot/retrait de colis, épicerie,
coiffure/soins du corps, infirmières...

Et là on n'est plus en zone urbaine (comme dans l'exemple du foodtruck
pizzeria) mais dans le monde très rural où s'organiser malgré tout le
maintien d'une présence régulière des commerces et services publics ou
l'animation culturelle pour tous, et qui rendent de grands services
notamment aux personnes plus agées qui ne peuvent plus conduire et ont des
difficultés avec les transports publics (ni les moyens ni le temps de payer
des taxis pour faire des dizaines de kilomètres et partir de chez eux toute
la journée pour rentrer ensuite trop chargés en transportant pendant des
heures des produits alimentaires fragiles et lourds).


Le mar. 18 sept. 2018 à 09:00, Philippe Verdy  a écrit :

> "takeaway" s'applique aussi à tous les commerces fixes qui font de la
> vente à emporter, dont la plupart des pizzerias en dur, ou même les petites
> "cabanes" quasi fixes en préfabriqué (théoriquement mobiles, mais ces
> mobile-homes sont quasi fixes toute l'année sur les parkings de
> supermarchés), ou les boulangeries traditionnelles et les distributeurs
> automatiques de sandwiches.
>
> Même les restaus traditionnels se sont mis à la vente à emporter, il n'y a
> pas que les "fastfoods" (ou les "drives" qui ont fleuri un peu partout). La
> vente à emporter alimentaire a une fiscalité différente en France (taux de
> TVA réduit au niveau "alimentaire" et non pas au niveau du taux de TVA des
> "services" pour la vente sur place (qui inclut aussi bien le service à
> table sur commande comme dans les restaus traditionnels et la plupart des
> brasseries, ou sur plateau avec caisse centrale et service à table par le
> client lui-même comme dans la plupart des fastfoods et cafétérias... car il
> reste encore un service en salle pour le nettoyage des tables, et nombre de
> fastfoods proposent aussi de ne pas attendre devant la caisse et de vous
> apporter votre plateau là où vous installez après être passé en caisse ou
> payé votre commande en ligne sur voitre smartphone ou sur une borne
> automatique; systématiquement on vous demande "sur place ou à emporter?" et
> ça change le prix et la présentation: "sur place" on est servi sur plateau,
> "à emporter" on est servi dans des sacs, exactement comme pour les "drive").
>
> Bref, il faudrait une autre clé pour les emplacements quasi fixes (loués
> ou réservés à l'année, à mois que le commerçant ne soit pas là avant
> l'heure limite d'ouverture du marché et que son emplacement soit alors
> autorisé à d'autres commerces ou comme parking) utilisés par les foodtrucks
> ou sur les places de marché ?
>
> Pour les foodtrucks et autres commerces itinérants (y compris les places
> de marché), pourquoi pas "amenity=parking", avec dedans un emplacement
> délimité par une zone ou un noeud "parking_space" avec une clé
> "dedicated=yes"+les clés normales du type de commerce (shop=* ou
> amenity=restaurant) et les autres clés classiques ? On peut ajouter à cet
> emplacement "takeway=yes" mais c'est à priori implicite pour les
> emplacements de parking, où il n'y a pas de salle même s'il peut y avoir
> une table ou deux et quelques chaises installées sur le parking mais
> débarassées en fin de service.
>
>
>
> Le mar. 18 sept. 2018 à 08:32, Jean-Christophe Becquet  a
> écrit :
>
>> Bonjour,
>>
>> Est-ce que :
>>
>> amenity=fast_food
>> cuisine=pizza
>>
>> vous semble la bonne description pour un camion qui vend des pizzas à
>> emporter ?
>>
>> Comme cet exemple
>> https://www.openstreetmap.org/node/4413391675
>>
>> Ajouter
>> takeaway=yes
>> ou takeaway=only
>>
>> selon les cas ?
>>
>> Merci
>>
>> Bonne journée
>>
>> JCB
>> --
>> Atelier-conférence Cartes en liberté avec OpenStreetMap - jeudi 4
>> octobre 2018 à Marseille
>>
>> https://www.adbs.fr/sites/default/files/documents/adbs-paca-atelier-conference-cartes-en-liberte-avec-openstreetmap_apitux_0.pdf
>>
>> ==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 : 

Re: [OSM-talk-fr] Camion pizza

[Philippe Verdy]

"takeaway" s'applique aussi à tous les commerces fixes qui font de la vente
à emporter, dont la plupart des pizzerias en dur, ou même les petites
"cabanes" quasi fixes en préfabriqué (théoriquement mobiles, mais ces
mobile-homes sont quasi fixes toute l'année sur les parkings de
supermarchés), ou les boulangeries traditionnelles et les distributeurs
automatiques de sandwiches.

Même les restaus traditionnels se sont mis à la vente à emporter, il n'y a
pas que les "fastfoods" (ou les "drives" qui ont fleuri un peu partout). La
vente à emporter alimentaire a une fiscalité différente en France (taux de
TVA réduit au niveau "alimentaire" et non pas au niveau du taux de TVA des
"services" pour la vente sur place (qui inclut aussi bien le service à
table sur commande comme dans les restaus traditionnels et la plupart des
brasseries, ou sur plateau avec caisse centrale et service à table par le
client lui-même comme dans la plupart des fastfoods et cafétérias... car il
reste encore un service en salle pour le nettoyage des tables, et nombre de
fastfoods proposent aussi de ne pas attendre devant la caisse et de vous
apporter votre plateau là où vous installez après être passé en caisse ou
payé votre commande en ligne sur voitre smartphone ou sur une borne
automatique; systématiquement on vous demande "sur place ou à emporter?" et
ça change le prix et la présentation: "sur place" on est servi sur plateau,
"à emporter" on est servi dans des sacs, exactement comme pour les "drive").

Bref, il faudrait une autre clé pour les emplacements quasi fixes (loués ou
réservés à l'année, à mois que le commerçant ne soit pas là avant l'heure
limite d'ouverture du marché et que son emplacement soit alors autorisé à
d'autres commerces ou comme parking) utilisés par les foodtrucks ou sur les
places de marché ?

Pour les foodtrucks et autres commerces itinérants (y compris les places de
marché), pourquoi pas "amenity=parking", avec dedans un emplacement
délimité par une zone ou un noeud "parking_space" avec une clé
"dedicated=yes"+les clés normales du type de commerce (shop=* ou
amenity=restaurant) et les autres clés classiques ? On peut ajouter à cet
emplacement "takeway=yes" mais c'est à priori implicite pour les
emplacements de parking, où il n'y a pas de salle même s'il peut y avoir
une table ou deux et quelques chaises installées sur le parking mais
débarassées en fin de service.



Le mar. 18 sept. 2018 à 08:32, Jean-Christophe Becquet  a
écrit :

> Bonjour,
>
> Est-ce que :
>
> amenity=fast_food
> cuisine=pizza
>
> vous semble la bonne description pour un camion qui vend des pizzas à
> emporter ?
>
> Comme cet exemple
> https://www.openstreetmap.org/node/4413391675
>
> Ajouter
> takeaway=yes
> ou takeaway=only
>
> selon les cas ?
>
> Merci
>
> Bonne journée
>
> JCB
> --
> Atelier-conférence Cartes en liberté avec OpenStreetMap - jeudi 4
> octobre 2018 à Marseille
>
> https://www.adbs.fr/sites/default/files/documents/adbs-paca-atelier-conference-cartes-en-liberte-avec-openstreetmap_apitux_0.pdf
>
> ==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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Camion pizza

[Jean-Christophe Becquet]

Bonjour,

Est-ce que :

amenity=fast_food
cuisine=pizza

vous semble la bonne description pour un camion qui vend des pizzas à
emporter ?

Comme cet exemple
https://www.openstreetmap.org/node/4413391675

Ajouter
takeaway=yes
ou takeaway=only

selon les cas ?

Merci

Bonne journée

JCB
-- 
Atelier-conférence Cartes en liberté avec OpenStreetMap - jeudi 4
octobre 2018 à Marseille
https://www.adbs.fr/sites/default/files/documents/adbs-paca-atelier-conference-cartes-en-liberte-avec-openstreetmap_apitux_0.pdf

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