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] loc_name vs. reg_name

[Bernhard R. Fischer]

On 2018-09-18 09:26, Warin wrote:
> On 18/09/18 16:37, Martin Koppenhoefer wrote:
>>
>> sent from a phone
>>
>>> On 18. Sep 2018, at 07:02, Bernhard R. Fischer 
>>> wrote:
>>>
>>> Is there any clarification about the difference between loc_name and
>>> reg_name?
>>
>> in which sense? Both tags are used for alternative names, local is
>> smaller/narrower in scope than regional, conceptually
>
> You may want a definition of 'local' and 'regional'.
>
> That varies across the globe.
> When a 'local' cop in Birdsville, Australia has a beat the size of the
> UK you may understand the difficulty of defining 'local'.
>
> Best left fuzzy to adapt for the place, with 'local' being a smaller
> area than 'regional'.
>

Ok of course, but the size of the entity to be named isn't determined by
the name-tag I choose rather than e.g. by place=hamlet/city/..., isn't it?

Regards,
Bernhard



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

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] loc_name vs. reg_name

[Bernhard R. Fischer]

Hi!

Ok, basically I understand the difference between "local" and "regional".

But actually I thought that this/these tags are used for names of
entities which are used by locals (in contrast to the official name of
something).

In this case, having two such tags would imply that there are locals who
call an entity by loc_name. And that there are other locals which are
"not so local" as the previous ones (not living directly there) which
call the same entity "reg_name".

Is that correct?

Regards,

Bernhard



On 2018-09-18 08:37, Martin Koppenhoefer wrote:
>
> sent from a phone
>
>> On 18. Sep 2018, at 07:02, Bernhard R. Fischer  wrote:
>>
>> Is there any clarification about the difference between loc_name and
>> reg_name?
>
> in which sense? Both tags are used for alternative names, local is 
> smaller/narrower in scope than regional, conceptually 
>
>
> Cheers,
> Martin 



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

[Talk-in] My diary on Open Data: Roads in India

[Naveen Francis]

Hello,

Open Data: Roads in India
https://www.openstreetmap.org/user/naveenpf/diary/44970

Please request to govt to release more #opendata in the spatial format

Thanks,
naveenpf
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[OSM-talk] Waterway rel with mix of line & poly

[Jem]

Is there any problem with defining a water feature that is a mix of
polygons & lines? e.g. https://www.openstreetmap.org/relation/6447531

Should it be fixed, or is it ok?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

Re: [Talk-vi] Road network improvements in Vietnam

[Rihards]

On 2018.09.19. 00:36, Andrew Wiseman wrote:
> Hello OSM Vietnam,
> 
> My name is Andrew Wiseman, I work for Apple on the maps team. My team is
> interested in doing some work on the road network in Vietnam on
> OpenStreetMap, things like adding missing roads, making sure roads
> connect properly, fixing incorrect alignments with GPS traces, ensuring
> road classifications are consistent, and other similar issues. 
> 
> Are there places you know of that need improvement or types of problems
> you see frequently?

Hi Andrew and thank you for your interest in OSM, as well as great, open
communication.

I have only mapped in Vietnam when visiting, but I long for returning
and mapping a bit more, as well as benefiting from our collective work.

From my visit, I recall that a major challenge was the rapid development
- new highways were built all over the place, buildings torn down and
built anew... One could only rely on ortophoto layers (and older GPS
traces) after visiting the place.

If there was a way to obtain recent - and preferably updated every now
and then - ortophoto for Vietnam, it could be of a great help.

> We have a Github page here about the
> project: https://github.com/osmlab/appledata/issues/121
> 
> Thank you,
> Andrew
> Apple, Inc.
> 
> Andrew Wiseman |  Maps | andrew_wise...@apple.com
> -- 
 Rihards

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

Re: [Talk-de] Relation für Gebäude

[Martin Koppenhoefer]

Am 18. September 2018 um 15:30 schrieb Benedikt Bastin <
b.bast...@googlemail.com>:

> Hallo zusammen!
>
> Ich arbeite gerade an Indoor-Karten und bin jetzt am Problem dran, ein
> gesamtes Gebäude herunterzuladen. Das Gebäude besteht aus einem
> Multipolygon für den Umriss und natürlich den diversen Räumen und POIs im
> Inneren. Das über eine Flächenabfrage mit Overpass oder über die einzelnen
> Knoten abzufragen ist, gelinde gesagt, hässlich und sehr fehleranfällig
> (beispielsweise U-Bahnen, Stromleitungen, Zäune an der Hauswand, etc.).
>



d.h. Du schlägst vor, U-Bahnen und Stromleitungen und Zäune an der Hauswand
in die Gebäuderelation einzufügen?
Ehrlich gesagt habe ich den Verdacht, du brauchst vielleicht einfach ein
größeres Polygon als nur ein oder mehrere Gebäude, vielleicht das komplette
Gelände / den Standort, dann sollte es einfach sein, alles benötigte über
eine räumliche Abfrage zu erhalten.



>
> Nun wäre eine Relation, die das gesamte Gebäude einschließt, eine super
> Sache, um das gesamte Gebäude strukturiert herunterladen und verarbeiten zu
> können. Es gab bereits Proposals dazu, die Relationen definiert haben, die
> dafür sehr gut geeignet wären (beispielsweise https://wiki.openstreetmap.
> org/wiki/Proposed_features/indoor), aber die sind leider alle inaktiv.
>


Normalerweise lösen wir das so, dass wir eine räumliche Abfrage machen, und
in dem Ergebnis dann die benötigten/interessanten Teile finden über das
Filtern mit tags. So kommt man ohne Relationen aus, die hier Probleme mit
sich bringen würden (vor allem müssen sie von Hand gepflegt werden, und
weil man sich darauf nicht verlassen kann, wird man sowieso eine räumliche
Abfrage machen um "alles" zu bekommen).

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-GB] 'historic' county boundaries added to the database

[Warin]

On 27/08/18 06:05, Martin Wynne wrote:

I don't think it's for those who have mapped something in OSM to
demonstrate majority support for its retention. I think it is for those
seeking to have others' contributions removed to demonstrate a clear
consensus in favour of deletion.


Should this consensus be among OSM mappers or OSM users?





OSM users can easily remove stuff in there pre filtering of OSM data. So 
it is not an issue for them.





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

[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: [Talk-it] aggiornamento emergency=access_point

[Martin Koppenhoefer]

2018-09-18 15:06 GMT+02:00 demon.box :

>
> Grazie Simone, ma non posso seguire questa modalità perchè ora l'ultima
> richiesta è di riassegnare anche tutti i codici. In sostanza devo anteporre
> LUME a tutti i codici che però saranno riorganizzati secondo una tabella di
> conversione che mi verrà fornita.
>
> In pratica:
>
> in entrata0101
> in uscita  LUME045
>
> in entrata0102
> in uscita  LUME046
>
> e così via...




ma se io vado lì, cosa vedo? 0102 oppure LUME046?
Un conto è convertire in LUME046 da 046, un'altro quello che adesso intendi
fare (tradurre con una lista).

Mentre il primo (anteporre un prefisso) è una cosa semplice, il secondo
probabilmente richiede un'altra procedura (per me a questo punto conviene
mappare ref:LUME=046 o anche ref:lume=LUME046, ma non toglierei i dati ref
che gli utenti hanno rilevati), e in sostanza è un import.

Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

[Talk-vi] Road network improvements in Vietnam

[Andrew Wiseman]

Hello OSM Vietnam,

My name is Andrew Wiseman, I work for Apple on the maps team. My team is 
interested in doing some work on the road network in Vietnam on OpenStreetMap, 
things like adding missing roads, making sure roads connect properly, fixing 
incorrect alignments with GPS traces, ensuring road classifications are 
consistent, and other similar issues. 

Are there places you know of that need improvement or types of problems you see 
frequently?

We have a Github page here about the project: 
https://github.com/osmlab/appledata/issues/121

Thank you,
Andrew
Apple, Inc.


Andrew Wiseman |  Maps | andrew_wise...@apple.com 

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

[Talk-at] Einladung zum September-Stammtisch in Graz am 24.9.2018

[Michael Maier]

Liebe OpenStreetMap-Interessierte in der Steiermark,

Der Stammtisch findet um 18:00 im Brot & Spiele in Graz statt -
Tischreservierung auf „OpenStreetMap“, wir sitzen im Kaminzimmer
(Nichtraucherbereich).

Zwecks Agenda und sonstigem bitte die Wiki-Seite¹ konsultieren:

[1] https://wiki.openstreetmap.org/wiki/Graz/Stammtisch

lg,
Michael

-- 
Michael Maier, Student of Telematics @ Graz University of Technology
OpenStreetMap Graz http://osm.org/go/0Iz@paV
http://wiki.osm.org/Graz
http://wiki.osm.org/Graz/Stammtisch

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

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: [Talk-it] aggiornamento emergency=access_point

[liste DOT girarsi AT posteo DOT eu]

Il 18/09/2018 15:06, demon.box ha scritto:

Grazie Simone, ma non posso seguire questa modalità perchè ora l'ultima
richiesta è di riassegnare anche tutti i codici. In sostanza devo anteporre
LUME a tutti i codici che però saranno riorganizzati secondo una tabella di
conversione che mi verrà fornita.

In pratica:

in entrata0101
in uscita  LUME045

in entrata0102
in uscita  LUME046

e così via...





Se vuoi io conservo ancora lo shapefile che mi ero creato quella volta e 
te lo mando, ha anteposto Lume nel codice:



ref=Lume


Non ho capito cosa intendi per entrata e uscita.


--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

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

[Talk-at] Müllinseln

[Christian Enzersdorfer]

Hallo,

Warum sind die Müllinseln ("Altstoffsammelstellen") nicht in OpenStreetMap - 
zumindest in Wien - enthalten?


Schöne Grüße
Christian
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

[Talk-at] Fwd: Re: [Tagging] Feature Proposal - RFC: Via ferrata simplified

[egil]

Hallo

Ich habe von Richard gehört, dass einige von Ihnen vielleicht daran 
interessiert sind, Vorschläge für Klettersteig-Tags zu diskutieren.


Es gibt jetzt zwei konkurrierende Vorschläge, siehe unten.

Grüße

Egil / pangoSE, Schweden


 Vidarebefordrat meddelande 
Ämne:   Re: [Tagging] Feature Proposal - RFC: Via ferrata simplified
Datum:  Tue, 4 Sep 2018 11:46:14 +0200
Från:   egil 
Svar till: 	Tag discussion, strategy and related tools 


Till:   tagg...@openstreetmap.org



Hi

Den 09/03/2018 kl. 02:53 PM, skrev Richard:

On Mon, Sep 03, 2018 at 01:25:45PM +0200, egil wrote:

https://wiki.openstreetmap.org/wiki/Proposed_features/Via_ferrata_simplified

please not a completely new utterly incompatible with everything else
proposal.

Many elements of the old proposal are in use and rendered by several
maps.

While the old proposal is controversial, the plan has been to overcome
much of the controversy by adding the possibility to tag ferratas as
relation of type route=ferrata (added a few days ago).

Why would you want to use route=hiking for ferrata if you can use
route=ferrata? Do you want to deprecate via_ferrata_scale as well?


 I responded to Richard here:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Via_ferrata_simplified
Feel free to join the discussion.

Cheers

___
Tagging mailing list
tagg...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

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: [Talk-de] Relation für Gebäude

[Tobias Knerr]

Am 18.09.2018, 16:21, schrieb Benedikt Bastin:
> Gibt es abseits des Zugehörigkeitsproblems noch weitere Sachen, die gegen 
> eine solche Relation sprechen?

Im Allgemeinen tendiert der Konsens in der Community dahin, Relationen
nur dort zu verwenden, wo sie notwendig sind.

Aus diesem Grund ist auch in Simple Indoor Tagging anders als bei dem
von dir verlinkten älteren Indoor-Proposal vorgesehen, dass der
Gebäudeumriss + level-Tags an den enthaltenen Elementen für die
Zuordnung zum Gebäude ausreichen soll.

Einen sehr ähnlich gelagerten Fall gibt es übrigens bei
3D-Gebäudemapping: Auch dort ist die Nutzung von Relationen zur
Zuordnung von Gebäudeteilen zum Gesamtgebäude in den allermeisten Fällen
optional¹ und unüblich – die weit überwiegende Mehrheit der 3D-Gebäude
verzichtet darauf.

Wenn du dennoch eine Relation verwenden willst, dann ist die
building-Relation die gängigste Wahl. Ich würde aber wie gesagt eher
davon abraten. Auch eine geringere Fehleranfälligkeit von Relationen
halte ich in der Praxis nämlich nicht für gegeben: Es ist einfach zu
schnell passiert, dass ein Mapper z.B. ein neues Objekt ergänzt, es aber
nicht zur Relation hinzufügt.


¹ Ausnahme ist die Klärung von Zuordnungsproblemen bei überlappenden
Gebäudeumrissen

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

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: [Talk-ca] Proposition d'import pour les arrêts d'autobus de EXO

[marc marc]

Bonjour,

Je viens poster ici mon avis suite à la demande qui m'a été faite
après discussion sur irc.
je réagis à la documentation de l'import sur le wiki
https://wiki.openstreetmap.org/wiki/FR-Import_arr%C3%AAts_d'autobus,_EXO_r%C3%A9seau_de_transport_m%C3%A9tropolitain
n'étant pas abonné à cette liste ci, je n'ai pas suivis une éventuelle 
discussion préalable et je risque donc peut-être de redire ce qui a déjà 
été dis.

globalement le projet d'import est correct.
cependant le point 5 (supprimer tous les arrêts existant) ne va pas
du tout.
je comprend bien que c'est bien plus pratique mais si c'est tant décrié 
c'est pour 3 raisons :
- supprimer/effacer conduit à une perte de l'historique de l'objet
- c'est indigeste à plus grande échelle. imagine que tu fasse un nouvel 
import dans 1 mois avec les nouveau arrêts ou avec des arrêts déplacé,
tu ne pas supprimer/recréer 100 arrêts pour un seul à ajouter.
- ces objets peuvent eux même être dans des relations, les supprimer va 
les retirer des relations et le nouvel objet ne prendra pas sa place,
donc au final tu détruits de l'information au lieu d'en rajouter.

Il m'a été dis que le nombre d'arrêt existant est très faible.
je pense donc que tu devrais commencer par un étape 0 :
ajouter une ref aux arrêts existant qui n'en ont pas.
comme cela cela te permet de garder le reste de ta procédure.
a plus large échelle, la solution est
https://wiki.openstreetmap.org/wiki/Conflation

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

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: [Talk-us] Yet more about USA Rail: now, wiki

[Martijn van Exel]

I pinned it for Nov 17-18 weekend. Add your city and plan a mapping party!
Martijn

> On Sep 18, 2018, at 1:27 PM, Martijn van Exel  wrote:
> 
> Okay there we are! 
> https://wiki.openstreetmap.org/wiki/Mapathon/US_Fall_Mapathon_2018 
>  
> 
> Sometime in November? Earlier?
> 
>> On Sep 18, 2018, at 1:03 PM, OSM Volunteer stevea > > wrote:
>> 
>> No hijack seen as actual or intended:  great idea, Martijn!
>> 
>> Trains, transit,  our map:  these really do keep getting better and better.
>> 
>> SteveA
>> 
>>> On Sep 18, 2018, at 12:01 PM, Martijn van Exel >> > wrote:
>>> 
>>> To branch out a little bit — sorry to hijack the thread Steve — it would be 
>>> nice to do a nationwide transit mapathon around transit. We used to run 
>>> nationwide coordinated mapathons and I miss them. I think they are fun to 
>>> connect communities. Who’s in and who wants to help coordinate?
>>> 
>>> Martijn
>> 
> 
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

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

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: [Talk-us] Yet more about USA Rail: now, wiki

[Martijn van Exel]

Okay there we are! 
https://wiki.openstreetmap.org/wiki/Mapathon/US_Fall_Mapathon_2018 
 

Sometime in November? Earlier?

> On Sep 18, 2018, at 1:03 PM, OSM Volunteer stevea  > wrote:
> 
> No hijack seen as actual or intended:  great idea, Martijn!
> 
> Trains, transit,  our map:  these really do keep getting better and better.
> 
> SteveA
> 
>> On Sep 18, 2018, at 12:01 PM, Martijn van Exel > > wrote:
>> 
>> To branch out a little bit — sorry to hijack the thread Steve — it would be 
>> nice to do a nationwide transit mapathon around transit. We used to run 
>> nationwide coordinated mapathons and I miss them. I think they are fun to 
>> connect communities. Who’s in and who wants to help coordinate?
>> 
>> Martijn
> 

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

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: [Talk-ca] Proposition d'import pour les arrêts d'autobus de EXO

[Damien Riegel]

Bonjour Claude,

Étant un novice en import également, j'attendais le retour d'autres
personnes. Peut-etre qu'une solicitation en anglais aurait plus de
résultats ?

Concernant les quelques noeuds mal placés, je pourrais les remettre en
place selon les coordonnées GTFS et y ajouter le numéro d'arret si tu veux,
plutot que de les supprimer. Je peux aussi travailler sur un script pour
automatiser la création des relations. On pourrait faire ça ligne par ligne
pour que ce soit plus simple de valider manuellement que les relations sont
correctes.

As-tu eu une réponse d'EXO concernant l'utilisation de leurs données dans
OSM ?

Damien

On Thu, 13 Sep 2018 at 12:54, Alouette955  wrote:

> Bonjour,
>
> Après quelques discussions informelles je propose ici un import pour les
> arrêts d’autobus du réseau EXO (anciennement Réseau de transport
> métropolitain).
>
>
> https://wiki.openstreetmap.org/wiki/FR-Import_arr%C3%AAts_d%27autobus,_EXO_r%C3%A9seau_de_transport_m%C3%A9tropolitain
>
> Cet import sera l’étape préliminaire à l’ajout des lignes et trajets
> d’autobus de ces réseaux par la création des relations incorporant tant les
> arrêts de bus que les chemins (rues) parcourues selon le *schéma de
> transport public v2* tel que décrit dans la page 
> *https://wiki.openstreetmap.org/wiki/FR:Bus
> *.
>
> Étant néophyte dans les imports j’aimerais soumettre cette page à tout
> commentaire permettant d’ajuster le tir allant jusqu’à me recommander de ne
> pas m’embarquer là-dedans.
>
> Merci,
>
> Claude
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-us] Yet more about USA Rail: now, wiki

[OSM Volunteer stevea]

No hijack seen as actual or intended:  great idea, Martijn!

Trains, transit,  our map:  these really do keep getting better and better.

SteveA

> On Sep 18, 2018, at 12:01 PM, Martijn van Exel  wrote:
> 
> To branch out a little bit — sorry to hijack the thread Steve — it would be 
> nice to do a nationwide transit mapathon around transit. We used to run 
> nationwide coordinated mapathons and I miss them. I think they are fun to 
> connect communities. Who’s in and who wants to help coordinate?
> 
> Martijn

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

Re: [Talk-us] Yet more about USA Rail: now, wiki

[Martijn van Exel]

To branch out a little bit — sorry to hijack the thread Steve — it would be 
nice to do a nationwide transit mapathon around transit. We used to run 
nationwide coordinated mapathons and I miss them. I think they are fun to 
connect communities. Who’s in and who wants to help coordinate?

Martijn

> On Sep 18, 2018, at 11:23 AM, OSM Volunteer stevea 
>  wrote:
> 
> Yes, I've been beating the drums rather loudly about USA Rail recently, yet 
> there is so much that OSM can (and should, imo) do about this.  OSM's actual 
> rail data (imported from TIGER a decade ago) do slowly improve, and for that 
> I am grateful, even as a lot of the work is both mine and many others.
> 
> However, our wiki regarding rail is, um, "messy" for reasons that are largely 
> historical.  In short, there is a distinct trend towards "statewide" rail 
> pages that rather comprehensively describe both freight/industrial rail (in 
> terms of major Class I and smaller railroads), then as things cleave from 
> freight to passenger, link to our Amtrak page (which remains quite 
> respectable) where applicable, AND describe the rapidly growing passenger 
> rail networks/systems in cities large, medium and small in the USA.  
> (Suburban/commuter trains, light rail systems, trams, monorails around 
> airports, tourism/heritage/historic/museum rail, etc.)
> 
> Unfortunately, there are also many rail wiki (most written by the 
> banned-from-OSM-years-ago infamous NE2) which, while seemingly 
> well-intentioned, are mere "dead end" histories of defunct rail from a 
> century ago, rather than the becoming-more-vibrant-daily rail network that I 
> (and others) want to see both properly mapped in OSM and documented in our 
> wiki in a sane, comprehensive way.
> 
> For example, (precede all of these with https://wiki.openstreetmap.org/wiki/) 
> here are some of these "defunct" pages I'd like to see "re-purposed" and 
> eventually go away:
> 
> Southern_Pacific_Transportation_Company
> Missouri_Pacific_Railroad
> Atchison,_Topeka_and_Santa_Fe_Railway
> Southern_Railway_(U.S.)
> Illinois_Central_Railroad_(pre-1972)
> 
> and I'm sure that isn't a complete list.  These railroads haven't existed for 
> decades and while I have great respect for how disused and abandoned 
> railroads both are and should be "in" OSM (and "properly" documented in our 
> wiki), this really isn't "today's" way to do it.  There are "cross-links" 
> with Wikipedia which likely make sense here, I'd like to focus OSM's wikis on 
> useful structure/organization of an entire states rail networks and providing 
> links to the actual underlying relation data that make our data so useful. 
> Wikipedia isn't going to do that, but it can (and should) capture 
> centuries-old history where we shouldn't.
> 
> Of course, there are wiki pages about USA Rail which must remain, including 
> the worldwide https://wiki.openstreetmap.org/wiki/WikiProject_Metro_systems 
> which has a USA section that is "fair to good" and more than one absolutely 
> charming wiki like 
> https://wiki.openstreetmap.org/wiki/Walt_Disney_World_Monorail_System which I 
> find delightful and shouldn't change a byte (unless they need updates).
> 
> In short, I'm asking this talk-us list if "rail wiki cleanup in the USA" is 
> on the right track (so, chime in with your consensus additions, please).  Is 
> the "trend" towards statewide rail wikis correct?  (It seems so to me).  Can 
> the NE2-authored "old stuff" (many of these wiki haven't been touched in 7+ 
> years) be repurposed and then deleted?
> 
> Please contact me on-list or off if you want to see rail data and rail wiki 
> continue to improve in OSM and we can talk about how — there is a great deal 
> to do!
> 
> SteveA
> California
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us


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

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: [Talk-de] Fläche in Polygone aufteilen

[Markus]

Hi Walter,

> hier ein sehr anspruchsvoller Ansatz:

ja, sowas würde mich als Herausforderung reizen :-)
(aber ich weiss noch nicht, ob ich mich da nicht grauslig übernehme
und Zeit habe ich grad auch nicht wirklich...)

Vielleicht gibt es sowas ja schon?

Ziel wäre:
OSM als Basiskarte,
auf der ich mit Mausklicks Polygone zusammenklicken kann,
die dann in einer PostgreSQL/PostGIS DB landen
und auf der Basiskarte wieder visualisiert werden können :-)

Ich bräuchte also eine VM zum Rumspielen...

mit was für einem freien OS? Ubuntu?
(habe von Konsole absolut keine Ahnung)

darauf eine PostgreSQL/PostGIS DB

OpenLayers oder Leaflet (was ist hier besser?)

einen Webserver zum Anzeigen

Noch etwas?

Was braucht meine VM für Specs?

- - - -

Und dann bin ich gespannt, ob ich das alles erst mal installiert und
vorbereitet kriege... ;-)

Mit herzlichem Gruss,
und danke für die Links,
Markus

> Du könntest "meine" Grenzpolygone in eine PostGIS-Datenbank
> laden und mit dem PostGIS-Addon Topology entsprechende Manipulationen
> machen.
> 
> PostGIS-Topology "arbeitet" mit Knoten (Nodes), Kanten (Edges) und
> Flächen (Areas) - genau was du dafür brauchst.
> 
> http://postgis.net/docs/Topology.html
> 
> http://blog.mathieu-leplatre.info/use-postgis-topologies-to-clean-up-road-networks.html
> 
> https://strk.kbt.io/blog/2011/11/21/topology-cleaning-with-postgis/
> 
> http://www.postgis.us/


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

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: [Talk-it] Giunto condotta forzata

[demon.box]

...a titolo informativo, visto che ho cercato ma non ho trovato nulla
momentaneamente per non disperdere l'informazione, ho fatto un nodo sulla
way usage=penstock così composto:

penstock=coupling
ref=xx

grazie, ciao

--enrico




--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[Talk-ca] Mapping Highway 7

[Yaro Shkvorets]

Hi All,

Our Ottawa chapter is having a little mapathon tonight  - we'll be mapping
things along Highway 7 AKA "The Lost Highway" (http://thelosthighway.ca).

Feel free to join us at 6 at Vimy Brewing:
https://www.meetup.com/openstreetmap-ottawa/events/254420322
We'll also talk about Waylens camera lending program and have some beers.

Or just contribute from home any time if you are interested. Here's the
project page: http://tasks.osmcanada.ca/project/135


-- 
Best Regards,
  Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

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

[Talk-GB] Nottingham Meeting tonight 19:30

[SK53]

Detals :https://wiki.openstreetmap.org/wiki/Nottingham/Pub_Meetup

Jerry
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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: [Talk-GB] 'historic' county boundaries added to the database

[Adam Snape]

Hi,

I think this needs discussing on its own merits, because the argument being
made here is different to the usual argument for adding historical
features. The OP and others have made clear that the motivation lies not in
recording now-disappeared historical features, but in mapping traditional
geographic boundaries that retain some cultural (and in some cases such as
the Royal Duchies - administrative and ceremonial) importance.

Kind regards,

Adam
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

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 

Re: [Talk-de] Relation für Gebäude

[Benedikt Bastin]

Hallo Roland

>Von daher wäre ich sehr interessiert zu wissen, um welches Gebäude es 
>sich handelt und warum nicht schon "alles mit Tag 'level' in der 
>Bounding Box/im Polygon" reicht (was in allen anderen bekannten Fällen 
>funktioniert).

Das Gebäude, um das es gerade konkret geht, ist das Informatikzentrum der 
Universität Bonn (https://www.openstreetmap.org/relation/7289002). In diesem 
Fall sind die Probleme tatsächlich noch nicht aufgetreten, bevor ich aber die 
Knoteniteration und das alles implementiere, wollte ich lieber erstmal 
nachfragen, ob es nicht doch eine schönere Relationslösung gibt. 

>Eines der Probleme ist z.B., dass die wichtigsten Strukturen
>überwiegend 
>ÖPNV-Anlagen sind; diese bestehen nahezu immer aus überirdischen, 
>unterirdischen und ebenerdigen Anteilen. Es gibt eigentlich nie
>Konsens, 
>was davon noch zum "Gebäude" gehört und nicht einmal wie viele Gebäude 
>es sind - weder unter den OSM-Mappern, noch außerhalb von OSM auf Basis
>
>der Definition von Gebäude (gebautes Ding mit Dach); weder Steit darum 
>noch zahlreiche Relationen pro Struktur sind da hilfreich.

Das Problem verstehe ich, aber trotzdem denke ich, dass eine Relation in vielen 
Fällen hilfreich wäre. Ich hab natürlich nicht den jahrelangen Background, da 
viel zu sagen, wenn ihr sagt, dass das definitiv nicht sinnvoll ist, werde ich 
mich danach richten.

Den Streit um die Zugehörigkeit kann ich in diesem Fall aber ja umgehen, das 
Gebäude ist hier schließlich klar abgesteckt. Die Relation müsste anfangs gar 
nicht unbedingt jeden Fall abdecken; als Notlösung könnte ich ja auch für mein 
Anwendungsgebiet eine eigene Relation definieren, die ich erstmal nur auf 
diesem Gebäude anwende.

Gibt es abseits des Zugehörigkeitsproblems noch weitere Sachen, die gegen eine 
solche Relation sprechen?

Viele Grüße,

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

Re: [Talk-GB] 'historic' county boundaries added to the database

[Colin Smale]

On 2018-09-18 15:47, Dave F wrote:

> As Frederick & others point out - It will open the floodgates for other 
> irrelevant data to be added.

Relevance is not at issue here - that is far too subjective. The point
is that the "OSM Community" is making a decision that this data is not
within the intended scope of OSM and is therefore nominated for
deletion. 

All we need now is a volunteer to: 

a) document the determination such that it can be used as jurisprudence
in similar cases in the future 

b) communicate this to the user in question 

c) perform the deletion 

As this is purely about data, it should probably be the DWG?___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-hr] nominatim status?

[hbogner]

On 12.09.2018 23:49, Matija Nalis wrote:

jel i drugima trazilica na www.openstreetmap.hr javlja zadnjih dana
dosta cesto:
"Error contacting nominatim.openstreetmap.org: 429" ?



Nakon što si javio, pokušao sam random nekoliko puta kroz nekoliko dana 
i nisam nijednom dobio error.



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

Re: [Talk-de] Relation für Gebäude

[Roland Olbricht]

Hallo zusammen,


Ich arbeite gerade an Indoor-Karten und bin jetzt am Problem dran, ein gesamtes 
Gebäude herunterzuladen. Das Gebäude besteht aus einem Multipolygon für den 
Umriss und natürlich den diversen Räumen und POIs im Inneren. Das über eine 
Flächenabfrage mit Overpass oder über die einzelnen Knoten abzufragen ist, 
gelinde gesagt, hässlich und sehr fehleranfällig (beispielsweise U-Bahnen, 
Stromleitungen, Zäune an der Hauswand, etc.).

Nun wäre eine Relation, die das gesamte Gebäude einschließt, eine super Sache, 
um das gesamte Gebäude strukturiert herunterladen und verarbeiten zu können. Es 
gab bereits Proposals dazu, die Relationen definiert haben, die dafür sehr gut 
geeignet wären (beispielsweise 
https://wiki.openstreetmap.org/wiki/Proposed_features/indoor), aber die sind 
leider alle inaktiv.


Wir machen (in Absprache mit Roland Wagner von der Beuth-Hochschule, der 
SNCF und Simon Poole, der Simple-Indoor entworfen hat) seit einigen 
Jahren Indoor-Navigation. Die Vorschläge für Relationen sind aus gutem 
Grund immer wieder aufgegeben worden.


Eines der Probleme ist z.B., dass die wichtigsten Strukturen überwiegend 
ÖPNV-Anlagen sind; diese bestehen nahezu immer aus überirdischen, 
unterirdischen und ebenerdigen Anteilen. Es gibt eigentlich nie Konsens, 
was davon noch zum "Gebäude" gehört und nicht einmal wie viele Gebäude 
es sind - weder unter den OSM-Mappern, noch außerhalb von OSM auf Basis 
der Definition von Gebäude (gebautes Ding mit Dach); weder Steit darum 
noch zahlreiche Relationen pro Struktur sind da hilfreich.


Von daher wäre ich sehr interessiert zu wissen, um welches Gebäude es 
sich handelt und warum nicht schon "alles mit Tag 'level' in der 
Bounding Box/im Polygon" reicht (was in allen anderen bekannten Fällen 
funktioniert).


Viele Grüße,

Roland (in diesem Fall dienstlich)

--
Dr. Roland Olbricht

MENTZ GmbH, Am Mittelhafen 10, 48155 Münster
T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300
E: olbri...@mentz.net, www.mentz.net

Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München
Geschäftsführer: Christoph Mentz, Amtsgericht München, HRB 91898

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

[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

[Talk-de] OSGeo Park auf der INTERGEO 2018 in Frankfurt vom 16 -18.10.2018

[Astrid Emde (FOSSGIS e.V.)]

Vom 16.-18. Oktober 2018 findet in diesem Jahr die INTERGEO 2018 in 
Frankfurt statt.



OSGeo Park
--
Der OSGeo Park ist in diesem Jahr wieder mit dabei, organisiert vom 
FOSSGIS e.V. und Engagierten der OpenStreetMap Community.


Auf dem OSGeo Park können Besucher sich während der drei 
Veranstaltungstage über zahlreiche Lösungen im Bereich Open Source GIS, 
freie Geodaten, GIS Technologie und OpenStreetMap informieren.


Neben einem OSGeo & OSM Informationsstand gibt es ein tagesfüllendes 
Vortragsprogramm. In Kurzvorträgen bekommen die Besucher einen 
schnellen, aber weitreichenden Einblick in die Welt der 
Open-Source-Software aus dem GIS Bereich und den damit verbundenen 
Möglichkeiten (zum Programm http://www.fossgis.de/wiki/Intergeo_2018).


Darüber hinaus gibt es einen Bereich mit Rechnern, diese sind mit der 
aktuellen OSGeoLive Version 12.0 bestückt und enthalten über 50 
verschiedene Softwareprojekte, Demodaten und Dokumentationen. Hier kann 
alles direkt ausprobiert werden. Bei Fragen helfen die Vertreter des 
FOSSGIS e.V. & der OSM Community gerne weiter.



Druckstation
---
(derzeit noch in Planung)

Es steht höchstwahrscheinlich wieder ein A0 Drucker bereit, so dass Sie 
gerne Ihren bevorzugten OpenStreetMap Kartenausschnitt im Großformat mit 
nach Hause nehmen können.



Vortragsprogramm
---
Das Vortragsprogramm entsteht in den nächsten zwei Wochen. Vorträge für 
die Programmgestaltung sind willkommen. Wer einen Vortrag rund um Open 
Source, OSGeo & OSM halten möchte, kann diesen gerne im Wiki eintragen 
unter https://www.fossgis.de/w/index.php?title=Intergeo_2018.



Mitmachen
-
Wer sich gerne im Rahmen des OSGeo Parks engagieren möchte, ist herzlich 
eingeladen einen Teil beizutragen. Tragt euch gerne bis zum 10.10.2018 
auf der Wiki-Seite ein.



Aufbau
---
Der Aufbau erfolgt am Montag 15.10.2018 Nachmittag. Genaue Zeit wird 
noch bekannt gegeben.
Direkt nach dem Aufbau treffen wir uns zum Stammtisch (Ort wird noch 
bekannt gegeben).


Wir freuen uns auf eine spannende INTERGEO 2018!

--
Astrid Emde
OSGeo Board Member
Open Source Geospatial Foundation
https://www.osgeo.org/member/astrid-emde/

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

Wochennotiz Nr. 425 04.09.2018–10.09.2018

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 425 mit vielen wichtigen Neuigkeiten aus der 
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2018/09/wochennotiz-nr-425/

Viel Spaß beim Lesen!
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Wochennotiz Nr. 425 04.09.2018–10.09.2018

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 425 mit vielen wichtigen Neuigkeiten aus der 
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2018/09/wochennotiz-nr-425/

Viel Spaß beim Lesen!
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

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: [Talk-GB] 'historic' county boundaries added to the database

[Dave F]

Hi all.

There's appears to be a misguided belief this hasn't been discussed 
previously. It has, numerous times, and the consensus of those who took 
part was so clear it's now included in the first page every new users sees.


I feel there is nothing to discuss/vote on as it all been said & done 
before. Transference to OHM is the only option.


As Frederick & others point out - It will open the floodgates for other 
irrelevant data to be added.


Cheers
DaveF


On 18/09/2018 09:53, Adam Snape wrote:

His,

I think I said earlier in the thread but I've never viewed OSM as a 
strict majority rule, more a do-ocracy or rule by consensus. 
Certainly, I think anybody proposing the deletion of others' mapping 
ought to be sure of clear community consensus, not just a mere 
majority opinion. Future mappers should not be bound by the views of 
7/12 mappers participating in a Loomio vote in 2018.


Kind regards,

Adam


On Tue, 18 Sep 2018, 09:11 Dan S, > wrote:


Though I've no particular expertise to add, this thread has tipped me
in favour of being happy with these boundaries. Colin very rightly
emphasised process - how do we come to some decision rather than
simply expressing our views and then sitting back waiting for it to
erupt again in 18 months? I'm not a big one for voting eg on tagging
but this seems to be a great case for a Loomio vote or a wiki vote, as
has already been suggested. Can someone perhaps set one up? Maybe a
Loomio vote, and we'd probably want to paste its outcome into the wiki
after to make sure it wasn't lost?

Dan

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



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


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

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

[Talk-it] Tasking Manager per le strade dell'Abruzzo

[Alessandro Palmas]

ciao lista,

ho appena letto con piacere che Samuele si sta dedicando a una 
traduzione sul wiki: evviva!


Lasciatemi però lanciare un grido di dolore sulle povere strade d'Abruzzo.
Esiste il task http://osmit-tm.wmflabs.org/project/8 dal 2016 e siamo 
ancora al 24% Negli ultimi due mesi c'è stata un pò di attività e le 
strade della regione sono balzate da 31.600 a 32.600 km 
http://osm-estratti.wmflabs.org/estratti/Abruzzo/stats


Dai, completiamo quel task così potremmo poi dedicarci al Molise 
dimostrando al mondo intero che esiste :-) :-)


Alessandro Ale_Zena_IT

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

[Talk-de] Relation für Gebäude

[Benedikt Bastin]

Hallo zusammen!

Ich arbeite gerade an Indoor-Karten und bin jetzt am Problem dran, ein gesamtes 
Gebäude herunterzuladen. Das Gebäude besteht aus einem Multipolygon für den 
Umriss und natürlich den diversen Räumen und POIs im Inneren. Das über eine 
Flächenabfrage mit Overpass oder über die einzelnen Knoten abzufragen ist, 
gelinde gesagt, hässlich und sehr fehleranfällig (beispielsweise U-Bahnen, 
Stromleitungen, Zäune an der Hauswand, etc.).

Nun wäre eine Relation, die das gesamte Gebäude einschließt, eine super Sache, 
um das gesamte Gebäude strukturiert herunterladen und verarbeiten zu können. Es 
gab bereits Proposals dazu, die Relationen definiert haben, die dafür sehr gut 
geeignet wären (beispielsweise 
https://wiki.openstreetmap.org/wiki/Proposed_features/indoor), aber die sind 
leider alle inaktiv.

Ich könnte mir selbst ein Relationsformat definieren, wollte aber erst 
nachfragen, ob es

1. nicht doch schon ein solches Format gibt, das einigermaßen verbreitet und 
akzeptiert ist, oder ob es
2. Anmerkungen und Wünsche für ein solches Format gibt.

Viele Grüße,

Benedikt (profgreenington)
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[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

[OSM-ja] 10/14 京都！街歩き！マッピングパーティ：第1回 海住山寺

[yasunari yamashita]

東京から京都に異動になった山下です。
皆さん、こんにちわ

京都復帰第一回目は車でしか行けない（？）海住山寺。
京都の五重塔もコンプリートを目指しますよ！

京都！街歩き！マッピングパーティ：第1回 海住山寺
https://openstreetmap-kyoto.connpass.com/event/100652/

車で行く都合上、定員少な目
皆さんの参加をお待ちしています！！
-- 
山下康成＠東京都新宿区→京都府向日市
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-it] aggiornamento emergency=access_point

[demon.box]

liste_girarsi wrote
> Fai seleziona tutto, tenendo premuto il tasto control (ctrl), 
> deselezioni i due o tre che non ti interessano, a questo punto 
> metti/correggi un tag unico per tutti nell'apposita finestra, poi 
> carichi mettendo nel changeset il commento e nel source, se non ricordo 
> male, overpass.api.

Grazie Simone, ma non posso seguire questa modalità perchè ora l'ultima
richiesta è di riassegnare anche tutti i codici. In sostanza devo anteporre
LUME a tutti i codici che però saranno riorganizzati secondo una tabella di
conversione che mi verrà fornita.

In pratica:

in entrata0101
in uscita  LUME045

in entrata0102
in uscita  LUME046

e così via...

ecco perchè la mia intenzione era quella di esportarli tutti, modificarli e
poi ricaricarli ma come spiegato prima mi vengono duplicati...
non sò se mi sono spiegato ;-)

--enrico





--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

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: [Talk-it] aggiornamento emergency=access_point

[liste DOT girarsi AT posteo DOT eu]

Il 18/09/2018 12:43, demon.box ha scritto:

P.S.: se dopo la query overpass faccio invece "carica dati in un editor OSM:
JOSM, Level0" allora funziona perfettamente ma in questo caso devo cliccare
uno per uno i nodi e modificarli all'interno di Josm mentre io volevo
modificarli in un file prima di importarli in Josm



Fai seleziona tutto, tenendo premuto il tasto control (ctrl), 
deselezioni i due o tre che non ti interessano, a questo punto 
metti/correggi un tag unico per tutti nell'apposita finestra, poi 
carichi mettendo nel changeset il commento e nel source, se non ricordo 
male, overpass.api.



--
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|
Simone Girardelli

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

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: [Talk-it] aggiornamento emergency=access_point

[demon.box]

liste_girarsi wrote
> Ok, se hai fatto, meglio così.

ciao Simone, in realtà riprendo questo discorso perchè ho fatto qualche
prova in più e c'è qualcosa che non quadra...

ecco i miei passaggi:

1) query overpass

node
  ["emergency"="access_point"][operator="Volontari Croce Bianca
Lumezzane"][ref]
  ({{bbox}});
out;

2) clicco su Esporta / download as GeoJSON

e ottengo il mio file export.geojson

che (estraendo soltanto 2 codici come test) è così composto:

{
  "type": "FeatureCollection",
  "generator": "overpass-ide",
  "copyright": "The data included in this document is from
www.openstreetmap.org. The data is made available under ODbL.",
  "timestamp": "2018-09-17T21:41:03Z",
  "features": [
{
  "type": "Feature",
  "properties": {
"@id": "node/5203264454",
"emergency": "access_point",
"emergency_telephone_code": "112",
"operator": "Volontari Croce Bianca Lumezzane",
"ref": "1805"
  },
  "geometry": {
"type": "Point",
"coordinates": [
  10.2833138,
  45.6196039
]
  },
  "id": "node/5203264454"
},
{
  "type": "Feature",
  "properties": {
"@id": "node/5200461914",
"emergency": "access_point",
"emergency_telephone_code": "112",
"operator": "Volontari Croce Bianca Lumezzane",
"ref": "1806"
  },
  "geometry": {
"type": "Point",
"coordinates": [
  10.2850445,
  45.6204301
]
  },
  "id": "node/5200461914"
}
  ]
}

3) faccio le mie modifiche ai codici e poi in Josm faccio apri questo file
export.geojson
ma qui iniziano i problemi perchè per ogni nodo mi aggiunge un tag 

@id=node/5203264454

che ovviamente è errato e non ci dovrebbe essere, inoltre anche elimino
manualmente questo tag sballato quando poi in Josm faccio carica dati
succede quello che temevo, cioè i 2 nodi da me modificati con il nuovo
codice vengono caricati come 2 nuovi nodi nello stessa posizione di quelli
originari e quindi non và per niente bene, cosa sbaglio?

P.S.: se dopo la query overpass faccio invece "carica dati in un editor OSM:
JOSM, Level0" allora funziona perfettamente ma in questo caso devo cliccare
uno per uno i nodi e modificarli all'interno di Josm mentre io volevo
modificarli in un file prima di importarli in Josm

Grazie

--enrico





--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

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