Re: [OSM-talk-fr] Rapprochement des adresses OSM et FANTOIR
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
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 ?
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
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 versi
Re: [OSM-talk-fr] Rapprochement des adresses OSM et FANTOIR
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