date:20170726

Pour moi ça s'apparente directement à un fastfood (techniquement parlant en
tant qu'établissement, car cela ne porte pas sur la spécialité
gastronomique ou la culture culinaire), avec la vente à emporter et qui
peut aussi ne pas avoir du tout de table à l'intérieur mais en terrasse.
En qoi c'est différent d'une boutique de rue servant des plats à emporter
(des pizzas, des sandwiches)? Ouvrir les huîtres pour pouvoir les déguster
c'est déjà du travail culinaire. Et des tas de services de restauration
peuvent ne pas avoir du tout de tables et chaises à eux.
Comparer aussi aux tables des kermesses et fêtes communales: l'espace, les
tables et les chaines est mis à disposition de l'organisateur de
l'événement, tout le monde peut s'y assoir même sans consommer. Il y a des
vendeurs ambulants, les gens vont se servir debout et ramènent leur plat et
vont s'asseoir où il y a de la place. Et ce n'est pas nécessairement le
"restaurateur" qui s'occupe lui-même de la surveillance, de la sécurité et
du nettoyage des lieux.

Comparer ensuite aux aires de pique-nique: c'est un exploitant qui vient
contrôler régulièrement la propreté et vider les poubelles. Voir aussi près
des plages avec les boutiques ambulantes (mais sur emplacement fixe
prédéfini où on est sur de les trouver) ou fixes à ouverture saisonnière :
l'emplacement est loué par eux mais ils n'ont pas la charge des équipements
autour et rien n'oblige les gens à consommer sur place. Idem dans les parcs
d'attractions, les foires-expos, les festivals... Pourtant il peut y avoir
aussi un service "à la place" avec des serveurs qui viennent prendre les
commandes et les apporter et aussi débarrasser et nettoyer l'espace qu'il a
le droit d'occuper (mais sans que ce soit réservé spécialement à cet usage)
et même devrait participer avec l'exploitant au nettoyage de lors de sa
fermeture, ou bien il paye seulement la location de l'emplacement et c'est
l'exploitant ou la commune qui se charge du reste (le reste du temps c'est
un règlement publique de propreté qui s'applique à tout le monde, la
commune n'ayant pas vocation à prendre en charge le nettoyage en
permanance, c'est un service de police qui verbalisera les contrevenants
qui laissent les endroits pollués).

On a divers degrés donc de ce qu'on peut appeler "restaurant" et sur la
façon de préparer les aliments ou de les servir. Le cas limite étant la
boutique de produits culinaires et le supermarché (mais pas toujours près à
consommer tout de suite, c'est la différence essentielle): si un
supermarché a un rayon de sandwiches à emporter, ou si un café a un
distributeur de sandwich, est-ce un "restaurant", un "fastfood"? Y-a-il
obligation qu'il y ait quelqu'un pour servir (si oui la boulangerie reste
bien aussi un restaurant, d'autant qu'on y trouve facilement une table et
quelques chaises et même des boissons fraiches avec ou sans verre, ou un
expresso servi dans une tasse)



Le 26 juillet 2017 à 18:55, Nicolas Toublanc  a écrit
:

> Bonjour,
>
> J'ai enfin pris le temps de rentrer dans l'un de ces bars à huître, et
> j'ai du nouveau.
>
> En effet, ils n'ont pas le statut de restaurant, donc ce qu'ils font,
> c'est:
>
>- ouvrir les huîtres, ou préparer des plateaux de fruits de mer
>- mettre à disposition une terrasse ou une salle pour manger, mais
>chacun peut amener ses boissons, son pain et son beurre, etc...
>
> Et ceux chez qui je suis allé proposent aussi un mode dégustation pour les
> huîtres, avec pain/beurre, sauce et un verre de muscadet.
>
> Donc au final, je pense qu'il ne faut pas leur mettre le tag restaurant,
> car ça porterait à confusion (on n'y trouve pas ce qu'on s'attend à trouver
> dans un restaurant, même si on peut au final manger sur place).
>
> Le fait de préparer des plateaux de fruits de mer ressemble davantage à ce
> que ferait un traiteur, et il est possible de déguster ou de pique-niquer
> sur place (mais le site de picnic est réservé au clients).
>
> Mais ce n'est ni un restaurant, ni un fast-food.
>
> Avez-vous de nouvelles idées sur comment se dépatouiller avec tout ça?
>
>
>
> 2017-07-10 10:41 GMT+02:00 Nicolas Toublanc :
>
>>
>>
>> 2017-07-09 15:03 GMT+02:00 Francescu GAROBY :
>>
>>> Attention, c'est "seafood", et non "seefood"...
>>>
>>>
>> Héhé, oui merci de la correction!
>>
>> > Est-il possible de multiplier les tags /*cuisine*/ et /*produce*/ afin
>>> > d'avoir les 2 informations?
>>> oui tu peux
>>> cuisine=oysters;seefood
>>> produce=oysters;seefood
>>> mais l'un incluant l'autre, à ta place je choisirais l'un des 2 selon ce
>>> qui est le plus important
>>>
>>>
>> Le plus important dans ce contexte, c'est bien oysters. Mais du coup, il
>> n'inclue pas seafood, donc indiquer les 2 me parait le plus adapté.
>>
>> Merci à tous les 3 d'avoir pris le temps de répondre à mes questions!
>>
>>
>>
>>> Francescu
>>>
>>> Le 9 juillet 2017 à 12:30, marc marc  a
>>> écrit :
>>>
 > il

Re: [Talk-GB] [Osmf-talk] Live OSM discussion in ~45 minutes (7.30pm UK time)

2017-07-26 Diskussionsfäden Frederik Ramm

Hi,

On 07/26/2017 07:45 PM, Andy Mabbett wrote:
> I've just learned that this week's Wikimedia Research Showcase,
> streamed online TONIGHT at 7.30pm UK time, will focus on structured
> data in OpenStreetMap. Details below.

Thank you for the link, apparently it can still be watched after:

> YouTube stream: https://www.youtube.com/watch?v=yC1jgK8C8aQ

I think the research bit was generally ok, albeit it didn't really
follow Muki Hakalay's "code of engagement" for scientists with OSM (
https://povesham.wordpress.com/2011/07/16/observing-from-afar-or-joining-the-action-osm-and-giscience-research/).

I took issue with a few items.

* The talk seemed to assume that the listener knows what "Dairy Queen"
or "Panera Bread" are ;)

* The talk seemed to try very hard to say OSM had "western standards" or
"UK cultural assumptions" but I felt that was very un-convincing on the
whole; it even showed two very differently built roads of the same
tagging in the US and Africa which to me seemed to prove the point that
things work ok - we don't demand that a road in Africa must be built to
the same standards as one in America to be a "primary" or whatever.

* The talk clearly had a HOT bias; towards the end there was even a
slide that tried to discuss "whose new ideas can influence the
standard", and it listed these four bullet points: "HOT", "Men",
"Hostile contributors", and "Code creators" (who, as discussed earlier,
had the power to limit the freedom of others).

* Sadly the talk included the usual drive-by accusations of sexism in
OSM. It said, and I am not making this up: "There has been some work by
Monica Stephens that has discussed how new tag proposals for feminized
or (inaudible) spaces are given less, quote, attention" (this is
referring to a very badly researched 2013 article that essentially
contrsated took low vote outcome on a childcare tagging proposal with
brothels and swinger cluby in OSM to brand OSM sexist), and then went on
"also, one of our interviewees mentioned that she had, quote, heard of
women not being listened to or respected". -- What he's doing here is
quoting an anonymous source that is quoting an anonymous source that
says something about OSM, and that is good enough to make a sexism claim.

The whole talk did, it seems to me, slightly overrate the importance of
tagging discussions (they claimed to have interviewed 15 people but it
is unclear how they selected those 15), and therefore the discussion
that ensued was mostly around the question "how can we make sure that
everyone has a say in tagging discussions".

There seemed to be an underlying assumption that binding votes on
tagging, or at least a well-defined process to standardize and maintain
the global tagging ontology, was necessary (and not least, all those
autocratic editor writes need to submit to the community vote and not
invoke privilege to create presets that others must then follow).

I wouldn't say this has given me any new insights or ideas for the
future, but it is an interesting study in how (relative) outsiders
approach OSM.

I think we as a project really need to publish a more through, and more
visible, takedown on that 2013 Monica Stephens article though. At the
time I thought "oh well, bad research comes and goes, no need to start a
fight every time a researcher writes something wrong about OSM", but
that one seems to be found, believed in, and quoted by other researchers
just too much.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk-fr] Valeur opening_hours supérieure à 255 caractères

L'autre solution c'est de mettre en valeur une URI vers un document externe
contenant la chaîne complète. Mais on sort de la base de données pour aller
n'importe où sur des données potentiellement non libres et jamais sous
contrôle direct de la communauté OSM qui ne saura jamais quand cette
ressource externe est modifiée sans aller la chercher explicitement (avec
le risque que quelqu'un aille y mettre des gigaoctets de données aléatoires
et planter un utilisateur de la base) ni qui l'a fait, et aussi le risque
de fermer l'accès aux modications (raison pour laquelle on admet
wikipedia= ou wikidata=Q et non pas des URLs libres en
valeur (qui ne sont admises que pour website sur un objet précis
directement associable à un domaine).

Si on met une URL il faudrait que ce soit vers un repository ouvert (type
GitHub, ou Subversion) où les participations de tiers sont admises et où
les décisions d'inclusions dans une branche ne dépendent d'un seul
utilisateur difficile à contacter.

Malheureusement OSM n'a pas un tel service pour ses propres besoins
permettant de stocker ce qui est difficilement représentable. Il faudrait
une extension au protocole de l'API OSM pour mettre des "supertags" pouvant
stocker des fichiers de taille arbitraire et si possible dans un format
ouvert facilement exploitable (CSV, XML, JSON, voire même une syntaxe wiki
à défaut du HTML qui peut poser des problèmes de sécurité, sinon un "plain
texte" pour une description libre ou des notes, ou un Hackpad pour
quelquechose un peu plus enrichi facilitant la lecture). Certains de ces
formats pourraient même être supportés par le moteur SQL sous-jascent pour
permettre des recherches. Les tags actuels ont leur limites mais il est peu
concevables d'en augmenter la longueur maximale.


Le 26 juillet 2017 à 15:29, marc marc  a écrit :

> Comme (sauf erreur) aucune solution n'existe pour l'instant pour décoder
> le report sur plusieurs tag, d'ici là, la chaîne ne serra utile qu'aux
> humains. à ta place je chercherais s'il n'existe pas des cas
> d'utilisation du genre opening_hours:website=https://lapage pour
> renseigner une version humainement digeste
>
>  > opening_hours=Sep-JunMo<...>;@2
>  > opening_hours:2=Jul-Aug<...>
> ca aurait le mérite de rendre la moitié des infos utilisable par les
> outils existants. donc y mettre la période la plus importante pour
> l'utilisateur et demander sur le wiki pour standardiser la 2ieme partie.
> ___
> 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] source sur l'objet <> sur le changeset

Le 26. 07. 17 à 20:38, Pierre-Yves Berrard a écrit :
>   * La poubelle : survey + photo aérienne.

si tu as vu la poubelle, survey est suffisant non ?
je ne pense pense pas que la photo aérienne ai apporté qlq chose dans le 
positionnement de celle-ci à côté de l'abribus, sauf si tu as un sat 
avec une résolution du cm/pixel ou presque.

> Les tags du changeset, selon ton schéma :
>   * source:geometry:platform=bing
>   * source::geometry:building=cadastre
>   * source:position:waste_basket=survey;bing

oui, 3 tag sur le changeset aurait selon moi suffit :
source=survey
source:geometry:platform=bing
source:geometry:building=cadastre
c'est mieux qu'environ 50 non ?

> Et pour ma question annexe ?

Comment extrais-tu la source de mon exemple tel qu'existait avant 
correction ?
A ma connaissance, tu n'as pas moyen (je rappelle que le tag est 
désyncro vu que les outils courant ne gèrent pas leur synchronisation)
Donc mettre 50 tag au lieu de 3  ne résout pas ta demande.
Aujourd'hui tu n'as aucun moyen d'extraire l'info que tu veux
sans oublier que l'intervention humaine est en elle-même est aussi une 
source (sauf si tu mets aussi source:mapper=toi sur les objets que tu 
touches).
Si tu voulais le faire, il faudrait rendre obligatoire l'ajout d'un tag 
source pour chaque caractéristique ajouté/modifiée.
Je pense pas que osm y gagnerait si c'était obligatoire.

> PS : à y réfléchir, on pourrait aller plus loin. Mettons un changeset 
> avec seulement des hydrants, je mets le tag emergency=hydrant sur le 
> changeset et je laisse juste les points sans attributs. Ça économise de 
> la place.

Le principal gain à mes yeux n'est pas la place (même si c'est toujours 
bon à prendre).
Le principal est d'éviter les infos dupliquée qui prennent du temps à 
encoder, qui se désynchronise mais qui n'apporte pas d'info supplémentaire.

Cordialement,
Marc

> Le 26 juillet 2017 à 20:14, marc marc a écrit :
> 
> Je ne comprend pas en quoi ta situation est différente de la mienne.
> exemple j'ai été voir un arrêt de bus hier.
> J'ai vu l'arrêt de bus, l'abribus, le banc, la poubelle, la rue, etc
> donc sur le changeset source=survey
> pour dessiner l'abribus et la route du parking, j'ai utilisé le sat
> donc sur le changeset source:geometry=mapbox
> 
> Si je devais décrire ces mêmes sources sur les objets,
> il me faudrait 48 tag source au lieu de 2 !
> 
> Ironie de la situation, la raison de ma visite sur place était un objet
> avec un beau source tag sur l'objet, ignoré par le contributeur suivant.
> Heureusement il a utilisé Id qui a ajouté (automatiquement il me semble)
> la source=Bing malgré que le contributeur n'ai renseigné.
> 
> Je n'ose pas imaginer lorsque je fais une petite rue et que j'ai au
> final 200 objets créés/modifiés et donc un millier de tag donc aurait
> besoin de 2000 tag source, indigeste !
> 
> Le 26. 07. 17 à 18:59, Pierre-Yves Berrard a écrit :
> 
>  > En ce qui me concerne, séparer les changeset selon la source est
> impossible.
>  > Je travaille le plus souvent sur une zone donnée, en essayant de
>  > positionner les objets les uns par rapport aux autres, donc en
>  > m'appuyant pour ce faire sur toutes les sources disponibles.
>  >
>  > Question annexe (mais importante) : avec la source uniquement sur le
>  > changeset, comment retrouver (facilement) la source pour qui
> exporterait
>  > les données ?
>  >
>  > PY
>  >
>  > Le 26 juillet 2017 à 18:30, marc marc a écrit :
>  >
>  > Le 26. 07. 17 à 17:51, Jean-Claude Repetto a écrit :
>  >  > une source pour la position et une autre source pour le nom
>  > oui source:geometry et source:name ont du sens.
>  > mais on peux mettre ce niveau de détail dans le changeset non ?
>  > tu as un exemple d'un changeset que tu as fait qui aurait un
> tag précis
>  > ayant une valeur différente selon l'objet sans que cela
> justifie de se
>  > faciliter la vie avec 2 changeset ?
>  >
>  > ce qui n'a pas de sens c'est source=machin sur l'objet
> puisque la seule
>  > façon de savoir ce que cela concerne c'est de retrouver le
> changeset
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SPAM Re: Modification du nom de plusieurs communes

Le 26 juillet 2017 à 16:46, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> Le 2017 Goue. 26 à 02:50, Philippe Verdy  a écrit :
>
> Sauf que les communes ne sont PAS des langues ISO 639 (ici on utilise des
> codes BCP 47, jamais les ISO 639 qui ne sont pas non plus stables...) et
> encore moins des entités ISO 3166 (pays et subdivisions de premier niveau
> ou de second niveau pour certains pays copmme la France, eux même souvent
> pas à jouor avec les entités officielles). Ce sont des nom officiels.
>
> Et là on ne parle pas des tags "name:=*", mais juste
> des tags "name=*" qui sont les noms par défaut, dans leur graphie non
> abrégée, sans capitalisation de toutes les lettres comme sur les adresses
> postales et avec tous leurs caractères signifiants, y compris apostrophes
> et autres ponctuations même si pour le courrier postal on les remplace par
> des espaces et on élimine bon nombre de signes diacritiques...)
>
> Le 26 juillet 2017 à 01:08, Christian Rogel  internet.fr> a écrit :
>
>> Qu’il soit clair, une fois pour toute, que personne ne propose de
>> « cacher » la version officielle des toponymes. Ce qui est dans les
>> « name:ISO639 » ne concerne en rien les rendus par défaut des « name ».
>> Les « name:ISO639 » doivent uniquement être attestés ou cohérents, sans
>> aucune limite territoriale. C’est la beauté esthétique de la situation de
>> langue non reconnue, personne ne peut s’y opposer, précisément, parce
>> qu’elle est hors la loi.
>>
>> Un texte de référence sur ce sujet : http://www.openstreetmap.bzh
>> /fr/2017/06/27/brezhoneg-e-maez-al-lezenn-neus-harzh-ebet-
>> evit-brezhonekan-ar-gartenn-openstreetmap/ (au besoin, choisir la
>> version en français dans la col. de gauche)
>>
>
>
> Le wiki OSM  n’est
> pas contradictoire avec ce que j’ai dit : tout dépend du zoom. Si le BCP 47
> est l’enveloppe générale, il est bien noté que les codes linguistiques sont
> tirés, en premier lieu des codes ISO 639 (2 et 3) et ce n’est que pour des
> langues peu connues ou peu écrites que l’on fait appel à d’autres codes.
> L’instabilité du code ISO 639 est uniquement référée aux translittérations.
>
> Dans l’espace européen, les principales langues écrites avec littérature
> sont notées sur OSM par le code ISO 639-2, le 639-3  concernant des
> dialectes littéraire.
>
> Ce ne sont pas des dialectes littéraires mais des langues (dont la plupart
ne sont même pas écrites avec une orthographe formalisée et bon nombre sont
des langues vivantes); quant à ISO 639-2 certains codes ne sont même pas
des langues alors que c'était affirmé comme tel, par exemple le quéchua ou
le bihari qui est une famille de langue, et le chinois qui peut être une
langue uniquement dans une de ses formes écrites standardisée en Chine,
mais pas du tout à l'oral et pas vraiment dans les autres pays ou
territoires où on parle et écrit le chinois).

Oui ISO 639 est un vrac fourre-tout où chacun semble en faire ce qu'il veut
sans vouloir se concerter avec ses voisins et de changer d'avis 2 ans
après; donc ISO 639 est inutilisable pour nos besoins : on n'est pas en
train de classer des livres dans des collections de bibliothèques ou de
créer un des nombreux catalogues d'ouvrages qu'il est presque impossible de
rapprocher correctement entre eux, un classement qui est ensuite revu
quelques années après et toujours aussi illogique et intrinsèquement
désorganisé.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Live OSM discussion in ~45 minutes (7.30pm UK time)

2017-07-26 Diskussionsfäden Dave F


What the !*&@

Just tuned in & they're talking about hostility & sexism?!

Anybody know the usernsme of AndyHall? (The blonde guy in the broadcast)

DaveF


Who are these people?

On 26/07/2017 18:45, Andy Mabbett wrote:

I've just learned that this week's Wikimedia Research Showcase,
streamed online TONIGHT at 7.30pm UK time, will focus on structured
data in OpenStreetMap. Details below.

-- Forwarded message --

The next Research Showcase will be live-streamed this Wednesday, July
26, 2017 at 11:30 AM (PST) 18:30 UTC.

YouTube stream: https://www.youtube.com/watch?v=yC1jgK8C8aQ

As usual, you can join the conversation on IRC at #wikimedia-research.
And, you can watch our past research showcases here:

https://www.mediawiki.org/wiki/Wikimedia_Research/Showcase#July_2017

This month's presentation:

Freedom versus Standardization: Structured Data Generation in a Peer
Production CommunityBy Andrew HallIn addition to encyclopedia articles
and software, peer production communities produce structured data,
e.g., Wikidata and OpenStreetMap’s metadata. Structured data from peer
production communities has become increasingly important due to its
use by computational applications, such as CartoCSS, MapBox, and
Wikipedia infoboxes. However, this structured data is usable by
applications only if it follows standards. We did an interview study
focused on OpenStreetMap’s knowledge production processes to
investigate how – and how successfully – this community creates and
applies its data standards. Our study revealed a fundamental tension
between the need to produce structured data in a standardized way and
OpenStreetMap’s tradition of contributor freedom. We extracted six
themes that manifested this tension and three overarching concepts,
correctness, community, and code, which help make sense of and
synthesize the themes. We also offer suggestions for improving
OpenStreetMap’s knowledge production processes, including new data
models, sociotechnical tools, and community practices.








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

Re: [OSM-talk-fr] Ce soir j'ai décidé de publier un livre...

2017-07-26 Diskussionsfäden Frédéric Rodrigo


Le 26/07/2017 à 09:47, Florian LAINEZ a écrit :

Salut Fred,
C'est un énorme boulot que tu as fait là. Quel dommage qu'il n'ai pas 
été publié à l'époque. Quelles en sont les raisons ? Tu as des plans 
pour l'updater et le publier ?
C'est à la même époque j'ai décider de me mettre à mon compte. Je me 
suis dit que ça me laisserait du temps libre pour terminer... ben non.
Je l'ai converti en markdown et publié sur github pour lui laisser une 
chance. Il a aussi servi de base aux formations que je donnais à 
l'époque sur le sujet dont le "sommaire" est là: 
https://wiki.openstreetmap.org/wiki/WikiProject_France/OSM-FR/Formations




Le 25 juillet 2017 à 00:04, Frédéric Rodrigo > a écrit :


Salut,

C'est l'ébauche d'un livre en français sur OpenStreetMap.

Ce contenu a été réalisé en 2010-2011. Ce livre n'est pas terminé,
il contient 11 chapitres (pas toujours complets) sur les 16
initialement prévus.

https://github.com/frodrigo/openstreetmap-livre



Il montre des cartes que l'on n'oserait même plus regarder, parle
d'OpenData comme d'un défit à relever, compare des licences qui
n'existent même plus, explore Potlatch ou encore l'XAPI.
Mais il parle aussi de choses qui non pas changées, de concepts,
d'approches, d'introduction, de fonctionnement et de l'histoire du
GPS, de comment organiser une carto-partie et plein de références
et de liens.

Ce contenu est placé sous licence Creative Commons Attribution /
Partage dans les mêmes conditions (CC-By-SA-4.0)
Frédéric Rodrigo - CC-By-SA-4.0 © 2010-2011

Frédéric.




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

Re: [OSM-talk-fr] SeFaireConnaitre

c'est bien le problème avec les adresses, il y a au moins 3 façon de 
faire documentée sur le wiki sans compter les variantes "perso"
- mettre que le no et laisser le système deviner la rue par proximité 
(bonjour les erreurs)
- mettre aussi la rue sur l'objet (info dupliqué mais le + portable)
- mettre des association street

Je pense qu'ilne faut pas procher le choix d'une méthode ou l'autre 
avant une hypothétique unanimité et modification de la page fr du wiki 
correspontande
tout au plus, on pourait sugérer qu'isl essaye de garder une cohérence 
avec le reste de la rue mais quid quand ils font des modifs dans une rue 
vierge ou quasi ? moi je laisserait tomber cette partie là,il y a + grave.

Idem pour le nom manquant sur la rue : cela aurait été sympa qu'il la 
rajoute en passant, on peux cependant quand même pas leur reprocher de 
ne pas avoir fait +, l'important est que ce qui est fait est bien fait.

Le 26. 07. 17 à 20:34, lenny.libre a écrit :
> Par contre dans les remarques qui leur sont faites, je ne vois pas 
> pourquoi on devrait supprimer le addr:street, c'est nouveau ?
> 
> Le commentaire : "Le positionnement géographique permet de savoir que le 
> "2" fait référence à la Place de la Nuit du 6 Août 1944".
> Un addr:street=Place de la Nuit du 6 Août 1944 serait donc inutile. Si 
> vous ne comprenez pas, allez sur place et regardez les numéros de rue : 
> y figurent juste un nombre, sans nom de rue. "
> 
> me parait un brin radical, car ce n'est pas toujours le cas, on met la 
> rue en tant que addr:street ou relation 
> :https://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses
> 
> Dans le cas que tu as cité, il faisait partie d'une relation (donc on 
> pouvait supprimer le addr:street) mais s'il n'y a pas de relation, il ne 
> faut pas le supprimer.
> 
> Maintenant SeFaireConnaitre supprime les addr:street même quand il n'y a 
> pas de relation 
> https://www.openstreetmap.org/node/507550316#map=19/44.63221/-1.14615
> 
> 
> En autre, s'ils mettent des contact:phone, contact:fax ils pourraient 
> mettre contact:housenumber, ... 
> https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Bremen_Schema
> 
> 
> cordialement
> 
> Leni
> 
> 
> 
> Le 24/07/2017 à 22:42, Romain MEHUT a écrit :
>> Ce n'est pas une question de motivation, c'est juste que via l'outil 
>> WhoDidIt j'ai défini un flux RSS pour les zones que je connais et je 
>> regarde donc les contributions qui les concernent. S'agissant des 
>> contributions de SeFaireConnaitre, mes corrections ne concernent que 
>> ces zones et donc c'est très loin d'être exhaustif. Dans le cas 
>> présent des Crédit Mutuel de Bretagne, il faudrait tous les passer en 
>> revue... pour retirer les tags en trop.
>>
>> Ils ont à nouveau commenté en nous remerciant des remarques faites et 
>> disent qu'ils mettront à jour les données.
>>
>> Romain
>>
>> Le 22 juillet 2017 à 11:58, marc marc > > a écrit :
>>
>> Tu es motivé Romain !
>> J'ai regaré au hazard quelques changet.. la qualité laisse en effet à
>> désirer.
>> Par contre je pense pas qu'un "je surveille" trimestre va les faire
>> s'améliorer même s'ils se sont déjà pris 3 blocages.
>> Le plus utile me semble être soit un copier/coller d'un message
>> explicatif (genre vos modifs sont en grande partie inutilisable voir
>> erroné) si possible par email à la direction, à défaut à l'email
>> générale + copie dans le chanset.
>> Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les
>> prévenir qu'ils payent pour un service ce mauvaise qualité
>> Si l'un d'eux demande des comptes à son prestataire, les choses
>> peuvent
>> s'améliorer
>> On peux aussi se "partager" l'envois de message. si plusieurs
>> personnes
>> écrivent, cela montre que ce n'est pas juste Romain qui chipote mais
>> qu'il y a un problème chez eux.
>> On peux aussi leur montrer cette conversation
>> Dernière solution : leur proposer une formation (payante) ou un
>> contrôle
>> qualité :-)
>>
>> mes 2 cents..
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] SPAM Re: Modification du nom de plusieurs communes

Le 26 juillet 2017 à 16:46, Christian Rogel <
christian.ro...@club-internet.fr> a écrit :

>
> Le 2017 Goue. 26 à 02:50, Philippe Verdy  a écrit :
>
> Sauf que les communes ne sont PAS des langues ISO 639 (ici on utilise des
> codes BCP 47, jamais les ISO 639 qui ne sont pas non plus stables...) et
> encore moins des entités ISO 3166 (pays et subdivisions de premier niveau
> ou de second niveau pour certains pays copmme la France, eux même souvent
> pas à jouor avec les entités officielles). Ce sont des nom officiels.
>
> Et là on ne parle pas des tags "name:=*", mais juste
> des tags "name=*" qui sont les noms par défaut, dans leur graphie non
> abrégée, sans capitalisation de toutes les lettres comme sur les adresses
> postales et avec tous leurs caractères signifiants, y compris apostrophes
> et autres ponctuations même si pour le courrier postal on les remplace par
> des espaces et on élimine bon nombre de signes diacritiques...)
>
> Le 26 juillet 2017 à 01:08, Christian Rogel  internet.fr> a écrit :
>
>> Qu’il soit clair, une fois pour toute, que personne ne propose de
>> « cacher » la version officielle des toponymes. Ce qui est dans les
>> « name:ISO639 » ne concerne en rien les rendus par défaut des « name ».
>> Les « name:ISO639 » doivent uniquement être attestés ou cohérents, sans
>> aucune limite territoriale. C’est la beauté esthétique de la situation de
>> langue non reconnue, personne ne peut s’y opposer, précisément, parce
>> qu’elle est hors la loi.
>>
>> Un texte de référence sur ce sujet : http://www.openstreetmap.bzh
>> /fr/2017/06/27/brezhoneg-e-maez-al-lezenn-neus-harzh-ebet-
>> evit-brezhonekan-ar-gartenn-openstreetmap/ (au besoin, choisir la
>> version en français dans la col. de gauche)
>>
>
>
> Le wiki OSM  n’est
> pas contradictoire avec ce que j’ai dit : tout dépend du zoom. Si le BCP 47
> est l’enveloppe générale, il est bien noté que les codes linguistiques sont
> tirés, en premier lieu des codes ISO 639 (2 et 3) et ce n’est que pour des
> langues peu connues ou peu écrites que l’on fait appel à d’autres codes.
> L’instabilité du code ISO 639 est uniquement référée aux translittérations.
>

Pas du tout, l'ISO 639 est instable dans ses listes de codes elles-mêmes,
mais aussi par sa sémantique ambiguë et le fait qu'il mélange tout. Il est
au delà de ça pas assez précis (oui il ne gère pas les distinctions
d'écritures, de conventions de translitérations... et tout un tas de code
ISO639 sont même INVALIDES interdits dans BCP47. Lit un peu les dernières
RFC du standard BCP 47 et tu verras les exclusions qui ont été faites et
pourquoi et comment les tags ISO639 sont **partiellement** importés dans le
registre IANA et pourquoi des changements dans ISO 639 ne sont pas pris en
compte (ces changements ne sont pas destinés à la localisation, mais juste
à la classification bibliographique qui veulent des systèmes simplifiés,
souvent trop simplifiés d'ailleurs, avec des catégories "fourre-tout" où
chaque bibliothèque peut faire un peu ce qu'il veut ou ne pas classer du
tout; toutes les bibliothèques n'utilisent pas ISO 639, certaines l'ont
même abandonné en faveur de BCP47 qui fournit des sémantiques plus précises
et adaptées à la localisation)

Enfin tous les codes BCP47 ne viennent pas non plus de ISO639, il y a des
codes spéciaux, et les codes hérités (mais dont la sémantique a été
clairement définie par des attributs ajoutés dans le registre IANA associé
qui fait référence, ce que l'ISO 639 omet complètement car il se contente
juste d'associer des noms de langues pas très précis ou ambigus à des
codes, et uniquement en anglais et français, mais même pas toujours les
noms usuels, certains noms étant même carrément faux mais jamais corrigés
et qui entrainent donc de la confusion)
ISO 639 aurait du être abandonné, mais s'il existe c'est juste parce que
quelques biliothèques le soutiennent encore, en fait plus pour leur propre
usage interne et avec d'anciens systèmes d'échange de références
bibliographiques)

La partie "technique" de ISO 639 n'a été développée partiellement que pour
ISO 639-2 mais pas du tout pour ISO 639-3 qui reste une norme
bibliographique et pas technique, complètement inadaptée à la localisation
et la traduction, alors que BCP47 convient parfaitement aux deux usages
bibliographiques et techniques et ne souffre pas d'autant de défauts et
d'aucun problème de stabilité et de compatibilité ascendante (des problèmes
récurrents sur pas mal de normes ISO qu'on ne peut pas stabiliser à moins
de ne pas se contenter de juste citer le numéro de norme ISO, mais toujours
la versionner avec une année en suffixe).

Historiquement on a eu des problèmes similaires entre ISO 10646 et Unicode.
Ils sont maintenant réglés pour l'essentiel à partir d'une version d'ISO
10646 où il a été décidé de synchroniser les deux standards et d'adopter
une politique commune de stabilité. Toutefois ISO

Re: [OSM-talk-fr] source sur l'objet <> sur le changeset

2017-07-26 Diskussionsfäden Pierre-Yves Berrard

Pour reprendre ton exemple :

   - L'arrêt de bus (un way) : photo aérienne.
   - Le bâtiment à côté : cadastre
   - La poubelle : survey + photo aérienne.
   - Une autre poubelle (pas sur photo aérienne) : survey


Les tags du changeset, selon ton schéma :

   - source:geometry:platform=bing
   - source::geometry:building=cadastre
   - source:position:waste_basket=survey;bing

Et pour ma question annexe ?

PS : à y réfléchir, on pourrait aller plus loin. Mettons un changeset avec
seulement des hydrants, je mets le tag emergency=hydrant sur le changeset
et je laisse juste les points sans attributs. Ça économise de la place.

Le 26 juillet 2017 à 20:14, marc marc  a écrit :

> Je ne comprend pas en quoi ta situation est différente de la mienne.
> exemple j'ai été voir un arrêt de bus hier.
> J'ai vu l'arrêt de bus, l'abribus, le banc, la poubelle, la rue, etc
> donc sur le changeset source=survey
> pour dessiner l'abribus et la route du parking, j'ai utilisé le sat
> donc sur le changeset source:geometry=mapbox
>
> Si je devais décrire ces mêmes sources sur les objets,
> il me faudrait 48 tag source au lieu de 2 !
>
> Ironie de la situation, la raison de ma visite sur place était un objet
> avec un beau source tag sur l'objet, ignoré par le contributeur suivant.
> Heureusement il a utilisé Id qui a ajouté (automatiquement il me semble)
> la source=Bing malgré que le contributeur n'ai renseigné.
>
> Je n'ose pas imaginer lorsque je fais une petite rue et que j'ai au
> final 200 objets créés/modifiés et donc un millier de tag donc aurait
> besoin de 2000 tag source, indigeste !
>
> Le 26. 07. 17 à 18:59, Pierre-Yves Berrard a écrit :
>
> > En ce qui me concerne, séparer les changeset selon la source est
> impossible.
> > Je travaille le plus souvent sur une zone donnée, en essayant de
> > positionner les objets les uns par rapport aux autres, donc en
> > m'appuyant pour ce faire sur toutes les sources disponibles.
> >
> > Question annexe (mais importante) : avec la source uniquement sur le
> > changeset, comment retrouver (facilement) la source pour qui exporterait
> > les données ?
> >
> > PY
> >
> > Le 26 juillet 2017 à 18:30, marc marc a écrit :
> >
> > Le 26. 07. 17 à 17:51, Jean-Claude Repetto a écrit :
> >  > une source pour la position et une autre source pour le nom
> > oui source:geometry et source:name ont du sens.
> > mais on peux mettre ce niveau de détail dans le changeset non ?
> > tu as un exemple d'un changeset que tu as fait qui aurait un tag
> précis
> > ayant une valeur différente selon l'objet sans que cela justifie de
> se
> > faciliter la vie avec 2 changeset ?
> >
> > ce qui n'a pas de sens c'est source=machin sur l'objet puisque la
> seule
> > façon de savoir ce que cela concerne c'est de retrouver le changeset
> > ___
> > 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] était Subject=Re: SeFaireConnaitre :|, devient SeFaireConnaitre :)

2017-07-26 Diskussionsfäden lenny.libre

Par contre dans les remarques qui leur sont faites, je ne vois pas
pourquoi on devrait supprimer le addr:street, c'est nouveau ?

Le commentaire : "Le positionnement géographique permet de savoir que le
"2" fait référence à la Place de la Nuit du 6 Août 1944".
Un addr:street=Place de la Nuit du 6 Août 1944 serait donc inutile. Si
vous ne comprenez pas, allez sur place et regardez les numéros de rue :
y figurent juste un nombre, sans nom de rue. "

me parait un brin radical, car ce n'est pas toujours le cas, on met la
rue en tant que addr:street ou relation
:https://wiki.openstreetmap.org/wiki/WikiProject_France/Tracer_des_b%C3%A2timents#Ajout_des_adresses

Dans le cas que tu as cité, il faisait partie d'une relation (donc on
pouvait supprimer le addr:street) mais s'il n'y a pas de relation, il ne
faut pas le supprimer.

Maintenant SeFaireConnaitre supprime les addr:street même quand il n'y a
pas de relation
https://www.openstreetmap.org/node/507550316#map=19/44.63221/-1.14615

En autre, s'ils mettent des contact:phone, contact:fax ils pourraient
mettre contact:housenumber, ...
https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Bremen_Schema

cordialement

Leni

Le 24/07/2017 à 22:42, Romain MEHUT a écrit :
Ce n'est pas une question de motivation, c'est juste que via l'outil
WhoDidIt j'ai défini un flux RSS pour les zones que je connais et je
regarde donc les contributions qui les concernent. S'agissant des
contributions de SeFaireConnaitre, mes corrections ne concernent que
ces zones et donc c'est très loin d'être exhaustif. Dans le cas
présent des Crédit Mutuel de Bretagne, il faudrait tous les passer en
revue... pour retirer les tags en trop.

Ils ont à nouveau commenté en nous remerciant des remarques faites et
disent qu'ils mettront à jour les données.

Romain

Le 22 juillet 2017 à 11:58, marc marc > a écrit :

Tu es motivé Romain !
J'ai regaré au hazard quelques changet.. la qualité laisse en effet à
désirer.
Par contre je pense pas qu'un "je surveille" trimestre va les faire
s'améliorer même s'ils se sont déjà pris 3 blocages.
Le plus utile me semble être soit un copier/coller d'un message
explicatif (genre vos modifs sont en grande partie inutilisable voir
erroné) si possible par email à la direction, à défaut à l'email
générale + copie dans le chanset.
Soit si cela ne suffit pas, là oü cela fait mal càd aux clients : les
prévenir qu'ils payent pour un service ce mauvaise qualité
Si l'un d'eux demande des comptes à son prestataire, les choses
peuvent
s'améliorer
On peux aussi se "partager" l'envois de message. si plusieurs
personnes
écrivent, cela montre que ce n'est pas juste Romain qui chipote mais
qu'il y a un problème chez eux.
On peux aussi leur montrer cette conversation
Dernière solution : leur proposer une formation (payante) ou un
contrôle
qualité :-)

mes 2 cents..

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

[OSM-talk-fr] source sur l'objet <> sur le changeset

Je ne comprend pas en quoi ta situation est différente de la mienne.
exemple j'ai été voir un arrêt de bus hier.
J'ai vu l'arrêt de bus, l'abribus, le banc, la poubelle, la rue, etc
donc sur le changeset source=survey
pour dessiner l'abribus et la route du parking, j'ai utilisé le sat
donc sur le changeset source:geometry=mapbox

Si je devais décrire ces mêmes sources sur les objets,
il me faudrait 48 tag source au lieu de 2 !

Ironie de la situation, la raison de ma visite sur place était un objet 
avec un beau source tag sur l'objet, ignoré par le contributeur suivant.
Heureusement il a utilisé Id qui a ajouté (automatiquement il me semble) 
la source=Bing malgré que le contributeur n'ai renseigné.

Je n'ose pas imaginer lorsque je fais une petite rue et que j'ai au 
final 200 objets créés/modifiés et donc un millier de tag donc aurait 
besoin de 2000 tag source, indigeste !

Le 26. 07. 17 à 18:59, Pierre-Yves Berrard a écrit :

> En ce qui me concerne, séparer les changeset selon la source est impossible.
> Je travaille le plus souvent sur une zone donnée, en essayant de 
> positionner les objets les uns par rapport aux autres, donc en 
> m'appuyant pour ce faire sur toutes les sources disponibles.
> 
> Question annexe (mais importante) : avec la source uniquement sur le 
> changeset, comment retrouver (facilement) la source pour qui exporterait 
> les données ?
> 
> PY
> 
> Le 26 juillet 2017 à 18:30, marc marc a écrit :
> 
> Le 26. 07. 17 à 17:51, Jean-Claude Repetto a écrit :
>  > une source pour la position et une autre source pour le nom
> oui source:geometry et source:name ont du sens.
> mais on peux mettre ce niveau de détail dans le changeset non ?
> tu as un exemple d'un changeset que tu as fait qui aurait un tag précis
> ayant une valeur différente selon l'objet sans que cela justifie de se
> faciliter la vie avec 2 changeset ?
> 
> ce qui n'a pas de sens c'est source=machin sur l'objet puisque la seule
> façon de savoir ce que cela concerne c'est de retrouver le changeset
> ___
> 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-GB] Live OSM discussion in ~45 minutes (7.30pm UK time)

2017-07-26 Diskussionsfäden Andy Mabbett

I've just learned that this week's Wikimedia Research Showcase,
streamed online TONIGHT at 7.30pm UK time, will focus on structured
data in OpenStreetMap. Details below.

-- Forwarded message --

The next Research Showcase will be live-streamed this Wednesday, July
26, 2017 at 11:30 AM (PST) 18:30 UTC.

YouTube stream: https://www.youtube.com/watch?v=yC1jgK8C8aQ

As usual, you can join the conversation on IRC at #wikimedia-research.
And, you can watch our past research showcases here:

   https://www.mediawiki.org/wiki/Wikimedia_Research/Showcase#July_2017

This month's presentation:

Freedom versus Standardization: Structured Data Generation in a Peer
Production CommunityBy Andrew HallIn addition to encyclopedia articles
and software, peer production communities produce structured data,
e.g., Wikidata and OpenStreetMap’s metadata. Structured data from peer
production communities has become increasingly important due to its
use by computational applications, such as CartoCSS, MapBox, and
Wikipedia infoboxes. However, this structured data is usable by
applications only if it follows standards. We did an interview study
focused on OpenStreetMap’s knowledge production processes to
investigate how – and how successfully – this community creates and
applies its data standards. Our study revealed a fundamental tension
between the need to produce structured data in a standardized way and
OpenStreetMap’s tradition of contributor freedom. We extracted six
themes that manifested this tension and three overarching concepts,
correctness, community, and code, which help make sense of and
synthesize the themes. We also offer suggestions for improving
OpenStreetMap’s knowledge production processes, including new data
models, sociotechnical tools, and community practices.





-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk-fr] Ostréiculteurs: producteurs, vendeurs, bar à huître

Sur le bâtiment
produce=oysters;seafood
cuisine=oysters;seafood

la question ouverte c'est est-ce que sa fonction première est
  de vendre des préparation comme un traiteur craft=caterer
  de vendre des produits non préparé (les huitres) shop=convenience
ou les 2
a mon avis, un tag description va être nécessaire

pour la salle à manger sans être un resto, je sèche

sur la table de pic-nique
leisure=picnic_table
access=customers
p'tre un seasonal si c'est saisonnier

Le 26. 07. 17 à 18:55, Nicolas Toublanc a écrit :

> Bonjour,
> 
> J'ai enfin pris le temps de rentrer dans l'un de ces bars à huître, et 
> j'ai du nouveau.
> 
> En effet, ils n'ont pas le statut de restaurant, donc ce qu'ils font, c'est:
> 
>   * ouvrir les huîtres, ou préparer des plateaux de fruits de mer
>   * mettre à disposition une terrasse ou une salle pour manger, mais
> chacun peut amener ses boissons, son pain et son beurre, etc...
> 
> Et ceux chez qui je suis allé proposent aussi un mode dégustation pour 
> les huîtres, avec pain/beurre, sauce et un verre de muscadet.
> 
> Donc au final, je pense qu'il ne faut pas leur mettre le tag restaurant, 
> car ça porterait à confusion (on n'y trouve pas ce qu'on s'attend à 
> trouver dans un restaurant, même si on peut au final manger sur place).
> 
> Le fait de préparer des plateaux de fruits de mer ressemble davantage à 
> ce que ferait un traiteur, et il est possible de déguster ou de 
> pique-niquer sur place (mais le site de picnic est réservé au clients).
> 
> Mais ce n'est ni un restaurant, ni un fast-food.
> 
> Avez-vous de nouvelles idées sur comment se dépatouiller avec tout ça?
> 
> 
> 
> 2017-07-10 10:41 GMT+02:00 Nicolas Toublanc  >:
> 
> 
> 
> 2017-07-09 15:03 GMT+02:00 Francescu GAROBY  >:
> 
> Attention, c'est "seafood", et non "seefood"...
> 
> 
> Héhé, oui merci de la correction!
> 
> > Est-il possible de multiplier les tags /*cuisine*/ et /*produce*/ 
> afin
> > d'avoir les 2 informations?
> oui tu peux
> cuisine=oysters;seefood
> produce=oysters;seefood
> mais l'un incluant l'autre, à ta place je choisirais l'un des 2
> selon ce
> qui est le plus important
> 
> 
> Le plus important dans ce contexte, c'est bien oysters. Mais du
> coup, il n'inclue pas seafood, donc indiquer les 2 me parait le plus
> adapté.
> 
> Merci à tous les 3 d'avoir pris le temps de répondre à mes questions!
> 
> Francescu
> 
> Le 9 juillet 2017 à 12:30, marc marc  > a écrit :
> 
> > il produit et sert avant tout des
> > huîtres, son produit phare, mais aussi d'autres fruits de mer.
> >
> > Donc soit on met produce=oysters et cuisine=oysters, mais on est
> > restrictif car il y a aussi d'autres crustacés. Soit on met 
> seefood à la
> > place de oysters, mais on ne met pas en avant la spécificité de
> > l'endroit: les huîtres, et on rend impossible une recherche 
> retournant
> > tous les producteurs d’huîtres de la région.
> >
>  > Est-il possible de multiplier les tags /*cuisine*/ et
> /*produce*/ afin
> > d'avoir les 2 informations?
> oui tu peux
> cuisine=oysters;seefood
> produce=oysters;seefood
> mais l'un incluant l'autre, à ta place je choisirais l'un
> des 2 selon ce
> qui est le plus important
> 
> Cordialement,
> Marc
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> 
> 
> -- 
> Francescu
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> 
> 
> -- 
> Nicolas Toublanc
> @toubiweb 
> 
> 
> 
> 
> -- 
> Nicolas Toublanc
> @toubiweb 
> 
> 
> ___
> 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] Ostréiculteurs: producteurs, vendeurs, bar à huître

2017-07-26 Diskussionsfäden Francescu GAROBY

Bonjour,
Pourquoi ça ne serait pas un restaurant ? On trouve tout type de lieux,
avec ce tag. Du restaurant étoilé au fish and chips...

Francescu

Le 26 juillet 2017 à 18:55, Nicolas Toublanc  a écrit
:

> Bonjour,
>
> J'ai enfin pris le temps de rentrer dans l'un de ces bars à huître, et
> j'ai du nouveau.
>
> En effet, ils n'ont pas le statut de restaurant, donc ce qu'ils font,
> c'est:
>
>- ouvrir les huîtres, ou préparer des plateaux de fruits de mer
>- mettre à disposition une terrasse ou une salle pour manger, mais
>chacun peut amener ses boissons, son pain et son beurre, etc...
>
> Et ceux chez qui je suis allé proposent aussi un mode dégustation pour les
> huîtres, avec pain/beurre, sauce et un verre de muscadet.
>
> Donc au final, je pense qu'il ne faut pas leur mettre le tag restaurant,
> car ça porterait à confusion (on n'y trouve pas ce qu'on s'attend à trouver
> dans un restaurant, même si on peut au final manger sur place).
>
> Le fait de préparer des plateaux de fruits de mer ressemble davantage à ce
> que ferait un traiteur, et il est possible de déguster ou de pique-niquer
> sur place (mais le site de picnic est réservé au clients).
>
> Mais ce n'est ni un restaurant, ni un fast-food.
>
> Avez-vous de nouvelles idées sur comment se dépatouiller avec tout ça?
>
>
>
> 2017-07-10 10:41 GMT+02:00 Nicolas Toublanc :
>
>>
>>
>> 2017-07-09 15:03 GMT+02:00 Francescu GAROBY :
>>
>>> Attention, c'est "seafood", et non "seefood"...
>>>
>>>
>> Héhé, oui merci de la correction!
>>
>> > Est-il possible de multiplier les tags /*cuisine*/ et /*produce*/ afin
>>> > d'avoir les 2 informations?
>>> oui tu peux
>>> cuisine=oysters;seefood
>>> produce=oysters;seefood
>>> mais l'un incluant l'autre, à ta place je choisirais l'un des 2 selon ce
>>> qui est le plus important
>>>
>>>
>> Le plus important dans ce contexte, c'est bien oysters. Mais du coup, il
>> n'inclue pas seafood, donc indiquer les 2 me parait le plus adapté.
>>
>> Merci à tous les 3 d'avoir pris le temps de répondre à mes questions!
>>
>>
>>
>>> Francescu
>>>
>>> Le 9 juillet 2017 à 12:30, marc marc  a
>>> écrit :
>>>
 > il produit et sert avant tout des
 > huîtres, son produit phare, mais aussi d'autres fruits de mer.
 >
 > Donc soit on met produce=oysters et cuisine=oysters, mais on est
 > restrictif car il y a aussi d'autres crustacés. Soit on met seefood à
 la
 > place de oysters, mais on ne met pas en avant la spécificité de
 > l'endroit: les huîtres, et on rend impossible une recherche retournant
 > tous les producteurs d’huîtres de la région.
 >
 > Est-il possible de multiplier les tags /*cuisine*/ et /*produce*/ afin
 > d'avoir les 2 informations?
 oui tu peux
 cuisine=oysters;seefood
 produce=oysters;seefood
 mais l'un incluant l'autre, à ta place je choisirais l'un des 2 selon ce
 qui est le plus important

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

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


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

Re: [Talk-us] [OSM-talk] Decline in accuracy of capture date metadata in Bing imagery

2017-07-26 Diskussionsfäden Paul Johnson

On Wed, Jul 26, 2017 at 9:48 AM, Bryan Housel  wrote:

> Hey this is a topic that I care about - It turns out, you are already
> chipping in some money for high resolution orthoimagery!
>
> OK state Geographic Information Council
> http://okmaps.onenet.net/index.html
>
> OK state GIS Portal:
> https://okmaps.org/OGI/search.aspx
>
> The NAIP 2015 layer "provides 1 meter GSD ortho imagery rectified within
> +/- 6 meters to true ground at a 95% confidence level. “
>
>
I'm aware of the 2015 imagery, however, most of the changes associated with
the Tulsa and small town renaissance happened more recently than that
imagery, with the bonus points of the older imagery being easier to discern
details like lane markings, building footprints and signpost positions (and
in the case of stop and yield signs, the sign shape from the shadow as
well).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

2017-07-26 Diskussionsfäden Pierre-Yves Berrard

En ce qui me concerne, séparer les changeset selon la source est impossible.
Je travaille le plus souvent sur une zone donnée, en essayant de
positionner les objets les uns par rapport aux autres, donc en m'appuyant
pour ce faire sur toutes les sources disponibles.

Question annexe (mais importante) : avec la source uniquement sur le
changeset, comment retrouver (facilement) la source pour qui exporterait
les données ?

PY

Le 26 juillet 2017 à 18:30, marc marc  a écrit :

> Le 26. 07. 17 à 17:51, Jean-Claude Repetto a écrit :
> > une source pour la position et une autre source pour le nom
> oui source:geometry et source:name ont du sens.
> mais on peux mettre ce niveau de détail dans le changeset non ?
> tu as un exemple d'un changeset que tu as fait qui aurait un tag précis
> ayant une valeur différente selon l'objet sans que cela justifie de se
> faciliter la vie avec 2 changeset ?
>
> ce qui n'a pas de sens c'est source=machin sur l'objet puisque la seule
> façon de savoir ce que cela concerne c'est de retrouver le changeset
> ___
> 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] Ostréiculteurs: producteurs, vendeurs, bar à huître

2017-07-26 Diskussionsfäden Nicolas Toublanc

Bonjour,

J'ai enfin pris le temps de rentrer dans l'un de ces bars à huître, et j'ai
du nouveau.

En effet, ils n'ont pas le statut de restaurant, donc ce qu'ils font, c'est:

   - ouvrir les huîtres, ou préparer des plateaux de fruits de mer
   - mettre à disposition une terrasse ou une salle pour manger, mais
   chacun peut amener ses boissons, son pain et son beurre, etc...

Et ceux chez qui je suis allé proposent aussi un mode dégustation pour les
huîtres, avec pain/beurre, sauce et un verre de muscadet.

Donc au final, je pense qu'il ne faut pas leur mettre le tag restaurant,
car ça porterait à confusion (on n'y trouve pas ce qu'on s'attend à trouver
dans un restaurant, même si on peut au final manger sur place).

Le fait de préparer des plateaux de fruits de mer ressemble davantage à ce
que ferait un traiteur, et il est possible de déguster ou de pique-niquer
sur place (mais le site de picnic est réservé au clients).

Mais ce n'est ni un restaurant, ni un fast-food.

Avez-vous de nouvelles idées sur comment se dépatouiller avec tout ça?



2017-07-10 10:41 GMT+02:00 Nicolas Toublanc :

>
>
> 2017-07-09 15:03 GMT+02:00 Francescu GAROBY :
>
>> Attention, c'est "seafood", et non "seefood"...
>>
>>
> Héhé, oui merci de la correction!
>
> > Est-il possible de multiplier les tags /*cuisine*/ et /*produce*/ afin
>> > d'avoir les 2 informations?
>> oui tu peux
>> cuisine=oysters;seefood
>> produce=oysters;seefood
>> mais l'un incluant l'autre, à ta place je choisirais l'un des 2 selon ce
>> qui est le plus important
>>
>>
> Le plus important dans ce contexte, c'est bien oysters. Mais du coup, il
> n'inclue pas seafood, donc indiquer les 2 me parait le plus adapté.
>
> Merci à tous les 3 d'avoir pris le temps de répondre à mes questions!
>
>
>
>> Francescu
>>
>> Le 9 juillet 2017 à 12:30, marc marc  a écrit
>> :
>>
>>> > il produit et sert avant tout des
>>> > huîtres, son produit phare, mais aussi d'autres fruits de mer.
>>> >
>>> > Donc soit on met produce=oysters et cuisine=oysters, mais on est
>>> > restrictif car il y a aussi d'autres crustacés. Soit on met seefood à
>>> la
>>> > place de oysters, mais on ne met pas en avant la spécificité de
>>> > l'endroit: les huîtres, et on rend impossible une recherche retournant
>>> > tous les producteurs d’huîtres de la région.
>>> >
>>> > Est-il possible de multiplier les tags /*cuisine*/ et /*produce*/ afin
>>> > d'avoir les 2 informations?
>>> oui tu peux
>>> cuisine=oysters;seefood
>>> produce=oysters;seefood
>>> mais l'un incluant l'autre, à ta place je choisirais l'un des 2 selon ce
>>> qui est le plus important
>>>
>>> Cordialement,
>>> Marc
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>>
>> --
>> Francescu
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Nicolas Toublanc
> @toubiweb 
>



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

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

Le 26. 07. 17 à 17:51, Jean-Claude Repetto a écrit :
> une source pour la position et une autre source pour le nom
oui source:geometry et source:name ont du sens.
mais on peux mettre ce niveau de détail dans le changeset non ?
tu as un exemple d'un changeset que tu as fait qui aurait un tag précis 
ayant une valeur différente selon l'objet sans que cela justifie de se 
faciliter la vie avec 2 changeset ?

ce qui n'a pas de sens c'est source=machin sur l'objet puisque la seule 
façon de savoir ce que cela concerne c'est de retrouver le changeset
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Appli Jungle Bus - nouvelle version 3.0.9

Une nouvelle version de l’application Jungle Bus est depuis quelques jours
disponible.

Estampillée version 3.0.9, l’application permet maintenant d’ajouter plus
de détails aux arrêts de bus (dont l'accessibilité) et plante beaucoup
moins souvent.
https://junglebus.io/appli-v3-0-9/
Vos retours sont comme toujours bienvenus sur Github.

PS : l'appli OSM Contributor qui partage la même base de code a été
également mise à jour
https://play.google.com/store/apps/details?id=io.mapsquare.osmcontributor

-- 

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

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

2017-07-26 Diskussionsfäden djakk djakk

Oui, il faut une source par tag en fait.

Le 26 juillet 2017 à 17:51, Jean-Claude Repetto  a écrit :

> Le 26/07/2017 à 15:59, Jo a écrit :
> > Il est préférable de taguer les source sur les changeset. Sinon on va
> > arriver à une situation comme en France où chaque objet a un tag source
> > d'un kilomètre de long qui prend énormément de place dans la BDD.
> >
>
> Bonjour,
>
> En général, on utilise simultanément plusieurs sources (imageries
> aériennes, cadastre, terrain, ...). Si on veut être précis, on doit
> indiquer la source pour chaque objet (et même parfois plusieurs sources
> pour un seul objet, par exemple une source pour la position et une autre
> source pour le nom).
>
> Jean-Claude
>
>
> ___
> 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] [OSM transport] Projet du mois - arrêts de bus

2017-07-26 Diskussionsfäden Jean-Claude Repetto

Le 26/07/2017 à 15:59, Jo a écrit :
> Il est préférable de taguer les source sur les changeset. Sinon on va
> arriver à une situation comme en France où chaque objet a un tag source
> d'un kilomètre de long qui prend énormément de place dans la BDD.
>

Bonjour,

En général, on utilise simultanément plusieurs sources (imageries
aériennes, cadastre, terrain, ...). Si on veut être précis, on doit
indiquer la source pour chaque objet (et même parfois plusieurs sources
pour un seul objet, par exemple une source pour la position et une autre
source pour le nom).

Jean-Claude


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

Re: [OSM-talk-fr] recherche d'une arrêt de bus sans nom dupliqué

Merci Jo.

Voici où j'en suis :
way["public_transport"="platform"]["bus"=yes]["name"][!"fixme"]

il reste à rajouter en condition
- le chemin n'est pas fermé (pour ne pas avoir les gros quais)
- soit qui ne fait pas partie d'un stop_area
- soit qui fait partie d'un stop_area mais dont le stop_area n'a pas de nom

Mais avec mon niveau débutant overpass, je bloque.

c'est pour cela que je demande si quelqu'un a tager une plateforme sans 
nom dupliqué

Si tu penses en avoir fait du côté d'avignon, je vais aller voir.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Hangout Transports en commun

2017-07-26 Diskussionsfäden Jo

Qui a le temps vendredi soir pour faire un Hangout sur le thème du
Transport en commun? Disons à 19h?

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

Re: [Talk-at] Jagdhütten

2017-07-26 Diskussionsfäden Borut Maricic

Ein starker Sommerregen in den Nachmittagsstunden reicht es,
um einem den weiteren Abstieg über dem steilen Gelände im
hohen Grass so gefährlich zu machen, dass eine ungeplante
Notübernachtung bei weitem gescheiter ist.

Abgesehen davon, dass ein Einbruch in solche Hütten sehr
schwierig ist (auch wenn man *sehr* motiviert ist), und dass
es in der/einer Gegend kaum andere dafür nutzbare Hütten
gibt, braucht man gar keine Unterkühlung-/Lebensbedrohung.
Ein Wettersturz mit starkem Regen unter milden
Temperatur-Bedingungen reich es schon. Gerade für solche
Situationen finde ich, dass es sehr beruhigend und für die
Beurteilung der Situation hilfreich sein kann, wenn einem am
Navi eine wettergeschützte Stelle gezeigt wird.

In meinen Augen ist ein amenity=shelter +
shelter_type=weather_shelter gerade für solche Stellen
vorgesehen. Wenn sogar shelter_type=rock_shelter vorgesehen
ist (s.
https://wiki.openstreetmap.org/wiki/DE:Key:shelter_type),
dann sehe ich wirklich keinen Grund um so eine
überdachte/geschüzte Stelle, wie in meinem Beispiel, nicht
mit einem so getaggtem Zusatzknoten zu mappen.

Was solche überzählige Stellen in Wien betrifft... naja, in
diesem Thread denke ich an die Jagdhütten und solch
geschützte Stellen im alpinen Gelände (und im konkreten Fall
z.B. an jemanden denkend, der am Nachmittag vom Reiting
absteigt, hinter sich schon fast 700 Höhenmeter-Abstieg hat
und vor sich noch etwa genauso viel).



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

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

Le 26. 07. 17 à 15:37, lenny.libre a écrit :
> lorsque je regarde un objet, je ne vais jamais voir le tag source du 
> groupe de modifications.

Tu te bases donc sur un tag malheureusement souvent désynchronisé :)
Dans josm c'est rapide de retrouver le changeset qui a modifié le tag
Je suis entrain de réfléchir a une proposition pour que josm affiche à 
côté du tag la source du changeset qui l'a modifié en dernier.
Cela permettrait d'avoir le confort du source tag sur l'objet sans info 
dupliquée ou désynchronisée.

> Et puis dans un groupe de modifications, il y plusieurs sources, si je 
> travaille sur un croisement, je met en source des passages protégés 
> l'imagerie et en source des panneaux ma connaissance sur le terrain et 
> le cadastre sur le nom de la voie
Pour ma part, j'essaye d'éviter de trop mixer les sources dans un 
changeset parce que sinon le suivant ne saura pas évaluer si ma source 
est plus récente que la sienne.
Généralement je fais un changeset séparé pour le survey (parce info 
ultra fraîche peu susceptible d'être incorrecte) du reste (les 
intégration opendata ou le sat qui a n'a pas été fait hier)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] [OSM-talk] Decline in accuracy of capture date metadata in Bing imagery

2017-07-26 Diskussionsfäden Bryan Housel

Hey this is a topic that I care about - It turns out, you are already chipping 
in some money for high resolution orthoimagery!

OK state Geographic Information Council
http://okmaps.onenet.net/index.html 

OK state GIS Portal:
https://okmaps.org/OGI/search.aspx 

The NAIP 2015 layer "provides 1 meter GSD ortho imagery rectified within +/- 6 
meters to true ground at a 95% confidence level. “ 

This is not spectacular resolution, but it is good enough for rough tracing in 
editors, and would at least give you a more recent alternative to Bing.

---

What aerial imagery exists?

Here is some info about high resolution orthoimagery in the United States.  The 
following statements are mostly true:

- States collect imagery every few years.
- They are supposed to do this to support the NAIP (National Aerial Imagery 
Program), a USDA program
- The imagery is 1meter/pixel or better. 
- It’s getting better all the time.  Some is even 6” or 3” in urban areas.
- Every state has a government GIS portal / WMS server where you can look for 
this information
- You might have to dig through government websites to find what you’re looking 
for, it’s not simple
- It’s generally public, but you might have to contact someone to get explicit 
permission to use it for OSM
- It was all supposed to be combined onto the USGS National Map, but this 
program is being shut down / defunded.

---

What can you do to help?

We collect this imagery data here:
https://github.com/osmlab/editor-layer-index 

Once it is added to the editor layer index, it will be available in iD and 
other editors.

There is lots of public imagery out there, but we need volunteers to:

1. find it in the first place
2. contact state GIS agencies for permission, if the website does not make 
license clear
3. figure out whether the WMS server can serve the imagery (some serve TMS/WTMS 
tiles that can be consumed directly in iD, others serve WMS which can sometimes 
be proxied)
4. add the source to editor-layer-index, along with a boundary polygon where 
the imagery is valid.

In conclusion, please follow the editor-layer-index project, and help add the 
public imagery (that you are already paying for) to the OSM editors!

Thanks, Bryan

> On Jul 26, 2017, at 6:10 AM, Paul Johnson  wrote:
> 
> On Tue, Jul 25, 2017 at 5:48 PM, Clifford Snow  > wrote:
> A contact in Microsoft said that the Bing imagery is made up of multiple 
> images which results in the date range. 
> 
> The imagery we are getting has improved over time, although it seems at a 
> snails pace. I'm sure if we were paying for imagery we would have different 
> requirements. Bing probably wants nice looking - with lots of green 
> vegetation. Our needs would be better served by leaf off imagery. So if 
> someone wants to start fund raising, we could have imagery that better fits 
> our needs. 
> 
> I would be willing to chip in some money to get updated high resolution 
> imagery for metro Tulsa and eastern Oklahoma.  Latest imagery available for 
> the area's already in Bing and it's 2011-2013 vintage stock at this point.  
> Between the renaissance of Tulsa and many small towns in the region, 1 new 
> town built and incorporated, and 3 or 4 towns that went bust and are in the 
> process of being torn down and recycled for materials, that imagery's not far 
> from being unusably old.
> ___
> talk mailing list
> t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk-fr] SPAM Re: Modification du nom de plusieurs communes

2017-07-26 Diskussionsfäden Christian Rogel


> Le 2017 Goue. 26 à 02:50, Philippe Verdy  a écrit :
> 
> Sauf que les communes ne sont PAS des langues ISO 639 (ici on utilise des 
> codes BCP 47, jamais les ISO 639 qui ne sont pas non plus stables...) et 
> encore moins des entités ISO 3166 (pays et subdivisions de premier niveau ou 
> de second niveau pour certains pays copmme la France, eux même souvent pas à 
> jouor avec les entités officielles). Ce sont des nom officiels.
> 
> Et là on ne parle pas des tags "name:=*", mais juste des 
> tags "name=*" qui sont les noms par défaut, dans leur graphie non abrégée, 
> sans capitalisation de toutes les lettres comme sur les adresses postales et 
> avec tous leurs caractères signifiants, y compris apostrophes et autres 
> ponctuations même si pour le courrier postal on les remplace par des espaces 
> et on élimine bon nombre de signes diacritiques...)
> 
> Le 26 juillet 2017 à 01:08, Christian Rogel  > a écrit :
> Qu’il soit clair, une fois pour toute, que personne ne propose de « cacher » 
> la version officielle des toponymes. Ce qui est dans les « name:ISO639 » ne 
> concerne en rien les rendus par défaut des « name ».
> Les « name:ISO639 » doivent uniquement être attestés ou cohérents, sans 
> aucune limite territoriale. C’est la beauté esthétique de la situation de 
> langue non reconnue, personne ne peut s’y opposer, précisément, parce qu’elle 
> est hors la loi.
> 
> Un texte de référence sur ce sujet : 
> http://www.openstreetmap.bzh/fr/2017/06/27/brezhoneg-e-maez-al-lezenn-neus-harzh-ebet-evit-brezhonekan-ar-gartenn-openstreetmap/
>  
> 
>  (au besoin, choisir la version en français dans la col. de gauche)


Le wiki OSM  n’est pas 
contradictoire avec ce que j’ai dit : tout dépend du zoom. Si le BCP 47 est 
l’enveloppe générale, il est bien noté que les codes linguistiques sont tirés, 
en premier lieu des codes ISO 639 (2 et 3) et ce n’est que pour des langues peu 
connues ou peu écrites que l’on fait appel à d’autres codes.
L’instabilité du code ISO 639 est uniquement référée aux translittérations.

Dans l’espace européen, les principales langues écrites avec littérature sont 
notées sur OSM par le code ISO 639-2, le 639-3  concernant des dialectes 
littéraire. Exemple : l’alsacien faisant partie de la zone Germany South-West, 
il est codé gsw.Le flamand du Westhoek (Lille-Dunkerque) est codé vls.
Le gallo et le normand n’ont pas de code ISO 639, mais, j’apprend par le wiki 
qu’ils pourraient être provisoirement codés par « fr-x-gallo » et « fr-x-norman 
». C’est une bonne nouvelle et il est possible que je l’utilise parallèlement à 
br.

« Sauf que les communes ne sont PAS des langues ISO 639 », dis-tu. Personne ne 
l’a prétendu et le code de langue concerne aussi  les «  old_name »  et les «  
alt_name » . En fait, pour les toponymes, qui ne sont pas des textes avec des 
caractéristiques discursives (syntaxe, flexions…), il serait plus juste de les 
référer à un continuum linguistique, un espace de sens dans lequel seul l’usage 
gouverne l’occurence du toponyme.
Ainsi, cela fait des siècles que Bordeaux et Tours sont désignés respectivement 
 comme Bourdel (mot occitan ou français) et Turgn ( < lat. Turones) par les 
brittophones, mais ceux-ci ne sont pas étonnés si l’on y substitue les noms 
locaux.
En Angleterre, quelques noms de lieu sont du pur normand, mais ils apparaissent 
au même niveau que les noms d’origine «  vieux bas-germanique ».

Les noms des accidents du relief peuvent prendre une forme de locution (Beg ar 
Raz = Pointe du Raz) qui met en jeu les caractéres de la langue. Tout aussi 
vrai pour les noms de rue et de POI.


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

Re: [OSM-talk-fr] recherche d'une arrêt de bus sans nom dupliqué

2017-07-26 Diskussionsfäden Jo

En Belgique j'ai continué de les taguer tous sur des noeuds isolés à coté
de la rue. Ici ill n'y a pas de duplication, car les noeuds stop_position,
s'ils sont déjà présents, n'ont que

public_transport=stop_position
et
bus=yes
ou
tram=yes

J'ai essayé d'utiliser le même principe à Avignon.

S'il y a une plateforme, je l'ai ajouté comme way, mais ceux n'ont pas plus
de détails au de delà de

highway=platform/railway=platform (pour la rendition)
et
public_transport=platform

et des fois
wheelchair=yes (s'il y a une partie plus élévée)
tactile_paving=yes

J'utilse ceci pour télécharger tout:

[out:xml][timeout:225][bbox:{{bbox}}];
(
  (
node["highway"="bus_stop"];
node["public_transport"="platform"];
node["public_transport"="stop_position"];
  );
  ._;<;
  way["highway"="platform"];
  way["amenity"="shelter"];
  node["amenity"="shelter"];
  relation["route"="bus"];
);
(._;>;);
out meta;

Pour les trams, il faut changer un petit peu la requête.

Polyglot

2017-07-26 15:37 GMT+02:00 marc marc :

> Bonjour,
>
> Dans le schéma v1,les arrêts de bus étaient représenté highway=bus_stop
> mis un nœud idéalement en dehors de la route.
> L'icône est généralement un bus avec le nom juste en dessous.
>
> Dans la v2, c'est public_transport=platform préconisé sur :
> un nœud s'il n'y a pas de quai proprement dit.
> un way pour les petits quais.
> une area pour les quais de taille plus conséquentes.
>
> Le nœud et l'area ne pose généralement pas de problème pour le rendu,
> l'icône étant proche du point ou dans l'area.
>
> J'aimerai voir comment se débrouille le moteur de rendu avec un arrêt de
> bus représenté par un (petit) way pour afficher un icône et un nom sur
> un chemin.
> Mais les différents arrêts de bus que je trouve sur des way ont des
> infos dupliquées dans tous les sens et il est donc difficile de savoir
> le rendu des tag séparément, surtout qu'on met souvent les anciens tag
> en plus pour être compatible.
>
> Dons si avez marqué ou vu un arrêt de bus récemment qui a son nom
> uniquement sur la plateforme, son no m’intéresserait.
> A défaut je vais devoir apprendre la syntaxe overpass pour "mais pas
> ceux qui font partie d'une stop_area qui a un nom" :)
>
> ___
> 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-br] Nova divisão territorial substitui mesorregiões e microrregiões

2017-07-26 Diskussionsfäden Leonardo Brondani Schenkel


On 2017-07-26 11:42, Sérgio V. wrote:
Pelo que entendi, então, quanto às MESO e MICRO regiões, colocadas no 
OSM como "admin_level", não faz o menor sentido tê-las no OSM.


Foi exatamente a discussão que eu abri.

Melhor então seria remover do OSM (somente) todas estas relações de meso 
e micro (sem mexer nos ways).


Se isso significa encontrar uma nova forma de 'taguear' as divisões 
estatísticas do IBGE (melhor ainda se a nova forma permite tanto as 
antigas como nas novas) de uma forma que não envolva o uso de 
'admin_level', mais uma vez concordamos plenamente e foi o que eu sugeri 
o ano passado (naturalmente, as novas divisões ainda não existiam), 
inclusive me voluntariei a criar e propor um novo esquema.


Infelizmente eu não fui capaz de persuadir os outros membros da lista e 
não pude obter consenso. Também não antecipei a grande resistência de 
alguns membros em mexer nas divisões do IBGE. Por causa disso acabei 
ficando sem energia e abandonei a discussão e não fui adiante com a 
proposta do novo esquema. Aconselho a quem tiver interesse olhar os 
arquivos desta lista do ano passado (janeiro a maio, se não me engano), 
e tirem suas próprias conclusões.


// Leonardo.


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

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

2017-07-26 Diskussionsfäden Jo

Il est préférable de taguer les source sur les changeset. Sinon on va
arriver à une situation comme en France où chaque objet a un tag source
d'un kilomètre de long qui prend énormément de place dans la BDD.

2017-07-26 14:45 GMT+02:00 Florian LAINEZ :

> il est préférable de préciser la source directement sur les objets
> eux-mêmes.
>
> Le 26 juillet 2017 à 13:33, djakk djakk  a écrit :
>
>> Oui effectivement j'ai carburé ^^ merci pour le comptage je ne pensais
>> pas en avoir fait autant :O
>>
>> Pour le soucis avec l'imagerie aérienne, je met un "source"='BDOrtho
>> IGN' sur l'arrêt de bus créé ou bien le "source" du changeset suffit ? Ou
>> bien j'arrête de mapper avec cette technique, laissant le boulot à un
>> mapper local ?
>>
>> Le 26 juillet 2017 à 09:42, Florian LAINEZ  a écrit :
>>
>>> Warning... les images aériennes ne sont pas forcément de toute fraîcheur
 et les arrêts de bus n'ont pas un emplacement immuable, surtout qu'il y en
 a pas mal qui font l'objet de travaux pour mise aux normes
 d'accessibilité... donc warning ;)

>>>
>>> +1
>>>
>>> Le 25 juillet 2017 à 17:52, Christian Quest  a
>>> écrit :
>>>
 Le 25/07/2017 à 17:29, marc marc a écrit :

> djakk 200 arrêts trouvé sur imagerie sat en 6 jours ? woaw tu carbures
> !
>
>
 Warning... les images aériennes ne sont pas forcément de toute
 fraîcheur et les arrêts de bus n'ont pas un emplacement immuable, surtout
 qu'il y en a pas mal qui font l'objet de travaux pour mise aux normes
 d'accessibilité... donc warning ;)

 --
 Christian Quest - OpenStreetMap France



 ___
 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
>>>
>>>
>>
>> ___
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

2017-07-26 Diskussionsfäden Pierre-Yves Berrard

J'aurais dit l'inverse.

Mes changesets sont en général une confrontation de plusieurs sources.
Donc je mets un tag source par objet, et si l'objet change, je change aussi
la source.
Rigueur. ;)

Le 26 juillet 2017 à 15:08, marc marc  a écrit :

> Moi j'aurais dis l'inverse :)
> Le changeset a été créé pour éviter de dupliquer 200 fois le même tag
> sur les 200 objets.
> Surtout que lorsque quelqu'un modifie l'objet, si le sourcetag précédent
> reste, il devient erroné (un arrêt de bus confirmé sur place alors que
> la source va toujours dire qu'il provient d'imagerie sat.
> Du coup il et impossible de se fier au source sur l'objet, on ne peux se
> baser que sur celui du changeset donc pas d'intérêt de dupliquer un tag
> qui deviendra désynchronisé par la suite.
> A la limite un fixeme serrait plus utilisable.. parce que celui là on le
> vire systématiquement lorsqu'on le traite.
>
> Le 26. 07. 17 à 14:45, Florian LAINEZ a écrit :
> > il est préférable de préciser la source directement sur les objets
> > eux-mêmes.
> >
> > Le 26 juillet 2017 à 13:33, djakk djakk  > > a écrit :
> >
> > Oui effectivement j'ai carburé ^^ merci pour le comptage je ne
> > pensais pas en avoir fait autant :O
> >
> > Pour le soucis avec l'imagerie aérienne, je met un "source"='BDOrtho
> > IGN' sur l'arrêt de bus créé ou bien le "source" du changeset suffit
> > ? Ou bien j'arrête de mapper avec cette technique, laissant le
> > boulot à un mapper local ?
> >
> > Le 26 juillet 2017 à 09:42, Florian LAINEZ  > > a écrit :
> >
> > Warning... les images aériennes ne sont pas forcément de
> > toute fraîcheur et les arrêts de bus n'ont pas un
> > emplacement immuable, surtout qu'il y en a pas mal qui font
> > l'objet de travaux pour mise aux normes d'accessibilité...
> > donc warning ;)
> >
> >
> > +1
> >
> > Le 25 juillet 2017 à 17:52, Christian Quest
> > > a
> écrit :
> >
> > Le 25/07/2017 à 17:29, marc marc a écrit :
> >
> > djakk 200 arrêts trouvé sur imagerie sat en 6 jours ?
> > woaw tu carbures !
> >
> >
> > Warning... les images aériennes ne sont pas forcément de
> > toute fraîcheur et les arrêts de bus n'ont pas un
> > emplacement immuable, surtout qu'il y en a pas mal qui font
> > l'objet de travaux pour mise aux normes d'accessibilité...
> > donc warning ;)
> >
> > --
> > Christian Quest - OpenStreetMap France
> >
> >
> >
> > ___
> > 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

2017-07-26 Diskussionsfäden lenny.libre




Le 26/07/2017 à 15:08, marc marc a écrit :

Moi j'aurais dis l'inverse :)
Le changeset a été créé pour éviter de dupliquer 200 fois le même tag
sur les 200 objets.
Surtout que lorsque quelqu'un modifie l'objet, si le sourcetag précédent
reste, il devient erroné (un arrêt de bus confirmé sur place alors que
la source va toujours dire qu'il provient d'imagerie sat.
Du coup il et impossible de se fier au source sur l'objet, on ne peux se
baser que sur celui du changeset donc pas d'intérêt de dupliquer un tag
qui deviendra désynchronisé par la suite.
A la limite un fixeme serrait plus utilisable.. parce que celui là on le
vire systématiquement lorsqu'on le traite.
oui et non, tu as sûrement raison, mais (vu l'état de ce champs source) 
lorsque je regarde un objet, je ne vais jamais voir le tag source du 
groupe de modifications.
Et puis dans un groupe de modifications, il y plusieurs sources, si je 
travaille sur un croisement, je met en source des passages protégés 
l'imagerie et en source des panneaux ma connaissance sur le terrain et 
le cadastre sur le nom de la voie


Leni



Le 26. 07. 17 à 14:45, Florian LAINEZ a écrit :

il est préférable de préciser la source directement sur les objets
eux-mêmes.

Le 26 juillet 2017 à 13:33, djakk djakk > a écrit :

 Oui effectivement j'ai carburé ^^ merci pour le comptage je ne
 pensais pas en avoir fait autant :O

 Pour le soucis avec l'imagerie aérienne, je met un "source"='BDOrtho
 IGN' sur l'arrêt de bus créé ou bien le "source" du changeset suffit
 ? Ou bien j'arrête de mapper avec cette technique, laissant le
 boulot à un mapper local ?

 Le 26 juillet 2017 à 09:42, Florian LAINEZ > a écrit :

 Warning... les images aériennes ne sont pas forcément de
 toute fraîcheur et les arrêts de bus n'ont pas un
 emplacement immuable, surtout qu'il y en a pas mal qui font
 l'objet de travaux pour mise aux normes d'accessibilité...
 donc warning ;)


 +1

 Le 25 juillet 2017 à 17:52, Christian Quest
 > a écrit :

 Le 25/07/2017 à 17:29, marc marc a écrit :

 djakk 200 arrêts trouvé sur imagerie sat en 6 jours ?
 woaw tu carbures !


 Warning... les images aériennes ne sont pas forcément de
 toute fraîcheur et les arrêts de bus n'ont pas un
 emplacement immuable, surtout qu'il y en a pas mal qui font
 l'objet de travaux pour mise aux normes d'accessibilité...
 donc warning ;)

 --
 Christian Quest - OpenStreetMap France



 ___
 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



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

[OSM-talk-fr] recherche d'une arrêt de bus sans nom dupliqué

Bonjour,

Dans le schéma v1,les arrêts de bus étaient représenté highway=bus_stop 
mis un nœud idéalement en dehors de la route.
L'icône est généralement un bus avec le nom juste en dessous.

Dans la v2, c'est public_transport=platform préconisé sur :
un nœud s'il n'y a pas de quai proprement dit.
un way pour les petits quais.
une area pour les quais de taille plus conséquentes.

Le nœud et l'area ne pose généralement pas de problème pour le rendu, 
l'icône étant proche du point ou dans l'area.

J'aimerai voir comment se débrouille le moteur de rendu avec un arrêt de 
bus représenté par un (petit) way pour afficher un icône et un nom sur 
un chemin.
Mais les différents arrêts de bus que je trouve sur des way ont des 
infos dupliquées dans tous les sens et il est donc difficile de savoir 
le rendu des tag séparément, surtout qu'on met souvent les anciens tag 
en plus pour être compatible.

Dons si avez marqué ou vu un arrêt de bus récemment qui a son nom 
uniquement sur la plateforme, son no m’intéresserait.
A défaut je vais devoir apprendre la syntaxe overpass pour "mais pas 
ceux qui font partie d'une stop_area qui a un nom" :)

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

Re: [OSM-talk-fr] Valeur opening_hours supérieure à 255 caractères

Merci pour les différentes versions. Je ne connaissais pas cette façon 
de « contourner » la limite des 255.


Charles MILLET
charlesmil...@free.fr

Le 26/07/2017 à 15:19, Philippe Verdy a écrit :

Autre solution si ce n'est pas assez clair avec des "@":

opening_hours=Sep-Jun {opening_hours["en période scolaire"]};Jul-Aug 
{opening_hours["durant l'été"]}
opening_hours["en période scolaire"]=Mo,Th 11:30-14:00;Tu 
11:30-14:00,16:45-21:00;We 11:30-14:15;Fr 11:30-13:30,17:30-20:15;Sa 
14:00-18:00;Su 09:30-12:30,15:00-18:00
opening_hours["durant l'été"]=Mo,Sa 14:00-19:00;Tu 10:00-11:30;We,Th 
10:00-11:30,14:00-19:00;Fr 10:00-11:30,14:00-21:00;Su 
09:00-12:00,14:00-19:00


Là on utilise des {accolades} pour indiquer explicitement le nom du 
tag complet (le sous-tag est un nom libre, éventuellement entre 
guillemets pour indiquer un libellé pouvant être affiché tel quel 
destiné à l'utilisateur et pouvant contenir des caractères "spéciaux 
ou des espaces), mais pouvant aussi bien être interprété de façon 
opaque si on ne l'affiche pas car la langue n'est pas adaptée), ou 
juste (le nom du tag complet est déduit du contenu des accolades on 
peut reprendre les crochets et éliminer les guillemets.


opening_hours=Sep-Jun [en période scolaire];Jul-Aug [durant l'été]
opening_hours[en période scolaire]=Mo,Th 11:30-14:00;Tu 
11:30-14:00,16:45-21:00;We 11:30-14:15;Fr 11:30-13:30,17:30-20:15;Sa 
14:00-18:00;Su 09:30-12:30,15:00-18:00
opening_hours[durant l'été]=Mo,Sa 14:00-19:00;Tu 10:00-11:30;We,Th 
10:00-11:30,14:00-19:00;Fr 10:00-11:30,14:00-21:00;Su 
09:00-12:00,14:00-19:00


C'est un problème générique, mais la syntaxe doit être claire et 
légère avant de l'adopter.


Le 26 juillet 2017 à 15:07, Philippe Verdy > a écrit :




Le 26 juillet 2017 à 15:03, Philippe Verdy > a écrit :

Noter qu'on ne serait pas obligé non plus de factoriser les
conditions, et il suffirait aussi de référencer  des régles
autosuffisantes:

opening_hours=@1;@2
opening_hours:1=Sep-JunMo,Th 11:30-14:00;Sep-JunTu
11:30-14:00,16:45-21:00;Sep-JunWe 11:30-14:15;Sep-JunFr
11:30-13:30,17:30-20:15;Sep-JunSa 14:00-18:00;Sep-JunSu
09:30-12:30,15:00-18:00
opening_hours:2=Jul-AugMo,Sa 14:00-19:00;Jul-AugTu
10:00-11:30;Jul-AugWe,Th 10:00-11:30,14:00-19:00;Jul-AugFr
10:00-11:30,14:00-21:00;Jul-AugSu 09:00-12:00,14:00-19:00


Ou même encore:

opening_hours=Sep-JunMo,Th 11:30-14:00;Sep-JunTu
11:30-14:00,16:45-21:00;Sep-JunWe 11:30-14:15;Sep-JunFr
11:30-13:30,17:30-20:15;Sep-JunSa 14:00-18:00;Sep-JunSu
09:30-12:30,15:00-18:00;@2
opening_hours:2=Jul-AugMo,Sa 14:00-19:00;Jul-AugTu
10:00-11:30;Jul-AugWe,Th 10:00-11:30,14:00-19:00;Jul-AugFr
10:00-11:30,14:00-21:00;Jul-AugSu 09:00-12:00,14:00-19:00


 le @2 permettant d'indiquer dans quel tag (opening_hours:2) se
situe la suite (sans lui adjoindre aucun critère "factorisé")




___
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] Valeur opening_hours supérieure à 255 caractères


Ok, ça m'a échappé dans le Wiki, j'approfondirai ça.

Merci encore pour ton retour.

Charles MILLET
charlesmil...@free.fr

Le 26/07/2017 à 15:22, David Crochet a écrit :

Bonjour

Sauf que tu n'avais pas mis les ":" à tes définitions ce qu'il fait 
qu'ils faut les répéter après chaque ";".


Avec le ":", si je ne me trompe pas, l'attribut va jusqu'au ":" 
suivant quel que soit le nombre de ";" entre



Cordialement




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

Re: [OSM-talk-fr] Valeur opening_hours supérieure à 255 caractères

Comme (sauf erreur) aucune solution n'existe pour l'instant pour décoder 
le report sur plusieurs tag, d'ici là, la chaîne ne serra utile qu'aux 
humains. à ta place je chercherais s'il n'existe pas des cas 
d'utilisation du genre opening_hours:website=https://lapage pour 
renseigner une version humainement digeste

 > opening_hours=Sep-JunMo<...>;@2
 > opening_hours:2=Jul-Aug<...>
ca aurait le mérite de rendre la moitié des infos utilisable par les 
outils existants. donc y mettre la période la plus importante pour 
l'utilisateur et demander sur le wiki pour standardiser la 2ieme partie.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Valeur opening_hours supérieure à 255 caractères

2017-07-26 Diskussionsfäden David Crochet


Bonjour

Sauf que tu n'avais pas mis les ":" à tes définitions ce qu'il fait 
qu'ils faut les répéter après chaque ";".


Avec le ":", si je ne me trompe pas, l'attribut va jusqu'au ":" suivant 
quel que soit le nombre de ";" entre



Cordialement

--
David Crochet


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

Re: [OSM-talk-fr] Valeur opening_hours supérieure à 255 caractères

Autre solution si ce n'est pas assez clair avec des "@":

opening_hours=Sep-Jun {opening_hours["en période scolaire"]};Jul-Aug {
opening_hours["durant l'été"]}
opening_hours["en période scolaire"]=Mo,Th 11:30-14:00;Tu
11:30-14:00,16:45-21:00;We 11:30-14:15;Fr 11:30-13:30,17:30-20:15;Sa
14:00-18:00;Su 09:30-12:30,15:00-18:00
opening_hours["durant l'été"]=Mo,Sa 14:00-19:00;Tu 10:00-11:30;We,Th
10:00-11:30,14:00-19:00;Fr 10:00-11:30,14:00-21:00;Su
09:00-12:00,14:00-19:00

Là on utilise des {accolades} pour indiquer explicitement le nom du tag
complet (le sous-tag est un nom libre, éventuellement entre guillemets pour
indiquer un libellé pouvant être affiché tel quel destiné à l'utilisateur
et pouvant contenir des caractères "spéciaux ou des espaces), mais pouvant
aussi bien être interprété de façon opaque si on ne l'affiche pas car la
langue n'est pas adaptée), ou juste (le nom du tag complet est déduit du
contenu des accolades on peut reprendre les crochets et éliminer les
guillemets.

opening_hours=Sep-Jun [en période scolaire];Jul-Aug [durant l'été]
opening_hours[en période scolaire]=Mo,Th 11:30-14:00;Tu
11:30-14:00,16:45-21:00;We 11:30-14:15;Fr 11:30-13:30,17:30-20:15;Sa
14:00-18:00;Su 09:30-12:30,15:00-18:00
opening_hours[durant l'été]=Mo,Sa 14:00-19:00;Tu 10:00-11:30;We,Th
10:00-11:30,14:00-19:00;Fr 10:00-11:30,14:00-21:00;Su
09:00-12:00,14:00-19:00

C'est un problème générique, mais la syntaxe doit être claire et légère
avant de l'adopter.

Le 26 juillet 2017 à 15:07, Philippe Verdy  a écrit :

>
>
> Le 26 juillet 2017 à 15:03, Philippe Verdy  a écrit :
>
>> Noter qu'on ne serait pas obligé non plus de factoriser les conditions,
>> et il suffirait aussi de référencer  des régles autosuffisantes:
>>
>> opening_hours=@1;@2
>> opening_hours:1=Sep-Jun Mo,Th 11:30-14:00;Sep-Jun Tu
>> 11:30-14:00,16:45-21:00;Sep-Jun We 11:30-14:15;Sep-Jun Fr
>> 11:30-13:30,17:30-20:15;Sep-Jun Sa 14:00-18:00;Sep-Jun Su
>> 09:30-12:30,15:00-18:00
>> opening_hours:2=Jul-Aug Mo,Sa 14:00-19:00;Jul-Aug Tu 10:00-11:30;Jul-Aug 
>> We,Th
>> 10:00-11:30,14:00-19:00;Jul-Aug Fr 10:00-11:30,14:00-21:00;Jul-Aug Su
>> 09:00-12:00,14:00-19:00
>>
>
> Ou même encore:
>
>> opening_hours=Sep-Jun Mo,Th 11:30-14:00;Sep-Jun Tu
>> 11:30-14:00,16:45-21:00;Sep-Jun We 11:30-14:15;Sep-Jun Fr
>> 11:30-13:30,17:30-20:15;Sep-Jun Sa 14:00-18:00;Sep-Jun Su
>> 09:30-12:30,15:00-18:00;@2
>> opening_hours:2=Jul-Aug Mo,Sa 14:00-19:00;Jul-Aug Tu 10:00-11:30;Jul-Aug 
>> We,Th
>> 10:00-11:30,14:00-19:00;Jul-Aug Fr 10:00-11:30,14:00-21:00;Jul-Aug Su
>> 09:00-12:00,14:00-19:00
>>
>
>  le @2 permettant d'indiquer dans quel tag (opening_hours:2) se situe la
> suite (sans lui adjoindre aucun critère "factorisé")
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

Moi j'aurais dis l'inverse :)
Le changeset a été créé pour éviter de dupliquer 200 fois le même tag 
sur les 200 objets.
Surtout que lorsque quelqu'un modifie l'objet, si le sourcetag précédent 
reste, il devient erroné (un arrêt de bus confirmé sur place alors que 
la source va toujours dire qu'il provient d'imagerie sat.
Du coup il et impossible de se fier au source sur l'objet, on ne peux se 
baser que sur celui du changeset donc pas d'intérêt de dupliquer un tag 
qui deviendra désynchronisé par la suite.
A la limite un fixeme serrait plus utilisable.. parce que celui là on le 
vire systématiquement lorsqu'on le traite.

Le 26. 07. 17 à 14:45, Florian LAINEZ a écrit :
> il est préférable de préciser la source directement sur les objets 
> eux-mêmes.
> 
> Le 26 juillet 2017 à 13:33, djakk djakk  > a écrit :
> 
> Oui effectivement j'ai carburé ^^ merci pour le comptage je ne
> pensais pas en avoir fait autant :O
> 
> Pour le soucis avec l'imagerie aérienne, je met un "source"='BDOrtho
> IGN' sur l'arrêt de bus créé ou bien le "source" du changeset suffit
> ? Ou bien j'arrête de mapper avec cette technique, laissant le
> boulot à un mapper local ?
> 
> Le 26 juillet 2017 à 09:42, Florian LAINEZ  > a écrit :
> 
> Warning... les images aériennes ne sont pas forcément de
> toute fraîcheur et les arrêts de bus n'ont pas un
> emplacement immuable, surtout qu'il y en a pas mal qui font
> l'objet de travaux pour mise aux normes d'accessibilité...
> donc warning ;)
> 
> 
> +1
> 
> Le 25 juillet 2017 à 17:52, Christian Quest
> > a écrit :
> 
> Le 25/07/2017 à 17:29, marc marc a écrit :
> 
> djakk 200 arrêts trouvé sur imagerie sat en 6 jours ?
> woaw tu carbures !
> 
> 
> Warning... les images aériennes ne sont pas forcément de
> toute fraîcheur et les arrêts de bus n'ont pas un
> emplacement immuable, surtout qu'il y en a pas mal qui font
> l'objet de travaux pour mise aux normes d'accessibilité...
> donc warning ;)
> 
> -- 
> Christian Quest - OpenStreetMap France
> 
> 
> 
> ___
> 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] Valeur opening_hours supérieure à 255 caractères

Le 26 juillet 2017 à 15:03, Philippe Verdy  a écrit :

> Noter qu'on ne serait pas obligé non plus de factoriser les conditions, et
> il suffirait aussi de référencer  des régles autosuffisantes:
>
> opening_hours=@1;@2
> opening_hours:1=Sep-Jun Mo,Th 11:30-14:00;Sep-Jun Tu
> 11:30-14:00,16:45-21:00;Sep-Jun We 11:30-14:15;Sep-Jun Fr
> 11:30-13:30,17:30-20:15;Sep-Jun Sa 14:00-18:00;Sep-Jun Su
> 09:30-12:30,15:00-18:00
> opening_hours:2=Jul-Aug Mo,Sa 14:00-19:00;Jul-Aug Tu 10:00-11:30;Jul-Aug We,Th
> 10:00-11:30,14:00-19:00;Jul-Aug Fr 10:00-11:30,14:00-21:00;Jul-Aug Su
> 09:00-12:00,14:00-19:00
>

Ou même encore:

> opening_hours=Sep-Jun Mo,Th 11:30-14:00;Sep-Jun Tu
> 11:30-14:00,16:45-21:00;Sep-Jun We 11:30-14:15;Sep-Jun Fr
> 11:30-13:30,17:30-20:15;Sep-Jun Sa 14:00-18:00;Sep-Jun Su
> 09:30-12:30,15:00-18:00;@2
> opening_hours:2=Jul-Aug Mo,Sa 14:00-19:00;Jul-Aug Tu 10:00-11:30;Jul-Aug We,Th
> 10:00-11:30,14:00-19:00;Jul-Aug Fr 10:00-11:30,14:00-21:00;Jul-Aug Su
> 09:00-12:00,14:00-19:00
>

 le @2 permettant d'indiquer dans quel tag (opening_hours:2) se situe la
suite (sans lui adjoindre aucun critère "factorisé")
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Valeur opening_hours supérieure à 255 caractères

Noter qu'on ne serait pas obligé non plus de factoriser les conditions, et
il suffirait aussi de référencer  des régles autosuffisantes:

opening_hours=@1;@2
opening_hours:1=Sep-Jun Mo,Th 11:30-14:00;Sep-Jun Tu
11:30-14:00,16:45-21:00;Sep-Jun We 11:30-14:15;Sep-Jun Fr
11:30-13:30,17:30-20:15;Sep-Jun Sa 14:00-18:00;Sep-Jun Su
09:30-12:30,15:00-18:00
opening_hours:2=Jul-Aug Mo,Sa 14:00-19:00;Jul-Aug Tu 10:00-11:30;Jul-Aug We,Th
10:00-11:30,14:00-19:00;Jul-Aug Fr 10:00-11:30,14:00-21:00;Jul-Aug Su
09:00-12:00,14:00-19:00

Cette syntaxe étant plus facile à générer automatiquement quand on dépasse
une longueur maximale, sans chercher à factoriser des conditions.

Noter enfin que la première sous-règle (en ayant factorisé "Sep-Sun" dans
le tag de base) n'est pas non plus facilement factorisable par heure de la
journée (c'est presque illisible et c'est même plus long!):
opening_hours:1=Su 09:30-11:30;Su-Fr 11:30-12:30;Mo,Th-Fr 12:30-13:30;Mo-Th
13:30-14:00;We-Sa 14:00-14:15;Sa 14:15-15:00;Sa-Su 15:00-16:45;Sa-Su,Tu
16:45-17:30;Fr-Su,Tu 17:30-18:00;Tu,Fr 18:00-20:15;Tu 20:15-21:00
Bref pas de solution de ce côté-là, on n'arrivera pas à tout combiner sans
une seule règle...



Le 26 juillet 2017 à 14:37, Philippe Verdy  a écrit :

> D'une part il y a des espaces en excédent mais ça ne résoud pas le
> problème.
> Comme ce sont des règles indépendantes (séparées par ;) On devrait pouvoir
> les éclater en plusieurs tags (les tags eux-mêmes n'ayant pas d'ordre,
> contrairement aux valeurs séparées par une virgule ',')
>
> Cela suggérerait; en factorisant le sélecteur de mois:
> opening_hours[Sep-Jun]=Mo,Th 11:30-14:00;Tu 11:30-14:00,16:45-21:00;We
> 11:30-14:15;Fr 11:30-13:30,17:30-20:15;Sa 14:00-18:00;Su
> 09:30-12:30,15:00-18:00
> opening_hours[Jul-Aug]=Mo,Sa 14:00-19:00;Tu 10:00-11:30;We,Th
> 10:00-11:30,14:00-19:00;Fr 10:00-11:30,14:00-21:00;Su
> 09:00-12:00,14:00-19:00
>
> Mais dans tous les cas l'éclatement d'une valeur unique demanderait une
> modification des clients. Une autre facon serait d'inclure une partie des
> sélecteurs pour l'associer à une règle dans un autre tag faisant le détail,
> cette syntaxe semblant claire et permettant de ne pas "louper" un
> "opening_hours=*" dans une sélection qui indique expressément qu'on a
> d'autres sous-règles dans des tags déterminés.
>
> opening_hours=Sep-Jun @1;Jul-Aug @2
> opening_hours:1=Mo,Th 11:30-14:00;Tu 11:30-14:00,16:45-21:00;We
> 11:30-14:15;Fr 11:30-13:30,17:30-20:15;Sa 14:00-18:00;Su
> 09:30-12:30,15:00-18:00
> opening_hours:2=Mo,Sa 14:00-19:00;Tu 10:00-11:30;We,Th
> 10:00-11:30,14:00-19:00;Fr 10:00-11:30,14:00-21:00;Su
> 09:00-12:00,14:00-19:00
>
> Bref à discuter et proposer.
>
>
> Le 26 juillet 2017 à 14:07, Charles MILLET  a
> écrit :
>
>> Bonjour,
>>
>> Quelqu'un a-t-il une solution ou une astuce pour décrire des horaires
>> d'ouverture (*opening_hours*) « complexes » qui dépassent 255 caractères
>> ?
>>
>> Pour information il s'agit des ces horaires ; elles décrivent un horaire
>> différent presque chaque jour et pour deux périodes différentes de l'année
>> — Sep-Jun et Jul-Aug :
>>
>> Sep-Jun Mo,Th 11:30-14:00; Sep-Jun Tu 11:30-14:00,16:45-21:00; Sep-Jun We
>> 11:30-14:15; Sep-Jun Fr 11:30-13:30,17:30-20:15; Sep-Jun Sa 14:00-18:00;
>> Sep-Jun Su 09:30-12:30,15:00-18:00; Jul-Aug Mo,Sa 14:00-19:00; Jul-Aug Tu
>> 10:00-11:30; Jul-Aug We,Th 10:00-11:30,14:00-19:00; Jul-Aug Fr
>> 10:00-11:30,14:00-21:00; Jul-Aug Su 09:00-12:00,14:00-19:00
>>
>> Bonne journée !
>>
>> --
>> Charles milletcharlesmil...@free.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] Valeur opening_hours supérieure à 255 caractères


Merci pour vos retours.

J'avais pensé à factoriser mais je pensais aussi  les ";" sont là pour 
marquer des ensembles fermes et que les deux période "Sep-Jun:" et 
"Jul-Aug:" en début de période ne devaient pas être suffisamment explicites.


Par contre effectivement pour es espaces en trop il faudra que je fasse 
attention.


Charles MILLET
charlesmil...@free.fr

Le 26/07/2017 à 14:42, Philippe Verdy a écrit :
C'est une autre façon de "factoriser" les mois, mais cette syntaxe est 
aussi une extension, et je ne suis pas convaincu car le ";" sépare 
TOUS les éléments et rien n'indique que "Sep-Jun:" s'applique comme 
critère à tous ce qui suit mais pas à la partie commençant par 
"Jul:Aug:". (noter encore que les espaces après ";" sont excédentaires)


Je pense que l'éclatement (avec un @ pour référencer une sous-règle) 
donne quelque chose de plus clair et plus facilement maintenable, 
chaque sous-règle restant elle-aussi indépendante indépendamment du 
filtre qu'on lui applique dans une règle "mère".



Le 26 juillet 2017 à 14:35, David Crochet > a écrit :


Bonjour


Le 26/07/2017 à 14:07, Charles MILLET a écrit :

Sep-Jun Mo,Th 11:30-14:00; Sep-Jun Tu 11:30-14:00,16:45-21:00;
Sep-Jun We 11:30-14:15; Sep-Jun Fr 11:30-13:30,17:30-20:15;
Sep-Jun Sa 14:00-18:00; Sep-Jun Su 09:30-12:30,15:00-18:00;
Jul-Aug Mo,Sa 14:00-19:00; Jul-Aug Tu 10:00-11:30; Jul-Aug
We,Th 10:00-11:30,14:00-19:00; Jul-Aug Fr
10:00-11:30,14:00-21:00; Jul-Aug Su 09:00-12:00,14:00-19:00


Sep-Jun: Mo,Th,Tu 11:30-14:00; Tu 16:45-21:00; We 11:30-14:15; Fr
11:30-13:30,17:30-20:15; Sa 14:00-18:00; Su
09:30-12:30,15:00-18:00; Jul-Aug: Mo,Sa,We,Th,Su 14:00-19:00;
We,Th,Fr,Tu 10:00-11:30; Fr 14:00-21:00; Su 09:00-12:00

Cordialement

-- 
David Crochet



___
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] [OSM transport] Projet du mois - arrêts de bus

il est préférable de préciser la source directement sur les objets
eux-mêmes.

Le 26 juillet 2017 à 13:33, djakk djakk  a écrit :

> Oui effectivement j'ai carburé ^^ merci pour le comptage je ne pensais pas
> en avoir fait autant :O
>
> Pour le soucis avec l'imagerie aérienne, je met un "source"='BDOrtho IGN'
> sur l'arrêt de bus créé ou bien le "source" du changeset suffit ? Ou bien
> j'arrête de mapper avec cette technique, laissant le boulot à un mapper
> local ?
>
> Le 26 juillet 2017 à 09:42, Florian LAINEZ  a écrit :
>
>> Warning... les images aériennes ne sont pas forcément de toute fraîcheur
>>> et les arrêts de bus n'ont pas un emplacement immuable, surtout qu'il y en
>>> a pas mal qui font l'objet de travaux pour mise aux normes
>>> d'accessibilité... donc warning ;)
>>>
>>
>> +1
>>
>> Le 25 juillet 2017 à 17:52, Christian Quest  a
>> écrit :
>>
>>> Le 25/07/2017 à 17:29, marc marc a écrit :
>>>
 djakk 200 arrêts trouvé sur imagerie sat en 6 jours ? woaw tu carbures !


>>> Warning... les images aériennes ne sont pas forcément de toute fraîcheur
>>> et les arrêts de bus n'ont pas un emplacement immuable, surtout qu'il y en
>>> a pas mal qui font l'objet de travaux pour mise aux normes
>>> d'accessibilité... donc warning ;)
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>>
>>>
>>>
>>> ___
>>> 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
>>
>>
>
> ___
> 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] Valeur opening_hours supérieure à 255 caractères

C'est une autre façon de "factoriser" les mois, mais cette syntaxe est
aussi une extension, et je ne suis pas convaincu car le ";" sépare TOUS les
éléments et rien n'indique que "Sep-Jun:" s'applique comme critère à tous
ce qui suit mais pas à la partie commençant par "Jul:Aug:". (noter encore
que les espaces après ";" sont excédentaires)

Je pense que l'éclatement (avec un @ pour référencer une sous-règle) donne
quelque chose de plus clair et plus facilement maintenable, chaque
sous-règle restant elle-aussi indépendante indépendamment du filtre qu'on
lui applique dans une règle "mère".


Le 26 juillet 2017 à 14:35, David Crochet  a écrit :

> Bonjour
>
>
> Le 26/07/2017 à 14:07, Charles MILLET a écrit :
>
>> Sep-Jun Mo,Th 11:30-14:00; Sep-Jun Tu 11:30-14:00,16:45-21:00; Sep-Jun We
>> 11:30-14:15; Sep-Jun Fr 11:30-13:30,17:30-20:15; Sep-Jun Sa 14:00-18:00;
>> Sep-Jun Su 09:30-12:30,15:00-18:00; Jul-Aug Mo,Sa 14:00-19:00; Jul-Aug Tu
>> 10:00-11:30; Jul-Aug We,Th 10:00-11:30,14:00-19:00; Jul-Aug Fr
>> 10:00-11:30,14:00-21:00; Jul-Aug Su 09:00-12:00,14:00-19:00
>>
>
> Sep-Jun: Mo,Th,Tu 11:30-14:00; Tu 16:45-21:00; We 11:30-14:15; Fr
> 11:30-13:30,17:30-20:15; Sa 14:00-18:00; Su 09:30-12:30,15:00-18:00;
> Jul-Aug: Mo,Sa,We,Th,Su 14:00-19:00; We,Th,Fr,Tu 10:00-11:30; Fr
> 14:00-21:00; Su 09:00-12:00
>
> Cordialement
>
> --
> David Crochet
>
>
> ___
> 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] Valeur opening_hours supérieure à 255 caractères

D'une part il y a des espaces en excédent mais ça ne résoud pas le problème.
Comme ce sont des règles indépendantes (séparées par ;) On devrait pouvoir
les éclater en plusieurs tags (les tags eux-mêmes n'ayant pas d'ordre,
contrairement aux valeurs séparées par une virgule ',')

Cela suggérerait; en factorisant le sélecteur de mois:
opening_hours[Sep-Jun]=Mo,Th 11:30-14:00;Tu 11:30-14:00,16:45-21:00;We
11:30-14:15;Fr 11:30-13:30,17:30-20:15;Sa 14:00-18:00;Su
09:30-12:30,15:00-18:00
opening_hours[Jul-Aug]=Mo,Sa 14:00-19:00;Tu 10:00-11:30;We,Th
10:00-11:30,14:00-19:00;Fr 10:00-11:30,14:00-21:00;Su
09:00-12:00,14:00-19:00

Mais dans tous les cas l'éclatement d'une valeur unique demanderait une
modification des clients. Une autre facon serait d'inclure une partie des
sélecteurs pour l'associer à une règle dans un autre tag faisant le détail,
cette syntaxe semblant claire et permettant de ne pas "louper" un
"opening_hours=*" dans une sélection qui indique expressément qu'on a
d'autres sous-règles dans des tags déterminés.

opening_hours=Sep-Jun @1;Jul-Aug @2
opening_hours:1=Mo,Th 11:30-14:00;Tu 11:30-14:00,16:45-21:00;We
11:30-14:15;Fr 11:30-13:30,17:30-20:15;Sa 14:00-18:00;Su
09:30-12:30,15:00-18:00
opening_hours:2=Mo,Sa 14:00-19:00;Tu 10:00-11:30;We,Th
10:00-11:30,14:00-19:00;Fr 10:00-11:30,14:00-21:00;Su
09:00-12:00,14:00-19:00

Bref à discuter et proposer.


Le 26 juillet 2017 à 14:07, Charles MILLET  a écrit :

> Bonjour,
>
> Quelqu'un a-t-il une solution ou une astuce pour décrire des horaires
> d'ouverture (*opening_hours*) « complexes » qui dépassent 255 caractères ?
>
> Pour information il s'agit des ces horaires ; elles décrivent un horaire
> différent presque chaque jour et pour deux périodes différentes de l'année
> — Sep-Jun et Jul-Aug :
>
> Sep-Jun Mo,Th 11:30-14:00; Sep-Jun Tu 11:30-14:00,16:45-21:00; Sep-Jun We
> 11:30-14:15; Sep-Jun Fr 11:30-13:30,17:30-20:15; Sep-Jun Sa 14:00-18:00;
> Sep-Jun Su 09:30-12:30,15:00-18:00; Jul-Aug Mo,Sa 14:00-19:00; Jul-Aug Tu
> 10:00-11:30; Jul-Aug We,Th 10:00-11:30,14:00-19:00; Jul-Aug Fr
> 10:00-11:30,14:00-21:00; Jul-Aug Su 09:00-12:00,14:00-19:00
>
> Bonne journée !
>
> --
> Charles milletcharlesmil...@free.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] Valeur opening_hours supérieure à 255 caractères

2017-07-26 Diskussionsfäden David Crochet


Bonjour


Le 26/07/2017 à 14:07, Charles MILLET a écrit :
Sep-Jun Mo,Th 11:30-14:00; Sep-Jun Tu 11:30-14:00,16:45-21:00; Sep-Jun 
We 11:30-14:15; Sep-Jun Fr 11:30-13:30,17:30-20:15; Sep-Jun Sa 
14:00-18:00; Sep-Jun Su 09:30-12:30,15:00-18:00; Jul-Aug Mo,Sa 
14:00-19:00; Jul-Aug Tu 10:00-11:30; Jul-Aug We,Th 
10:00-11:30,14:00-19:00; Jul-Aug Fr 10:00-11:30,14:00-21:00; Jul-Aug 
Su 09:00-12:00,14:00-19:00


Sep-Jun: Mo,Th,Tu 11:30-14:00; Tu 16:45-21:00; We 11:30-14:15; Fr 
11:30-13:30,17:30-20:15; Sa 14:00-18:00; Su 09:30-12:30,15:00-18:00; 
Jul-Aug: Mo,Sa,We,Th,Su 14:00-19:00; We,Th,Fr,Tu 10:00-11:30; Fr 
14:00-21:00; Su 09:00-12:00


Cordialement

--
David Crochet


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

Re: [Talk-es] Bar tradicional -> ¿ amenity=pub o amenity=bar ?

2017-07-26 Diskussionsfäden Miguel Sevilla-Callejo

Hola Daniel,

Lo primero es disculparme si te has sentido ofendido. Ni mucho menos era mi
intención.

Agradezco tus colaboraciones y las valoro como las de los demás aunque no
esté de acuerdo con ellas, como es el caso del hilo que nos ocupa.

Simplemente quería estar seguro que no se hacía una traducción unilateral
de un problema polémico y sin consenso. De hecho, el tema esa abierto en la
lista de tagging, por l oque considero que ni la versión inglesa es
totalmente correcta/consensuada.

Perdón si no me he expresado adecuadamente.

Un saludo

Miguel

--
*Miguel Sevilla-Callejo*
Doctor en Geografía

2017-07-26 12:26 GMT+01:00 dcapillae :

> No entiendo muy bien a qué te refieres ni por qué haces una referencia
> personal. El wiki es un espacio colaborativo, todo el mundo lo puede
> editar.
>
> ¿Que si he traducido yo esa página? Sí, he traducido muchas páginas del
> wiki. ¿Cómo? Como he podido, dedicándole tiempo y esfuerzo, pensando
> únicamente en el bien de la comunidad hispana. ¿Traducciones con consenso?
> La versión de referencia para el wiki suele ser la versión en inglés, a
> veces la versión en alemán o en otro idioma. Siempre intento ser fiel al
> original, a veces incluso tan fiel que la traducción no suena bien en
> español, pero lo prefiero así. ¿Que está mal traducido? Pues se corrige. Si
> no he acertado a traducirlo todo lo bien que se podría, pido disculpas.
> Entiendo que no hace falta señalarme por ello.
>
> El wiki es un trabajo colaborativo, si algo está mal, se puede corregir. No
> necesitas mi permiso ni el de nadie para corregirlo. También puedes añadir
> un enlace a este hilo si lo consideras oportuno.
>
> No quiero disgustarme contigo, Miguel. Últimamente no hago más que recibir
> críticas por traducir el wiki. Pensaba que estaba haciendo un bien. Por
> suerte algunos colaboradores lo entienden así y me lo agradecen de vez en
> cuando. No lo hago para que nadie me lo agradezca, pero tampoco para que
> nadie me señale por ello.
>
>
>
> -
> Daniel Capilla
> OSM user: dcapillae
> --
> View this message in context: http://gis.19327.n8.nabble.
> com/Bar-tradicional-amenity-pub-o-amenity-bar-tp5876448p5899787.html
> Sent from the Spain mailing list archive at Nabble.com.
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

[OSM-talk-fr] Valeur opening_hours supérieure à 255 caractères


Bonjour,

Quelqu'un a-t-il une solution ou une astuce pour décrire des horaires 
d'ouverture (/opening_hours/) « complexes » qui dépassent 255 caractères ?


Pour information il s'agit des ces horaires ; elles décrivent un horaire 
différent presque chaque jour et pour deux périodes différentes de 
l'année — Sep-Jun et Jul-Aug :


Sep-Jun Mo,Th 11:30-14:00; Sep-Jun Tu 11:30-14:00,16:45-21:00; Sep-Jun 
We 11:30-14:15; Sep-Jun Fr 11:30-13:30,17:30-20:15; Sep-Jun Sa 
14:00-18:00; Sep-Jun Su 09:30-12:30,15:00-18:00; Jul-Aug Mo,Sa 
14:00-19:00; Jul-Aug Tu 10:00-11:30; Jul-Aug We,Th 
10:00-11:30,14:00-19:00; Jul-Aug Fr 10:00-11:30,14:00-21:00; Jul-Aug Su 
09:00-12:00,14:00-19:00


Bonne journée !

--
Charles MILLET
charlesmil...@free.fr

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

Re: [Talk-br] Nova divisão territorial substitui mesorregiões e microrregiões

2017-07-26 Diskussionsfäden Nelson A. de Oliveira

2017-07-26 6:42 GMT-03:00 Sérgio V. :
> Pelo que entendi, então, quanto às MESO e MICRO regiões, colocadas no OSM
> como "admin_level", não faz o menor sentido tê-las no OSM.

Cuidado:
https://lists.openstreetmap.org/pipermail/talk-br/2016-May/011328.html

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

Re: [OSM-talk-fr] [OSM transport] Projet du mois - arrêts de bus

2017-07-26 Diskussionsfäden djakk djakk

Oui effectivement j'ai carburé ^^ merci pour le comptage je ne pensais pas
en avoir fait autant :O

Pour le soucis avec l'imagerie aérienne, je met un "source"='BDOrtho IGN'
sur l'arrêt de bus créé ou bien le "source" du changeset suffit ? Ou bien
j'arrête de mapper avec cette technique, laissant le boulot à un mapper
local ?

Le 26 juillet 2017 à 09:42, Florian LAINEZ  a écrit :

> Warning... les images aériennes ne sont pas forcément de toute fraîcheur
>> et les arrêts de bus n'ont pas un emplacement immuable, surtout qu'il y en
>> a pas mal qui font l'objet de travaux pour mise aux normes
>> d'accessibilité... donc warning ;)
>>
>
> +1
>
> Le 25 juillet 2017 à 17:52, Christian Quest  a
> écrit :
>
>> Le 25/07/2017 à 17:29, marc marc a écrit :
>>
>>> djakk 200 arrêts trouvé sur imagerie sat en 6 jours ? woaw tu carbures !
>>>
>>>
>> Warning... les images aériennes ne sont pas forcément de toute fraîcheur
>> et les arrêts de bus n'ont pas un emplacement immuable, surtout qu'il y en
>> a pas mal qui font l'objet de travaux pour mise aux normes
>> d'accessibilité... donc warning ;)
>>
>> --
>> Christian Quest - OpenStreetMap France
>>
>>
>>
>> ___
>> 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
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-lt] Lankytinų vietų kolekcionavimas

2017-07-26 Diskussionsfäden Tomas Straupis

Netyčia gūglės žymėtojų pokalbyje išsprūdo, kad visi Karolio
(lietuvon.lt) duomenys - atviri, galima naudoti į sveikatą.
Tai galima bus padaryti palyginimą Lietuvon vs OSM :-)

https://plus.google.com/u/0/+MariusKarotkis/posts/BWYne8zur7q?cfem=1

P.S. Rytoj 18:00 Valstybiniame turizmo informacijos centre bus
pristatoma svetainė pamatyklietuvoje.lt
https://places.openmap.lt/#m=18/25.31/54.7/t/T

-- 
Tomas

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

Re: [Talk-es] Bar tradicional -> ¿ amenity=pub o amenity=bar ?

2017-07-26 Diskussionsfäden Miguel Sevilla-Callejo

Hola,

Vuelvo a este tema con un mes de retraso y quería comentar un par de cosas:

Por favor, releer el hilo desde el principio, yo ya expresé claramente mi
posición y parece que sigue sin haber consenso entre algunos editores.

Me releo con un mes de retraso la discusión de pub/bar y me pregunto si
@dcapillae ha traducido y cómo la wiki?

Por favor, cuidado con hacer traducciones sin consenso, creo que hay que
poner BIEN CLARO que NO hay consenso en el uso de esos términos. Es más,
para la traducción al español habría uqe incluir un enlace a este hilo.

Yo, directamente abriría un debate, junto con los colegas latinos (esto ya
lo hemos tratado en el el grupo de Telegram) para proponer etiquetas
adicionales, por ejemplo, en México, con la pulquerías.

Un saludo

Miguel


--
*Miguel Sevilla-Callejo*
Doctor en Geografía

2017-06-22 19:10 GMT+01:00 Alan Grant :

> Hola Daniel,
>
> Entiendo perfectamente, a mi también me ha parecido lo bastante
> interesante para preguntar en el otro foro. Cuando digo que "no tiene
> importancia" no quiero decir que no vale la pena hablar del tema.
>
> Para contrastar con otro ejemplo: he encontrado varias centros comerciales
> en España etiquetados como "landuse=commercial". Los he cambiado a
> "landuse=retail", porque en este caso me parece totalmente claro en el wiki
> que "retail" es para tiendas y comercial para oficinas (o otros negocios
> que no son tiendas). La casualidad que la palabra "comercial" parece a
> "commercial" no cambia eso.
>
> En cambio la diferencia entre "pub" y "bar" me parece tan poco preciso que
> he llegado a la misma conclusion, que no vale la pena modificar las
> etiquetas existentes. Creo para realmente mejorar este aspecto de OSM
> tendríamos que empezar mejorando el wiki inglés (por ejemplo con más fotos
> con explicaciones claras de porque corresponden a una o otra de las
> etiquetas).
>
>
>
>
>
>
>
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-br] Nova divisão territorial substitui mesorregiões e microrregiões

2017-07-26 Diskussionsfäden Sérgio V .

Puxa, ótimo ter colocado isto Leonardo.
Pelo que entendi, então, quanto às MESO e MICRO regiões, colocadas no OSM como 
"admin_level", não faz o menor sentido tê-las no OSM.

Segundo as respostas do IBGE, isto não estaria certo, nem do ponto de vista 
legal, nem do prático:
-Do ponto de vista legal: elas não possuem caráter administrativo. Não são 
"admin".
-Do ponto de vista prático: não existe nada que obrigue atividade prática entre 
os membros das regiões, e se há atividade prática, não depende diretamente do 
estatuto das regiões.

Melhor então seria remover do OSM (somente) todas estas relações de meso e 
micro (sem mexer nos ways).
E sobretudo não mapear mais as novas "Regiões Geográficas Imediatas e 
Intermediárias".
Isto acaba com a trabalheira inútil de tê-las (e mais ainda de mantê-las) no 
OSM.
Ajuda a focar no que realmente interessa para estar no OSM.

- - - - -

--- Resposta do IBGE ---

..."Criadas pelo IBGE, as Microrregiões e Mesorregiões são utilizadas apenas 
para fins estatísticos. Não se constituem em entidades político-administrativas 
autônomas, não possuem qualquer instituição administrativa e nem previsão 
constitucional."...
..."Os "agrupamentos" dos estados são regionalizações que visam a organização, 
o planejamento e a execução de funções públicas. Não podendo ser definidos como 
regiões político-administrativas."...


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-at] Jagdhütten

2017-07-26 Diskussionsfäden grubernd


On 2017-07-26 06:26, Friedrich Volkmann wrote:
Welches Vordach? Die Stelle links unter der Stiege oder die Stelle 
rechts mit der Bank? Die sind doch beide nicht mehr als 1m überdeckt! So 
was willst du doch nicht ernsthaft als Shelter taggen? Da müssten wir in 
Wien hunderttausende Shelters mappen, denn 1m Überstand hat so gut wie 
jedes Haus irgendwo.


du meinst so wie die ganzen Bushaltestellenhütterln? ja. bitte.

ich wünsche dir, dass du oder ein dir nahestehender Mensch _niemals_ 
auch nur annähernd in die Situation kommst wo ein 1 Meter breites 
Vordach den Unterschied zwischen ein paar ungemütlichen Stunden und dem 
Tod durch Unterkühlung ausmacht.


im Gebirge können solche Schutzplätze in der Karte aber genau diesen 
Unterschied machen.



grüsse,
grubernd

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

Re: [OSM-talk-be] CRAB-adressen met underscore

2017-07-26 Diskussionsfäden Sus Verhoeven

Hooi Glenn,

Bedankt voor de aanpassing.
Wordt er nog iets gedaan aan de aanpassing voor de validatie van de
huisnummers met een underscore ?

Sus

2017-07-25 12:47 GMT+02:00 Glenn Plas :

> Fixed in new aptum release:
>
> testcase:
>
> http://aptum.bitless.be/?pcode=2100=Van%
> 20Amstelstraat*=true=
>
> Er zijn veel fouten rechtgezet denk ik, laat weten als er problemen zijn
> met een van de onderstaande straten.
>
>  data/1700.json|   52 +-
>  data/1700/borrestraat02.json  |   76 -
>  data/1700/gemeenteplein01.json|  156 -
>  data/1700/kapelleveld02.json  |   43 -
>  data/1700/kasteelstraat02.json|  770 -
>  data/1700/kerkstraat01.json   |   16 -
>  data/1700/kerkstraat02.json   |   16 -
>  data/1700/kerkstraat03.json   |  539 
>  data/1700/marktplein02.json   |   16 -
>  data/1700/oudstrijdersstraat02.json   |  876 -
>  data/1700/potaardestraat01.json   |   28 -
>  data/1700/poverstraat01.json  |  538 
>  data/1700/rozenlaan01.json|  444 ---
>  data/1700/stationsstraat01.json   | 1702 --
>  data/1701.json|8 +-
>  data/1701/kerkstraat02.json   |  798 -
>  data/1701/poverstraat02.json  |  460 ---
>  data/1702.json|   24 +-
>  data/1702/breugelweg01.json   |   16 -
>  data/1702/gemeenteplein02.json|   28 -
>  data/1702/kerkweg02.json  |   55 -
>  data/1702/rozenlaan02.json|  165 -
>  data/1702/stationsstraat01.json   |   28 -
>  data/1702/stationsstraat02.json   |  431 ---
>  data/1703.json|   28 +-
>  data/1703/kapelleveld01.json  |   88 -
>  data/1703/kasteelstraat01.json|  112 -
>  data/1703/kerkstraat01.json   |   78 -
>  data/1703/kerkweg01.json  |  277 --
>  data/1703/marktplein01.json   |  355 ---
>  data/1703/oudstrijdersstraat01.json   |  388 ---
>  data/1703/potaardestraat02.json   |  443 ---
>  data/1850.json|4 +-
>  data/1850/lintbaan02.json |  348 --
>  data/1852.json|4 +-
>  data/1852/lintbaan01.json |   16 -
>  data/2000.json|   16 +-
>  data/2000/bredestraatan.json  |  588 
>  data/2000/fortuinstraatan.json|  404 ---
>  data/2000/kloosterstraatan.json   | 2296 -
>  data/2000/sintrochusstraatan.json |  389 ---
>  data/2018.json|   24 +-
>  data/2018/isabellaleian.json  | 2256 -
>  data/2018/mariahenrittaleian.json |  219 --
>  data/2018/mariatheresialeian.json |  311 --
>  data/2018/molenstraatan.json  | 1120 ---
>  data/2018/statiestraatan.json |  591 
>  data/2018/vestingstraatan.json| 1027 --
>  data/2020.json|8 +-
>  data/2020/boomsesteenwegan.json   | 2360 --
>  data/2020/dennenlaananwi.json |  256 --
>  data/2030.json|4 +-
>  data/2030/hermanvosstraatan.json  |  270 --
>  data/2040.json|   20 +-
>  data/2040/bosstraatan.json| 1168 ---
>  data/2040/dorpstraatbzl.json  | 1450 -
>  data/2040/heidestraatbzl.json | 1055 --
>  data/2040/kapelstraatbzl.json |  371 ---
>  data/2040/vestingstraatbzl.json   |   19 -
>  data/2060.json|8 +-
>  data/2060/groenstraatanbo.json|  175 -
>  data/2060/veldstraatan.json   | 1355 
>  data/2100.json|   20 +-
>  data/2100/heirmanstraatde.json|   88 -
>  data/2100/krijgsbaande.json   |   55 -
>  data/2100/sintrochusstraatde.json | 2280 -
>  data/2100/turnhoutsebaande.json   | 3905 ---
>  data/2100/vanamstelstraatde.json  | 2235 -
>  data/2140.json|   32 +-
>  data/2140/beekstraatbo.json   |  531 ---
>  data/2140/groenstraatanbo.json|  790 -
>  data/2140/hogewegbo.json  |  758 -
>  data/2140/kattenbergbo.json   | 1529 -
>  data/2140/laarbo.json |  924 --
>  data/2140/turnhoutsebaanbo.json   | 5678
>  data/2140/vaderlandstraatbo.json  |  563 
>  data/2140/weerstandlaanbo.json|  880 -
>  data/2170.json|8 +-
>  data/2170/heirmanstraatme.json|  872 -
>  data/2170/ringlaanme.json | 2258 -
>  data/2180.json|   84 +-
>  data/2180/antverpiastraatek.json  |  136 -
>  data/2180/beekstraatek.json   |  352 --
>  data/2180/berkenlaanek.json   |  208 --
>  data/2180/bistek.json | 1636 --
>  data/2180/bosstraatek.json|  895 --
>

Re: [OSM-talk-fr] Ce soir j'ai décidé de publier un livre...

Salut Fred,
C'est un énorme boulot que tu as fait là. Quel dommage qu'il n'ai pas été
publié à l'époque. Quelles en sont les raisons ? Tu as des plans pour
l'updater et le publier ?

Le 25 juillet 2017 à 00:04, Frédéric Rodrigo  a
écrit :

> Salut,
>
> C'est l'ébauche d'un livre en français sur OpenStreetMap.
>
> Ce contenu a été réalisé en 2010-2011. Ce livre n'est pas terminé, il
> contient 11 chapitres (pas toujours complets) sur les 16 initialement
> prévus.
>
> https://github.com/frodrigo/openstreetmap-livre
>
>
> Il montre des cartes que l'on n'oserait même plus regarder, parle
> d'OpenData comme d'un défit à relever, compare des licences qui n'existent
> même plus, explore Potlatch ou encore l'XAPI.
> Mais il parle aussi de choses qui non pas changées, de concepts,
> d'approches, d'introduction, de fonctionnement et de l'histoire du GPS, de
> comment organiser une carto-partie et plein de références et de liens.
>
> Ce contenu est placé sous licence Creative Commons Attribution / Partage
> dans les mêmes conditions (CC-By-SA-4.0)
> Frédéric Rodrigo - CC-By-SA-4.0 © 2010-2011
>
> Frédéric.
>
>
>
> ___
> 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] [OSM transport] Projet du mois - arrêts de bus