Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

2020-05-26 Par sujet Philippe Verdy 
J'ai bien compris la role de 'layer" mais ça ne fonctionne pas dans la
formule publiée où ce n'est qu'un facteur d'échelle: layer=2 multiplie les
id retournés par 2 mais un id=2 créé par une telle valeur de layer entre en
collision avec l'id=1 pour un autre noeud situé ailleurs sur la carte à la
précision donnée.
Ce n'est donc PAS une multiplication mais une addition (d'une constante)
qu'il faut faire pour séparer les id's de noeuds sur des layers différents.
Chaque layer numérote ses noeuds sur une grille N*N correspondant aux
latitudes/longitudes arrondies au facteur de zoom près, il faut donc bien
*ajouter* (layer*N*N). Ici N=2^zoom et c'est le zoom ici qui tient lieu de
niveau de précision (avec zoom=0, la grille N*N ne fait que 1*1 et se
réduit à 1 point pour toute la planète positionné à la longitude 0 et la
latitude 0, donc sur sur l'équateur et le Méridien de Greenwich, légèrement
décalé dans WGS84, ce point étant dans le Golfe de Guinée à l'ouest de
l'Afrique centrale). Avec le zoom=1 on a 4 points sur la planisphère WGS84
mais 2 des points sont au pole sud, le troisième est l'antipode du premier
point aussi sur l'équateur. Les points de la grille délimitent à chaque
fois 4 carreaux divisant le premier en parties égales en surface et en
côtés sur la planisphère.

Le facteur d'échelle (2^zoom) est ce qui est classiquement utilisé sur OSM,
chaque zoom supplémentaire divisant l'angle total de 360° (en longitude
comme en latitude) par 2.

La niveau de zoom 8 correspond à une précision légèrement supérieure à 1
degré (on peut aussi le traduire en distance grâce au rayon moyen de la
Terre pour une distance mesurée sur un géoïde parfaitement sphérique, ce
que la Terre n'est évidemment pas à sa surface étant donné sa forme
ovoïdale aplatie aux pôles et le relief, c'est pour ça qu'on parle juste de
rayon moyen et sur OSM on retient une moyenne mesurée sur le plan de
l'équateur au niveau moyen de la mer, ou bien la longueur totale de
l'équateur, soit environ 10 000 km pour ses 90° de longitude sur un quart
de l'équateur)

De fait pas besoin du paramètre "précision", "zoom" en tient lieu.

La combinaison de latitude et longitude en un seul entier peut se faire de
deux façon:
* avec la fonction ST_QUAD (par entrelacement alterné des bits de longitude
et latitude), qui existe déjà dans la base PostGIS que tu utilises et qui
sert déjà pour indexer les recherches par coordonnées proches au sein d'un
même carreau et permet de définir un intervalle carré englobant le point
cherché;
* ou en multipliant une des coordonnées par la borne supérieure (non
incluse) de l'autre coordonnée, donc (2^zoom), et non pas une
multiplication par un "nombre premier supérieur à 10^précision"; le
nombre premier n'apporte rien, plus facile à calculer mais pas pratique
pour indexer les coordonnées 2D car cela divise la carte en bandes
ultrafines avec de nombreux points faisant tout le tour de la Terre avant
le point proche de la bande suivante ou précédente.

L'anomalie que j'ai signalée concerne justement le facteur "layer"
(utiliser un nombre premier > 10^précision dans la formule initiale marche,
mais la restriction aux premiers ne sert à rien et le nombre=10^precision
marche aussi donc pas besoin de ">").


Le mar. 26 mai 2020 à 19:30, François Lacombe  a
écrit :

> Philippe, je crois que tu ne comprends pas.
>
> Le mar. 26 mai 2020 à 17:24, Philippe Verdy  a écrit :
>
>> Justement j'ai proposé un patch, pas juste exposé les problèmes. C'est
>> nécessaire pour éviter que ce code maintenant publié soit utilisé tel quel
>> sans correction au risque d'importer des géométries farfelues, car un tel
>> script peut servir à faire des imports en masse sans trop regarder...
>>
>
> Proposer un patch de cette façon en l'assortissant de phrases buttoir
> n'apporte rien et surtout décourage d'autres de publier leur contribution,
> si c'est pour avoir à faire à ce genre de discours.
> Personne n'a parlé d'import dans OSM. Les cas d'usage proposés étaient
> d'utiliser certains logiciels, en particulier osrm, avec des données qui ne
> viennent pas d'OSM.
>
> Mon utilisation est certainement trop limitée pour avoir vu le problème
> des antipodes.
> Que le code soit perfectible, certes. On ne va quand même pas attendre
> qu'il soit parfait pour le publier?
> Tu ne semble pas avoir compris pourquoi les layers avaient été introduits
> ici. Quand on combine plusieurs jeux de données, des nœuds peuvent se
> trouver au même endroit sans devoir être fusionnés.
>
> +1 avec Adrien et Jérôme, j'ai tout simplement pas envie de regarder la
> suite.
>
> François
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

2020-05-26 Par sujet François Lacombe 
Philippe, je crois que tu ne comprends pas.

Le mar. 26 mai 2020 à 17:24, Philippe Verdy  a écrit :

> Justement j'ai proposé un patch, pas juste exposé les problèmes. C'est
> nécessaire pour éviter que ce code maintenant publié soit utilisé tel quel
> sans correction au risque d'importer des géométries farfelues, car un tel
> script peut servir à faire des imports en masse sans trop regarder...
>

Proposer un patch de cette façon en l'assortissant de phrases buttoir
n'apporte rien et surtout décourage d'autres de publier leur contribution,
si c'est pour avoir à faire à ce genre de discours.
Personne n'a parlé d'import dans OSM. Les cas d'usage proposés étaient
d'utiliser certains logiciels, en particulier osrm, avec des données qui ne
viennent pas d'OSM.

Mon utilisation est certainement trop limitée pour avoir vu le problème des
antipodes.
Que le code soit perfectible, certes. On ne va quand même pas attendre
qu'il soit parfait pour le publier?
Tu ne semble pas avoir compris pourquoi les layers avaient été introduits
ici. Quand on combine plusieurs jeux de données, des nœuds peuvent se
trouver au même endroit sans devoir être fusionnés.

+1 avec Adrien et Jérôme, j'ai tout simplement pas envie de regarder la
suite.

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

Re: [OSM-talk-fr] Restaurant d'entreprise

2020-05-26 Par sujet Christian Rogel 
> Le 26 mai 2020 à 10:53, Florian LAINEZ  a écrit :
> De mon point de vue access=private 
>  
> retranscrit bien ce qui est documenté dans le wiki : l'accès est autorisé 
> seulement sur autorisation individuelle.
> Si le restaurant est inter-entreprise, cela fonctionne tout de même. Je pense 
> que même s'il est ouvert aux externes avec un plein tarif, cela fonctionne 
> car ces personnes sont souvent l'exception et nécessitent une autorisation 
> (ou une simple invitation / être accompagné) : c'est bien une autorisation 
> individuelle.
> Au contraire, access=destination se base sur la destination : cela ne me 
> paraît adapté qu'aux véhicules sur une voie et pas vraiment aux personnes qui 
> vont se restaurer.


La discussion en cours sur la liste internationale à propos de l’extension de 
la page https://wiki.openstreetmap.org/wiki/Key:access
montre que la clé access est utlisée quasi-exclusivement comme le permission 
d’être présent physiquement dans un lieu.

Dans le paragraphe Facility restrictions, on lit cependant : «  leisure 
entities , such as leisure 
=sports_centre 
 or leisure 
=playground 
 
where private describes a closed user group e.g. members only or children of a 
particular school. » 

Il y a pourtant une différence conceptuelle d'avec l’autorisation d’accéder à 
la jouissance d’un service.

J’aimerais trouver, si possible, dans l’usage actuel, trouver un autre mot, 
mais, regarder Taginfo n’apporte pas de lumière.
On y trouve un access:condiional , et finalement très peu de customer et 
customers.

Faut-il créer un restaurant:for ? Quelles valeurs ?  employees ? (pas forcèment 
exact) 
cela suppose un service condtionnel comme dans social facility:fo, 
healthcare:for et social centre:for (et library:for 1 item) ,
mais, ne renseigne pas sur le détail des services.


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

Re: [OSM-talk-fr] Restaurant d'entreprise

2020-05-26 Par sujet deuzeffe 

Le 26/05/2020 à 10:53, Florian LAINEZ a écrit :


Le plan B c'est d'utiliser :
  cafeteria=university pour les restaurants universitaires (RU)
  cafeteria=schoolpour les cantines d'écoles
  cafeteria=corporate pour les restaurants d'entreprise

Par contre, j'hésite entre "amenity=restaurant" et
"amenity=fast_food + fast_food=cafeteria". Je suis preneur d'idées
également. Dans les 3 cas ci-dessus, ce sont des self, pas de. 
service à table.


Oui mais non. Je fréquente des RU où le service est aussi proposé à 
table. Et les CROUS font bien la différence entre le RU traditionnel (du 
type self) et les cafet. (du type commande et livraison au comptoir).



On aurait donc :
*  amenity=fast_food*
*  fast_food=cafeteria*
*  access=private
   private=students;employees*ou *cafeteria=university;school;corporate*
*  operator=Sodexo;Elior;Accor;Compass;Restalliance*


CROUS C, commune C, département D, régions R pour les étudiants et les 
scolaires. Oui, les selfs scolaires gérés par le public existent encore.


et si on veut faire le choses bien, on trouve un tag pour préciser 
quelles entreprises peuvent accéder aux restaurants inter-entreprises / 
universités aux restaurants universitaires


Bon courage pour les RU/Cafet. CROUS...

--
deuzeffe - je ne trolle pas, j'informe.

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

Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

2020-05-26 Par sujet Philippe Verdy 
Justement j'ai proposé un patch, pas juste exposé les problèmes. C'est
nécessaire pour éviter que ce code maintenant publié soit utilisé tel quel
sans correction au risque d'importer des géométries farfelues, car un tel
script peut servir à faire des imports en masse sans trop regarder...
J'ai donc proposé une formule corrigée en expliquant, libre à l'auteur d'en
tenir compte, mais au moins ma remarque est publique et d'autres peuvent la
voir dans la liste des correctifs proposés.

Je pense que l'auteur corrigera (il n'est pas obligé de prendre mon patch
tel quel, il y a bien d'autres moyens de calculer un node-id sans prendre
en compte dans l'id les coordonnées réelles, ce qui donne des clés entières
assez élevées, dépassant la capacité d'un entier, même en 64-bits, si on
veut la précision demandée sur OSM)

La précision sur OSM peut monter actuellement au dixième de seconde d'arc
soit 5 décimales environs, mais OSM peut monter à 7 décimales pour une
précision centimétrique (qui commence à être utilisée par endroit dans les
zones très denses), bien que les outils GPS n'ont cette précision que pour
les coordonnées satellitaires, mais pas du tout les coordonnées fixes au
sol à cause des déplacements techtoniques non uniformes et autres
déformations géologiques ou érosives du terrain: les différents pays ont
des modèles de coordonnées fixes qui leur sont propres, région par région,
et qui évoluent indépendamment de la précision satellitaire coordonnée au
plan mondial, donc on a de gros doutes sur les précisions centimétriques
valables seulement à certaines dates et qui changent d'année en année, et
OSM ne trace pas non plus les dates des noeuds en fonction de leur source,
mais uniquement en fonction de la date de modif/d'ajout/d'intégration dans
OSM)

Au mieux OSM ne peut donc avoir qu'une précision métrique au plan mondial,
et sinon, sur des zone distances ne dépassant pas quelques kilomètres, une
précision *relative* centimétrique mais non coordonnée de façon aboslue. Et
on n'a pas encore de modèle mondial permettant de cadres précisément tous
les référentiels géographiques locaux ou nationaux et leurs évolutions,
aucun indication du référentiel utilisé dans les noeuds où tous les modèles
des différentes sources et dates sont mélangés. Rien que le RGF légal
français évolue indépendamment du WGS84, et entre les deux les écarts
évoluent en permanence: une partie des données peuvent être précises au
centimètre près, mais on n'a aucun moyen de les délimiter si elles sont
mélangées aux autres toutes aussi précises mais selon un autre référentiel,
ou d'autres moins précises. Le travail de "fusion" consiste à chercher à
plus ou moins les accorder à un instant donné sans garantie que ce sera
stable pour l'avenir. Même les orthophotos évoluent avec l'évolution des
MNT dont la prise en compte n'est pas synchronisée.

OSM ne peut pas y faire grand chose, c'est aux sources de  trouver les
moyens de coordonner leurs modèles et publier les corrections apportées.
avec OSM on fait de notre mieux au milieu de cette variété, seulement pour
que la fusion obtenue soit à peut près conforme à une réalité constatée
localement à un instant donné, mais on ne peut pas stabiliser ces données
mieux qu'avec une précision globale métrique et décimétrique dans les zones
les plus développées suffisamment riches en sources de données qu'on peut
comparer entre elles.


Le mar. 26 mai 2020 à 13:33, PanierAvide  a écrit :

> Ça fait toujours plaisir de bon matin la bienveillance de la communauté du
> libre ;-) Les bonnes pratiques : d'abord le positif, ensuite les critiques
> constructives, enfin rester dans la bienveillance et la volonté de proposer
> un logiciel de meilleure qualité pour tous <3
>
> Cordialement,
>
> Adrien P.
>
> Le 26/05/2020 à 13:17, François Lacombe a écrit :
>
> Bonjour Philippe,
>
> Le mar. 26 mai 2020 à 06:52, Philippe Verdy  a écrit :
>
>> Ce code source n'apporte strictement rien.
>>
>
> Merci à toi.
>
> Bonne journée
>
> François
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://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] Restaurant d'entreprise

2020-05-26 Par sujet Christian Rogel 
> Le 26 mai 2020 à 10:53, Florian LAINEZ  a écrit :
> J'aime beaucoup utiliser un même tag pour préciser quel type de personnes 
> peut accéder : private=employees;students. Est-ce que "private" est le bon 
> tag pour ça ? Peut-être.
> Le plan B c'est d'utiliser :
>  cafeteria=university pour les restaurants universitaires (RU)
>  cafeteria=school pour les cantines d'écoles
>  cafeteria=corporate pour les restaurants d’entreprise

C’est en ligne avec la discussion que j’ai initiée sur les bibliothéques 
(national, regional, school, university, depository, etc.). 
Sauf que j’ai mis « internal » pour couvrir les centres de documentation 
internes.
L’accès est spécifié à part avec corporate. Une bibliothèque peut être interne 
et ouverta à diférentes gens.

> Par contre, j'hésite entre "amenity=restaurant" et "amenity=fast_food + 
> fast_food=cafeteria". Je suis preneur d'idées également. Dans les 3 cas 
> ci-dessus, ce sont des self, pas de service à table.
> Le wiki me paraît clair 
>  sur le 
> sujet : "Une cafétéria est un type d'établissement de restauration où il y a 
> peu ou pas de service à table, que ce soit dans un restaurant ou dans un 
> établissement comme une entrepris ou une école."
> A partir du moment où l'on se sert soit-même ce sont donc les tags 
> "amenity=fast_food + fast_food=cafeteria" qu'il faut privilégier (même si 
> cela froisse notre orgueil de français de mettre le mac-do et les restaurants 
> d'entreprises dans la même meta-catégorie).
> 
> On aurait donc :
>   amenity=fast_food
>   fast_food=cafeteria
>   access=private
>   private=students;employees ou cafeteria=university;school;corporate
>   operator=Sodexo;Elior;Accor;Compass;Restalliance


Un restaurant d’entreprise ou un self-service (scolaire, universitaire, 
chaînes) n’est pas un fast-food. Ces derniers sont apparus après
les self-services.

On peut considérer qu’un fast-food est une variante de cafétaria, mais pas 
l’inverse.

La question se résume à distinguer le service au comptoir et le self. On 
considère le service à la place comme celui par défaut dans
un restaurant ou un bar.


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

Re: [OSM-talk-fr] Restaurant d'entreprise

2020-05-26 Par sujet Philippe Verdy 
C'est assez limite pour les restaux d'entreprise indépendants, ne fixant
pas réellement de condition d'accès autre que des tarifs préférentiels pour
certains clients abonnés, que ce soit sous forme de convention de
refacturation à l'entreprise du reliquat non payé par le client, ou un
préachat par l'entreprise, qui promet une fréquentation minimale et
paye forfaitairement en fonction de cela jusqu'à concurrence du maximum
négocié, ou via des formules de type "carte de fidélité", ou même encore
des marges arrières au restaurant qui se font payer avec des tickets
restaurants pour compenser en partie la réduction qui leur est offerte sur
le prix du repas.

En fin de compte il est assez courant que des restos commerciaux
indépendants acceptent de tels accords, ne serait-ce que parce que cela
leur garantie des recettes continues et le maintien de salariés en cuisine
ou pour le service, l'entretien des locaux ou la surveillance et la
sécurité des clients et du personnel, et les autres charges récurrentes
(indépendantes du nombre de couverts servis mais existant su seul fait du
maintien de l'activité et des charges sociales ou fiscales dues). Nombre de
restos, même les plus petits et familiaux, et même avec un seul employé
gérant sur place, ou le seul propriétaire exploitant, ne demandent que ça:
avoir une base de clients réguliers sur laquelle ils peuvent compter.
Peu importe alors la formule proposée avec des accords, le tarif réduit est
négocié en fonction de ce service au menu, ce qui n'empêche pas les ventes
"à la carte" mais plus aléatoires et donc plus chers pour couvrir le risque
pris et les pertes plus importantes (tant que cela reste encore rentable et
que l'exploitant ne perd pas d'argent durablement, sinon il arrêtera le
service de s'endetter alors qu'il devrait pouvoir vivre de son travail).
un resto d'entreprise est donc avant tout une réponse commerciale adaptée à
une demande, il n'y a pas beaucoup de restrictions (hormis les cantines
d'écoles et pour enfants, dont la sécurité doit être assurée).



Le mar. 26 mai 2020 à 10:54, Florian LAINEZ  a écrit :

> Hello,
> Je crois qu'on commence à bien défricher le terrain.
>
> De mon point de vue access=private
> 
> retranscrit bien ce qui est documenté dans le wiki : l'accès est autorisé 
> *seulement
> sur autorisation individuelle*.
> Si le restaurant est inter-entreprise, cela fonctionne tout de même. Je
> pense que même s'il est ouvert aux externes avec un plein tarif, cela
> fonctionne car ces personnes sont souvent l'exception et nécessitent une
> autorisation (ou une simple invitation / être accompagné) : c'est bien une
> autorisation individuelle.
> Au contraire, access=destination se base sur la destination : cela ne me
> paraît adapté qu'aux véhicules sur une voie et pas vraiment aux personnes
> qui vont se restaurer.
>
> J'aime beaucoup utiliser un même tag pour préciser quel type de personnes
> peut accéder : private=employees;students. Est-ce que "private" est le bon
> tag pour ça ? Peut-être.
> Le plan B c'est d'utiliser :
>  cafeteria=university pour les restaurants universitaires (RU)
>  cafeteria=school pour les cantines d'écoles
>  cafeteria=corporate pour les restaurants d'entreprise
>
> Par contre, j'hésite entre "amenity=restaurant" et "amenity=fast_food +
>> fast_food=cafeteria". Je suis preneur d'idées également. Dans les 3 cas
>> ci-dessus, ce sont des self, pas de service à table.
>>
> Le wiki me paraît clair
>  sur le
> sujet : "Une cafétéria est un type d'établissement de restauration où il y
> a peu ou pas de service à table, que ce soit dans un restaurant ou dans un
> établissement comme une entrepris ou une école."
> A partir du moment où l'on se sert soit-même ce sont donc les tags
> "amenity=fast_food + fast_food=cafeteria" qu'il faut privilégier (même si
> cela froisse notre orgueil de français de mettre le mac-do et les
> restaurants d'entreprises dans la même meta-catégorie).
>
> On aurait donc :
> *  amenity=fast_food*
> *  fast_food=cafeteria*
>
> *  access=private  private=students;employees* ou
> *cafeteria=university;school;corporate*
> *  operator=Sodexo;Elior;Accor;Compass;Restalliance*
>
> et si on veut faire le choses bien, on trouve un tag pour préciser quelles
> entreprises peuvent accéder aux restaurants inter-entreprises / universités
> aux restaurants universitaires
>
>
> Le mar. 26 mai 2020 à 08:27, George Kaplan  a
> écrit :
>
>> Bonjour,
>>
>> Je rebondis sur cette proposition pour élargir au cas des cantines
>> scolaires que je vois souvent marquées avec amenity=restaurant. Est-ce
>> qu’on pourrait les marquer de la même façon que ces RIE ?
>>
>> amenity=restaurant
>> access=private
>> private=students
>>
>> George
>>
>> > Le 25 mai 2020 à 18:44, Marc M.  a écrit :
>> >
>> > Bonjour,
>> >
>> > Le 25.05.20 à 16:07, Florian LAINEZ a écrit :
>> >> Hello,
>> >> Je me

Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

2020-05-26 Par sujet Jérôme Seigneuret 
Le mar. 26 mai 2020 à 06:52, Philippe Verdy  a écrit :

> Ce code source n'apporte strictement rien.
>
Ça a le mérite d'être clair!

>
> Pas même sa description qui est fonctionnellement aberrante concernant la
> formule des "node id", un pseudo-hashcode qui n'en est même pas un, qui
> réclame un nombre premier pour encoder le couple de coordonnées alors que
> cela n'a rien à voir et qu'il n'est pas nécessaire du tout que ce soit
> premier, on peut directement utiliser "180*10^precision" à la place de
> "prime" en voyant que les latitudes sont données en degrés entre -90.0
> et +90.0, ou bien  "360*10^precision" si les latitudes ne sont pas
> normalisées à cet intervalle et reboucle chaque méridien avec son
> antiméridien (au quel cas un module 360 suffit sur chacune des deux
> coordonnées à les normaliser "à moitié", sans unifier un point et son
> antipode situé à la même longitude mais à la latitude+180°)
>
>round(mod(lat, 360), precision) + round(mod(lon, 360) , precision) *
> 360*10^precision
>
Le code source est libéré je pense que tu peux proposer quelque chose en ce
sens qui permettrait à la communauté quelque choses de constructif

>
> Les arrondis sont mal exprimés aussi dans la formule originale qui va donc
> confondre une partie de la précision de la longitude en recouvrant des
> points ailleurs à une autre longitude.
>
> [Pour une unification complète des points antipodiques, il faut un test
> d'intervalle pour la latitude modulo 360, pour la ramener à un intervalle
> large de 180°, en ajoutant ou pas 180° à la longitude, selon la parité de
> l'intervalle de latitude, et en remplaçant ou pas la latitude par son
> complémentaire à 180° selon la même parité]. Et je pense même que c'est
> inutile à moins que la base QGis stocke des coordonnées non normalisées
> (avec des latitudes hors de -90.0 à +90.0, même s'il est probable qu'elle
> puisse avoir en revanche des longitudes hors de l'intervalle -180.0 à +180°
> pour la cartographie le long de la ligne de changement de date (aux îles
> Kiribati, aux île Kouryles et à travers la pointe du Kamtchatka en Sibérie
> extrême-orientale, et sinon sur le continent antarctique dans le secteur
> revendiqué par l'Australie).
>
> Et concernant le paramètres "layer" qui multiplie le tout, c'est encore
> plus stupide, sa seule valeur valide est 1, toute autre valeur n'apporte
> rien d'autre qu'un changement d'échelle des ids, sauf la valeur 0 qui rend
> tous les ids générés nuls.
>
Pareillement. Peut-être que ça a une utilité justement pour le projet
originale pour filtrer un niveau d'échelle un peu comme le fait INTERLIS

>
> J'espère qu'une telle formule (totalement fausse) n'a jamais réellement
> été utilisée pour importer des géométries dans OSM!
>
Peut-être que SeFaireConnaitre ... Non je sors

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

Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

2020-05-26 Par sujet PanierAvide 
Ça fait toujours plaisir de bon matin la bienveillance de la communauté 
du libre ;-) Les bonnes pratiques : d'abord le positif, ensuite les 
critiques constructives, enfin rester dans la bienveillance et la 
volonté de proposer un logiciel de meilleure qualité pour tous <3


Cordialement,

Adrien P.

Le 26/05/2020 à 13:17, François Lacombe a écrit :

Bonjour Philippe,

Le mar. 26 mai 2020 à 06:52, Philippe Verdy > a écrit :


Ce code source n'apporte strictement rien.


Merci à toi.

Bonne journée

François

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

Re: [OSM-talk-fr] DCbrain rend publique une partie de son code en open source

2020-05-26 Par sujet François Lacombe 
Bonjour Philippe,

Le mar. 26 mai 2020 à 06:52, Philippe Verdy  a écrit :

> Ce code source n'apporte strictement rien.
>

Merci à toi.

Bonne journée

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

Re: [OSM-talk-fr] Restaurant d'entreprise

2020-05-26 Par sujet Florian LAINEZ 
Mince, je découvre que tous les Flunchs sont tagués amenity=restaurant et
non pas amenity=fast_food : https://overpass-turbo.eu/s/Uoh
Néanmoins certains ont le tag fast_food=cafeteria #Bazarre

On ne fera donc pas l'impasse d'une réflexion plus large de la manière dont
mapper une cafétéria, soit "une chaîne de restauration en libre-service".
Fast-food or not fast-food ? Il faudrait décider pour Flunch, Casino
cafeteria et toutes ces enseignes :
https://fr.wikipedia.org/wiki/Liste_de_cha%C3%AEnes_de_restaurants#France

Le mar. 26 mai 2020 à 10:53, Florian LAINEZ  a écrit :

> Hello,
> Je crois qu'on commence à bien défricher le terrain.
>
> De mon point de vue access=private
> 
> retranscrit bien ce qui est documenté dans le wiki : l'accès est autorisé 
> *seulement
> sur autorisation individuelle*.
> Si le restaurant est inter-entreprise, cela fonctionne tout de même. Je
> pense que même s'il est ouvert aux externes avec un plein tarif, cela
> fonctionne car ces personnes sont souvent l'exception et nécessitent une
> autorisation (ou une simple invitation / être accompagné) : c'est bien une
> autorisation individuelle.
> Au contraire, access=destination se base sur la destination : cela ne me
> paraît adapté qu'aux véhicules sur une voie et pas vraiment aux personnes
> qui vont se restaurer.
>
> J'aime beaucoup utiliser un même tag pour préciser quel type de personnes
> peut accéder : private=employees;students. Est-ce que "private" est le bon
> tag pour ça ? Peut-être.
> Le plan B c'est d'utiliser :
>  cafeteria=university pour les restaurants universitaires (RU)
>  cafeteria=school pour les cantines d'écoles
>  cafeteria=corporate pour les restaurants d'entreprise
>
> Par contre, j'hésite entre "amenity=restaurant" et "amenity=fast_food +
>> fast_food=cafeteria". Je suis preneur d'idées également. Dans les 3 cas
>> ci-dessus, ce sont des self, pas de service à table.
>>
> Le wiki me paraît clair
>  sur le
> sujet : "Une cafétéria est un type d'établissement de restauration où il y
> a peu ou pas de service à table, que ce soit dans un restaurant ou dans un
> établissement comme une entrepris ou une école."
> A partir du moment où l'on se sert soit-même ce sont donc les tags
> "amenity=fast_food + fast_food=cafeteria" qu'il faut privilégier (même si
> cela froisse notre orgueil de français de mettre le mac-do et les
> restaurants d'entreprises dans la même meta-catégorie).
>
> On aurait donc :
> *  amenity=fast_food*
> *  fast_food=cafeteria*
>
> *  access=private  private=students;employees* ou
> *cafeteria=university;school;corporate*
> *  operator=Sodexo;Elior;Accor;Compass;Restalliance*
>
> et si on veut faire le choses bien, on trouve un tag pour préciser quelles
> entreprises peuvent accéder aux restaurants inter-entreprises / universités
> aux restaurants universitaires
>
>
> Le mar. 26 mai 2020 à 08:27, George Kaplan  a
> écrit :
>
>> Bonjour,
>>
>> Je rebondis sur cette proposition pour élargir au cas des cantines
>> scolaires que je vois souvent marquées avec amenity=restaurant. Est-ce
>> qu’on pourrait les marquer de la même façon que ces RIE ?
>>
>> amenity=restaurant
>> access=private
>> private=students
>>
>> George
>>
>> > Le 25 mai 2020 à 18:44, Marc M.  a écrit :
>> >
>> > Bonjour,
>> >
>> > Le 25.05.20 à 16:07, Florian LAINEZ a écrit :
>> >> Hello,
>> >> Je me demande comment mapper un restaurant d'entreprise,
>> >> c'est à dire une cantine uniquement accessible aux salariés.
>> >> Pour l'instant j'ai utilisé
>> >> amenity=restaurant
>> >> access=private
>> >> qu'en pensez-vous ?
>> >
>> > cela me semble convenir.
>> > éventuelement en rajoutant private=employees qui a la fois
>> > évite que quelqu'un pense que c'est une erreur et décrit
>> > qui y a accès.
>> >
>> >> Je n'ai pas trouvé quoi que ce soit sur le wiki,
>> >
>> > https://wiki.openstreetmap.org/wiki/Tag:access%3Dprivate
>> > liste le cas des parking pour employés,
>> > tu peux éventuelement rajouter le cas du resto
>> >
>> >> il faudrait préciser les possibilités d'accès
>> >
>> > Mais tous ne sont pas interdit aux non employés.
>> >
>> > Cordialement,
>> > Marc
>> >
>> > ___
>> > 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 
>


-- 

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

Re: [OSM-talk-fr] Restaurant d'entreprise

2020-05-26 Par sujet Florian LAINEZ 
Hello,
Je crois qu'on commence à bien défricher le terrain.

De mon point de vue access=private

retranscrit bien ce qui est documenté dans le wiki : l'accès est
autorisé *seulement
sur autorisation individuelle*.
Si le restaurant est inter-entreprise, cela fonctionne tout de même. Je
pense que même s'il est ouvert aux externes avec un plein tarif, cela
fonctionne car ces personnes sont souvent l'exception et nécessitent une
autorisation (ou une simple invitation / être accompagné) : c'est bien une
autorisation individuelle.
Au contraire, access=destination se base sur la destination : cela ne me
paraît adapté qu'aux véhicules sur une voie et pas vraiment aux personnes
qui vont se restaurer.

J'aime beaucoup utiliser un même tag pour préciser quel type de personnes
peut accéder : private=employees;students. Est-ce que "private" est le bon
tag pour ça ? Peut-être.
Le plan B c'est d'utiliser :
 cafeteria=university pour les restaurants universitaires (RU)
 cafeteria=school pour les cantines d'écoles
 cafeteria=corporate pour les restaurants d'entreprise

Par contre, j'hésite entre "amenity=restaurant" et "amenity=fast_food +
> fast_food=cafeteria". Je suis preneur d'idées également. Dans les 3 cas
> ci-dessus, ce sont des self, pas de service à table.
>
Le wiki me paraît clair
 sur le
sujet : "Une cafétéria est un type d'établissement de restauration où il y
a peu ou pas de service à table, que ce soit dans un restaurant ou dans un
établissement comme une entrepris ou une école."
A partir du moment où l'on se sert soit-même ce sont donc les tags
"amenity=fast_food + fast_food=cafeteria" qu'il faut privilégier (même si
cela froisse notre orgueil de français de mettre le mac-do et les
restaurants d'entreprises dans la même meta-catégorie).

On aurait donc :
*  amenity=fast_food*
*  fast_food=cafeteria*

*  access=private  private=students;employees* ou
*cafeteria=university;school;corporate*
*  operator=Sodexo;Elior;Accor;Compass;Restalliance*

et si on veut faire le choses bien, on trouve un tag pour préciser quelles
entreprises peuvent accéder aux restaurants inter-entreprises / universités
aux restaurants universitaires


Le mar. 26 mai 2020 à 08:27, George Kaplan  a
écrit :

> Bonjour,
>
> Je rebondis sur cette proposition pour élargir au cas des cantines
> scolaires que je vois souvent marquées avec amenity=restaurant. Est-ce
> qu’on pourrait les marquer de la même façon que ces RIE ?
>
> amenity=restaurant
> access=private
> private=students
>
> George
>
> > Le 25 mai 2020 à 18:44, Marc M.  a écrit :
> >
> > Bonjour,
> >
> > Le 25.05.20 à 16:07, Florian LAINEZ a écrit :
> >> Hello,
> >> Je me demande comment mapper un restaurant d'entreprise,
> >> c'est à dire une cantine uniquement accessible aux salariés.
> >> Pour l'instant j'ai utilisé
> >> amenity=restaurant
> >> access=private
> >> qu'en pensez-vous ?
> >
> > cela me semble convenir.
> > éventuelement en rajoutant private=employees qui a la fois
> > évite que quelqu'un pense que c'est une erreur et décrit
> > qui y a accès.
> >
> >> Je n'ai pas trouvé quoi que ce soit sur le wiki,
> >
> > https://wiki.openstreetmap.org/wiki/Tag:access%3Dprivate
> > liste le cas des parking pour employés,
> > tu peux éventuelement rajouter le cas du resto
> >
> >> il faudrait préciser les possibilités d'accès
> >
> > Mais tous ne sont pas interdit aux non employés.
> >
> > Cordialement,
> > Marc
> >
> > ___
> > 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] Restaurant d'entreprise

2020-05-26 Par sujet George Kaplan 
Bonjour,

Je rebondis sur cette proposition pour élargir au cas des cantines scolaires 
que je vois souvent marquées avec amenity=restaurant. Est-ce qu’on pourrait les 
marquer de la même façon que ces RIE ?

amenity=restaurant
access=private
private=students

George

> Le 25 mai 2020 à 18:44, Marc M.  a écrit :
> 
> Bonjour,
> 
> Le 25.05.20 à 16:07, Florian LAINEZ a écrit :
>> Hello,
>> Je me demande comment mapper un restaurant d'entreprise, 
>> c'est à dire une cantine uniquement accessible aux salariés.
>> Pour l'instant j'ai utilisé
>> amenity=restaurant
>> access=private
>> qu'en pensez-vous ?
> 
> cela me semble convenir.
> éventuelement en rajoutant private=employees qui a la fois
> évite que quelqu'un pense que c'est une erreur et décrit
> qui y a accès.
> 
>> Je n'ai pas trouvé quoi que ce soit sur le wiki,
> 
> https://wiki.openstreetmap.org/wiki/Tag:access%3Dprivate
> liste le cas des parking pour employés,
> tu peux éventuelement rajouter le cas du resto
> 
>> il faudrait préciser les possibilités d'accès
> 
> Mais tous ne sont pas interdit aux non employés.
> 
> Cordialement,
> Marc
> 
> ___
> 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