[OSM-talk-fr] forum: Bing sur JOSM Ubuntu
Le message suivant : ## Bonjour, le menu Imagery ne me propose pas Bing dans JOSM Ubuntu. il n'y a que Image rectifiée et Calque vide. comment puis je avoir la carte satellite en fond comme sous mon interface JOSM windows svp ? merci. a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2 Une réponse sur la liste directement n'est hélas pas transmise sur le forum, ce qui n'empeche pas une concertation avant réponse par email. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour repondre. -- Tout commentaire sur ce message peut être demandé à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel outil diff cadastre
Philippe Verdy verd...@wanadoo.fr wrote: Est-ce que OSM doit jouer un rôle d'auxiliaire de contrôle fiscal en corrigeant gratuitement ce qui est ou n'est pas dans leur cadastre (ce qui pourrait être un bénéfice inavoué motivant les collectivités à ouvrir leur données SIG et à collaborer avec OSM) ? Euf… théorie du complot? Je pense que nous ne sommes pas assez rigoureux (d'un point de vue fiscal!) ni n'avons un but qui puisse convenir à ce genre d'utilisation. Ça va servir à quoi à l'administration fiscale qu'on rajoute des ruines en building=yes? Et puis je les vois bien justifier auprès des contribuables que si si il faut payer parce qu'on les a vu sur OSM… À l'extrême limite j'ai vu des piscines sur Bing/CRAIG/etc. non signalées sur le cadastre… mais peut-être parce qu'elle étaient hors-sol, etc, etc. Cette hypothèse de bénéfice non avoué me paraît peu plausible. Vue le peu de moyens de collectivités pour faire leurs contrôles, [...] Désolé mais on sort du cadre des discussion de cette liste. Merci de respecter la charte : on parle de OSM. Je suis désolé de jouer le vilain, mais si certaines de tes interventions sont pertinentes et intéressantes, le gros de ces mêmes messages font de telles disgressions (hors sujet) et sont tellement longues qu'il me semble que c'est finalement contre productif... Perso je ne lis plus qu'en diagonale et encore rapidement, mais bon ce que j'en dis ce n'est que mon avis personnel... -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] bonjour + utilisation de data.gouv.fr
Bonjour,effectivement ces remarques rejoignent ce que j'ai mis dans le wiki. Mais malgré le fait que certaines landes ou prairies puissent être incluses aux polygones des données ONF, cela reste rare (moins de 2-3 % de la surface, de mon "expérience"), et en tous cas sans commune mesure avec les erreurs d'interprétation (notamment parcelles de jeunes peuplements forestiers considérées comme des prairies) et le manque de précision de Corine Landcover. Existe-t-il un outil (dans JOSM ?) qui permette de scinder en sous-polygones les "morceaux" de polygone venant intersecter un polygone nouvellement importé ? Si c'est le cas, on pourrait imaginer la démarche suivante :- on importe des polygones des shape ONF ;- on découpe les morceaux de polygones Corine venant intersecter le polygone ONF, et on les supprime ;- pour affiner le tout, on vérifie par photointerprétation ou visite de terrain la cohérence de l'ensemble.Bien sûr, l'idéal est que cet import soit fait par un local de l'étape, qui à déjà fréquenté les forêts en question... Je suis d'attaque pour faire celles de Sarthe et de Mayenne, les parcourant régulièrement dans le cadre de mon travail...Pour mémoire, les forêts publiques représentent 25% de la surface forestière totale, mais de façon très variable selon les régions/départements (une grande majorité en Lorraine, mais seulement 10-12% en Sarthe par exemple...)Pour ce qui est du libre accès pour les promeneurs, plusieurs situation possibles dans les forêts publiques :- Forêts domaniales : oui, sauf réserve biologique (info disponible dans une autre couche ONF en OpenData, cf wiki)- Forêt des collectivités : oui, sauf réserve biologique ou rares autres exceptions- Forêt d'établissement publics (hôpitaux, Universités...) : généralement non. L'info est aisément récupérable dans le nom de la forêt (si les termes "domaniale", "communale", "départementale" ou "régionale" n'apparaissent pas, on est sans doute dans ce cas-là- Forêt domaniale affectée : correspond souvent aux camps militaires, donc non. même chose que la ligne précédente pour avoir l'info.A votre disposition pour en discuter plus dans le détail. Si vous voulez un aperçu de ce que pourrait donner le résultat de la méthode que je propose (sauf que je n'ai pas découpé les polygones Corine, ne sachant pas comment faire), vous pouvez aller voire le massif de Sillé-le-Guillaume.Bien cordialement,Sylvain H. Message d'origine De : "Christian Quest" cqu...@openstreetmap.fr À : "Discussions sur OSM en français" talk-fr@openstreetmap.org Objet : Re: [OSM-talk-fr] bonjour + utilisation de data.gouv.fr Date : 10/02/2012 13:36:50 CET Le 8 février 2012 16:03, ar...@netcourrier.com a écrit : Bonjour, j'arrive fraichement sur le talk-fr bien que contribuant déjà depuis quelques temps à OSM (notamment dans les forêts sarthoises, grâce à mon précieux GPS, Garmin Oregon de son petit nom). J'ai un peu fouillé dans data.gouv.fr, et ai déniché des données qui me semblent intéressantes : les périmètres des forêts publiques, produites par l'ONF. Je me suis permis de mettre à jour le wiki en ce sens. Par ailleurs, j'ai intégré le périmètre de la forêt domaniale de Sillé-le-Guillaume à OSM avec landuse=forest et name="forêt domaniale de Sillé-le-Guillaume". Je suis en train de faire les vérifications mais le tracé me semble très précis (sans commune mesure avec Corine Landcover). Il faudra simplement retirer du polygone les maisons forestières, les étangs et les quelques prairies permanentes, et retirer la couche issue de Corine Landcover, ou plutôt n'y laisser que les forêts privées attenantes à la forêt domaniale. Qu'en pensez-vous ? Par ailleurs, j'ai importé quelques cours d'eau issus de data.gouv.fr (agence de l'eau Loire-Bretagne), toujours dans les forêts publiques sarthoises. Leur précision semble relativement bonne (de l'ordre de 10m a priori), après vérification de terrain. Votre avis sur la faisabilité à plus grande échelle ? Bien cordialement, Sylvain H. Je viens de regarder ce jeu de fichier SHP issus de l'ONF. Voir:http://bit.ly/yaKcYS Ca a effectivement l'air relativement précis au niveau du tracé. Mais...la description indique "Contours des forêts publiques relevant du régime forestier : terrains domaniaux et communaux, y compris les terrains qui ne sont pas en nature de forêt." - on a donc un mélange entre du landuse=forest et parfois autre chose. - seules les forêts publiques y figurent Un apport me semble être la récupération des noms des forêts publiques, et leur caractère publique ce qui peut être utile (access=yes ? ou un leisure=forest ?). -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org
[OSM-talk-fr] place = locality / hamlet
Sur le cadastre, un nom est affiché souvent dans les champs à coté des bâtiments d'une ferme. A ma connaissance, ce même nom sert d'adresse. Plusieurs questions : 1 - Utilisez vous place=locality ou place=hamlet pour une ferme unique ? 2 - Utilisez vous un point ou une area pour enregistrer cette information 3 - Si area : quel contour utilisez vous. Si un point, à quel endroit le placez vous (à la place du texte dans le cadastre ou sur le bâtiment) ? Cdlt POG ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Le 11/02/2012 18:45, Po G a écrit : Sur le cadastre, un nom est affiché souvent dans les champs à coté des bâtiments d'une ferme. A ma connaissance, ce même nom sert d'adresse. Plusieurs questions : 1 - Utilisez vous place=locality ou place=hamlet pour une ferme unique ? place=isolated_dwelling http://wiki.openstreetmap.org/wiki/Tag:place%3Disolated_dwelling 2 - Utilisez vous un point ou une area pour enregistrer cette information Point en ce qui me concerne. 3 - Si area : quel contour utilisez vous. Si un point, à quel endroit le placez vous (à la place du texte dans le cadastre ou sur le bâtiment) ? Au milieu de la cour de ferme, au niveau du puits. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Po G nux...@gmail.com wrote: Sur le cadastre, un nom est affiché souvent dans les champs à coté des bâtiments d'une ferme. A ma connaissance, ce même nom sert d'adresse. Plusieurs questions : 1 - Utilisez vous place=locality ou place=hamlet pour une ferme unique ? isolated_dwelling ou hamlet suivant la taille estimée locality c'est à priori pour les endroits avec un nom mais sans habitants. 2 - Utilisez vous un point ou une area pour enregistrer cette information Point 3 - Si area : quel contour utilisez vous. Si un point, à quel endroit le placez vous (à la place du texte dans le cadastre ou sur le bâtiment) ? Si possible dans un espace publique vers le croisement des routes importantes... Le plus possible au centre du hameaux... -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Le 11/02/2012 19:01, Pierre-Alain Dorange a écrit : Po Gnux...@gmail.com wrote: Sur le cadastre, un nom est affiché souvent dans les champs à coté des bâtiments d'une ferme. A ma connaissance, ce même nom sert d'adresse. Plusieurs questions : 1 - Utilisez vous place=locality ou place=hamlet pour une ferme unique ? Le nom peut servir d'adresse serait plus juste. isolated_dwelling ou hamlet suivant la taille estimée locality c'est à priori pour les endroits avec un nom mais sans habitants. Ma pratique : * en milieu urbain, il y a aussi des toponymes, donc place=locality. Le nom du quartier ( ou de l'ancienne commune fusionnée ex. Bourtzwiller dans le 68) peut être placé en plus. On joue plus sur l'historique du terrain (les toponymes sont souvent porteurs de sens local). * en milieu rural : s'il n'y a que de la nature, c'est place=locality; si c'est un hameau ciblé, un corps de ferme identifié en tant que tel j'ai aussi utilisé isolated_dwelling ou hamlet 2 - Utilisez vous un point ou une area pour enregistrer cette information Point 3 - Si area : quel contour utilisez vous. Si un point, à quel endroit le placez vous (à la place du texte dans le cadastre ou sur le bâtiment) ? Si possible dans un espace publique vers le croisement des routes importantes... Le plus possible au centre du hameaux... Il risque d'y avoir doublon entre le name d'un landuse farmyard (logiquement area - voir http://wiki.openstreetmap.org/wiki/FR:Tag:landuse%3Dfarmyard) et un (logiquement point) place=locality. Il faut juste choisir l'approche la plus pragmatique. Ouais, je sais on ne tague pas pour le rendu, mais on ne tague pas non plus 2x la même réalité (sauf bonnes raisons). Denis, fan de topo ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Nouvel outil diff cadastre
Le 11 févr. 2012 à 15:01, Pierre-Alain Dorange a écrit : Désolé mais on sort du cadre des discussion de cette liste. Merci de respecter la charte : on parle de OSM. Je suis désolé de jouer le vilain, mais si certaines de tes interventions sont pertinentes et intéressantes, le gros de ces mêmes messages font de telles disgressions (hors sujet) et sont tellement longues qu'il me semble que c'est finalement contre productif… Pas bien compris : pour une fois que Philippe sortait de considérations techniques pour parler d'OSM en général dans les possibles relations avec les SIG publics (des relations moins fantasmées qu'elles n'en ont l'air), c'est là qu'on lui dit qu'il est hors-sujet. Tout ce que dit Philippe est souvent passionnant ou sans intérêt pour le non-geek. Personne n'est obligé de tout lire, encore moins de commenter chaque partie de ses propos. Ceux qui comprennent tout ce qu'il dit peuvent picorer un point ou un autre pour nous fournir un autre angle. Du point dont il est question ici, je dirais qu'il est amusant de penser qu' OSM pourrait avoir, un jour, la même crédibilité floue que Wikipédia : on pourrait à la fois s'en méfier et parfois en faire une mesure de la réalité. Un exemple simple : certaines régions ont ou auront une couverture photo de 10 cm et, donc pendant quelques mois, des dizaines d'OSMeurs pourraient créer de l'avance sur beaucoup de documents officiels. Mais, comme le signale Philippe, opendata + montée en puissance des SIG publics de plus en plus mutualisés, pourraient aussi nourrir OSM aussi rapidement que, l'exploitation des images publiques. Exemple : le fait qu'il n'y ait qu'un seul service SIG pour les 87 communes du Pays de Brest et qu'une partie de la voirie et du bâti viennent compléter les données OSM, fait que, sur un quart de département, OSM a acquis une qualité de couverture peu commune, qui appelle pourtant un fort complément bénévole. Christian (sans tirets)___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] place = locality / hamlet
Je n'utilise quasiment pas locality et isolated_dwelling. J'utilisais locality pour les petits hameaux, mais on m'a fait remarquer ici que cela ne concernait que les lieux inhabités. Concernant les fermes en hameau, j'ai pris le pris le parti de faire comme si elles avaient forcément plusieurs habitations : 1 parce que c'est de plus en plus vrai, en Bretagne, car les familles se regroupent en construisant sur les terrains possédés en commun. 2 parce que les bâtiments utilitaires sont rénovés et transformés en habitations, là où les exploitations disparaissent. Tout groupement de constructions agricoles est, soit déjà multihabité, soit va le devenir bientôt. C'est donc un hamlet, au moins, par ici. Christian (sans tirets) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Retour sur le bogue XML du backend d'Osmose et sur la compatibilité du frontend HTML/JS/CSS
=== Premier point ===
Je reviens sur le problème de la fonction quoteattr() du module
sax.saxutils actuellement installé sur le serveur Osmose.
Visiblement, cette fonction n'est pas du tout issue du vrai module
sax.saxutils, mais n'est qu'un stub qui se contente de placer son
paramètre entre guillemets ASCII ().
Je note que cela invalide TOUTE chaîne contenant non seulement un
caractère et commercial (), trouvés dans les URL notamment, mais
aussi dans des noms comme Hôtel BB ou CA, mais aussi des
guillemets ASCII, et même les caractères et qui ne sont pas
réencodés non plus sous la forme amp;, lt; et gt; (ce que
fait la fonction originale).
La fonction actuelle remplace en revanche systématiquement les
apostrophes ASCII (') sous la forme apos; alors que ce n'est pas
nécessaire si la valeur sera retournée entre guillemets ASCII () : la
fonction quoteattr() du module Pythin original ne le fait pas.
Bref, l'actuelle fonction quoteattr() utilisée ne fait rien d'autre
que remplacer dans la chaîne source les apostrophes ASCII (') par
apos;, et encadrer la chaîne obtenue de guillemets ASCII. Elle
n'emploie pas du tout la fonction escape(), comme documentée par
Python, et ne détermine pas non plus le type de guillemets simples ou
doubles (selon lequel ou lesquels sont présents dans la chaîne source)
à utiliser pour encadrer la valeur retournée (et éviter de réencoder
l'autre type).
Ces erreurs se retrouvent par exemple (on m'a demandé de trouver un
lien dans Osmose, sur une valeur pas encore corrigée) dans :
http://rawedit.openstreetmap.fr/edit/node/739753876
(ici l'erreur signalée est sur l'ortographe du mot Hôtel dans Hotel BB)
Bref je redemande à ce que celui qui maintient le serveur
Osmose.openstreetmap.fr vérifie d'où vient la fonction quoteattr()
utilisée, car soit ce n'est pas celle importée depuis le module
sax.saxutils (elle est écrasée par une autre en conflit dans un autre
module), soit ce module pythin sax.saxutils n'est qu'un stub écrit
rapidement mais pas l'original sur le serveur backend.
=== Deuxième point ===
Et je continue de voir des corruptions de données issues de rawedit,
notamment par des utilisateurs qui visiblement utilisent aussi de très
vieilles versions d'Internet Explorer sur Windows ou MacOS (plus
maintenues par Microsoft voire abandonnées complètement sur MacOS
depuis des années) parce que certaines fonctionne Javascript
fonctionnent incorrectement sur ces versions (pour correctement
encoder le texte en UTF-8 dans la fonction javascript
encodeURIcomponent). Bref c'est encore une demande pour intégrer
jQuery dans Osmose pour remplacer le code Javascript émis par le
frontend et écrit trop rapidement et mal testé pour éviter des
problèmes de compatibilité (et éventuellement les contourner si
possible, sinon afficher une erreur sur le navigateur client afin
qu'il ne puisse pas valider une valeur erronée).
D'ailleurs il me semble que les mêmes utilisateurs de vieilles
versions de navigateur, pour contourner certaines erreurs, évitent de
taper le moindre accent dans Osmose/rawedit. Mais ils ne font pas
attention du tout sur le fait que les données affichées dans Rawedit
peuvent contenir autre chose que des caractères latins (par exemple
des traductions en russe, grec, arabe ou hébreu qui sont TOTALEMENT
corrompues par ces vieux navigateurs web incompatibles et par
l'absence de leur détection ou de solution de contournement par un
support Javascript remplaçant leur fonction javascript
encodeURIcomponent() prédéfinie mais complètement boguée).
Pour la viabilité à long terme des données OSM, il est hautement
souhaitable que les mises à jour effectuées sur la base ne se
contentent pas seulement de mentionner le nom et la version du
logiciel d'édition utilisé, mais aussi la plateforme sur laquelle elle
est exécutée (pour JOSM : indication du type de machine Java et sa
version ; pour rawedit : indication du type de navigateur, sa version
et le type d'OS, sous une forme abrégée si le User-Agent est trop
détaillé, mais suffisante par exemple IE6.x;Win95, voire aussi le
jeu de caractères systèmes sur les versions de Windows avant XP).
Bien sûr on pourrait détecter les changeset des utilisateurs de ces
vieilles versions, mais je ne suis pas convaincu que ce soit des
erreurs volontaires de ces utilisateurs, qui peut-être n'ont pas
d'autre moyen de contribuer avec leur matériel ou logiciel et ne sont
pas assez calés pour installer ou utiliser un autre OS dessus, ou bien
ne le peuvent pas (matériel utilisé seulement en prêt, tel quel, par
exemple depuis un cybercafé, voire même un PC de travail d'une
administration ou d'une bibliothèque française sous-équipée) :
Au lieu d'exclure ces utilisateurs, leur fournir un support très
amélioré avec jQuery (qui fournit de nombreuses fonctions de
contournement très efficaces et bien optimisées) serait nettement
préférable (et peut-être aussi quelques contrôles de validité et
cohérence du côté du serveur Backend, voire même depuis le serveur
