Re: [OSM-talk-fr] Attribution
Effectivement, mais en réduisant la fenêtre on voit que la carte est trop
haute et il apparait une barre verticale de défilement plutôt malvenue,
qu'il faut utiliser pour voir le bas de la carte avec les liens
nécessaires...
En écran large (en CSS, "@media(min-width:768px){ ... }"), la barre de
défilement est désactivée, pas de scrollbar automatique, le débordement est
tronqué avec "overflow:hidden".
---
Un "overflow:hidden" est toujours dangereux quand on n'est pas certain que
le rendu ne débordera jamais sur aucun écran ni aucun mode d'accessibilité.
Il faut aussi être sur des polices utilisées, ce qui n'est pas du tout
évident entre les PC sous différentes versions de Windows, les Macs, les
tablettes et smartphones, et leurs localisations, et les différents
navigateurs qui peuvent régler des tailles de polices différentes, ou selon
les densités de pixels des écrans (et imprimantes, bien que ce type de site
à contenu dynamique ne vise pas tellement l'impression).
Personnellement je trouve l'attribut CSS "overflow:hidden" (raccourci pour
"overflow-x:hidden; overflow-y:hidden") stupide la plupart du temps
(souvent un signe de paresse ou manque de maîtrise du développeur CSS qui
se met à tout mélanger et ne s'en sort plus autrement, avec des feuilles de
style tellement patchées qu'ils ne savent plus comment les gérer sans à
chaque fois casser autre chose), sauf si on veut réellement tronquer une
image qu'on a un autre moyen de faire défiler par exemple par glissement au
doigt, ou si le défilement n'est pas nécessaire comme une photo panoramique
en image de fond; il faut absolument l'éviter pour les contenus actifs
contenant des liens nécessaires ou s'il y a du texte dedans). Avant de
l'employer il faut vraiment tester sans et être sûr qu'on ne peut pas faire
autrement ou qu'on a une autre façon de faire apparaître le contenu masqué.
Le 11 juillet 2014 20:52, Régis Bouguin a écrit :
> Bonsoir
>
>
>
> J'ai eu une réponse, c'est à priori un problème de css dont ils
> s'occupent. En réduisant la largeur de la fenêtre, l'attribution leaflet et
> OpenStreetMap réapparaissent effectivement
>
>
>
> Cordialement,
>
>
> Le 11/07/2014 17:05, Philippe Verdy a écrit :
>
> En revanche ce site abonde en mention de droits relatifs à la concession
> faire à Facebook et au fait que ce sont des données Facebook, et menace
> même de frais de gestion de 50 euros par "abus" en cas de villation des
> règles de Facebook...
> Pas plus de mention non plus sur sa version mobile. Ce site engrange des
> marges commerciales des commerçants qui veulent se faire référencer.
>
> Bref abus manifeste de la part de ce site qui prétend vouloir faire
> respecter le droit par les autres (en leur imposant aussi la cession
> unilatérale et irrévocable des données collectées), mais surtout pas par
> lui-même ! Et le premier truc que demande ce site à ses visiteurs c'est
> leur position avant même de montrer les conditions d'utilisation abusives
> qu'il faut chercher en commençant par refuser la demande de
> géolocalisaition avant même de l'avoir visité un peu pour savoir de quoi ça
> parle.
>
>
>
> J'aime pas cette manie des sites et applis mobiles qui commencent par
> s'approprier tous les droits sans expliquer ce qu'ils vont faire de ces
> données. Sur mon Android, toute nouvelle appli est réglée par défaut avec
> les droits bloqués même si pour charger l'appli il a fallu d'abord accorder
> les droits sur Google Play, et je peux les retirer à tout moment (cela
> concerne pas seulement la géolocalisaiton mais l'usage de plus en plus
> abusif sur les applis mobiles du droit d'accès à nos contacts et listes
> d'applis installées, pour les spammer, et souvent de façon très insistante,
> ou pire encore pour qu'ils puissent lire tous les SMS ou email reçus ou
> envoyés, et en envoyer quand elles veulent même à des numéros surtaxés sans
> laisser de trace dans le journal, ou lire nos emails, ou même nos clouds
> privés où ils peuvent aller stocker et lire ce qu'ils veulent ou même y
> modifier des fichiers, certains n'hésitent pas non plus à se connecter à
> tous nos réseaux sociaux, récupérer des photos et les publier sur leur site
> immédiatement).
>
> Les applis mobiles sont aujourd'hui une vraie plaie dans leur
> comportement, on a besoin d'OS qui nous protègent plus que les OS
> préinstallés sur les smartphones et tablettes, qui sont de vraies
> passoires. Ni Google ni Apple ne font de la prévention en retirant de leurs
> appstores les applis malveillantes sur ce point. Certaines sont si
> malveillantes qu'elles vont même interrompre des applis concurrentes pour
> afficher de la pub en vidéo qu'on ne peut même pas interrompre, ou pour
> remplacer les bandeaux publicitaires d'un réseau concurrent. En plus a
> plupart sont très mal écrites et facilement exploitables par des intrus (et
> cela inclut notamment les applis préinstallées par les constructeurs ou par
> les vendeurs et qu'on ne peut pas enlever de leur firmware).
>
>
> Le
[OSM-talk-fr] vending_machine=yes in France
I'm cleaning up vending and saw that vending_machine=yes was used in some places in France: http://overpass-turbo.eu/s/4am 1. amenity=bicycle_rental I don't see the point. The tag itself already indicates the difference to shop=bicycle+service:bicycle:rental=yes 2. public_transport Probably indicates vending=public_transport_tickets, but would it be wrong to set the tags if the is a drink&food vending machine? At least you would need vending=* . I can see the idea, but I don't think we should tag everything on the platform with ...=yes (I could for example see that causes problems with the operator= tag as I for example have seen railway vending machines as bus stops close to the train station). In some places there was also a great public_transport schema in place, then I would just put the node for the amenity=vending_machine + vending=public_transport_tickets into the stop_area relation. What do you think? Greetings from Germany, Andi __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] vending_machine=yes in France
Le 13/07/2014 19:09, Andreas Goss a écrit : I'm cleaning up vending and saw that vending_machine=yes was used in some places in France: http://overpass-turbo.eu/s/4am 1. amenity=bicycle_rental I don't see the point. The tag itself already indicates the difference to shop=bicycle+service:bicycle:rental=yes The good tag is vending=yes, rent process not available at all station. It's more clear in french translation http://wiki.openstreetmap.org/wiki/FR:Tag:amenity=bicycle_rental For vending_machine=yes on network=VCUB (Bordeaux) it's my fault. http://wiki.openstreetmap.org/wiki/Bordeaux/VCUB 2. public_transport Probably indicates vending=public_transport_tickets, but would it be wrong to set the tags if the is a drink&food vending machine? At least you would need vending=* . I can see the idea, but I don't think we should tag everything on the platform with ...=yes (I could for example see that causes problems with the operator= tag as I for example have seen railway vending machines as bus stops close to the train station). In some places there was also a great public_transport schema in place, then I would just put the node for the amenity=vending_machine + vending=public_transport_tickets into the stop_area relation. What do you think? In Lyon I think it's the same problem, it's for ticket on tram station. Greetings from Germany, Andi __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ 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] vending_machine=yes in France
1. amenity=bicycle_rental The good tag is vending=yes, rent process not available at all station. It's more clear in french translation http://wiki.openstreetmap.org/wiki/FR:Tag:amenity=bicycle_rental I don't speak French so this is what google gives me: "yes for stations that have a possibility of payment and ticket printer (registration shortest possible time in these stations)." First of all I don't understand why this tag covers payment, when we have payment= which can be used in many ways. Then I assume you always need some kind of ticket for the bike? So then it depends if you just want to set payment:ticket (or something like that) on the station or do you include the vending machine, because then you might as well just set payment:cash=yes (I mean if I got to a cinema I also don't tagg it with vending=yes, because i can get the ticket right there and pay with cash). The stations where you can't do this are then different, because payment:cash=no. Maybe we should then consider a new value for payment like only and then you set payment:vcub_ticket=only. At least I think that is the direction this should be going. __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] vending_machine=yes in France
Le 13/07/2014 21:02, Andreas Goss a écrit : 1. amenity=bicycle_rental The good tag is vending=yes, rent process not available at all station. It's more clear in french translation http://wiki.openstreetmap.org/wiki/FR:Tag:amenity=bicycle_rental I don't speak French so this is what google gives me: "yes for stations that have a possibility of payment and ticket printer (registration shortest possible time in these stations)." First of all I don't understand why this tag covers payment, when we have payment= which can be used in many ways. Yes, you right. Then I assume you always need some kind of ticket for the bike? No. You register for a subscription (from 1 day to 1 years). In fact there is no a physical automaton vending machine. The machine sell subscription, no physical objects. It's not just a payment point. So then it depends if you just want to set payment:ticket (or something like that) on the station or do you include the vending machine, because then you might as well just set payment:cash=yes (I mean if I got to a cinema I also don't tagg it with vending=yes, because i can get the ticket right there and pay with cash). The stations where you can't do this are then different, because payment:cash=no. Maybe we should then consider a new value for payment like only and then you set payment:vcub_ticket=only. At least I think that is the direction this should be going. So vending=subscription payment:debit_cards=yes and no vending_machine key right ? Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] tissus économique : expérimentation sur Orange
Il manque une bbox à ta requête "ref:SIRET=*", on a droit à une carte vierge, centrée autour d'un point en Allemagne près de Bonn... Mais si on sélectionne autour d'Orange, je ne vois pas grand chose de significatif, juste certaines entreprises dans certains secteurs. A ce sujet on a des "ref:NAF=" contenant les numéros APE apparemment mais ce ne sont pas des références correctes (5 chiffres plus une lettre) utilisables comme identifiants uniques (contrairement aux codes SIRET voire SIREN qu'on peut utiliser en "ref:FR:SIRET=*" ou "ref:FR:SIREN=*"), juste des classifications applicables à toute une série d'entreprises de même activité partout en France (et seulement en France). - 1°, ce ne devrait même pas être "ref:NAF=*" mais "ref:FR:NAF=*" puisque cela ne concerne que la France (j'aime pas du tout qu'on s'approprie pour la France des codes courts à 3-4 letttres sans le préfixe ISO du pays "FR:". - 2°, et au lieu de "ref:*" il faudrait autre chose; il n'y a rien d'international applicable à ce genre de classification (ou je n'ai pas trouvé). Bref je mettrais plutôt "FR:NAF=*" sans autre chose devant, ou sans doute moins ambigu "FR:APE=*", à défaut de "activity:FR:APE=*" s'il y a une internationalisation proposées des classifications de type d'activités (au moins dans l'Union Européenne, laquelle pourrait avoir aussi son propre codage de type "activity:EU:WXYZ=*", avec en valeur un ou plusieurs codes séparés par point-virgules, ou bien la Banque mondiale ou l'OCDE, ou une agence de l'ONU qui pourraient avoir leur codage à eux aussi de type "activity:OECD=*" pour classer les entreprises avec qui traitent ces organismes internationaux). Le 12 juillet 2014 17:45, ZIMMY a écrit : > Bonjour, > > Depuis que je suis passé en communauté de communes se pose la question des > savoir-faire poussés par chacun. Vu le niveau de détail obtenu sur le > bassin > d'Orange, on m'a concédé de poursuivre l'observatoire éco via OSM. > En revanche comme je n'avais pas qualifié les données pour être exploitée > de > façon plus fine j'ai commencé à mettre à jour celle-ci dans un premier > temps > sur les "zone d'intérêt communautaire" (peut-être). > Afin de faciliter leur visualisation voici le lien : > http://overpass-turbo.eu/s/49E > > Je suis preneur de vos observations, suggestions... > > Bon week-end > > > > - > Cordialement, > ZIMMY > Jean-Louis ZIMMERMANN > Développeur territorial (CCPRO,FR84) > Mandataire OSM-France sur le Grand-Sud-est > -- > View this message in context: > http://gis.19327.n5.nabble.com/tissus-economique-experimentation-sur-Orange-tp5811216.html > Sent from the France mailing list archive at Nabble.com. > > ___ > 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
