Re: [OSM-talk-fr] Rapprochement des adresses OSM et FANTOIR

[rainerU]

Merci Vincent. J'ai vérifie et tout semble ok à présent.

Rainer

Am 03.04.2018 um 15:06 schrieb Vincent de Château-Thierry:

Bonjour,

Le 04/03/2018 à 16:58, rainerU a écrit :


Il y a dix jours, j'ai ajouté des adresses à Perpignan mais aujourd'hui encore 
ces adressent restent en source=C+O dans le fichier bano-66.csv et 
n'apparaissent pas en vert sur le rendu BANO. Exemple :


http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/42.69586/2.90604

Les adresses des rues au nord de l'avenue Mermoz, ajoutées en 2014, sont 
marquées source=OSM dans le fichier data et apparaissent en vert sur le rendu. 
Ce n'est pas le cas pour les adresses des rues côté sud que j'ai ajoutées le 
21/03/18. Y a-t-il une explication pour cette différence ou un blocage dans la 
génération des fichiers ?


Rainer, toutes mes excuses pour le délai de réponse.
L'anomalie que tu soulignais est normalement corrigée désormais. Elle était liée 
à un bug sur le traitement des suffixes (la commune de Perpignan est concernée) 
qui faisait en cascade planter toutes les mises à jour de la commune.


=> https://github.com/osm-fr/bano/issues/146

vincent

___
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] Import station essence

[Stéphane Péneau]

Bonsoir,

Voilà où on en est. S'il n'y a pas d'objections, je posterai le message 
demain :


tl;dr
The French community has reviewed this proposed import but refuses it
as is, for various reasons listed below.

- A lot of "new" amenity=fuel are already in Osm
http://audit.osmz.ru/browse/navads_fuel/NVDS346_54a1ba689826bf65d6a31b83
http://audit.osmz.ru/browse/navads_fuel/NVDS368_545f7bfa82efa41a49637ace
The conflation tool should check the existing fuel stations in a larger 
area.


- Most opening_hours are wrong.
A lot of fuel stations can be use 24/7 with a bank card. Moreover, when 
some opening hours are present in your data set they usually represent 
the opening hours of the supermarket, neither the 24/7 automatic station 
nor the opening hour of the station when operated with personal for the 
payment.


- Phone numbers :
When a fuel station belongs to a supermarket, the imported phone number 
is the supermarket one. We don't think it's a useful information.

You could check whether a phone number is duplicated in the data (most
likely the number of the company) or already on another node in the
vicinity (most likely the number of the supermarket the station is
attached to). If you find something, please don't import the phone
number.

- Don't delete imported objects with ref:navads
Sorry but we disagree. Check yourself if you must ignore a POI before 
adding it over and over in Osm.

Users should be able to remove a node that does not exist in reality
without looking for possible applications or imports that may want to
add the node over and over again in OSM. Please check whether the POI
should be ignored before importing it in an update.

- ref:navads
This ref tag is a private one. Nobody can use it. We understand that it 
will be easier for you to update the fuel station, but if everybody 
starts using their private tag, the database will become a mess.


- postal code
Why ? A postal code for a supermarket, a car's shop, it's ok, but on a 
fuel station ?


We already have an open fuel station database. These data are included 
in Osmose to let the contributors manually check each node.



Le 30/03/2018 à 01:44, osm.sanspourr...@spamgourmet.com a écrit :

Moreover, when some opening hours are present in your data set they represent 
the opening hours of the supermarket, neither the 24/7 automatic station nor 
the o.h. of the station when operated with personal for the payement.


Jean-Yvon



Gesendet: Freitag, 30. März 2018 um 00:47 Uhr
Von: "Philippe Verdy - verd...@wanadoo.fr" 

An: "Discussions sur OSM en français" 
Betreff: Re: [OSM-talk-fr] Import station essence

Le 29 mars 2018 à 21:34, Stéphane Péneau  a
écrit :


Résumons :

tl;dr
It's better since you choose not to overwrite the existing opening_hours,
but the French community still refuse this import as is.

- A lot of "new" amenity=fuel are already in Osm
http://audit.osmz.ru/browse/navads_fuel/NVDS346_54a1ba689826bf65d6a31b83
http://audit.osmz.ru/browse/navads_fuel/NVDS368_545f7bfa82efa41a49637ace
Your conflation tool should check the existing fuel stations in a larger
area.

- Most opening_hours are wrong.
A lot of fuel stations can be use 24/7 with a bank card


Automated 24/7 services may be, but this is generally not available for all
services, just a few kinds of fuels. And these automats are also not very
friendly: you jsut insert your credit card, they immediately request an
authoirization for a large amount of money, which is locked on you credit
card limits (weekly or monthly) and also by your bank for some time, until
the station will finalize the transaction for the effective amount of fuel
you took.
And many drivers (notably the poorest ones) cannot use at all these
automats, or don't want to use it because of how they manage the
transaction: so they'll go to stations only on real opening hours where
only the effective amount to pay will be paid and taken on their credit
card, or they will be able to pay with cash (when their credit card has
exhauisted its weekly or montly maximum, for example on a few days after
they paid their house renting costs, or if they had to pay some other
important bill, even if for that they opted to take a credit).

A "24/7 automat" does not mean the station is open 24/7; so the
opening_hours should not apply to the presence of such automats which
should be completely ignored and tagged separately.
___
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] Et si on fabriquait notre récepteur/logger GPS ?

[Stéphane Péneau]

Hello,

Alors, qui était qui dans ce test ?

Je rappelle les protagonistes :
- Smartphone Sony Xperia Ray
- Smartphone HTC One mini
- Tablette Nexus 9
- Tablette Nvidia Tablet Shield K1
- Navspark GL.

Et les résultats :
http://umap.openstreetmap.fr/fr/map/comparaison-recepteurs-gnss_208577

On peut facilement éliminer la trace bleue (Xperia Ray), la orange (HTC 
One mini), ainsi que la rouge (Nvidia Shield).

Il nous reste la trace verte et la trace jaune.

Je le rappelais, ce n'est pas vraiment la position absolue qui comptait 
dans ce test, mais la façon dont les traces se décalaient en cas 
d'obstacles alors que le déplacement reste rectiligne. Une antenne sur 
le toit est censée mieux capter les signaux des satellites, et pouvoir 
plus facilement discriminer les signaux ayant subi un rebond.
Voici quelques pistes où les traces vertes restent parallèles alors que 
les jaunes dérivent :

http://www.stemani.fr/public/gnss/gnss1.jpg
http://www.stemani.fr/public/gnss/gnss2.jpg
http://www.stemani.fr/public/gnss/gnss3.jpg
C'est encore plus flagrant sur cette dernière capture :
http://www.stemani.fr/public/gnss/gnss4.jpg

La trace jaune est la tablette Nexus 9, et la verte est bien le 
récepteur Navspark GL avec l'antenne sur le toit.


Si quelqu'un souhaite regarder de plus près, par exemple dans Josm, les 
voici :

http://www.stemani.fr/public/gnss/test_gnss.zip

Stéphane




Le 28/03/2018 à 00:59, Stéphane Péneau a écrit :

Le 28/03/2018 à 00:10, Francois Gouget a écrit :

J'aurais tendance à dire qu'il n'y en a pas un pour rattraper les
autres. Mais peut-être ai-je raté les points importants ?
Normalement, si tu décoches au fur et à mesure les traces qui te 
semble les moins bonnes pour qu'elles ne perturbent plus l'affichage, 
tu devrais trouver assez facilement celle qui vient de l'antenne sur 
le toit.
J'avoue qu'avoir quelques niveaux de zooms supplémentaires, ça aide, 
mais umap semble limité sur ce point.


Je donnerai la réponse dans quelques jours.

___
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] ODbL toujours inaccessible

[Philippe Verdy]

Selon la fondation OSMF elle-même, la CC-BY-SA-4.0 est marquée comme
incompatible (principalement en raison du fait qu'elle autorise la
substitution par toute version ultérieure, une option qui existe encore
dans la version 4.0 et qui lui permettrait donc d'opter pour des clauses
devenant incompatibles avec OSM).
Et la CC-BY-SA-4.0 ne permet pas de la restreindre en supprimant cette
clause de mise à jour automatique.

La clause problématique est "BY-SA version N.0, or a later version of the
BY-SA license", elle figure dans CC-BY-SA 2.0, 2.5, 3.0 et toujours dans
4.0.

https://creativecommons.org/share-your-work/licensing-considerations/compatible-licenses

Pourtant les changements sont significatifs.

La version 4.0 a ajouté des éléments concernant les "collecteurs de droits
collectifs" (sociétés collectant et gérant les droits pour le compte de
tiers qui les détiennent réellement et sont les réels émetteurs de licence,
et qui sont en charge de faire respecter et appliquer ces droits et
licences et devenir des parties autorisées à agir en justice dans
différentes juridictions où l'auteur détenteur des droits ne serait pas
lui-même présent ou représenté).

Ces collecteurs de droits sont essentiellement des sociétés privées, des
cabinets d'avocats, ou des assos/fondations; pour bénéficier de leurs
services, les auteurs doivent au minimum adhérer et payer une cotisation et
éventuellement faire une avance de frais pour une action judiciaire contre
toute personne physique ou morale (publique ou privée) violant les droits
couverts par les licences Creative Commons, d'une façon non autorisée par
la législation locale qui est opposable à cette personne.

Ces sociétés peuvent également agir par des moyens extrajudiciaires (par
exemple des campagnes publiques de dénonciation de violation des droits
d'auteur) mais elles peuvent aussi agir pour chercher des preuves tangibles
de ces abus, ou agir comme intermédiaire de négociation pour régler un
litige avec un auteur

Elles peuvent aussi agir de façon préventive et alerter les auteurs
concernés de l'existence de tels abus, pour qu'il puisse décider quoi faire
(ou pour qu'il puisse agir dans les temps où une telle dénonciation est
possible avant que la violation de droit ne soit finalement plus défendable
en justice pour cause de délai dépassé : le droit bien qu'ayant été
initialement abusé est entériné de fait et a été réapproprié, il est perdu
par l'auteur dans la juridiction de celui qui se l'est "légalement"
approprié en l'utilisant; toutefois même dans ce cas on peut encore agir
pour que cette appropriation dans une juridiction donnée ne soit pas
extensible à d'autres juridictions et faire savoir publiquement que cette
appropriation "légale" ne sera pas reconnue ailleurs, car la société de
collecte de droit aura pris soin de faire reconnaître les droits de
l'auteur légitime dans nombre d'autres jruidications, par le jeu
d'alliances avec des défenseurs locaux dans les autres juridictions: le
droit abusé et mal acquis ne sera donc plus exportable et celui en ayant
abusé préférera alors y renoncer et reconnaitre et rétablir les droits de
l'auteur d'origine en lui cédant à nouveau légalement les droits qu'il a
abusés, et en revanche obtenir de l'auteur légitime une licence normale
d'utilisation; de tels règlements peuvent être compliqués si celui ayant
abusé le droit pour se l'approprié a commencé à revendre ses propres
licences à des tiers, qui pourront demander réparation du préjudice subis
par eux, notamment le fait qu'ils seraient devenus eux-mêmes "coupables" de
recel d'abus de droits d'auteur; hors bien souvent celui ayant revenu ces
licences "légalement" aura limité la réparation des préjudices au seul prix
payé pour cette licence mais pas pour les dommages subséquents qui se
verraient maintenant contraints d'appliquer les termes de la licence
originale CC émise par l'auteur légitime qui en avait été exproprié
"légalement").

Certaines juridictions offrent des durées très limitées de recours (règles
de procédures amiables, procédures nécessaires...) contre cette
appropriation de droits d'auteur (durées très inférieures à la durée
d'exclusivité des droits d'auteur reconnue dans la jurdicition) : dans ces
juridictions, il est relativement facile d'exproprier un auteur en
commençant à abuser ces droits de façon très discrète, juste pour marquer
une "date d'occupation du terrain". Ensuite il est difficile de les en
déloger: ce "squat" devient un droit légal de propriété ou d'usage,
permettant même de le revendre ou le relouer en toute légalité dans cette
même juridiction (pour l'exportation c'est une autre histoire puisque les
droits de propriété ou d'usage entreront en conflit avec un droit
équivalent détenu par un autre tiers pour les autres juridictions).

Hors le but des licences CC est justement de faire reconnaitre un droit
opposable internationalement et non juridiction par juridiction. CC a
pourtant du le faire pour certaines juridictions en créant des 

Re: [OSM-talk-fr] Rapprochement des adresses OSM et FANTOIR

[Vincent de Château-Thierry]

Bonjour,

Le 04/03/2018 à 16:58, rainerU a écrit :


Il y a dix jours, j'ai ajouté des adresses à Perpignan mais aujourd'hui 
encore ces adressent restent en source=C+O dans le fichier bano-66.csv 
et n'apparaissent pas en vert sur le rendu BANO. Exemple :


http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/42.69586/2.90604

Les adresses des rues au nord de l'avenue Mermoz, ajoutées en 2014, sont 
marquées source=OSM dans le fichier data et apparaissent en vert sur le 
rendu. Ce n'est pas le cas pour les adresses des rues côté sud que j'ai 
ajoutées le 21/03/18. Y a-t-il une explication pour cette différence ou 
un blocage dans la génération des fichiers ?


Rainer, toutes mes excuses pour le délai de réponse.
L'anomalie que tu soulignais est normalement corrigée désormais. Elle 
était liée à un bug sur le traitement des suffixes (la commune de 
Perpignan est concernée) qui faisait en cascade planter toutes les mises 
à jour de la commune.


=> https://github.com/osm-fr/bano/issues/146

vincent

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