Re: [OSM-talk-fr] recherche d'adresses et POI, comment quitter Google ?

[Djo_man via Talk-fr]

Bonsoir, 

Pour répondre à la question de la recherche "centre hospitalier luynes"  QWANTS 
MAPS  va pourvoir plutôt bien. c'est du osm pour la carte mais avec du pages 
jaunes pour l'adresse ? Je sais pas exactement qui fait quoi et comment, mais 
ça marche. 
Djo man 



 Cyrille37 OSM via Talk-fr a écrit 

>Bonjour,
>
>Sujet récurent.
>
>Avec Nominatim https://osm.org la recherche de "Centre Hospitalier, 
>Luynes" ne donne aucun résultat, il faut saisir le nom complet "Centre 
>Hospitalier Jean Pagès, Luynes".
>
>Sur la base adresse data.gouv.fr https://adresse.data.gouv.fr/map aucun 
>résultat pour "Centre Hospitalier Jean Pagès, Luynes" puisque ce n'est 
>pas une adresse.
>
>Heureusement, l'appli Smartphone OsmAnd trouve "Centre Hospitalier, Luynes".
>
>Connaissez-vous un moteur de recherche sur le Web ou en API qui trouve 
>les demandes raccourcies comme "Centre Hospitalier, Luynes" ?
>
>Merci,
>Cyrille37.
>
>
>___
>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] Rivages sur OSM V2 - Evolution des règles pour les plages et la ligne de côte

[djo_man via Talk-fr]

  
  
Bonjour, 



Rivages sur OSM V2.pdf


http://pc.cd/udqctalK


avec liens cliquables



Djo man




Le 11/05/2020 à 14:48, djo_man a
  écrit :


  
  
  Bonjour, 
  
  
  J'ai eu un peu de temps ce week-end
pour préciser à la fois l'état du tagging
pour les côtes et décrire les problématiques que cela soulève en
terme de rendu de carte.
Il s'agit d'un PDF avec des photos aériennes commentées de JOSM
et modifiées sur photoshop.
  
  
  
  http://pc.cd/ssGrtalK
  
  
ça ne résoudra pas la question du manque de vote pour cette
  dernière modif de wiki
  mais permettra de comprendre ce qui est en jeu pour OSM voire
  pour OPENSEAMAP.
Le Mont Saint-Michel nous remerciera peut être...
Djo man

  
  
  
  Le 07/05/2020 à 10:06, Yves P. a
écrit :
  
  
Salut,

Votre discussion est assez technique ;)

Pouvez-vous mettre un lien sur un schéma, une photo aérienne, le(s) rendu(s) et si possible une carte marine pour qu'on puisse suivre ?
(et tant qu'à faire ne pas cartographier n'importe quoi)

Merci,

__
Yves



  Des fois certains mapper vont même jusqu'à dessiner ses zones encore plus bas que la ligne de basse mer car avec les belles images aériennes et une eau claire on en voit tres bien les contours. C'est presque un autre probleme mais explique bien que l'enchainement de ses zones ressemble à un geant code barre le long des côtes avec beach et bare_rock qui s'enchaînent.


un exemple ici stp :)



___
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] [M] rendu de la mer et modèle de tag pour les cotes. Était : Evolution des règles pour les plages et la ligne de côte (zones et traits)

[djo_man via Talk-fr]

  
  
Bonjour, 



Ma demarche soutient ce PM uniquement.
https://github.com/gravitystorm/openstreetmap-carto/issues/3854
qui propose de mettre en place un
  moteur de test de l'inversion des calques et les modes de fusion
  pour le rendu.

Ce qui permettra de gérer les
  transparences de l'eau en général et donc aussi les surfaces
  d'estran.
que cela soit tidal=yes ou
  wetland=tidalflat m'importe secondairement.



Pour tous les autres PM, les
  négociations devront se faire aussi.


oui, il faut apercevoir les
  natural=sand et les natural=bare_rock en dessous de la coastline !
  



Et je conviens qu'un changement
  unilatéral du modèle de tag ne peut et ne doit pas passer en force
  sans discussion.



djo man











Le 16/05/2020 à 15:49,
  osm.sanspourr...@spamgourmet.com a écrit :


  
  Le 15/05/2020 à 19:23, Djo_man via Talk-fr - talk-fr@openstreetmap.org
a écrit :
  
  
Donc, je
  voudrais, ici lancer une petite hola pour les contributeurs
  Imagico et Jeisenbe pour les soutenir. 
  
  Sans moi ! Grosso modo on a cassé le rendu (il suffit de
comparer le rendu FR du rendu par défaut) pour justifier une
modélisation qui permettra un rendu futur.
  Ce n'est plus taguer pour le rendu c'est ignorer des tags
existants et ayant un sens (tidal=yes). S'ils veulent il peuvent
appliquer le bleu peu transparent sur les zone water (ou
océaniques) à l'exclusion des zones tidal=yes. 
  
  Tant qu'on a n'a pas de données sous-marines (on en a mais sous
la surface), quel intérêt ?
  tidal=yes permet d'afficher après les autres couches un rendu
de l'estran.
  J'avais fait un comparatif
  des rendus.
  On avait du sable, Christoph -imagico) nous dit que le sable
c'est essentiellement sur terre. Exact dans le Sahara, pas sûr
que ce soit l'endroit où OSM est le plus utile et le plus
utilisé.
  Il refuse de rendre natural=shoal. En soit le tag est mauvais
(natural indique normalement une surface hormis pour coastline).
  Effectivement tidal=yes serait plus logique mais ce
n'est pas son avis.
  
  low_level_water=yes serait sans doute plus idoine qu'un
natural=reef. Mais la notion est utile.
  L'argument que tidleflat est plus utilisé est pervers :
Christoph et Josef change unilatéralement le wiki, rendent ce
qui les intéresse et après disent que ce sont les bons tags car
plus rendus.
  Voir :
  
  https://github.com/gravitystorm/openstreetmap-carto/issues/3840
(c'est le même ticket, simplement j'ai répondu) Jean-Yvon
  
  Note : le rendu vectoriel n'a pas la notion d'océan, c'est la
valeur par défaut.
  
  Jean-Yvon
  
  
  
  ___
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] rendu de la mer et modèle de tag pour les cotes. Était : Evolution des règles pour les plages et la ligne de côte (zones et traits)

[Djo_man via Talk-fr]

t;les plages sont interdites par défaut et les grèves pas sauf si elles
>servent d'accès à la mer(*)), on les met du DPM à quoi ? BMVE serait
>logique dans OSM, car on utilise PMVE. Et si quelqu'un veut mettre son
>rond de serviette, heu sa serviette, au niveau 0 absolu, il risque de ne
>le mettre qu'une fois tous les 20 ans sur un sable détrempé.
>
>Djo man, c'est bien le BMVE et non le BMME.
>
>Blague à part, *vus les profils des plages ça revient à positionner les
>plages en mer* ! Donc les arrêter à la ligne de mi-marée ne serait pas
>déconnant (c'est aussi la partie de la plage la plus utilisée). Je dis
>plages mais je pense beach : les grèves sont incluses. Mais peut-être
>qu'on peut laisser le moteur de rendu repositionner le nom dans les terres.
>
>De plus (mais c'est une mauvaise raison) l'imagerie est souvent coupée
>avant.
>
>Pourquoi le 0 des cartes terrestres ? C'est intéressant pour avoir une
>idée du profil de marée / de la plage. Pas prévu par OSM, sauf à faire
>des way avec ele=0.
>
>Trait absolu de basse mer : idem et de plus utile pour le calcul des
>lignes de base. Et comme dit par Thomas on a ce qu'il faut pour le faire
>en France.
>
>Et comme ça, pour faire un rendu propre, on ajoute un dégradé
>transparent bleuté entre ces lignes.
>
>Et on évite ces hérésies de tidalflat et de tidal=yes : natural=sand,
>mud, gravel d'un côté et des traits de côtes y compris de basses côtes
>(désolé pour les végans^^).
>
>Je dis hérésie c'est pourtant cette horreur qui est décrite dans le wiki
>anglais <https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline> :
>
>/Mean low water springs
><http://en.wikipedia.org/wiki/Mean_low_water_spring>//is the position of
>the lowest tide. There is currently no agreed way of tagging this line
>in OSM. One way of tagging it is to tag the area between mean low water
>springs and OSM coastline as //natural
><https://wiki.openstreetmap.org/wiki/Key:natural>=wetland
><https://wiki.openstreetmap.org/wiki/Tag:natural%3Dwetland>//+//wetland
><https://wiki.openstreetmap.org/wiki/Key:wetland>=tidalflat
><https://wiki.openstreetmap.org/wiki/Tag:wetland%3Dtidalflat>//. /
>
>Si on arrive à nous mettre d'accord, on pourra envisager une proposition
>au niveau international.
>
>Le 13/05/2020 à 14:36, Denis Bigorgne - denis.bigor...@gmail.com a écrit :
>> en clair que la position de la coastline change chaque année !!!
>
>Par chez moi, la pointe de sable et les blancs de sable, se déplacent
>plutôt à chaque grande marée tous les 15 jours. Pas le trait de côte OSM
>;-).
>
>Comme tu dis les plages dégraissent en hiver. On a en plus des
>mouvements plus lents par exemple dus à un train de tempêtes.
>
>Là où c'est peut-être utile de se mettre d'accord c'est de savoir si la
>limite sable/roche on la met plutôt en hiver ou en été. J'aurais
>tendance à dire en été car il y a plus de monde à fréquenter le littoral
>en été. Des objections ?
>
>De même la pente entre la dune et la rivière évolue en fonction du
>coefficient.
>
>> Et à mon humble avis, (hors sujet) OSM se porterait mieux avec une
>> coastline définie comme le trait de côte français, la limite entre le
>> bistre et le vert des cartes du SHOM.
>
>Pas du tout hors sujet, en plein dedans.
>
>Car selon Wikipédia
><https://en.wikipedia.org/wiki/Mean_high_water_springs> :
>
>*Mean high water springs (MHWS)* is the highest level that spring tides
><https://en.wikipedia.org/wiki/Spring_tide> reach on the average over a
>period of time (often 19 years).
>
>C'est à dire que c'est la moyenne des vives-eaux (95) et non la moyenne
>des vives-eaux d'équinoxes (100).
>
>Il y a deux périodes de grandes marées par 29 jours, c'est donc la
>moyennes des marées en ne prenant que les "sommets" tous les 14,5 jours.
>
>C'est donc bien 95 qui est à retenir. Source : Wikipédia
><https://fr.wikipedia.org/wiki/Calcul_de_mar%C3%A9e> : "Une marée de
>coefficient 95 est une marée de *vives-eaux moyennes*.".
>
>Par contre même si je comprends, comme ce n'est pas la convention au
>niveau mondial je pense qu'il est préférable d'en rester au coef de 95.
>Ça permet aussi de distinguer le trait de côte et la limite communale.
>Au début j'étais plutôt de ton avis.
>
>Comme en Allemagne, *les limites des communes sont à la pleine mer de
>120 et le trait de côte à 95*.
>
>Jean-Yvon
>
>(*) JORF n°0116 du 12 mai 2020
>texte n° 6
><https://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT41865329=id>*Décret
>n° 2020-548 du 11 mai 2020 prescrivant les mesures générales nécessaires
>pour faire face à l'épidémie de covid-19 dans le cadre de l'état
>d'urgence sanit

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

[Djo_man via Talk-fr]

inistratives
>Comme indiqué dans le document, les limites administratives et le trait de
>côte mènent des vies séparées. Ils sont confondus jusqu'à présent
>principalement par simplicité. La distinction a été faite en
>Grande-Bretagne par exemple (https://osm.org/go/0EUaUjt-). (Où d'ailleurs,
>pour des raisons de définition différente, la limite administrative est
>située plus bas que le trait de côte.) En France, on devrait à peu près
>pouvoir utiliser l'Histolitt pour tracer les limites. (Un exemple local où
>les deux ways sont séparés : https://osm.org/go/erhXbQdi--)
>
>Pour les frontières maritimes, il y a tout ce qu'il faut ici :
>https://data.shom.fr/donnees/contexte/shom_data_context_delmar#001=eyJjIjpbLTUyMTI0MC42MzAxMzcwOTE4NSw1ODMzNTYyLjA5MDE4NDk2NV0sInoiOjYsInIiOjAsImwiOlt7InR5cGUiOiJJTlRFUk5BTF9MQVlFUiIsImlkZW50aWZpZXIiOiJERUxNQVJfUFlSX1BOR19XTERfMzg1N19XTVRTIiwib3BhY2l0eSI6MSwidmlzaWJpbGl0eSI6dHJ1ZX0seyJ0eXBlIjoiSU5URVJOQUxfTEFZRVIiLCJpZGVudGlmaWVyIjoiRkRDX0dFQkNPX1BZUi1QTkdfMzg1N19XTVRTIiwib3BhY2l0eSI6MSwidmlzaWJpbGl0eSI6dHJ1ZX1dfQ==
>
>Thomas.
>
>
>On Tue, 12 May 2020 at 15:09, GarenKreiz  wrote:
>
>> Si on lit attentivement les définitions de MHWS, il faut calculer la
>> moyenne des marées successives de plus haute amplitude au moment des
>> nouvelles et pleines lunes soit 4 marées en gérnéral par mois et non pas
>> pour toutes les marées de vives eaux (coefficent supérieur à 70). Etant
>> donné les variations introduites par la pression atmosphérique et l'effet
>> du vent, je ne suis pas sûr que cela fasse beaucoup de différence entre les
>> deux moyennes et on peut sans doute utiliser la définition la plus simple!
>>
>>
>>
>> On Tue, 12 May 2020 at 12:41, Denis Bigorgne 
>> wrote:
>>
>>> Bonjour,
>>>
>>> Juste un point de détail à corriger dans la page 8 :
>>>
>>> "La ligne de côte pour OSM doit etre placée sur le «mean high water
>>> springs», «pleine Mer Moyenne de vives-eaux» : hauteur moyenne des*
>>> hautes mer de marée de printemps*."
>>> devrai être remplacée par
>>> "La ligne de côte pour OSM doit etre placée sur le «mean high water
>>> springs», «pleine Mer Moyenne de vives-eaux» :  hauteur moyenne des *hautes
>>> mer de vives eaux*"
>>>
>>> ("spring tides" en anglais ne désigne pas les marées de printemps - voir
>>> ""
>>> https://tidesandcurrents.noaa.gov/glossary.html#springtidesortidalcurrents;
>>> : Tides of increased range [...] occurring semimonthly as the result of the
>>> Moon being new or full. )
>>>
>>>
>>> Le lun. 11 mai 2020 à 22:15, Djo_man via Talk-fr <
>>> talk-fr@openstreetmap.org> a écrit :
>>>
>>>> Bonsoir,
>>>>
>>>> Bien sur, il faut diffuser si personne n'y voit à redire.
>>>>
>>>> Djo man
>>>>
>>>>
>>>>
>>>>  Yves P. a écrit 
>>>>
>>>>
>>>> J'ai eu un peu de temps ce week-end pour préciser à la fois l'état du
>>>> tagging
>>>> pour les côtes et décrire les problématiques que cela soulève en terme
>>>> de rendu de carte.
>>>> Il s'agit d'un PDF avec des photos aériennes commentées de JOSM et
>>>> modifiées sur photoshop.
>>>>
>>>> http://pc.cd/ssGrtalK
>>>>
>>>>
>>>> Un grand merci pour ce travail de "dingue" :)
>>>>
>>>> Il m'a permis (entre-autres) de comprendre la différence entre BDOrtho
>>>> IGN et Géolittoral.
>>>>
>>>> ça ne résoudra pas la question du manque de vote pour cette dernière
>>>> modif de wiki
>>>> mais permettra de comprendre ce qui est en jeu pour OSM voire pour
>>>> OPENSEAMAP.
>>>>
>>>> Je peux transmettre le lien à Malcolm Herring (OpenSeaMap) ?
>>>> Il ne parle pas le français, mais devrait suivre les illustrations :)
>>>>
>>>> Le Mont Saint-Michel nous remerciera peut être...
>>>>
>>>> Le rendu standard montre l'estran :) mais comme une zone marcageuse :/
>>>> Pas le carte basque : c'est marrée haute ;D
>>>>
>>>> Encore merci, Djo man :)
>>>>
>>>> __
>>>> Yves
>>>> ___
>>>> 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
>>
>
>___
>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] Evolution des règles pour les plages et la ligne de côte

[Djo_man via Talk-fr]

Bonjour, 

En fait non, j'habite pas le coin, même si je l'apprécie vraiment. Là où c'est 
pas un hazard c'est que je l'ai choisi car je n'y avais pas touché... 

Là ou je sevis c'est le 44. Et je sais que certains pourraient avoir à redire 
sur mon utilisation extensive du tidalflat à la place du tidal=yes. 

J'entends déjà les clairons du " tag pour le rendu" . Mais j' ai une defense:
- c'est pas un tag pour un autre, à mon avis, car tidal=yes n'est pas un tag 
pleinement opérationnel du fait qu'il intervient en ajout secondaire sur un 
autre tag et reclame de diviser des surfaces existantes de rocher/mud/beach 
selon une ligne imaginaire qui, en plus, n'est pas en reflet d'une réalité sur 
le terrain: la coastline. Mais je peux comprendre qu'un tag principal n'est pas 
forcément le top car la mer recouvre plusieurs types d'espaces naturels. 
- mais là où on peut dire qu'il sagit d'un tag naturel quand même c'est que 
l'écosystème mer (avec poissons, etc) vient recouvrir l'écosystème rochers. 
Donc natural=wetland est assez judicieux et permet d'ajuster avec des tag 
secondaires en surcouche. 
-  quand on sait que le modele de tag est conçu en réponse à un probleme de 
rendu du bleu de la mer, il devient logique d'utiliser le seul rendu comme 
méthode de visibilité de l'avancement du travail. 
- la cartographie complete de l'estran du 44 est fait de wetland= tidalflat si 
un jour il faut migrer ça sera facile. 
- et pour finir. Le modèle de tag et le rendu sont à la traine mais on avance 
quand même. 

J'irais jusqu'à dire qu'il y a eu regression dans le rendu des côtes. Regardez 
le rendu de geofabric standard qui est en ce moment l'image du rendu osm.org de 
l'année dernière comparé à celle d'aujourd'hui :  
http://tools.geofabrik.de/mc/#15/47.4402/-2.4886=4=mapnik=geofabrik=mapnik-german=here-map

Bon, certains diront que j'ai triché car j'ai utilisé la transparence nomal du 
tidalflat pour recouvrir les rochers/sand qui normalement n'auraient pas dû 
etre visible (je peux expliquer) mais avouez que c'est une carte tres correcte, 
juste et exploitable. 

Djo man 


Envoyé depuis mon smartphone Xperia de Sony

 Jean-Yvon Landrac a écrit 

>Bonjour voisin (je suppose que le lieu pris n'est pas par hasard),
>
>j'ai à redire (à la marge, c'est déjà très bien).
>Je te passerai en MP, ce soir sans doute, tu en feras ce que tu veux
>(une v2 ?).
>
>J'ai dit à Yves d'attendre si ce n'est pas trop tard. Et ce n'était pas
>trop tard.
>
>De plus j'ai signalé le fil de discussion à Thomas Pétillon qui doit
>être dans la région de Quimper/Bénodet et qui a lui aussi remonté du
>trait de côte. Il a trouvé la discussion intéressante et devrait y
>participer.
>
>Tiens :
>
>https://www.ouest-france.fr/bretagne/lorient-56100/quelques-jours-encore-avant-de-se-mettre-la-plage-de-guidel-larmor-plage-6832671
>
>/Dans le cadre de la loi d’État d’urgence sanitaire, le gouvernement
>doit promulguer le décret qui prévoit l’interdiction d’accès aux plages.
>Charge ensuite au préfet d’accorder des dérogations aux communes./
>
>Donc en absence de décret, c'est autorisé !
>
>Jean-Yvon, Guidelois comme tu t'en doutes
>
>Le 11/05/2020 à 22:15, Djo_man via Talk-fr - talk-fr@openstreetmap.org a
>écrit :
>>
>> Bonsoir,
>>
>> Bien sur, il faut diffuser si personne n'y voit à redire.
>>
>> Djo man
>>
>>
>>
>>
>>  Yves P. a écrit 
>>
>>
>>> J'ai eu un peu de temps ce week-end pour préciser à la fois l'état du
>>> tagging
>>> pour les côtes et décrire les problématiques que cela soulève en
>>> terme de rendu de carte.
>>> Il s'agit d'un PDF avec des photos aériennes commentées de JOSM et
>>> modifiées sur photoshop.
>>>
>>> http://pc.cd/ssGrtalK
>>
>> Un grand merci pour ce travail de "dingue" :)
>>
>> Il m'a permis (entre-autres) de comprendre la différence entre BDOrtho
>> IGN et Géolittoral.
>>>
>>> ça ne résoudra pas la question du manque de vote pour cette dernière
>>> modif de wiki
>>> mais permettra de comprendre ce qui est en jeu pour OSM voire pour
>>> OPENSEAMAP.
>>>
>> Je peux transmettre le lien à Malcolm Herring (OpenSeaMap) ?
>> Il ne parle pas le français, mais devrait suivre les illustrations :)
>>>
>>> Le Mont Saint-Michel nous remerciera peut être...
>>>
>> Le rendu standard montre l'estran :) mais comme une zone marcageuse :/
>> Pas le carte basque : c'est marrée haute ;D
>>
>> Encore merci, Djo man :)
>>
>> __
>> Yves
>>
>> ___
>> 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] Evolution des règles pour les plages et la ligne de côte

[Djo_man via Talk-fr]

Bonjour, 

Oui, c'est exact. Je modifie pour la v2.

 J'ai voulu faire du littéral simpliste (à l'anglaise) aidant à la 
comprehension mais ce n'est pas precis. La majorité des marées en question 
(servant au calcul de cette moyenne) sont bien de printemps en general. 
D'ailleurs cette année c'était une 119 dans le week-end du 8 mai mais personne 
n'a eu le droit de la voir

Djo man 

Envoyé depuis mon smartphone Xperia de Sony

 Denis Bigorgne a écrit 

>Bonjour,
>
>Juste un point de détail à corriger dans la page 8 :
>
>"La ligne de côte pour OSM doit etre placée sur le «mean high water
>springs», «pleine Mer Moyenne de vives-eaux» : hauteur moyenne des* hautes
>mer de marée de printemps*."
>devrai être remplacée par
>"La ligne de côte pour OSM doit etre placée sur le «mean high water
>springs», «pleine Mer Moyenne de vives-eaux» :  hauteur moyenne des *hautes
>mer de vives eaux*"
>
>("spring tides" en anglais ne désigne pas les marées de printemps - voir ""
>https://tidesandcurrents.noaa.gov/glossary.html#springtidesortidalcurrents;
>: Tides of increased range [...] occurring semimonthly as the result of the
>Moon being new or full. )
>
>
>Le lun. 11 mai 2020 à 22:15, Djo_man via Talk-fr 
>a écrit :
>
>> Bonsoir,
>>
>> Bien sur, il faut diffuser si personne n'y voit à redire.
>>
>> Djo man
>>
>>
>>
>>  Yves P. a écrit 
>>
>>
>> J'ai eu un peu de temps ce week-end pour préciser à la fois l'état du
>> tagging
>> pour les côtes et décrire les problématiques que cela soulève en terme de
>> rendu de carte.
>> Il s'agit d'un PDF avec des photos aériennes commentées de JOSM et
>> modifiées sur photoshop.
>>
>> http://pc.cd/ssGrtalK
>>
>>
>> Un grand merci pour ce travail de "dingue" :)
>>
>> Il m'a permis (entre-autres) de comprendre la différence entre BDOrtho IGN
>> et Géolittoral.
>>
>> ça ne résoudra pas la question du manque de vote pour cette dernière modif
>> de wiki
>> mais permettra de comprendre ce qui est en jeu pour OSM voire pour
>> OPENSEAMAP.
>>
>> Je peux transmettre le lien à Malcolm Herring (OpenSeaMap) ?
>> Il ne parle pas le français, mais devrait suivre les illustrations :)
>>
>> Le Mont Saint-Michel nous remerciera peut être...
>>
>> Le rendu standard montre l'estran :) mais comme une zone marcageuse :/
>> Pas le carte basque : c'est marrée haute ;D
>>
>> Encore merci, Djo man :)
>>
>> __
>> Yves
>> ___
>> 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] Evolution des règles pour les plages et la ligne de côte

[Djo_man via Talk-fr]

Bonsoir, 
Bien sur, il faut diffuser si personne n'y voit à redire. 
Djo man


 Yves P. a écrit 

>
>> J'ai eu un peu de temps ce week-end pour préciser à la fois l'état du tagging
>> pour les côtes et décrire les problématiques que cela soulève en terme de 
>> rendu de carte.
>> Il s'agit d'un PDF avec des photos aériennes commentées de JOSM et modifiées 
>> sur photoshop.
>> 
>> http://pc.cd/ssGrtalK 
>
>Un grand merci pour ce travail de "dingue" :)
>
>Il m'a permis (entre-autres) de comprendre la différence entre BDOrtho IGN et 
>Géolittoral.
>> ça ne résoudra pas la question du manque de vote pour cette dernière modif 
>> de wiki
>> mais permettra de comprendre ce qui est en jeu pour OSM voire pour 
>> OPENSEAMAP.
>> 
>Je peux transmettre le lien à Malcolm Herring (OpenSeaMap) ?
>Il ne parle pas le français, mais devrait suivre les illustrations :)
>> Le Mont Saint-Michel nous remerciera peut être...
>> 
>Le rendu standard montre l'estran :) mais comme une zone marcageuse :/
>Pas le carte basque : c'est marrée haute ;D
>
>Encore merci, Djo man :)
>
>__
>Yves
>___
>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] Evolution des règles pour les plages et la ligne de côte

[djo_man via Talk-fr]

  
  
Bonjour, 


J'ai eu un peu de temps ce week-end
  pour préciser à la fois l'état du tagging
  pour les côtes et décrire les problématiques que cela soulève en
  terme de rendu de carte.
  Il s'agit d'un PDF avec des photos aériennes commentées de JOSM et
  modifiées sur photoshop.



http://pc.cd/ssGrtalK


  ça ne résoudra pas la question du manque de vote pour cette
dernière modif de wiki
mais permettra de comprendre ce qui est en jeu pour OSM voire
pour OPENSEAMAP.
  Le Mont Saint-Michel nous remerciera peut être...
  Djo man
  



Le 07/05/2020 à 10:06, Yves P. a
  écrit :


  Salut,

Votre discussion est assez technique ;)

Pouvez-vous mettre un lien sur un schéma, une photo aérienne, le(s) rendu(s) et si possible une carte marine pour qu'on puisse suivre ?
(et tant qu'à faire ne pas cartographier n'importe quoi)

Merci,

__
Yves


  
Des fois certains mapper vont même jusqu'à dessiner ses zones encore plus bas que la ligne de basse mer car avec les belles images aériennes et une eau claire on en voit tres bien les contours. C'est presque un autre probleme mais explique bien que l'enchainement de ses zones ressemble à un geant code barre le long des côtes avec beach et bare_rock qui s'enchaînent.

  
  un exemple ici stp :)



___
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] Evolution des règles pour les plages et la ligne de côte

[Djo_man via Talk-fr]

J'aimerais bien et j'y pense depuis un bout de temps car effectivement le wiki 
lui-même (coastline, Beach, bare_rock, mud, tidal, tidalflat, frontieres 
marines, shoal, etc) manque de ces images. Mais il va falloir s'y coller car ce 
n'est pas si simple... 

Djo man 


 Yves P. a écrit 

>Salut,
>
>Votre discussion est assez technique ;)
>
>Pouvez-vous mettre un lien sur un schéma, une photo aérienne, le(s) rendu(s) 
>et si possible une carte marine pour qu'on puisse suivre ?
>(et tant qu'à faire ne pas cartographier n'importe quoi)
>
>Merci,
>
>__
>Yves
>
>> Des fois certains mapper vont même jusqu'à dessiner ses zones encore plus 
>> bas que la ligne de basse mer car avec les belles images aériennes et une 
>> eau claire on en voit tres bien les contours. C'est presque un autre 
>> probleme mais explique bien que l'enchainement de ses zones ressemble à un 
>> geant code barre le long des côtes avec beach et bare_rock qui s'enchaînent.
>un exemple ici stp :)
>
>
>
>___
>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] Evolution des règles pour les plages et la ligne de côte

[Djo_man via Talk-fr]

Pour préciser mon point de vue. 

Au sujet de l'autonomie du trait de côte par rapport à la plage, je l'estime 
nécessaire car
toute la longueur des cotes mappées sera à terme constituée de zones de 
rochers, de zone de sables, beach ou natural=sand, de zone de natural=mud. Ses 
zones vont, pour les roches et les sables, le plus couramment du natural=heath 
ou grass qui ne voient jamais aucunes marées en haut jusqu'au plus bas de la 
plus basse mer. 

Des fois certains mapper vont même jusqu'à dessiner ses zones encore plus bas 
que la ligne de basse mer car avec les belles images aériennes et une eau 
claire on en voit tres bien les contours. C'est presque un autre probleme mais 
explique bien que l'enchainement de ses zones ressemble à un geant code barre 
le long des côtes avec beach et bare_rock qui s'enchaînent. 

Il serait donc pour moi  illogique que par extension du modèle de tag (qui 
paliait d'abord à des problèmes de rendu)  l'on cherche à répercuter le 
découpage horizontal des plages (pour reprendre la logique de l'orientation du 
code barre donc Nord sud des plages) sur les 2 autres type de zones naturelles. 
On risque de se retrouver avec 6 zones differentes au lieu de 3. 

Donc pour moi l'estran qui va jusqu'à la coastline (on pourrait aussi remettre 
ça en cause ) doit être une grande zone qui recouvre toutes les zones 
naturelles du bord de mer. 

Djo man

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

Re: [OSM-talk-fr] Evolution des règles pour les plages et la ligne de côte

[Djo_man via Talk-fr]

Bonjour, 
Non, non, je fais bien référence à une modif du wiki de 2017 de natural =beach 
précédent celle de 2019 en question sur ce fil. 

Je peux retrouver les dates et les noms si besoin. 

Djo man



 osm.sanspourr...@spamgourmet.com a écrit 

>Djo man fait référence à une modification de Key:tidal
><https://wiki.openstreetmap.org/w/index.php?title=Key:tidal=1905678=1368829>.
>
>Du coup https://wiki.openstreetmap.org/wiki/FR:Key:tidal n'est plus à jour.
>
>Et avoir un bon rendu sera plus difficile.
>
> > /Le rendu de la mer à changé recemment. Maintenant le jaune des
>plages est recouvert par le bleu de la mer. /
>
>Encore une horrible décision venue de nulle part je crains (gouvernance
>des forts en gueule ?).
>
>
>/Donc maintenant on peut sans dommage changer le modèle de tag pour
>dessiner une vraie plage unique estran compris et espèrer bientôt une
>prise en compte des tidal./
>
>/
>/
>
>Comme le fait le rendu HOT ou mieux le rendu OSM France
><http://tile.openstreetmap.fr/?zoom=16=47.7660=-3.5278=B000FFF>./
>/
>
>Résultat : la plage de la falaise à Guidel
><https://www.openstreetmap.org/way/4535618#map=16/47.7660/-3.5251>
>disparait côté mer mais reste côté Laïta. D'ailleurs en regardant les
>données ce n'est pas la ligne de côte (coastline) qui fait la différence
>mais le fait que ce soit dans une commune ou pas. En effet la Laïta fait
>partie du trait de côte depuis 10 mois.
>
>Avec l'affichage actuel, la plage est réduite à la zone de marnage entre
>la pleine mer de 95 et celle de 120, c'est à dire à une peau de chagrin.
>D'un point de vue logique ça devrait être aussi entre la basse mer de 95
>et la pleine mer de 95 (tidal=yes).
>
>/D'ailleurs, vu que la costline doit etre accrochée sur la moyenne des
>hautes mer elle est de fait amenée à evoluer avec le temps mais à mon
>avis sans qu'aucun point de la coastline ne soit partagé avec le contour
>de la plage ce qui permet de bouger cette ligne sans toucher à la limite
>entre le sable et les rochers. /
>
>Je ne comprends pas : le sable va et vient, facilement 50 cm de
>différence entre l'été et l'hiver, la plage se déplace donc bien plus
>que le trait de côte. Regardez les différentes vues aériennes de ce coin
>par exemple.
>
>Avec aussi des galets qui "disparaissent" ou "apparaissent" (sur
>d'autres plages).
>
>Et les deux évoluent en même temps.
>
>Le trait de côte n'est pas la limite sable/rochers, il y a des zones
>sableuses où le haut de la plage est une dune.
>
>Que tu déplaces le trait de côte et que les deux côtés de la plage
>(tidal=yes ou pas) suivent ou que tu utilises une plage de part et
>d'autre de ce trait ne change rien : tu devras déplacer le trait de côte
>s'il recule (ou plus rarement avance - dunes en arrière d'un estuaire
>par exemple) et déplacer la plage si elle se déplace.
>
>N. B; : plage est incorrect : beach recouvre aussi les grèves.
>
>Jean-Yvon
>
>Le 06/05/2020 à 22:03, Djo_man via Talk-fr - talk-fr@openstreetmap.org a
>écrit :
>
>___
>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] Evolution des règles pour les plages et la ligne de côte

[Djo_man via Talk-fr]

Bonjour,

Pour moi, le débat est légèrement décalé :

Apres avoir beaucoup retravaillé la ligne de côte depuis pas mal d'année, j'en 
viens à conclure que le modèle de tag pour les plages est historiquement un 
tagguing pour le rendu. 

Et non, ce n'est pas un troll de ma part. Je m'explique. 

Il y a 3 ans quand le wiki a été modifié pour ajouter que la plage ne devait 
descendre que jusqu' à la ligne de la moyenne des hautes mer, la coastline, il 
n'etait, de memoire, pas encore question de tagguer le reste de l'estran en 
autre chose. Le natural schoal est arrivé plud tard. 

Le rendu de la mer passant en premiere couche, (pour des questions 
d'obligation, je crois, à l'epoque) les plages dessinées avec estran compris 
devenaient trop grandes et recouvraient la ligne de coastline. Ça faisait 
désordre. 

Il y a eu debat et même ici sur la question tout à fait judicieuse de ce qu'il 
fallait faire au sujet des plages qui n'existent qu'a de petites marées. Pas 
solution trouvé à part faire descendre la costline au niveau de la basse mer. 

Le rendu de la mer à changé recemment. Maintenant le jaune des plages est 
recouvert par le bleu de la mer. 

Donc maintenant on peut sans dommage changer le modèle de tag pour dessiner une 
vraie plage unique estran compris et espèrer bientôt une prise en compte des 
tidal.

D'ailleurs, vu que la costline doit etre accrochée sur la moyenne des hautes 
mer elle est de fait amenée à evoluer avec le temps mais à mon avis sans 
qu'aucun point de la coastline ne soit partagé avec le contour de la plage ce 
qui permet de bouger cette ligne sans toucher à la limite entre le sable et les 
rochers. 

Donc perso, je trouve que ça va dans le bon sens même si la carte osm.org n'a 
pas encore trouvé le truc (ou les ressources de calcul) pour créer un estran 
par transparence pour montrer à la fois le sable, les rochers, la vase. 

Djo man



Envoyé depuis mon smartphone Xperia de Sony

 GarenKreiz a écrit 

>Bonjour,
>
>Je viens de m'apercevoir que les règles concernant le positionnement des
>surfaces "beach" par rapport au chemin "coastline" ont été modifiées en
>février 2019 dans le wiki anglophone (par "imagico"), modification qui n'a
>pas encore été répercutée dans le wiki français.
>
>Une plage pourrait être maintenant positionnée sous la ligne de côte ou
>même être traversée par elle. Une telle évolution des règles me semble
>assez structurante et j'aimerais connaître le processus de décision : y
>a-t-il eu un vote? Comment sont tracées ce type de décisions?
>
>Cordialement
>
>___
>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] Re: zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO

[djo_man via Talk-fr]

  
  


  
https://wiki.openstreetmap.org/wiki/Key:winery
Cette page me semble inopérante

  


inopérante pour décrire le vin geographiquement car bien souvent, il y a plusieurs vins par domaine. ils peuvent etre de plusieurs AOP ou IGP et des fois rien pour certains domaines. par exemple, il est tres courant dans le beaujolais qu'il y ai 2 AOp différents plus un IGP. Cela vient du fait que les appellations sont assises sur les parcelles.

il pas question de taguer à la parcelle mais pour un landuse
donc il faut décrire ce qui est potentiellement possible sur le landuse

les appellations sont bien géographique

://en.wikipedia.org/wiki/List_of_wine-producing_regions
  si tu veux mapper des régions, mape des régions.


on est pas obligé de mapper des régions quand on a des landuses
  déjà présents. Ils sont bien réels.

je ne comprends pas la remarque de
  osm.sanspourr...@spamgourmet.com  : Loire Valley n'est pas une
  region adminstative. ces regions sont des dénominations qui sont
  aussi reprises sur le traité de lisbonne qui décrit les
  protections des AOP.

le nom des régions est important car par exemple : Madiran juste
  à coté de la région de Bordeaux à un nom très spécifique. 

Comme Champagne ou Bourgogne, Rhône. la limite être ses régions
  est importante


  
- vineyard:appellation:aop= issu de la base INAO ("appellation" car la 
WIPO (wolrd intellectual property organization) l'utilise 
  

oui, pourquoi pas mettre les termes internationaux. PDO et PGI

  je comprend pas la différence.
*=blabla AOP ou *=truc IGP ne va pas ?

les landuses peuvent être à la fois AOP et IGP et leur nom est
  différent. 

il faut trouver une manière de lister la classification puis leur
  nom
oui, peut être se limiter à ne mettre que
  vineyard:appellation:pdo = "name" et vineyard:appellation:pgi =
  "name"


  


c'est  pas de l'humour noir, c'est sarcastique...
les appellations françaises ne sont pas si simples donc...


djo


  ___
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] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO

[djo_man via Talk-fr]

  
  

Une page du wiki m'en a donné l'idée.
  https://wiki.openstreetmap.org/wiki/Key:winery

Cette page me semble inopérante car elle est basée sur le tag
  craft=winery + winery= "" plutot que landuse=vineyard. 

En europe et assez largement dans le monde ou des appellations
  sont présentes, le classement des vins est basé sur le type de
  cépages sur des parcelles repérées donc de la vigne.


Je propose alors sur le landuse=vineyard (un ensemble de
  parcelles):
- vineyard:regions= regions selon la page de wikipedia
  https://en.wikipedia.org/wiki/List_of_wine-producing_regions
- vineyard:classification= AOP ou/et IGP
- vineyard:appellation:aop= issu de la base INAO ("appellation"
  car la WIPO (wolrd intellectual property organization) l'utilise
  https://www.wipo.int/ipdl/en/search/lisbon/search-struct.jsp)
- vineyard:appellation:igp= issu de la base INAO (conforme à
  l'europe)

- vineyard:denomination= issu de la base INAO ("denomination"
  franco français mais pas uniquement car d'autre régions du monde
  ont repis l'idée)
on pourrait rajouter le reste au besoin :
- vineyard:grape= cépages selon la page wikipedia
  https://en.wikipedia.org/wiki/List_of_grape_varieties (il faudrait
  le faire à la parcelle mais on le fait bien pour les arbres...)


ça plait ?

ça fait réagir quelqu'un ?
djoman


    
Le 17/06/2019 à 10:07, djo_man via
  Talk-fr a écrit :


  
  
  Bonjour à tous, 
  
  Je ne trouve pas de file de discussion parlant de la
possibilité de préciser par un tag les appellations AOC/AOP/IGP
des zones landuse=vineyard.
  On en a jamais parlé ? si ?
  
  https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dvineyard
  
  l'INAO en France fourni actuellement un shp des zones
d'appellation (480Mo !) et met actuellement à jour sa base. Une
reforme est en ce moment en cours pour simplifier et rénover les
périmètres. Une bonne moitié des périmètres sont déjà approuvés
et disponibles sur le site de l'INAO. Le reste est en cours de
concertation et les projets sont disponibles sur le site de
l'INAO.
  https://www.inao.gouv.fr/Espace-professionnel-et-outils/Suivi-des-demarches/Consultations-publiques-des-projets-d-aires-geographiques-ou-parcellaires-delimitees-des-AOC-et-IGP
  
  Personnellement, je n'envisage pas d'intégrer les périmètres
mais plutôt d'ajouter 1 tag ou 2 sur des ways existants de
landuse=vineyard en les recoupant au besoin.
  
  Djoman
  
  
  
  ___
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

[OSM-talk-fr] zones viticoles - appellation AOC/AOP/IGP et sous-destination INAO

[djo_man via Talk-fr]

  
  
Bonjour à tous, 

Je ne trouve pas de file de discussion parlant de la possibilité
  de préciser par un tag les appellations AOC/AOP/IGP des zones
  landuse=vineyard.
On en a jamais parlé ? si ?

https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dvineyard

l'INAO en France fourni actuellement un shp des zones
  d'appellation (480Mo !) et met actuellement à jour sa base. Une
  reforme est en ce moment en cours pour simplifier et rénover les
  périmètres. Une bonne moitié des périmètres sont déjà approuvés et
  disponibles sur le site de l'INAO. Le reste est en cours de
  concertation et les projets sont disponibles sur le site de
  l'INAO.
https://www.inao.gouv.fr/Espace-professionnel-et-outils/Suivi-des-demarches/Consultations-publiques-des-projets-d-aires-geographiques-ou-parcellaires-delimitees-des-AOC-et-IGP

Personnellement, je n'envisage pas d'intégrer les périmètres mais
  plutôt d'ajouter 1 tag ou 2 sur des ways existants de
  landuse=vineyard en les recoupant au besoin.

Djoman

  


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

Re: [OSM-talk-fr] Tag pour constructeur de maisons ?

[djo_man]

  
  
à écrire ça, tu méconnais le travail
  des architectes.
  Leur travail ne s’arrête certainement pas à la production de jolis
  plans...
  Ils font presque tous de la coordination de chantier.
  C'est en général les responsables du déroulé des chantiers.
  On appelle ça "la direction de chantier" dans  le jargon des
  bâtiments publics.
  Comme tout bon maître d’œuvre qui assume son boulot...
  ça se perd, c'est vrai, dans le marché privé de la "maison" et de
  la promotion immobilière de base.
  
  djoman
  
  Le 24/10/2016 à 20:38, pepilepi...@ovh.fr a écrit :


  
  Le 24/10/2016 à 00:55, Jérôme Amagat
a écrit :
  
  

  [...]
  
  Après avoir fait ton choix tu peux aussi ajouter quelque chose
  sur la page de discussion de office= https://wiki.openstreetmap.org/wiki/Talk:Key:office
  en expliquant un peu ce que fait cette entreprise et ton choix
  pour voir ce qu'en pense d'autres (des anglophones qui
  connaissent un peu ce type de travail).

  
  Comme ça
?
  J'ai un peu l'impression de lancer une bouteille à la mer...
  Bonne soirée,
  JP
  


  


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

Re: [OSM-talk-fr] Re: Rendu FR... un peu de neuf

[djo_man]

  
  
Bonjour, 

merci à toi, Christian, pour tous tes efforts.
ça avance, ça avance. De nouveaux rendus qui donnent envie d'en
  ajouter dans la base...
Dans la prolongation de la question du trait de côte, j'oserais
  demander un petit rendu qui permettrait de rendre visible une
  chose assez présente dans la base , les water=tidal . D'autant que
  les natural=bare_rock  et les natural=mud, avec ou sans tidal=yes,
  viennent parfois gâcher la compréhension du trait de côte et des
  limites de ce qui est recouvert:
  https://www.openstreetmap.org/#map=16/47.3030/-2.5119
Les premiers rendus de mer sur ORG recouvrant tout jusqu'au trait
  de côte placé très haut sur la côte (la moyenne des vives-eaux
  équivalent à un coef 95, de mémoire). La solution trouvée il y a 2
  ans de faire venir au premier plan les plages recouvertes par le
  trait de cotes à permis de rendre un usage à la carte mais comme
  le problème datait depuis assez longtemps, les traits de côtes ont
  étés très largement descendus sur l'estran afin de montrer un peu
  de plage et de barres rocheuses. J'avoue avoir fait ça moi aussi
  d'autant que l'on avait pas la nouvelle génération V2 de la
  géolittoral ni les orthophotos de qualité (sur le 44 notamment).

Je propose (sans savoir si c'est facilement réalisable) que tous
  les water=tidal (et les tidal=yes en sur-couche) soient bleus à
  l’identique de la mer mais auraient un mode de fusion de type
  produit avec les natural=beach, natural=bare_rock et natural=mud
  se trouvant au dessous. L'avantage serait que les surfaces de
  sables sous le trait de côte prennent une teinte bleue sans trop
  contraster avec les zones de rocher qui n’auraient pas été
  renseignés (trous bleus) : 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#18/47.10305/-2.08575
au passage, il faudrait faire venir les natural=bare_rock non
  rendus sur FR mais sur ORG:
  https://www.openstreetmap.org/#map=17/47.27940/-2.50289
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#17/47.27951/-2.50389

Une autre solution de rendu reprendrait un motif pointilliste
  bleu (des carrés tournés dans le désordre, remplissant au moins
  50% de la surface). Cette fois les motifs seraient opaques et les
  tidal blancs et mais laisseraient passer dans leur blanc les
  natural se trouvant dessous mais pas la mer.

La question de la ligne de limite administrative du trait de côte
  pourrait peut-être être remise à plus tard, car surimpressionnée ?
je pousse le bouchon un peu trop ?
Le poisson va morde cette fois ou bien c'est trop tôt ?
J'attendrais la marée...

djoman


Le 03/09/2016 à 22:38, Christian Quest
  a écrit :


  
 Les nouveautés du samedi...
  
  - bug corrigé sur les ponts, et j'en ai profité pour ajouter
  le rendu des man_made=bridge ce qui permet de voir l'emprise
  des ponts, exemple:
  http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#18/48.85716/2.34108
  
  - l'ordre de priorité pour placer les noms dans les petites
  échelles (zoom 6 par exemple) est revu, et Vannes est bien au
  rendez-vous:
  http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/46.958/2.615
  
  - des icônes de commerces avaient disparu, elles sont de
  retour (contrôle technique, lavage auto, glaces, etc)
  

 - icône pour les bornes de recharge de
  véhicules électriques: http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#17/47.85187/3.54325
  

ainsi que plein de petites bricoles...
  

Pour les côtes, je vais voir ce que je
  peux faire, en fait les limites administratives n'ont pas
  besoin d'être mises sur les côtes, mais encore faut-il pouvoir
  faire le tri ;)
  


  -- 
Christian Quest - OpenStreetMap France

  
  
  
  
  ___
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

[OSM-talk-fr] attribution homengo.com

[djo_man]

  
  
bonsoir

Homengo n'ont à priori pas d'attribution sur la carte...

djo_man
  


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

Re: [OSM-talk-fr] DKIM Re: Démo recherche d'adresse / POI (Jour de Fête)

[djo_man]

  
  
bonjour, 

"général de gaulle, Nantes" ne donne rien à Nantes
sur Nominatim c'est en premier résultat.

c'est pas encore ça
ça m'a l'air bien compliqué les outils de recherche.
Qu'est ce qui bloque dans l'absolu ?

(je sais que je ne devrais pas poser ce genre de question en ces
temps de crise de foie)
    djo_man


Le 20/12/2014 10:51, Cyrille Giquello a
  écrit :


  Étonnant !
Sur osm.org aucun résultat pour "rue pierre mandes france, Limoge".
Sur http://dev.geovelo.fr/jdf/ il y a des propositions, dont la bonne
rue "Rue Pierre Mandés-France, Limoges".

Ne pourrait-on pas avoir ce moteur de recherche sur
http://tile.openstreetmap.fr/ ?

Le 15 octobre 2014 18:52, GaelADT gael.sauva...@gmail.com a écrit :

  
Bonjour,

Nous en avions parlé rapidement lors de SotM France : nous (Géovélo  Luc
Léger, contributeur OSM) travaillons depuis quelque temps sur un système de
recherche de rue / POI / etc. Ce projet s'appelle pour le moment Jour de
Fête : https://github.com/lluc/django_jdf

Un site de démo a été mis en place histoire de donner une idée à tout le
monde, avec les données France (pas forcément super à jour) :
http://dev.geovelo.fr/jdf/

Attention ce n’est pas fait pour de la production: le serveur peut donc
potentiellement être un peu long à retourner des résultats. Et il reste
encore pas mal de soucis à régler, mais c’est un début.

Pour faire simple : il n'y a aucun outil suffisamment ergonomique, libre,
pour qu'un utilisateur lambda trouve un objet sur OSM, si possible avec de
l'auto-complétion. Si bien qu'aujourd’hui beaucoup de services utilisent
Google pour la recherche d’adresse ou de POI.

Ce que nous avons fait n'est pas forcément un truc révolutionnaire, mais
nous espérons que cela sera une nouvelle étape pour rendre OSM plus
accessible en France et que cela ferra enfin bouger les choses niveau
geocoding (chez Géovélo on en a marre d'utiliser l'API Google pour
l'autocomplétion !)

Voici ce qu'est aujourd'hui "Jour de Fête" :
- un projet libre qui est basé sur les données d'un import Nominatim,
- recherche phonétique d'objet OSM ("avenue edouar michelin" sera reconnu),
- reconnaissance sémantique ("rue edouard michelin" sera reconnu, même s’il
existe uniquement  "avenue edouard michelin"),
- un outil entièrement configurable : on peut choisir les tags OSM qui
doivent être reconnus (une option existe pour tout sortir), on peut choisir
dans quel ordre doivent sortir les résultats (exemple les villes avant les
rues, etc.).

Exemples concrets d’utilisation :
- rechercher uniquement les rues (ou tout autre chose) sur le territoire
d’une commune,
- rechercher uniquement les gares, arrêts de bus, de tramway, de métro et
les ordonner (d’abord les gares, puis les arrêts, etc.)
- et bien sur notre exemple pour Géovélo faire une recherche d’adresse / POI
fine en choisissant précisément les types de POI que l’on veut faire
remonter et dans quel ordre (commune avant quartier, quartier avant avenue,
gare avant magasin, etc.)

Ce qu'il reste à faire / Roadmap :
- optimiser les temps de réponse, voir ce que cela donne sur un serveur
digne de ce nom,
- recherche partielle ("zola tours" sera reconnue)
- forcer la recherche sur une bounding box
- ajouter les numéros de rue : Faire un lien vers BANO ?
- améliorer l'ordonnancement des résultats
- faire une mise à jour des données via les diff de OSM (la mise à jour des
données prend 1 heure pour la France actuellement)

Voilà merci d’avance pour vos retours.

Gaël.



--
View this message in context: http://gis.19327.n5.nabble.com/Demo-recherche-d-adresse-POI-Jour-de-Fete-tp5820413.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

[OSM-talk-fr] BANO - rapprochement dans l'rouge, mystère

[djo_man]

  
  
bonjour, 

ici:
http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#16/47.4607/-2.2532
ça reste rouge et pourtant là c'est bon :
http://cadastre.openstreetmap.fr/fantoir/#insee=44098

les orthographes sont différentes. 
Par exemple : Rue des Tisserands=OSM, FANTOIR=440980389D contre "Rue
des Tisserandscoulement" pour l'affichage BANO
on est bien à coulement et dans le fichier FANTOIR "DES TISSERANDS"
n'est pas collé à "COULEMENT"

autre mystère : RUE DES TISSERANDS COULEMENT est dans la case "voies
sans adresses" alors que l'on voit bien qu'il y en a des adresses.

il y a t'il un problème sur la liste de rapprochement de "voies sans
adresses" ?
ou bien existerait-il d'autres voies pourtant les mêmes noms que je
ne vois pas ?
ou bien ?

djoman
  


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

Re: [OSM-talk-fr] BANO - rapprochement dans l'rouge, mystère

[djo_man]

  
  
Dans ce cas il faut donc ajouter Tournoly...

http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/47.46965/-2.23004

merci
djoman


Le 14/12/2014 15:37, Vincent de
  Château-Thierry a écrit :


  
  Le 14/12/2014 15:00, djo_man a écrit :
  
  

ici:

http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#16/47.4607/-2.2532

ça reste rouge et pourtant là c'est bon :

http://cadastre.openstreetmap.fr/fantoir/#insee=44098


les orthographes sont différentes.

Par exemple : Rue des Tisserands=OSM, FANTOIR=440980389D contre
"Rue des

Tisserandscoulement" pour l'affichage BANO

on est bien à coulement et dans le fichier FANTOIR "DES
TISSERANDS"

n'est pas collé à "COULEMENT"


autre mystère : RUE DES TISSERANDS COULEMENT est dans la case
"voies

sans adresses" alors que l'on voit bien qu'il y en a des
adresses.


il y a t'il un problème sur la liste de rapprochement de "voies
sans

adresses" ?

ou bien existerait-il d'autres voies pourtant les mêmes noms que
je ne

vois pas ?

ou bien ?

  
  
  Les 6 rues avec 'Coulement' collé dans le nom du Cadastre avaient
  un code Fantoir dans OSM, donc le rapprochement se faisait entre
  Fantoir et OSM, d'où la présence dans les colonnes vertes. Mais
  comme l'orthographe côté Cadastre divergeait aussi bien du Fantoir
  (où 'Coulement' est décollé) que d'OSM (ou il n'y a pas de
  'Coulement') le cadastre ne participait pas au rapprochement. Au
  final, pas d'adresses en base BANO (donc pas de présence dans la
  rubrique 'Voies avec Adresses') et du rouge car on n'a bien des
  adresses issues du Cadastre, mais non rapprochées.
  
  Le souci, c'est 'Coulement' collé, ce qui est un bug côté BANO.
  C'est géré / contourné par un fichier qui liste ces collages
  abusifs. En rentrant les 6 noms en question dans le fichier, tout
  va mieux :
  
  http://cadastre.openstreetmap.fr/fantoir/#insee=44098
  
  
  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] Bano - nouveaux rapprochements ?

[djo_man]

  
  
Bonjour, 

une erreur de rapprochement est systmatique ds que le nom affich
dans BANO comporte  la fin du nom le numro de la voie
exemple: Rue Auguste Masson (Vc61)
Le nom de la rue est bonne dans OSM

Le Croisic est du coup tout rouge !
alors qu'il pourrait tre presque bleu

j'ai commenc  renseigner le FANTOIR mais c'est trop fastidieux...

merci  tous pour cet outil !
djo_man


Le 03/06/2014 12:26, Christian Quest a
  crit:


  Une passe complte a t refaite.


On est pass  14,88 million d'adresses ddoublonnes.


On en est  "amliorer encore les rapprochements",
  amlioration sur 2 axes:
- rapidit: pour faire des rapprochements beaucoup
  rgulirement, idalement quotidiens
- qualit: rapprocher un peu plus de donnes


  
  


  Le 3 juin 2014 11:24, Lenny lenny.li...@orange.fr a
  crit :
  
Bonjour,
J'ai lu dans un des fils prcdents que c'tait une des
prochaines tapes prvues.
http://gis.19327.n5.nabble.com/BANO-100-des-departements-traites-td5807147.html
lenny

Le 01/06/2014 21:19, JB a crit :

  

  Bonjour,
  Est-ce qu'un nouvelle srie de rapprochement
  OSM-Cadastre va tre lance ?
  (C'est utile aprs une semaine d'ajouts de noms de rue
  de tous les cots, on voit plus o on en est).
  JB.
  
  ___
  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
  

  





-- 
Christian Quest - OpenStreetMap France
  
  
  
  
  ___
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] OpenStreetMap Stack Mind Map (cartographie conceptuelle)

[djo_man]

  
  
bonjour, 

OSMAND est offline et online (le wiki n'est pas  jour)
c'est vrai que le offline est encore quelque peut limit aux courtes
distances mais samliore de mise  jour en mise  jour

djo_man



Le 15/04/2014 09:56, Christophe Rodier
  a crit:


  

  

  Bonjour,

Je viens de finir la v2 d'une mind map (cartographie conceptuelle) autour
d'OpenStreetMap.

  
  Suite  une prsentation impromptu de la v1 lors du
SOTMFR (merci  Christian Quest pour avoir fait la
prsentation), j'ai reu des retours sur des choses
manquantes et d'autres qui taient mal places. Donc
pour la v2 j'ai utilis un nouvel outil (MindMeister) et
rajouter des liens et notes sur (presque) chaque lment.
  
  
  
  C'est par ici: http://threefiftythree.com/osm-stack-visualisation/
  
  Je l'ai envisag comme un outil d'apprentissage pour
  visualiser les multiples facettes du monde OSM. Si a
  peut-tre utile  d'autres (dbutants ou confirms), tant
  mieux.
  
  Bien sur, tout n'est pas inclus, il n'est pas possible de
  tout inclure, il faut bien s'arrter  un moment. 
  Si vous avez des conseils, voyez de gros
oublis, des erreurs ou des points qui devraient tre
dplacs ou lis, dites-le moi. Et si vous souhaitez
participer, dites-le moi aussi. Et puis merci de faire
circuler et partager si vous pensez que c'est utile.

  
Merci

Christophe
  

  

PS: Je n'ai pas pu trouver quelque chose de similaire sur le
web, mais si a existe merci de m'envoyer le lien.
  
  
  
  ___
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] natural=cloud

[djo_man]

  
  
bonjour, 

J'ai test et a marche !
Il pleut vraiment  cet endroit

http://www.openstreetmap.org/way/270790379


djo_man



Le 01/04/2014 08:46, Pierre Knobel a
  crit:


  Je me colle  la traduction.
  
  

2014-04-01 8:32 GMT+02:00 Pierre-Yves
  Berrard pierre.yves.berr...@gmail.com:
  
Gnial !
  On l'attendait avec impatience.


  
  
2014-04-01 8:28 GMT+02:00 Christian Quest cqu...@openstreetmap.fr:

  

  Personne pour la traduction en
franais ?
  


  2014-04-01 8:02 GMT+02:00 Pierre Knobel pierr...@gmail.com:
  

  Bonjour,

Un nouveau tag pour la carto 3D : https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcloud
. Ne pas oublier de rajouter un layer=*.

  
  Pierre


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

  





-- 
Christian Quest -
  OpenStreetMap France
  Confrence "State Of
  The Map" France du 4 au 6 avril 
  Paris

  
  
  ___
  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




  


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

Re: [OSM-talk-fr] Riverbank - de retour

[djo_man]

  
  
bonjour, 

Sans doute que prdemment il tait outer dans la grande relation
mais vue que je suis en train de remettre les choses comme il faut
c'est  dire une relation par outer ds qu'il y a des iles
pas de relation quand il n'y pas d'iles
l je me rappelle qu'il n'y a pas d'ile (trs rare)
et bien il doit etre tout seul sans les bons tags maintenant..
voir prcdente discussion

Je regarde cela de suite.

djo_man


Le 02/03/2014 13:47, JB a crit:

Si quelqu'un
  comprend celui-l :
  
http://www.openstreetmap.org/note/125800#map=13/47.2736/-1.9258layers=N
  
  Le riverbank n'est pas rendu sur ce tronon, alors que celui de
  l'ouest l'est. La seule diffrence que je vois est que celui de
  l'ouest est dans un multipolygone avec les mmes tags sur le MP
  (mais un tag rsiduel riverbank est sur le way).
  
  JB.
  
  
  ___
  
  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] Riverbank - de retour

[djo_man]

  
  
Ben l, je sche.
Rien a voir avec la problmatique des relations imbiques.
(disparition des iles dont l'ile de nantes)
Ni celle sur la problmatique d'une trop grosse relation. (modles
et usage de la base)

- Le riverbank est des plus simples avec le bon tag et sans
relation, sans iles, sans super relation 
rien que du trs commun.
- Le riverbank juste en amont qui est exactement sur le mme modle
(pas de relation, etc) est lui bien rendu...
- La seule petite diffrence c'est que celui qui n'est pas rendu a
un "name". c'est quand mme pas cela ?

donc
soit il est en cours de rendu.
soit un problme de prise en compte dans la base.

une autre ide ?

    djo_man

Le 02/03/2014 19:35, djo_man a crit:


  
  bonjour, 
  
  Sans doute que prdemment il tait outer dans la grande relation
  mais vue que je suis en train de remettre les choses comme il faut
  c'est  dire une relation par outer ds qu'il y a des iles
  pas de relation quand il n'y pas d'iles
  l je me rappelle qu'il n'y a pas d'ile (trs rare)
  et bien il doit etre tout seul sans les bons tags maintenant..
  voir prcdente discussion
  
  Je regarde cela de suite.
      
      djo_man
  
  
  Le 02/03/2014 13:47, JB a crit:
  
  Si quelqu'un
comprend celui-l : 
http://www.openstreetmap.org/note/125800#map=13/47.2736/-1.9258layers=N

Le riverbank n'est pas rendu sur ce tronon, alors que celui de
l'ouest l'est. La seule diffrence que je vois est que celui de
l'ouest est dans un multipolygone avec les mmes tags sur le MP
(mais un tag rsiduel riverbank est sur le way). 
JB. 

___ 
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] Riverbank - de retour

[djo_man]

  
  
Bon, 
a semble rgl (generation en cours des tuiles aux zooms
18--15)
Mais je ne peux dire ce qui a vraiment march
- modification de la gometrie ?
- suppression du name (je le remettrais plus tard ) ?
- reconnection des ways des waterway=river avec un noeud sur le
pourtour des riverbank ?
- ou tout simplement une rcriture dans la base ?

djo_man


Le 02/03/2014 19:54, djo_man a crit:


  
  Ben l, je sche.
  Rien a voir avec la problmatique des relations imbiques.
  (disparition des iles dont l'ile de nantes)
  Ni celle sur la problmatique d'une trop grosse relation. (modles
  et usage de la base)
  
  - Le riverbank est des plus simples avec le bon tag et sans
  relation, sans iles, sans super relation 
  rien que du trs commun.
  - Le riverbank juste en amont qui est exactement sur le mme
  modle (pas de relation, etc) est lui bien rendu...
  - La seule petite diffrence c'est que celui qui n'est pas rendu a
  un "name". c'est quand mme pas cela ?
  
  donc
  soit il est en cours de rendu.
  soit un problme de prise en compte dans la base.
  
  une autre ide ?
      
      djo_man
  
  Le 02/03/2014 19:35, djo_man a
crit:
  
  

bonjour, 

Sans doute que prdemment il tait outer dans la grande relation
mais vue que je suis en train de remettre les choses comme il
faut
c'est  dire une relation par outer ds qu'il y a des iles
pas de relation quand il n'y pas d'iles
l je me rappelle qu'il n'y a pas d'ile (trs rare)
et bien il doit etre tout seul sans les bons tags maintenant..
voir prcdente discussion

Je regarde cela de suite.
    
    djo_man


Le 02/03/2014 13:47, JB a crit:

Si
  quelqu'un comprend celui-l : 
  http://www.openstreetmap.org/note/125800#map=13/47.2736/-1.9258layers=N
  
  Le riverbank n'est pas rendu sur ce tronon, alors que celui
  de l'ouest l'est. La seule diffrence que je vois est que
  celui de l'ouest est dans un multipolygone avec les mmes tags
  sur le MP (mais un tag rsiduel riverbank est sur le way). 
  JB. 
  
  ___ 
  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




  


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

Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

[djo_man]

  
  
bonjour, 

ab_fab:
non pas du tout.
il ne s'agit pas d'une relation par ways ouverts outer mais d'une
relation ajoutant des ways ferm outer

djo_man

Le 07/02/2014 09:03, Ab_fab a crit:


  
Bonjour,

  
"Il
n'existe donc plus qu'une seule relation type=multipolygone
+ waterway=riverbank" (pour toute la Loire)


  
Pour le rendu cela signifie qu'en voulant faire le rendu d'une
tuile  St Nazaire, tu dois aller charger des donnes jusqu'au
Puy en Velay pour vrifier que l'tendue d'eau est ferme,
n'est-ce pas ?

  

Et un rendu qui ne se baserait que sur un extrait rgional
  (par ex. les Pays de Loire) ne pourrait pas s'assurer de la
  fermeture du polygone.
Je ne nie pas que c'est la ralit du terrain, mais
  j'imagine que c'est super contraignant pour les rendus (en
  particulier de zones restreintes, comme avec Maperitive).
  
  
  Bonne journe

  
  

Le 7 fvrier 2014 08:00, djo_man djo_...@laposte.net
  a crit :
  
 Bonjour
  
  POUR INFO :
  La Loire a retrouv ses Iles.
  Il n'existe donc plus qu'une seule relation
  type=multipolygone + waterway=riverbank
  http://www.openstreetmap.org/relation/2794697
  
  
  MAIS :
  il s'agit du schma de tag ancien.
  Le nouveau : type=multipolygone + natural=water +
  water=river ne fonctionne pas dans le rendu ORG et FR
  http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
  
  Pour Christian,
  Ce nouveau schma n'est pas implment dans le rendu ?
  
  merci
      djo_man


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

  





-- 
ab_fab
  "Il n'y a pas de pas perdus", Nadja
  
  
  
  
  ___
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] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

[djo_man]

  
  
bonjour, 

Vous faites erreur.

la relation est constitue de ways ferm OUTER et non pas de ways
ouvert OUTER. a change tout.

En plus, et comme le wiki le demande, les ways ferms OUTER ( qui
n'ont pas changs ) sont taggus sur l'objet en waterway=riverbank
Ce sont les iles INNER qui posaient problmes car non pris en compte
dans le schema nouveau : natural=water + water=river

Je comprend votre confusion vu que sur le wiki il est dcrit 2
schmas mais avec plusieurs mthodes. les ways ferms et les ways
ouvert

Cependant, comme Christian, je ne comprend pas pourquoi les iles ne
seraient pas rendus avec le schema natural=water 
C'est pourtant les cas. J'ai laiss durant 1 semaine ce schema en
place, et les iles n'apparaissaient pas.
Mais ds replacement du schema waterway=riverbank dans la relation,
les iles sont rapparues assez rapidement (1 jour pour les tuiles
souvent appelles)

si je me suis plant, je ne vois pas ou...
En tout cas a remarche !

djo_man


Le 07/02/2014 10:44, Pieren a crit:


  2014-02-07 10:32 GMT+01:00 Frdric Rodrigo fred.rodr...@gmail.com:


  
Le lit de rivire est une entit unique.

  
  Oui, la fort amazonienne aussi. Ca n'est pas une raison pour faire un
seul polygone qui couvrirait le cinquime de l'amrique du sud (au
pif). Il faut parfois tre pragmatique. Il n'y a aucune ncessit 
faire un seul polygone pour les riverbank. Alors si on peut l'viter,
autant revenir  quelque chose de plus facile  maintenir pour les
contributeurs (je dis bien "si on a le choix", ce qui n'est pas
toujours possible). Je ne parle pas de rendu ici mais de difficult 
maintenir les grosses relations en gnral (c'est vrai aussi pour les
itinraires "type=route").
J'imagine bien que a peut poser quelques difficults supplmentaires
pour les consommateurs de donnes qui devront faire une requte
spatiale un peu complique pour rcuprer tous les contours. Mais il y
a aussi la solution propose par Christian (une superrelation). Et de
manire gnrale, dans OSM, on privilgie toujours la solution qui
facilite la vie des contributeurs, pas celle qui facilite la vie des
consommateurs de donnes au dtriment des contributeurs. Ce sont ces
derniers qui font vivre le projet et qu'il faut choyer en priorit.

Pieren

___
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] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

[djo_man]

  
  

Le 07/02/2014 15:12, Pieren a crit:


  
Moi, ce que je propose, c'est de supprimer la grosse relation
multipolygon et de n'en faire que des petites aux endroits ncessaires
(c.a.d. l o il y a des lots et uniquement l). 



Je crois que le problme  la base vient de cela.
Des relations bases sur un seul way ferm riverbank avec ses iles.
donc 30/40 relations (je ne sais plus)
avec le temps d'autres ont t ajouts pour faire apparaitre les
iles oublies .

c'est aux alentours des grosses villes et alentours des sections
avec beaucoup d'iles qu'il y avaient le plus de problmes.
les embrouilles ne sont forcement arrivs que petit  petit.

pour info: environ 95% des OUTER de la Loire ont des INNER (iles)

Dans ce cas, cela reviendrait  faire au moins 30/40 relations...

djo_man
  


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

Re: [OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

[djo_man]

  
  
La mthode pour la relation riverbank
type=multipolygone + waterways=riverbank sur des ways ferm OUTER
qui se touchent avec des iles en INNER : 
vient du wiki.

lorsqu'il y a qu'une relation, elle est visible et modifiable. pas
moyen de se tromper.

avant il y avait 2 voire 3 relations au mme endroit. 
(certaines en reprenant juste le OUTER et ajoutant juste quelques
iles dont les autres relations n'avaient pas)
personne ne savaient pourquoi. 
laquelle modifier ?
personne ne prenant le temps de supprimer ce qu'il faut
plusieurs fois La Loire a inond ses iles  cause de mauvaises
manipulation/ajout de relation, etc (3 fois en 2 ans: c'est plus que
d'hivers...)

je veux bien modifier ce qu'il faut mais pour aboutir  quoi au
juste ?
sans compter qu'il faut que le rendu rende... (sinon La Loire va
encore tre inond: a le fait pas...)

djo_man




Le 07/02/2014 13:49, Pieren a crit:


  2014-02-07 13:32 GMT+01:00 Ab_fab gamma@gmail.com:


  
En effet, a change tout. Dsol pour la confusion et le bruit !

  
  

  la relation est constitue de ways ferm OUTER et non pas de ways ouvert
OUTER. a change tout.


  
  Au contraire, c'est pire ! Si ce sont des ways ferms qui se touchent.
Suivant les logiciels qui les traitent, le multipolygone pourrait tre
considr comme invalide:

http://postgis.refractions.net/docs/using_postgis_dbmanagement.html#OGC_Validity

Il n'y a pas trop de logique  assembler tous ces polygones en
conservant des ways ferms (si ce n'est, peut-tre,  rduire le
nombre de ways et donc de membres de la relation). Si l'ide de dpart
est de dire que c'est "une entit unique", ajouter des ways
(artificiels) qui traversent le fleuve  intervalle rgulier ne
correspond  rien dans le monde rel. Autant aller jusqu'au bout de
votre logique et ne garder que les berges. Mais personnellement, je
prfre, et de loin, conserver les ways ferms et ventuellement
coupls  une relation multipolygon lorsqu'il y des ilots 
l'intrieur.

Pieren

___
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

[OSM-talk-fr] rendu FR - schéma NEW contre OLD - relation riverbank - La Loire

[djo_man]

  
  
Bonjour

POUR INFO :
La Loire a retrouv ses Iles.
Il n'existe donc plus qu'une seule relation type=multipolygone +
waterway=riverbank
http://www.openstreetmap.org/relation/2794697


MAIS :
il s'agit du schma de tag ancien.
Le nouveau : type=multipolygone + natural=water + water=river ne
fonctionne pas dans le rendu ORG et FR
http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank

Pour Christian,
Ce nouveau schma n'est pas implment dans le rendu ?

merci
djo_man
  


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

Re: [OSM-talk-fr] Un coup de /dirty. Tiens, il est passé où ?

[djo_man]

  
  
Bonsoir, 

Oui problme:
- il y avaient plusieurs relations emmles jusqu'a TOURS !
- il y a avait aussi des ways riverbank les uns sur les autres
- j'ai dml. 
- Les Iles de la Loire sont rapparues !

- J'ai supprim les petites relations riverbank en doublon
- j'ai complet la grosse relation riverbank avec tout les INNER :
http://www.openstreetmap.org/relation/2794697
- La loire est de nouveau noy sous les eaux !

je comprend pas.
la relation est pourtant correcte et respecte le wiki.

Une ide?
je suis preneur

djo_man



Le 28/01/2014 16:18, JB a crit:


  
  Merci pour l'info, je viens de lire.
  Par contre, je ne sais pas si la chaine postgre/mapnik se prend
  les pieds dans le tapis, mais aprs du dirty + status (tuile
  rellement re-rendue), j'ai toujours les pieds dans l'eau, alors
  que les donnes semblent bonnes (rendu dfaut et humanitaire, en
  tous cas).
  Quelqu'un a du recul sur les multipolygones de 38000 nuds et 417
  membres ?
  JB.
  
  
  Le 28/01/2014 15:40, Romain MEHUT a
crit:
  
  

  
Le 28 janvier 2014 15:19, JB jb...@mailoo.org
  a crit :
   Je n'avais pas fait
attention jusqu' peu, mais le clic droit + afficher
l'image + ajouter /dirty c'est du pass ?
Le clic droit ne me propose plus rien du genre.
Et encore du coup, si quelqu'un sait rpondre  :
http://www.openstreetmap.org/note/108549
  
  
  
  Ce problme a t discut sur la liste nantaise cf. http://www.linux-nantes.org/wws/arc/openstreetmap-nantes/2014-01/msg1.html

  
  Romain
  

  




___
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] De la disparition des Iles de la LOIRE - [Un coup de /dirty. Tiens, il est passé où ?]

[djo_man]

  
  
bonjour, 

vrai: il y a mlange des 2 modles
mais la superposition des relations fonctionnait
dornavant ce n'est plus le cas avec cette seule relation.

Alors,

je veux bien essayer mais actuellement les 2 modles sont bien
implment ?

lequel est prfrable. le NEW ou le OLD ?

djo_man


Le 28/01/2014 20:31, George Kaplan a
  crit:


  
  
Date: Tue, 28 Jan
  2014 18:31:24 +0100


From:
  djo_...@laposte.net

To:
  talk-fr@openstreetmap.org

Subject: Re:
  [OSM-talk-fr] Un coup de /dirty. Tiens, il est pass o ?




 Bonsoir,



 Oui problme:

 - il y avaient
  plusieurs relations emmles jusqu'a TOURS !

 - il y a avait
  aussi des ways riverbank les uns sur les autres

 - j'ai dml.

 - Les Iles de la
  Loire sont rapparues !





 - J'ai supprim
  les petites relations riverbank en doublon

 - j'ai complet la
  grosse relation riverbank avec tout les INNER :


  http://www.openstreetmap.org/relation/2794697


 - La loire est de
  nouveau noye sous les eaux !





 je comprend pas.
  la relation est pourtant correcte et respecte le wiki.



 Une ide?






D'abord bravo pour le boulot abattu, je m'y tais frott 
Amboise mais sans la motivation d'aller jusqu' l'ocan.



La relation 2794697 porte les 2 schmas dfinis
  dans le wiki :


Tags used are:
Common tagging:type=multipolygon+waterway=riverbank 
OR
New tagging:type=multipolygon+natural=water+water=river


a ne viendrait
  pas de l ? Il faudrait en choisir un seul.
  
  
  
  
  ___
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] [Retour présentation] OSM au Géopnr

[djo_man]

  
  
bonjour, 

pour rsumer:
une page de wiki  suivre pour lintgration des PNR:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles/Import_des_donn%C3%A9es_INPN#Parcs_Naturels_R.C3.A9gionaux

Les PNR recouvrent les primtres de plusieurs communes, il s'agit
de leur emprise administrative 
comme ici par exemple. http://www.openstreetmap.org/relation/2023660
le PNR de grande brire. 
http://inpn.mnhn.fr/espace/protege/FR809

cette emprise n'est pas le primtre de leur actions qui est plus
restreinte sur une zone  preserver. le Coeur du parc
Dans le cas du PNR de grande Brire le primtre d'action n'est pas
connu (pas sur le serveur TMS du site INPN ) mais par contre on
connait un autre primtre, trs spcifique pour ce PNR, le marais
indivi: http://www.openstreetmap.org/relation/2023661

il existe aussi pour ce PNR 2 autres petit perimtre qui s'apparente
plus  des sanctuaires ou l'accs est interdit:
http://www.openstreetmap.org/relation/2023659

il serait d'ailleurs dommage d'ajoindre le tag.
leisure=nature_reserve sur l'ensemble du primtres administratif
des PNR (ensemble de communes) car cela "rend" une emprise norme
qui risque de recouvrir les autres emprises de protection comme les
sites RAMSAR. Et puis on ne peut pas dire que l'ensemble des PNR
soit une zone de type nature_reserve. Ce qui fait qu'au final les
emprises total PNR ne peuvent actuellement pas tre rendu sur les
openstreetmap.org et openstreetmap.fr . Il est plus judicieux de
mettre ce tag sur le coeur des PNR quand ils sont connus.
http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dnature_reserve

    djo_man
en direct du 44



Le 09/01/2014 17:42, Sylvain Montagner
  a crit:


  
  Bonjour,

Je viens de m'inscrire sur la liste OSM-Talk-fr, et c'est donc
mon premier message. J'espre donc ne pas faire de boulette !

Je suis gomaticien dans un Parc naturel rgional
(Normandie-Maine), et j'tais donc prsent  cette rencontre
"GoPNR", o j'ai particulirement apprci les 2 interventions
OSM (et o j'ai dcouvert la qualit des prsentation "prezi"
que je ne connaissais pas !).
Ma question est relative aux Parcs naturels (rgionaux) dans
OSM, et je ne crois pas que nous y ayons rpondu lors de la
prsentation :
Comment pourrions nous intgrer dans Open Street Map les
primtres des Parcs naturels rgionaux ?
N'tant pas un contributeur rgulier, je ne suis pas habitu 
toutes les subtilits, mais je me dis que ce doit tre par
l'utilisation (cration) d'un tag spcifique.
Schant que la plupart des PNR sont bass sur les primtres des
communes, cela pourrait passer par l'ajout d'un Tag aux objets
des communes. Malheureusement, ce n'est pas le cas de tous les
PNR, puisque certains ne concernent que partiellement certaines communes...
Nous (notre rseau de gomaticiens GoPNR) disposons des
fichiers SIG correspondants, ainsi que de la base de donnes des
communes des Parcs (vous pouvez par exemple les consulter sur le
WebSig du PNR Oise Pays de France,  cette
  adresse).

Si vous avez des pistes ou des conseils, je suis (nous sommes) donc preneur !
Ce serait d'ailleurs pour moi un bon "cas d'cole", car j'ai une
deuxime question plus particulire  poser derrire (base de
donnes d'arbres de vergers), mais chaque chose en son temps !

Merci  vous.

Sylvain Montagner
PNR Normandie-Maine
   
  
  
  ___
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] [Retour présentation] OSM au Géopnr

[djo_man]

  
  
bonjour Christian

Oui et Non,

La page du wiki qui est utilis par tous depuis le depart (semble
il) est celle ci: 
http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles/Import_des_donn%C3%A9es_INPN#Parcs_Naturels_R.C3.A9gionaux

C'est une proposition qui finalement est reste d'autant qu'il n'y
a pas grand monde  ajouter des parcs
elle est bien faite avec son tableau des ID en fonction des
diffrents types de parcs, site ramsar, et autres arret de biotope,
etc
boundary=protected_area + protect_id=*. 
l'ajout du numro issu de l'ISPN avec le tag ID_SPN est aussi bien
pens.

il y a la page wiki anglaise :
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area
plus complte en fonction des pays qui reclame un remplacement du
protected_id par un protect_class mais il semble qu'il s'agisse du
mme classement.

finalement assez stable tout a. 

djo_man



Le 10/01/2014 16:59, Christian Quest a
  crit:


  

  
Une fois les tags des PNR bien dfinis (a semble un
  peu flou actuellement, non ?), on pourra faire une requte
  dans la base pour les rcuprer et les afficher soit en
  surcouche dynamique sur un fond statique (exemple avec overpass-turbo.eu
  et aussi umap), soit faire un rendu spcifique qui les met
  en vidence.



  

  

  


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

Re: [OSM-talk-fr] [Retour présentation] OSM au Géopnr

[djo_man]

  
  
les protected_id correspondent aux protected_class, bas tous les
deux sur la classification de l'UICN, d'alleurs :
http://wiki.openstreetmap.org/wiki/Key:protect_id

pour les PNR c'est bien =5. il faudrait sans doute uniformiser pour
la version anglaise
Je ne trouve pas cela ambigu ni flou ( j'avais quand mme mis un peu
de temps  comprendre,  ;-) )

et c'est vrai que c'est dommage que dans le tableau il n'y ai pas la
France.
A rajouter donc. Je sais pas du tout faire. dsol. Je laisse la
main.

djo_man


Le 10/01/2014 19:28, Jrme Amagat a
  crit:


  
j'ai trouv ce document qui donne la categorie UICN suivant
  le type de parc francais :
http://www.uicn.fr/IMG/pdf/Espaces_proteges.pdf
  
  

Le 10 janvier 2014 18:55, Christian
  Quest cqu...@openstreetmap.fr
  a crit :
  
La lecture du wiki me confirme dans mon
  impression de flou.
  
  
  http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area
pourrait tre complt pour la France, car il y a un
tableau avec les spcificits de chaque pays, mais la
France n'y est pas.


  
  Le 10 janvier 2014 18:03, djo_man
djo_...@laposte.net
a crit :

  

   bonjour
Christian

Oui et Non,

La page du wiki qui est utilis par tous depuis
le depart (semble il) est celle ci: 
http://wiki.openstreetmap.org/wiki/WikiProject_France/Parcs_nationaux_et_r%C3%A9gionaux,_r%C3%A9serves_naturelles/Import_des_donn%C3%A9es_INPN#Parcs_Naturels_R.C3.A9gionaux

C'est une proposition qui finalement est reste
d'autant qu'il n'y a pas grand monde  ajouter
des parcs
elle est bien faite avec son tableau des ID en
fonction des diffrents types de parcs, site
ramsar, et autres arret de biotope, etc
boundary=protected_area + protect_id=*. 
l'ajout du numro issu de l'ISPN avec le tag
ID_SPN est aussi bien pens.

il y a la page wiki anglaise :
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area
plus complte en fonction des pays qui reclame
un remplacement du protected_id par un
protect_class mais il semble qu'il s'agisse du
mme classement.

finalement assez stable tout a. 

djo_man



Le 10/01/2014 16:59, Christian Quest a
  crit:


  

  

  Une fois les tags des PNR bien
dfinis (a semble un peu flou
actuellement, non ?), on pourra
faire une requte dans la base pour
les rcuprer et les afficher soit
en surcouche dynamique sur un fond
statique (exemple avec overpass-turbo.eu
et aussi umap), soit faire un rendu
spcifique qui les met en vidence.
  
  
  

  

  

  
  

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

  

  
  
  
  


-- 
Christian Quest - OpenStreetMap France

Re: [OSM-talk-fr] Du nouveau sur le rendu osmfr...

[djo_man]

  
  
bonjour, 

depuis la page map_features principale en FR 
on accde directement  cette page en cliquant sur la cl
waterway:lock_gate
http://wiki.openstreetmap.org/wiki/FR:Tag:waterway%3Dlock_gate
ou il est clairement explicit le landuse:bassin
mais aussi tout le "tagguage" complet en cas d'cluse.
cette page n'est pas une proposition. 

Comme Christian, je pense que les bassins peuvent se vider.
C'est ce qui m'a toujours gn pour les tagguer.

Pour le rendu, du point de vue de l'indication gographique, en
emplacement de bassin
est majoritairement l'endroit ou l'on a potentiellement que de
l'eau. Pour cela je pencherais pour un rendu
ou les bassins sont bleus avec des hachures blanches plutt que
blanc avec des hachures bleues.

Ce qui rsoudrait la question ? pas sur...
Mais marcherait pour le reste des diffrent type de bassins 
(entre autre les marais salant?)

    djo_man



Le 27/10/2013 13:17, Claude a crit:

Le 27/10/2013
  11:09, Christian Quest a crit :
  
  landuse=basin
est  utiliser pour des bassins pouvant recevoir de l'eau, pas
pour des tendues qui en contiennent en permanence.

Ceci explique le choix d'une hachure...


Le wiki n'est pas explicite, mais c'est assez implicite vu les
sous-tags retension/detention/infiltration


https://wiki.openstreetmap.org/wiki/FR:Tag:landuse%3Dbasin


landuse=basin ne me semble donc pas adapt  une cluse, car il
y a de l'eau en permanence dedans.


waterway=lock ne figure pas dans le wiki, et n'est pas trs
utilis (1133 fois sur des way d'aprs taginfo).

Il faudrait le documenter si il y a consensus autour.




  
  bonjour
  
  
  On parle de waterway=lock ici dans le wiki
  
  http://wiki.openstreetmap.org/wiki/FR:Key:lock traduit de la page
  
  http://wiki.openstreetmap.org/wiki/Key:lock
  
  
  c'est la galement que l'on trouve landuse=basin pour dfinir le
  bassin de l'cluse
  
  
  il faudrait effectivement un consensus. je veux bien documenter
  alors
  
  
  cordialement
  
  Claude
  
  
  



  


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

Re: [OSM-talk-fr] Du nouveau sur le rendu osmfr...

[djo_man]

  
  
bonjour Christian
Le 15/10/2013 11:00, Christian Quest a
  crit:



  


- une grosse refonte du rendu des btiments publics
  (correction d'un problme d'empilement dans le dessin,
  maintenant ils sont dessins comme des landuse)
exemple:
avant http://tile.openstreetmap.fr/?zoom=18lat=48.86166lon=2.31724layers=B00

aprshttp://tile.openstreetmap.fr/?zoom=18lat=48.86166lon=2.31724layers=B00



  

je ne connaissais pas le plan masse de l'assemble Nationale ,
Je trouvais a tres bizarre pourtant : 
normal le rendu inverse la logique !
ce qui est sombre ne represente pas les btiments.

la lecture rapide d'une carte emprunte  la logique de lecture d'un
paysage: (ici il faudrait un rfrence, ds que j'ai le temps...)
ce qui est plus sombre est plus devant soi, ce qui est plus clair
est rejete au fond.

Je pense que les btiments publiques doivent etre sombre
il y a sans doute une difficult quand c'est l'ilot entier qui est
taggu plutot que chacun des bti...

djoman
  


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

Re: [OSM-talk-fr] Du nouveau sur le rendu osmfr...

[djo_man]

  
  
solution intermdiaire: 
dtourer en sombre assez pais le tag en question plutot que
d'assombrir la surface ?
djo_man

Le 15/10/2013 14:09, Christian Quest a
  crit:


  Tu as bien cern le problme.


Quand amenity=public_building est mis sur les btiments
  eux-mme, a les rend plus fonc et le rendu me semble
  correct.
Par contre, quand ce tag est mis sur une zone plus large,
  comme un landuse, a donne un rsultat qui ne me plait pas
  totalement car les btiments seront dessins par dessus et en
  pus clair. C'est mieux (surtout si on a d'autres objets qui
  viennent se dessiner par dessus comme dans l'exemple que j'ai
  indiqu), mais pas encore idal.
  
  

Le 15 octobre 2013 14:00, djo_man djo_...@laposte.net
  a crit :
  
 bonjour Christian
  Le 15/10/2013 11:00, Christian Quest a crit:
  
   

  


- une grosse refonte du rendu des btiments
  publics (correction d'un problme d'empilement
  dans le dessin, maintenant ils sont dessins comme
  des landuse)
exemple:
avant http://tile.openstreetmap.fr/?zoom=18lat=48.86166lon=2.31724layers=B00

aprshttp://tile.openstreetmap.fr/?zoom=18lat=48.86166lon=2.31724layers=B00



  

  
  je ne connaissais pas le plan masse de l'assemble
  Nationale ,
  Je trouvais a tres bizarre pourtant : 
  normal le rendu inverse la logique !
  ce qui est sombre ne represente pas les btiments.
  
  la lecture rapide d'une carte emprunte  la logique de
  lecture d'un paysage: (ici il faudrait un rfrence, ds
  que j'ai le temps...)
  ce qui est plus sombre est plus devant soi, ce qui est
  plus clair est rejete au fond.
  
  Je pense que les btiments publiques doivent etre sombre
  il y a sans doute une difficult quand c'est l'ilot entier
  qui est taggu plutot que chacun des bti...
  
  djoman


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

  





-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
  
  
  
  
  ___
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] Outil d'intégration des adresses à nouveau disponible

[djo_man]

  
  
bonjour, 
sur Rez, il s'agit bien des faux positifs
J'image que cela doit tre la mme chose pour le reste de Nantes
Metropole
djo_man

Le 02/10/2013 15:12, Frdric Rodrigo a
  crit:


  

  
Sans le bug d'affichage on voir que la hausse est assez
  rcente
  http://osmose.openstreetmap.fr/fr/errors/graph.png?source=1347item=8080class=2start_date=2013-05-20

Ne pas prendre la date exacte, car le palier plat prcdent
est une priode ou les analyses de ce type n'ont pas
tournes  cause de la perte du serveur.

  
  C'est possible de confirmer ou infirmer que a vient de
  faux-positifs ? On a galement perdu le frontend il n'y a pas
  trop longtemps et l'on a recre (on va pouvoir crire une saga
  rien que avec des histoires de serveurs osmose)
  

Frdric.


  
  

Le 1 octobre 2013 23:16, isnogoud os...@free.fr
  a crit :
  Le 01/10/2013 09:25, Bruno Cortial a
crit :

  
Le 30 septembre 2013 21:05, Frdric Rodrigo fred.rodr...@gmail.com
a
crit :

  
  

  Autre chose, le nombre d'adresses manquantes  Nantes
  monte...
  

http://osmose.openstreetmap.fr/fr/errors/graph.png?source=1347item=8080class=http://osmose.openstreetmap.fr/fr/errors/graph.png?source=1347item=8080class=2
  
  


Bonjour,
Bonne remarque !
J'ai explor les changesets et l'onglet history de
http://owl.apis.dev.openstreetmap.org,
mais je n'ai pas trouv de
suppression de noeuds adresses. Est-que les faux
positifs d'Osmose sur ces
adresses n'auraient pas t remis  zro ?

Bruno
  


Bonsoir,

Sauf erreur, les donnes actuelles sont celles mise 
disposition par Nantes Mtropole en janvier 2013.

Une nouvelle publication a eu lieu en juin dernier sur le
site opendata. Si l'outil d'intgration se met  niveau, le
graphe va grimper encore.

La mise  jour plus ou moins automatise vers OSM reste un
sujet  traiter. L'outil d'import est utile pour traiter des
adresses  l'unit.
La mise  disposition des nouvelles rues au format xml
pourrait faciliter le travail. Cela pourrait tre avant la
fin de l'anne si j'ai le temps...

Librement

Christophe

  

___
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] Amélioration rendu FR sur les zooms faibles...

[djo_man]

  
  
bonjour, 

Que de difficults pour "rendre" une carte  partir de donnes non
unifies...

- Au zoom 9 ne faudrait-il pas rendre plus visibles les limites des
dpartements dans un violet leger?
(elles sont prsentes mais quasi invisible)

- pour nommer les dpartements, une technique de violet gras
semi-transparent en trs grosse typo qui pourrait tre plac en fond
et recouvrable par la toponymie des villes serait peut tre lisible
? serait-ce valable aussi pour les autres pays ?

- zoom 8 :un brin de prsence supplmentaire pour les villes
d'envergures rgionales serait-peut tre mieux, en restant dans une
taille en dessous de celle des rgions (voire augmenter celle des
rgions?)

-  quoi la confiture ? ;)

    djo_man

Le 17/08/2013 20:06, Christian Quest a
  crit:


  J'ai modifi la requte pour les noms de capitales, en effet, le
schma de tag est peu clair et il y a plein de variations:
- is_capital=country
- capital=yes + admin_level=2
- capital=2

La requte gre maintenant les 3 possibilits, et j'en ai profite pour
complter les quelques capitales pour lesquelles il manquait des
infos.

Les zoom jusqu' 7 ont t recalculs, c'est nettement mieux.
J'ai aussi mis les libells un tout petit peu plus gros.


Autre changement majeur: un patch  mapnik pour grer diffremment les
limites entre metatile.
L'effet est qu'il y a beaucoup moins de textes et cartouches coups.
Il m'en reste encore sur une requte trs spciale pour les noms de rues.

Ds que celle-ci sera corrige et les tuiles recalcules, je lancerai
un concours o il y aura un pot de confiture (maison)  gagner si vous
trouvez un texte coup ;)

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





  


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

Re: [OSM-talk-fr] Amélioration rendu FR sur les zooms faibles...

[djo_man]

  
  
bonjour

Je n'ai pas encore particip aux remarques sur ce rendu TOP FR
Voici les miennes :

zoom 3
- la disparition des frontires est interessante mais dans ce cas il
faudrait sans doute renforcer la visibilit des noms des continents

zoom 4
- quelle est cette capitale qui prend lieu et place de la cte du
cap Sizun ?
il s'agit de cette limite administrative en fait :
http://www.openstreetmap.org/browse/way/232710933
- il manque un paquet de points noirs capitales ?

zoom 5
- la Sardaigne et la Sicile affichent leurs ctes
- il manque un paquet de noms de capitales ?

zoom 6
- rien  dire personnellement, top

zoom 7
- si les dpartements devaient tre cits ce serait pas sur ce
niveau de zoom ?
mais cela ferait du monde, je sais...

  
  
  Rien  dire de plus
  Sauf peut tre revenir sur une vieille discution sur la couleur
  trs peut visible (zoom 8-9-10) des trunks vertes ?
  (je pense toujours aprs rflexion qu'une dclinaison de violet
  serait la bonne couleur)
  
  
  Merci  toi Christian pour tes efforts de nous doter d'une carte
  vraiment exploitable
  
  djo_man
  
  
  
  
  Le 16/08/2013 08:43, Christian Quest a crit:


  J'ai intgr les nouveaux zoom 1  11 au rendu FR...

Quelques explications ici:
http://openstreetmap.fr/blogs/cquest/rendu-fr-premiers-zooms

Pour leur recalcul, explications l:
http://wiki.openstreetmap.org/wiki/FR:Servers/tile.openstreetmap.fr et
l http://openstreetmap.fr/blogs/cquest/osm-fr-faibles-zooms

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





  


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

Re: [OSM-talk-fr] Article Aménagements cyclables et troubles de la description dans OpenStreetMap

[djo_man]

  
  
Bonsoir, 

J'ai crer un filtre pour supprimer tous les messages de Philippe
qui pollue cette liste. 
Je lis tout et je ne peux pas me permettre de lire toute son
"incontinence verbale", 
car s'en est une...

Pieren ne peut pas se permettre de dire ce que je dis vu sa
position.

Mais j'ai un nouveau problme : 
De plus en plus de messages parle de Philippe ou lui rponds, et
cela pollue cette liste aussi.
Je vous promet que c'est dans chacun des fils de lecture maintenant
!

Comment faire ?

Pour ma part, je vais rajouter un filtre pour viter cela mais me
voici encore avec nouveau problme : 
Bien souvent les contributeurs dveloppent aussi des ides
intressantes en rponse  Philippe.
1fois sur10. Dommage de s'en priver

    djo_man dpit
(pas la peine de rpondre Philippe, je n'entends pas)



Le 14/07/2013 18:57, Christian Rogel a
  crit:


  
  
  

  

  Le 14.07.2013 17:35, Philippe Verdy a crit:
  

  
Sur ce point l oui. Tu ne vois pas
  qur son smiley ne sert  rien ? Il ne riait pas de
  lu-mme, mais fait de l'humour prtendu en se
  moquant des autres. C'est lui qui ne comprend
  rien. Son flaming reste inacceptable, mme avec un
  smiley.
  

  

  

  
  
  Je te rappelle (mais, l'as-tu lu et mdit?) qu'une grande
partie d'entre nous estiment que ta logorrhe/incontinence
verbale/inadaptation sociale/surdit intellectuelle/TOC du
clavier/talage inutile et approximatif de ton immense culture,
etc. sont une agression sui generis.
  Personne d'entre nous ne subira de dommage intellectuel ou
autre  avoir essay de ramener l'inondation dans son lit. Les
pompiers restent toujours des hros.
  Il y a donc quelque inconscience de ta part  te plaindre
d'un prtendu flaming : c'est toi qui crache du texte sur un
mode volcanique et nous sommes pris de faire comme si de rien
n'tait.
  
  
  Ceci dit, tu tais, pourtant, en voie de gurison : c'tait
relatif, puisque tu alternes bouillie et textes courts.
  
  
  Ce que nous attendons, c'est une esquisse d'autocritique, pas
des manifestations toujours plus ruptives, face  des piqres
de moustique.
  
  
  Christian R.
  
  
  
  ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr



  


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

Re: [OSM-talk-fr] Petit bug dans la dernière version du plugin cadastre

[djo_man]

  
  
bonjour  tous

idem pour moi

djo_man

Le 09/07/2013 12:21, Nicolas Moyroud a
  crit:

Bonjour,
  
  
  Je voudrais signaler un bug dans la dernire version du plugin
  cadastre. Depuis que j'ai fait la mise  jour  la dernire
  version, j'ai un bug qui fait planter le plugin ds qu'il y a une
  feuille avec des informations de golocalisation et que je
  confirme leur utilisation. Si je choisis "non" pas de plantage
  mais il faut alors golocaliser  la main, ce qui est quand mme
  un peu dommage... Je prcise que j'ai essay avec diffrents
  systmes de projection : Lambert 4 avec diffrentes zones et
  Lambert 9 zones. Hier a m'a fait le plantage sur une commune et
  ce soir a recommence avec une autre. Par exemple la commune de
  Chanoy en Haute-Marne. a ne plantait pas avec la version
  prcdente du plugin. Le mme bug est galement arriv  un autre
  contributeur qui participe au trac des limites de communes.
  
  Pieren est-ce que tu aurais le temps de regarder d'o vient le
  problme ?
  
  
  Nicolas
  
  
  ___
  
  Talk-fr mailing list
  
  Talk-fr@openstreetmap.org
  
  http://lists.openstreetmap.org/listinfo/talk-fr
  
  


  


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

Re: [OSM-talk-fr] Island, Coastline et rendu.

[djo_man]

  
  
bonjour, 

ici les iles sont rendues avec juste le tag coastline et sans
limites administratives

http://tile.openstreetmap.fr/?zoom=15lat=47.30025lon=-2.49697layers=B0FFF

tu dois avoir juste un problme de mise  jour du rendu "mer" vu que
le dlais est assez long: au moins 4 semaines dans mon souvenir
et le rendu osm.fr de Christian doit utiliser le mme rendu "mer"
que osm.org

djo_man

Le 08/07/2013 16:51, Tetsuo Shima a
  crit:


  En m'intressant au rendu des les et ilots depuis qu'on en reparle
sur cette liste avec les mise a jour du rendu FR, je m'apercois que
tout un tas de petites iles ne sont pas rendues.

Exemple ici en Bretagne devant l'Aber Wrac'h

http://tile.openstreetmap.fr/?zoom=13lat=48.61785lon=-4.56019layers=B0FFF

Les iles tagges juste avec la surface natural=coastline
n'apparaissent pas sur les rendus. Seules celles ou cette surface sert
de limite administrative apparaissent!

J'ai rat quelques choses? A priori c'est la meme chose pour le rendu
"officiel" openstreetmap.org. C'est pour ca que ca me semble bizarre.

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




  


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

Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles

[djo_man]

  
  
bonjour,

Je profite de ce fil pour parler du rendu propos que l'on voit bien
dans l'exemple
il s'agit des marais salants qui sont presque toujours en zone NR
car trs souvent en zone RAMSAR

Christian tu propose donc qu' un certain niveau de zone de rendre
les salines (landuse=salt_pond) comme des natural=mud
(soit dit en passant le landuse=salt_pond est le seul landuse qui
n'a pas rendu sur mapnik)

Je trouverais plus judicieux qu'ils soient rendu comme les bassins.
finalement ce qu'ils sont.
comme l: 
http://tile.openstreetmap.fr/?zoom=14lat=47.39542lon=-2.48194layers=B0

En ce qui concerne le calage  60 des RN : super, mais il est bien
difficile de diserner le primtre maintenant qu'ils sont moins
nombreux
le rendu 2u propose une surface legerement verte au zoom 14 sur
l'ensemble du primtre de la rserve. c'est plus parlant pour
comprendre tout de suite que
nous sommes dans la reserve mais gacherait  de plus fort zoom les
couleurs des landuses

oserais-je demander un degrad de vert  transparent sur le
primtre sur une paisseur de 100m environ ?

djoman
(le fou qui a recopi les marais salants depuis bing)


  


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

Re: [OSM-talk-fr] Import adresses Grand Lyon

[djo_man]

  
  
bonjour, 

voici le lien pour la page complte du wiki sur l'intgration des
adresses sur Nantes
http://wiki.openstreetmap.org/wiki/Nantes/Adresses_postales_Nantes_M%C3%A9tropole
et le lien "L'outil ddi  l'intgration"
: http://arboulig.free.fr/OSM/ImportNM/

vous pouvez voir qu'il n'y a presque plus d'adresses  intgrer sauf
3 ou 4  l'ouest de Nantes.
cet outil tait tres pratique car il permettait d'intgrer les rues
unes  unes avec les point d'adresse et la relation qui les
rassemble
seulement la verification du nom de la rue pour qu'elle colle 
celle de la relation restait  faire.
On pouvait de plus ajouter des commentaires et ajouter le statut de
l'opration en cours.

bref le top pour l'intgration des adresses.

Je crois que c'est Bruno Cortial qui est  l'origine de l'outil, 
vrifier sur la liste nantaise
http://www.linux-nantes.org/wws/info/openstreetmap-nantes

djoman


Le 31/05/2013 12:37, Jean-Baptiste
  Holcroft a crit:


  Je peux donner un coup de main si vous faites un mapcraft. Va
ne doit pas tre plus compliqu que la cadastre.
  Le 31 mai 2013 12:34, "GaelADT" gael.sauva...@gmail.com
a crit:

  Sylvain Maillard wrote
   Salut,
  
   il s'agit effectivement de donnes qui ont t libres,
  et qui ne sont
   pas
   encore dans OSM. A savoir qu'il y a dj pas mal
  d'adresses prsentes dans
   OSM (surtout centre ville) donc pas d'import brutal !
  
   J'ai dj regard les jeux de donnes mais je n'ai pas
  encore eu le temps
   de m'en occuper ... par contre je peux t'aider 
  comprendre comment elles
   sont structures pour faciliter l'intgration ;)
   De ce que j'avais vu des donnes brutes sur le site
  opendata il y a besoin
   de faire des jointures entre plusieurs couches (ce qui
  est dans mes
   cordes)
   ... sur le lien que tu as donn apparemment c'est dj
  fait, mais par
   contre il y a clairement un problme au niveau de la
  projection : le
   fichier fourni est indiqu en CC46, alors que les
  coordonnes des points
   sont en WGS84 !
   Les points semblent  peu prs bien placs (j'ai retrouv
  chez moi), et
   positionns sur la limite des btiments. Il y a des rues
  qui ne semblent
   pas trs droites, a demande  vrifier avec les donnes
  dj dans OSM
   pour
   comparaison ;)
  
   Je met galement en copie al liste local-lyon, qui me
  parat plus
   approprie pour rgler les dtails de terrain ;)
  
   Sylvain
  
  Ok super. Je vais galement jeter un coup dil aux donnes.
  Donc l'ide serait de faire comment ? Essayer de croiser les
  donnes du
  Grand Lyon et de OSM pour voir l o il y a des manques. Et
  ensuite importer
   la main les adresses rue par rue dans JOSM ?
  
  Gal.
  
  
  
  --
  View this message in context: http://gis.19327.n5.nabble.com/Import-adresses-Grand-Lyon-tp5763488p5763503.html
  Sent from the France mailing list archive at Nabble.com.
  
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-fr

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



  


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

Re: [OSM-talk-fr] Metatuiles les plus denses en nœuds

[djo_man]

  
  
bonjour, 

je suis méta enchanté de cette petite blague. ;)

djoman


Le 25/05/2013 13:30, Christian Quest a
  écrit :


  Le 25 mai 2013 12:58, Ista Pouss ista...@gmail.com a écrit :

  
Le 24 mai 2013 22:30, Christian Quest cqu...@openstreetmap.fr a écrit :


  Frederik Ramm a produit une liste des metatuiles les plus denses en


Une métatuile protège de la métapluie peut être ?


  
  
Pour se protégéer de la métapluie, il faut un métapébroque.




  


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

Re: [OSM-talk-fr] Rendu OSM-FR : couleurs highway

[djo_man]

  
  
bonjour, 

personnellement, j'ai toujours trouv que c'tait le plus gros
dfaut du rendu mapnik
+1 donc

un bleu/vert ? (vert canard fonc)

djo_man


Le 21/04/2013 13:44, Francescu GAROBY a
  crit:


  

  Je rejoins Pierre-Alain, tout particulirement avec son
dernier exemple : les routes vertes ressortent beaucoup
moins bien que les autres !
  
  Mme les oranges ressortent mieux, alors qu'elles sont moins
  importantes...
  

Francescu
  
  

Le 21 avril 2013 13:34, Pierre-Alain
  Dorange pdora...@mac.com
  a crit :
  
Philippe Verdy verd...@wanadoo.fr
  wrote:
  
   Je suis moi-mme "daltonien" comme on dit, le terme
  plus exact tant

 "deutranope mineur" [...]

Je prcise que ma remarque sur le "daltonisme" tait une
boutade, tout
ce que tu cris est fort intressant mais sans rapport aucun
avec le
sujet du forum, je zappe donc cette introduction...

 [...] Malgr tout la
 couleur principal du trait forme un
  contraste suffisant par rapport aux
   forts et vignes alentours. Certes il est difficile
  de savoir quelle est la
   couleur du trait, mais on voit qu'il contraste avec
  le fond dont on
   reconnait bien la couleur.
  

OK, je suis donc bien pas normal car sur l'exemple
ci-dessous je vois
par merger "naturellement" et "facilement" la structure du
rseau
routier qui forme un anneau au sud de la ville. Pour moi le
vert du
trunk est tellement peu vident que je ne vois plus que (du
premier
abord) que l'axe nord-sud.

https://dl.dropboxusercontent.com/u/722984/osm-couleurs.pdf

L par exemple : http://osm.org/go/eqr4qlc-
Je trouve pas du tout assez visible la N10 qui traverse du
nord-est au
sud-ouest que les axes secondaires (D731, D674)

J'en conclus que je dois donc tre une exception.

Dsol de tout ce bruit pour rien.

  
--
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
  

  




-- 
Cordialement,
Francescu GAROBY
  
  
  
  
  ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr



  


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

[OSM-talk-fr] nom de parcelles de foret - analyse osmose wikipedia

[djo_man]

  
  
bonjour  tous

En lanant la nouvelle analyse wikipedia d'osmose et en regardant le
lien sur les 7 forets pouvant faire un lien wikipedia, on tombe
exclusivement sur une petite partie de foret de cet endroit :
http://www.openstreetmap.org/?lat=45.66297lon=0.30471zoom=16layers=M

il s'agit de 7 parcelles avec une reference en guise de name. au sud
de la voie ferre. La zone est super definie par ailleurs et
complte on dirait. Etrange tout cela...

Une nouvelle manire de faire de la gestion parcellaire des forets ?

djo_man
  


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

Re: [OSM-talk-fr] Vers une mise à disposition d'un rendu FR (était: osm13 est opérationnel !)

[djo_man]

  
  

Le 22/02/2013 16:02, ades_...@orange.fr
  a crit:


  , autant je coince sur la suppression des limites d'immeubles dans les vues rapproches. 
En gnral ces limitations d'origine cadastrales collent assez bien avec la ralit et c'est un bon indicateur de la morphologie des zones urbanises. 



+1

bonjour, 

carrment en ce qui concerne le zoom 18 et 17 et pas seulement pour
reprer la 4me maison. 

Il s'agit l bien de lire une information morphologique importante
qui en dit long culturellement. 

Du bati accol sur des parcelles en lanires n'a rien  voir avec
une grosse longre qui a subi des rallongements successifs. 

djo_man
  


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

Re: [OSM-talk-fr] Suppression GR dans OSM (encore) (était [forum-osm-fr] Réalisation de cartes Garmin...)

[djo_man]

bonjour,
+1
a contre cœur
un peu marre de voter à ce sujet.
Bon courage pour le SOTM-Fr


On passe à autre chose ?
Un sujet de la semaine pour compléter un maximum les chemins de rando ? 
(sans relations)

comme pour se venger sur quelque chose qui va servir...

djo_man


Le 21/02/2013 15:04, Mickaël Guéret a écrit :

Le mercredi 20 février 2013 à 06:41 +0100, Tetsuo Shima a écrit :

Et pour les autres itinéraires, comme les lignes d'autobus ... c'est
protégé aussi ou j'ai le droit de suivre l'itinéraire de bus et de
reproduire dans OSM!!!

Ne confondons pas tout : les gestionnaires de lignes d'autobus ne
vendent pas de guides de leurs lignes, leurs survie ne dépend pas de ces
infos... Contrairement à la FFRP dont une ressource financière
importante vient sans doute de la vente des guides de randonnée. Si on
imagine qu'une autre société vendent des guides de leurs randos, basés
sur des données OpenStreetMap (elle en a le droit, selon la licence
OdbL), la FFRP ne sera sans doute pas aussi muette ! Et là, c'est qui le
fautif ? Le site OpenStreetMap ou la société qui réutilise les données
OSM ?...

Je suis pour la suppression de ces relations dans la base...tant que la
FFRP n'a pas clairement donné un avis positif.

Cordialement,
Mika_Gueret


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




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

Re: [OSM-talk-fr] [OSM-Nantes] Re: Contributeur indélicat ?

[djo_man]

  
  
bonjour  tous

Au final si on analyse bien le fond de la question on trouve une
entreprise dont ses salaris contributeurs ne sont pas motivs
spcialement par la qualit de la base ni ses buts mais uniquement
pour rpondre  leurs suprieurs. 

L on touche  la question essentielle selon moi : les
contributions ne devraient qutre que personnelle, afin de
maintenir l'envie de bien faire. Ou bien alors, le suprieur
hirachique devrait renseigner son mail puisque que c'est lui qui
donne les ordres de contributions et la vitesse  laquelle elles
doivent sans doute etre effectues...

Plusieurs fois, je n'ai pas eu de rponse par ces contributeurs
cachs derrire GEOVELO

djo_man 
(c'est pas nom propre non plus mais je suis unique et motiv ;-) )


Le 14/02/2013 10:32, GaelADT a crit:


  cquest wrote

  
Alors qui envoie les changeset actuellement sous le pseudo Geovelo ?

Comment contacter cette personne pour la raisonner et faire qu'il ne
faille pas assez systmatiquement repasser derrire ses contributions
?

Quelqu'un a les coordonnes tlphoniques de la Compagnie des
Mobilits qui est derrire Govlo ?

  
  Oui le pseudo derrire Govlo est bien quelqu'un de l'entreprise par
contre.

Je lui ai fais les explications ncessaires sur sa version de JOSM /
changeset / rponses aux messages (mme si a m'tonne qu'il ne rpond pas
?).

Aprs je souhaite aussi calmer un peu les changes. Ok, il n'utilise pas
toutes les bonnes manires peut-tre, mais a, a peut changer. Aprs dire
qu'il faut systmatiquement repasser derrire lui, je pense qu'il ne faut
pas aller jusque l dans le discours, car c'est un peu mchant  la vue de
ses nombreuses contributions.

Egalement d'accord pour que la discussion ne devienne pas un lynchage en
public ;-) (surtout quand je vois les drives avec des contributions venant
sois disant de la mme entreprise alors qu'en fait non...) Tout le monde ici
 intrt  ce que a se passe bien et dans la bonne humeur. Le mieux serait
qu'une seule personne qui matrise bien (pas moi donc) prenne contact avec
lui (me contacter directement et je donne ensuite son adresse mail
personnelle) et regarde dans ses futures contributions ce qui pourrait tre
amlior.

Gal. 



--
View this message in context: http://gis.19327.n5.nabble.com/Contributeur-indelicat-tp5728399p5749342.html
Sent from the France mailing list archive at Nabble.com.

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




  


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

Re: [OSM-talk-fr] [OSM-Nantes] Re: Contributeur indélicat ?

[djo_man]

  
  
bonjour  tous

si j'en crois tous les messages sur les liste nantais et talk-fr
GeoveloCDM = Megacity = geovelo-cdm = M-Rick

il y a les bourrages d'urne et maintenant les bourrages de base sur
la quasi totalit (!) des rues nantaises pos par ce contributeur
ou bien cette boite geovelo:
_onway_=no
access=yes
lanes=2

je ne trouve pas cela raisonnable. Suis-je le seul dans ce cas ?
Dj que le DWG nous emmerde pour le cadastre...

Si on ajoute le problme du changement unilatral sans discussion et
en simple excution d'un ordre de Nantes Mtropole du changement de
classification des voies de l'ouest Nantais

Si on ajoute le problme de la mauvais intgration de ses donnes.
POI en triple, des infos discordantes au mme endroit sur des
changeset diffrents sans commentaire.

Et il n'y pas que sur Nantes qu'il svit maintenant, LeMans,
Toulouse entre autres. Je n'ai pas mis de lien sur tous les posts
qui en parlent, cela serait trop long... Il ne vient pas ici en
parler. Je crois portant qu'il est en relation avec quelqu'un de la
liste nantaise ou sur talk-fr.

il va finir par ce faire bloquer par le groupe d'action. Faudrait le
prvenir. Mais pas moi... Je ne le trouve pas tres respecteux dans
les echanges que l'on a pu avoir ensemble.

bonne nuit
djo_man






Le 13/02/2013 20:24, Romain MEHUT a
  crit:

a continue: http://forum.openstreetmap.fr/viewtopic.php?f=6t=489start=10#p2388
  
  Romain
  
  
Le 1 octobre 2012 16:36, Jean Couteau jean.cout...@gmail.com a
crit :

  


  
  Du travail pour le futur DWG franais
?


Pour les tags "en trop", j'en ai vu pas mal introduits
  par GeoveloCDM sur Coueron et Indre. Ce n'est pas trs
  lgant et a surcharge, mais tant que a ne drange pas,
  je laisse. Je pense que c'est ajout pour les calculs
  d'itinraires Geovelo. J'aurais envie de dire que dans ces
  cas l il faudrait amliorer l'outil...



Jean
  

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



  


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

Re: [OSM-talk-fr] Un groupe de coordination était Support publicitaire

[djo_man]

bonjour,

+1

C'est pile le sujet que je voulais évoquer sur la liste.
Ou est passé le projet de la semaine ?
ou bien le jeu de la semaine, etc...

J'y vois que des avantages.
Et avec de bons sujets choisis cela permettrait entre autre de
communiquer sur la réactivité, la précision, la vigueur d'OSM

les sujets, il faudrait les choisir dans une liste remplie par nous tous
le plus HOT, le plus juste, le plus drôle (pourquoi pas), le plus 
urgent, etc


Pour que cela soit efficace il faudrait sans doute des rapports
intermédiaires, du suivi, des graphiques, des conclusions et
faire du prémâché pour les média.

djo_man



Le 01/02/2013 19:24, PierreV a écrit :

Pourquoi pas relancer le projet de la semaine... si j'ai bien compris, je
crois que ça a disparu en 2012 mais quand j'ai commencé c'etait bien
pour donner des idées de quoi faire:
http://wiki.openstreetmap.org/wiki/Project_of_the_week/2011



--
View this message in 
context:http://gis.19327.n5.nabble.com/Un-groupe-de-coordination-etait-Support-publicitaire-tp5747518p5747647.html
Sent from the France mailing list archive at Nabble.com.

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




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

[OSM-talk-fr] http://www.tuugo.fr semble ne pas respecter la licence osm

[djo_man]

bonjour,

http://www.tuugo.fr utilise des cartes mapnik pour le placement des 
entreprises mais n'indique pas sa licence.
je vous laisse faire, je n'ai pas le temps de leur envoyer un mail en ce 
moment.


djo_man

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

Re: [OSM-talk-fr] Import bâti cadastral, encore du travail à faire

[djo_man]

  
  
bonjour, et meilleurs vux  OSM et ses fourmis

Je me suis pos aussi cette question ds mon premier import du
cadastre.
J'ai cherch  regrouper.
(pas fait beaucoup, et puis la nouvelle demande de double compte me
refroidi )

- en ville (village) On les repre facilement grce aux diffrences
entre les toitures, 
le sens des faitage, l'ombrage. J'avais donc conclu que 2 btis
clairement construits
diffremment au vu des toitures devaient mener  2 building=yes. 
Presque pas de fusion. J'ai mme arrt de fusionn

- en tissu diffus distendus l c'est plus dur, j'ai vu beaucoup de
garages rajouts 
aux btisses qui en cadastre avait une limite sparative mais qui
dans les faits
rclamaient une fusion avec le plus gros bti. 
Pas beaucoup de fusion. J'ai arrte aussi plus par doute

- en tissu de campagne, c'est encore plus compliqu car plus
d'adresse cadastrale
pour vrifier. Dans les hameaux anciens ou bti de corps de ferme
assembl il n'y a
pas trop moyen de passer devant pour regarder, les toitures sont
clairement diffrentes
et traduisent des poques diffrentes mais on sait aussi
qu'historiquement il s'agissait
des mme familles. 
fusion si les btis sont assimilables aux mme poques et sur une
mme parcelle
(il faut vrifier sur le serveur)
pas fusion si beaucoup de parcelles correspondent  des btis
diffrents.

au final j'en ai fait trs peu des fusions. 
et puis finalement j'aime bien les limites sparatives entre bti
a me donne une information sur la logique d'usage du sol,
ce que ne donne pas la carte TOP25 par exemple

70% me parait norme au vu de ce que j'ai dans mon coin, mme
30%...

djo_man




Le 14/01/2013 13:28, Christian Quest a
  crit:

Le 14 janvier 2013 13:03, Pieren pier...@gmail.com a crit :
  
 Bonjour,
  
  Je voudrais faire part ici d'un retour d'exprience sur le
  bti
  cadastral de deux villages de taille moyenne (1500.. 2000
  habitants)
  que j'ai eu l'occasion d'examiner en dtail ce week-end. Dans
  le
  premier, j'ai immdiatement constat le nombre ahurissant de
  polygones
  "building=yes" qui se dcoupaient suivant le parcellaire, trs
  fragment dans cette commune rurale. En ne conservant que les
  contours
  extrieurs (dfinition du tag "building=yes"), j'ai pu
  supprimer
  approximativement 70% des polygones. Dans le deuxime cas,
  l'urbanisation tait plus rcente mais il y avait encore env.
  30% de
  "buildings" en trop. Le dcoupage des btiments par le
  cadastre semble
  donc trs, trs variable d'une commune  l'autre, mais aussi 
  l'intrieur d'une mme commune (et ne semble pas dpendre de
  pratiques
  spcifiques  un CDIF).
  



C'est aussi mon impression.


Dans ma ville c'est plutt l'inverse... un immeuble de
  plusieurs tages et des garages qui n'ont qu'un polygone, et
  dans ce cas, je recoupe.



  
  -- 
  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
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Proposition d'intégration des données du parc botanique de Haute-Bretagne

[djo_man]

bonsoir à tous.

Je travaille avec autocad.

Il faut savoir qu'il n'est pas du tout fait pour le géographique car on 
ne peut associer aucune base de donnée à aucune ligne. On peut à la 
rigueur disposer d'une multitude de calques nommés pour catégoriser les 
lignes mais c'est tout. On peut aussi donner des couleurs ou des type de 
lignes qui a l'appui d'une légende pourrait indiquer des propriétés aux 
géometries.


Il doit y avoir quelques posibilités pourtant d'y associer quelques 
tableurs pour y ranger quelques propriété de lignes. Ce doit etre le 
bout du monde pour ce logiciel.


Donc question essentielle à leur poser.
Ou sont rangées les informations hors géometrie pure ?

djo_man

Le 09/01/2013 22:45, Nicolas Moyroud a écrit :
Bon j'ai reçu les données, c'est vraiment très problématique. Il 
s'avère que les gestionnaires du parc travaillent avec le logiciel 
AutoCAD que je ne connais absolument pas et dont je n'ai pas la 
licence. Impossible donc d'exploiter le fichier dwg qu'ils m'avaient 
envoyé dans un premier temps. J'ai trouvé des infos sur un format 
d'échange dxf d'AutoCAD et je leur ai demandé de me fournir un fichier 
à ce format. J'arrive à l'ouvrir avec QGIS, mais tout ce que j'obtiens 
ce sont des jolis traits qui se dessinent, sans aucune valeur 
attributaire associée. En gros, j'ai un beau dessin dans QGIS, mais 
rien d'exploitable comme info géographique.
J'ai cherché des infos sur le web, testé différents outils de 
tranformation dxf vers shp ou kml, ça marche mais au final j'obtiens 
toujours le même résultat : un beau dessin qui ne sert à rien ! Donc 
là je sèche complètement dès la première étape. Si quelqu'un a une 
expérience de ce genre de choses avec les formats AutoCAD, je veux 
bien un peu d'aide. Ou si quelqu'un veut s'occuper de cet import de 
données dans OSM, je peux aussi lui transmettre les données et lui 
laisser la main. :-)

Merci pour votre aide.

Nicolas

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




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

Re: [OSM-talk-fr] Création du Groupe d'accompagnement aka Cadastre task force

[djo_man]

bonjour à tous

+1 avis de Pieren

Peu importe les inconvénients de gestion, à terme il y a plus de risque 
à être non-visible qu'a être ouvert, même si c'est souvent dur d’être 
ouvert et si ça ralenti fortement les actions. L'ouverture de toutes les 
paroles garanti l'existence même de tout projet commun. Bien souvent le 
caché engendre à lui tout seul masse de problèmes. Vérifiable dans la 
vie de tout les jours


djo_man

Le 15/10/2012 13:00, Pieren a écrit :

2012/10/15 partir-en-vtt ad...@partir-en-vtt.com:

De plus, on entre dans la même dérive que celle du DWG à savoir :
un petit nombre décide pour beaucoup.

Je vais être d'accord avec partir-en-vtt sur un point mais pas celui-ci.
Le DWG se targue de n'appliquer qu'une politique définie par la ...
communauté. Même si on voit bien que ce qui est désigné par
communauté, c'est toujours à peu près le même groupe de personnes.
Mais bon, d'un autre côté, les membres de la communauté se foutent
des imports massifs tant que ça n'arrive pas chez-eux. L'histoire du
compte séparé, ça leur passe à 20.000 au dessus de la tête. Donc, il
reste un petit groupe de gens qui sont soucieux de l'impact de ces
imports sur le projet, en particulier dans des zones à faibles niveaux
de participants (et donc d'auto-contrôle). Pendant longtemps, ils se
sont cru seuls et ont dû être surpris par notre mobilisation sur la
liste principale parce que jusque là, leurs interventions
n'intéressaient qu'un nombre limité de personnes.

Par contre, sur le point de la confidentialité, j'aurais tendance
maintenant à être d'accord avec partir-en-vtt. Ce qui mine le plus
l'action du DWG ou de l' OSMF en général, c'est leur manque de
communication et de transparence. Dans un projet comme OSM, il ne faut
rien cacher et il faudrait ouvrir cette liste, sans inscription
préalable. Le risque de voir des contributeurs injustement accusés est
inférieur à celui de créer une suspicion de prise de contrôle par un
petit groupe sur le reste de la communauté. Si le but de ce groupe est
d'imposer certaines règles, il faut d'abord montrer que ces règles
sont connues et admises par l'immense majorité et que l'avis de tous,
même du plus petit contributeur, est pris en compte. Ne répétons pas
les mêmes erreurs que le DWG.

Pieren

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




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

Re: [OSM-talk-fr] écoles et osmose

[djo_man]

merci bien
rassuré que tout soit prévu...

djo_man


Le 10/10/2012 19:25, Frédéric Rodrigo a écrit :

Le 10/10/2012 17:03, djo_man a écrit :

bonjour à tous

dans osmose, il y a
a mapper- école non intégrée
mais aussi
intégration- école

cela parle semble-il des mêmes écoles restant à intégrer


C'est bien ça.



mais pourtant lorsque l'on corrige l'un il ne corrige pas
automatiquement autre ?


Si, c'est automatique, le délai est juste de 6h.

Frédéric.


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




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

[OSM-talk-fr] écoles et osmose

[djo_man]

bonjour à tous

dans osmose, il y a
a mapper- école non intégrée
mais aussi
intégration- école

cela parle semble-il des mêmes écoles restant à intégrer

mais pourtant lorsque l'on corrige l'un il ne corrige pas 
automatiquement autre ?


djo_man


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

Re: [OSM-talk-fr] Imports du cadastre et compte dédié - import adresses Nantes aussi !

[djo_man]

  
  
bonjour, 

ptition

touchez pas au modle franais d'intgration des donnes !
Au cas par cas avec compltude et mise  jour des donnes adjacentes
!
On veut pas tre assimils  des gros bourrins de l'upload !

djo_man

Le 29/09/2012 08:24, Ab_fab a crit:

Mais ce pnorman, c'est qui ?
  S'il reprsente la fondation, pourquoi n'utilise-t-il pas un
  compte ddi et explicite pour ses prises de contact au sujet des
  imports ?
  
  Bien entendu, je suis cynique, mais on peut tout  fait suivre sa
  logique et ne pas aller chercher son pdigre sur le wiki. La
  seule limite c'est que si on l'ignore, il peut bloquer.
  Aprs tout, il trouve une trace d'un import ou d'une intgration
  et ne prend pas la peine d'aller chercher si la mthodologie a t
  dcrite dans le wiki. 
  Les infos sur les noeuds adresse font qu'on identifie "Nantes
  mtropole" et que mme un anglo-saxon peut retrouver sans
  ambiguit la page wiki de rfrence.
  
  La page du wiki de l'intgration donne TOUT ce qui est ncessaire
  pour tracer les donnes et retrouver les changesets concerns. Il
  est en mesure de considrer qu'il y a eu import / intgration ...
  parce que la mthodologie qui a t discute pendant des semaines
  a tenu compte de la traabilit qu'il tait ncessaire d'apporter.
  L'intgration a pris des mois entiers, encore une fois rue par rue
  
  Ca devient un gros n'importe quoi
  
  Le 28 septembre 2012 23:31, isnogoud os...@free.fr
a crit :
Bonsoir 
  tous,
  
  Le cadastre n'est pas le seul projet concern par le sujet.
  
  Je viens de recevoir le message suivant de pnorman :
  
  ==
  
  I was looking at some data in Nantes and saw that you had
  imported a bunch of addresses there. Although there's not much
  to be done at this point, I wanted to remind you if you had
  any future imports planned that imports need to be done from a
  dedicated account and after consultation with the community,
  which includes the imports@ mailing list.
  
  I checked my imports@ archive and didn't find any proposed
  Nantes imports.
  
  This is just a reminder for if you plan anything in the
  future.
  
  ==
  
  Le projet d'import d'adresses  Nantes est dcrit dans le
  dtail dans le wiki d'OSM : http://wiki.openstreetmap.org/wiki/Nantes/Adresses_postales_Nantes_M%C3%A9tropole.
  
  
  Il a t signal sur cette liste de diffusion fin 2011 et
  dbut 2012  plusieurs occasions.
  Le 7 mars dernier, plusieurs membres du bureau d'OSM France
  ont particip  la runion avec Nantes Mtropole  propos de
  ce projet.
  
  Jusqu' ce jour, personne n'a mis d'objection ou de remarque
  quant  la dmarche adopte ni voqu le recours  un compte
  OSM ddi.
  
  Le message de pnorman est  verser au dbat actuel sur cette
  liste. pnorman n'attend pas de rponse de ma part.
  
  Je relve simplement que le projet n'est pas un import brut et
  massif mais qu'il s'agit d'une intgration rue par rue avec
  vrification et souvent correction manuelle par le
  contributeur.
  La logique est la mme que pour les corrections d'osmose. Y
  a-t-il un compte ddi pour la correction des erreurs
  signales par osmose ?
  
  Nantes Mtropole procde rgulirement  des mises  jour de
  ses donnes adresses.
  Un nouveau projet est  monter pour traiter leur intgration 
  OSM.
  
  Il serait bon que la communaut OSM aboutisse  un accord sur
  la manire de procder. Cela concerne potentiellement de
  nombreux projets Opendata.
  
  Librement
  
  Christophe
  
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-fr

  
  
  
  
  -- 
  ab_fab
  "Il n'y a pas de pas perdus"
  
  
  
  ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr



  


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

Re: [OSM-talk-fr] Imports du cadastre et compte dédié - import adresses Nantes aussi !

[djo_man]

  
  
bonjour,

J'ai intgr les adresses du quartier de Bellevue  Nantes avec
l'outil en question. Il manquait beaucoup de choses de base.
(parkings, voies, impasses, jardins, pelouses). J'ai intgr les
adresses + les modifs par rue en essayant de toujours noter les rues
dans l'intitul du changeset afin dtre traable. 

Pas possible de faire cela avec un compte ddi !
j'aurais d faire autrement et j'en aurais oubli la moiti ! 

djo_man


Le 29/09/2012 11:58, Jean Couteau a
  crit:


  Le 29/09/2012 11:36, Ab_fab a crit :

  
Pour la publicit de l'import / intgration, je suis OK. Mais si la
seule vraie obligation est ensuite de crer un compte ddi, qui va
contribuer ?
Dans les discussions prliminaires sur les adresses de Nantes, il a t
choisi de permettre de contribuer avec le moins d'engagement possible,
pour s'assurer de toujours finir proprement ce qui a t entam.
Bref, c'est une opration par rue.

http://wiki.openstreetmap.org/wiki/Nantes/Adresses_postales_Nantes_M%C3%A9tropole
Sur la page du wiki, on voit la rpartition par utilisateurs : certains
se sont normment impliqus, et auraient peut tre cr un compte pour
l'occasion. D'autres (et je m'y place volontiers) ont eu une activit
plus symbolique. Dans mon cas, je n'aurais probablement pas particip.

  
  
J'ai beaucoup particip  cette intgration, dans mon cas les changesets
taient plutt par quartier que par rue, mais l n'est pas le problme.
Crer un compte ddi, je l'aurai srement fait. Par contre, comme pour
le cadastre, nous tions sur un processus d'intgration manuelle,
comment procde-t-on quand, lorsque l'on veut intgrer les adresses
d'une rue, on doit modifier la gomtrie de la rue (sur certaines villes
de la communaut urbaine, on avait encore des rues manquantes, ou sans
nom, ou  la gomtrie vraiment ancienne (sans Bing pour aider)) ? On se
retrouve dans le mme cas que lors de l'intgration du cadastre. Nos
changesets ne comportent pas que des donnes intgres ( moins de
vouloir crer des erreurs).

Certes, cela reste un "import" et cela doit tre trait comme tous les
imports et la publicit sur imports@ aurait pu tre ajoute (mais on a
quand mme fait pas mal de pub sur le boulot effectu), mais dans notre
cas, je dirais que le compte spar est quand mme encore plus litigieux
que pour le cadastre (l'chelle est vraiment diffrente et le travail
manuel au-moins sinon plus important). Attention  ne pas mettre trop de
contraintes.

Pour cette intgration, de nombreuses fois, j'ai fait des sessions
d'intgration d'une dizaine de rues sur ma pause le midi. Avec tout le
process de compte spar,... je ne l'aurais pas fait et l'intgration
aurait t beaucoup plus longue. De plus, dans le cas de Nantes, la
communaut est de plus en plus importante, la mtropole, le CG  et
Libertic participants grandement  nous aider (organisation de
cartoparties, soutien logistique,...). Ces "imports" n'ont pas tu la
communaut locale, bien au contraire.

Jean

PS : il me semble que je dois tre le 2me plus gros contributeur sur
cette intgration (loin derrire isnogoud qui a vraiment abattu un
boulot monstre) et je n'ai reu aucun message pour l'instant.


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



  


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

Re: [OSM-talk-fr] Hauteur de marée référente pour trait de côte ?

[djo_man]

  
  
bonjour  tous

Pour rpondre  Christian,
( arretez-moi ds que je dis une btise)

La limite du domaine public maritime c'est le trait de cte pour la
France.
La limite du domaine maritime c'est les plus hautes eaux (article
L.2111-4 du code gnral de la proprit des personnes publiques
(CGPPP)) 
le trait de cote devrait tre le boundary=administrative dans OSM ?

Donc il devrait y avoir 2 ways dcals : 1 pour le
boundary=administrative + water=tidal (partie haute) et 1 pour le
natural=coastline et non pas tout confondu dans un seul way . non ?

Il faudrait tout redessiner la coastline atlantique et les limites
administatives de cette cte ? ( y'a pas de mare en mditerrane ?
 ;-) )

djo_man

Le 20/09/2012 13:40, Bruno Cortial a
  crit:


  Le 20 septembre 2012 09:58, Fanny
Schertzer fanny.schert...@gmail.com
a crit :

  
  
  http://wiki.openstreetmap.org/wiki/Coastline
  prconise le "mean high
  water spring", soit grosso modo une pleine mer de coefficient
  70. Plus
  bas donc que la terre des cartes marines, mais plus haut que
  le niveau
  moyen.
  
  Fanny

  


  

Bonjour,
"mean highwater spring" cela correspond  "pleine mer de
  vive eau moyenne", donc c'est un coeff 90. En hauteur absolue
  l'cart entre un coeff 90 et 120 est en gnral d'une 50aine
  de centimtres sur les cotes atlantiques en france. c'est dj
  pas mal, avec un trait de cte forcement diffrent.


Exemple  Brest :
une mare de 90http://maree.info/82?d=20120929
Et une mare de 110http://maree.info/82?d=20121017


Dans des coins plus particuliers on dpasse 1m20 d'cart
  entre lemean highwater spring d'OSM (et anglais) et notre
  "120" franais (IGN  SHOM).
St-Malo "90"http://maree.info/52?d=20120929

St-Malo "110"http://maree.info/52?d=20121017




A noter toutefois que la norme OSM est la plus simple 
  mapper  partir d'orthophotos : les laisses de mer qui y sont
  visibles sont plus proches du niveau attendu par OSM.


A+
Bruno
  
  
  
  
  ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr



  


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

Re: [OSM-talk-fr] Hauteur de marée référente pour trait de côte ?

[djo_man]

Le 25/09/2012 16:56, Bruno Cortial a écrit :



Par contre concernant les limites administrative des communes 
présentent dans OSM, doivent-elle déborder la natural=coastline ?
Pour moi la commune s'arrête au trait de côte. Le cadastre étend la 
zone sur la mer, mais sans critère cohérent. Le maire a un droit de 
police dans la bande des 300 mètres, mais il s'agit d'un territoire 
qui relève de l'état.


trait de cote=limite de la commune/canton/region/france me parait le 
plus juste

mais comment on fait ?
on en reste au coef 90 comme tu disais ? environ la moyenne des marées 
hautes.


mais rien à voir avec les geolittoral qui me semble avoir été faites 
toutes effectivement durant un laps de temps similaire rapport au niveau 
d'eau mais ne sont pas du tout à la moyenne des marées hautes. On voit 
trop d'estran


djo_man

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

Re: [OSM-talk-fr] Modération de la liste talk-fr [Etait : Potlatch, utilisable avec le cadastre ?]

[djo_man]

bonjour à tous

j'interviens rarement sur la liste mais ce que signal Pieren à été un 
problème pour moi aussi.
J'ai, au début, souvent lu les mails en questions pour au final être 
plus perdu qu'avant .

Rien de grave pourtant car je suis très persévérant.

Aujourd'hui j'ai blacklisté ce posteur incontient.
plus de bruit...

Je pense aussi comme Pieren qu'il devrait être modéré.

Désolé Philippe. Il est fort possible pourtant que j'irai lire ton blog.

djoman

Le 11/09/2012 19:25, Pieren a écrit :

2012/9/11 Ista Pouss ista...@gmail.com:


Philippe ne me dérange
absolument pas : au bout de la dizième ligne je ne le lis en général plus)
(désolé Philippe),

Beaucoup réagissent comme toi. Mais on reçoit aussi parfois ici des
plaintes de gens qui se désabonnent parce qu'il y a trop de messages
ou trop d'informations. A force, Philippe peut parfois dire d'énormes
bêtises que personne ne corrige puisque seuls les nouveaux le lisent.
Le risque étant ensuite qu'il soit pris au pied de la lettre
évidemment.

Pieren

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




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

Re: [OSM-talk-fr] Suppression des GR dans OSM

[djo_man]

bonjour,

J'ai bien tout lu,
Je crois avoir tout compris

Au début des mes contributions actives (1 an), j'ai été surpris par la
force d'OSM : Une rigueur légale qui est le support de sa force libre.
Je comprend ceux qui voudraient défendre les bons principes mais
j'estime qu'il ne faut pas risquer de toucher cette rigueur légale.

je suis pour la suppression des termes litigieux appartenant à la FFRP
ainsi que la suppression des itinéraires lorsqu'ils ne peuvent pas être
rattaché à des itinéraires autorisés, historiques, etc

ça me fait bien c... pourtant.

Mais je me réconforte par les avancées futures
avec la FFRP redoré par la pureté de notre BDD OSM.

librement
bien à vous tous.
djo_man

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

[OSM-talk-fr] fusion de bing maps avec OSM ? info ou intox ?

[djo_man]

Title: Philippe Saill et Stven Aoustin, architectes  Nantes pour
  un architecture contemporaine

  
  

bonjour  tous

au detour du blog de
http://iphonesoft.fr/2012/05/04/iphoto-la-mise-a-jour-101 on croise

"Il faut savoir que Microsoft a annonc la fusion de Bing
Maps avec OSM, ce que fait dj Facebook ou encore Foursquare.
"

info ou intox ?
  


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

Re: [OSM-talk-fr] Accueil des nouveaux contributeurs

[djo_man]

  
  
bonjour, 

J'ai commenc vritablement  contribuer  OSM qu'il y 1 an. Mon
caractre me guide toujours  assembler les infos dispos avant de
faire quoi que ce soit mais pourtant j'ai fait pas mal d'erreurs
qu'aujourd'hui encore, je corrige. 

J'ai de moi mme contact des contributeurs de la zone ou je
souhaitais travailler et j'ai aussi t contact par certains quand
mes erreurs taient trop visibles. Grce  cela (et  la liste) j'ai
"dcouvert" les outils d'autocorrection ( la semaine dernire
encore: osmose par nom de contributeur, bravo pour cet outil ! ).
J'imagine que tous les contributeurs ne sont pas comme moi.

Personnellement, j'aurais vraiment aim qu'un mail automatique
resumant les vidences me soit envoy par l'asso. Je trouverais a
efficace et non-intrusif car clairement automatique.

Et dans ce mail si il y a un lien vers une page super dbutant,
dbutant, etc, trs bien.

Et dans ce mail si il y avait un lien vers une page pour choisir un
parrain, pourquoi pas.

Si jamais un contributeur chevronn d'une zone veut, en plus,
prendre contact directement et nominativement, cela resterait
compatible.

Aprs, il y a sans doute la manire de ce "premier contact direct"
pour viter l'effet "l'intrusif" . a doit tre d'abord une question
de ressenti perso. De mon cot, je trouve qu'un contact direct ds
mes premires contributions m'aurait un peu dcontenanc.
Qu'aurais-je pens ? Puisqu'ils voient tout ce que je fais, j'ai les
boules car je me sens jug ? Puisqu'ils sont si jaloux de
l'intgrit de leur base je ne ferais plus rien avant dtre sur ? 

quoi qu'il en soit
ce que vous ferez sera bien pour moi
djo_man



Le 06/02/2012 10:53, Ab_fab a crit:
Bonjour,
  
  
  Pensez-vous qu'un outil identifiant les nouveaux
contributeurs sur un territoire donn (une rgion, la France
Mtropolitaine) serait une bonne chose ?
  
  
  L'ide tant de pouvoir facilement les identifier pour
  _ regarder la teneur des premires contributions,
  _ proposer par la messagerie interne de les pauler pour les
premiers pas, guider vers des tutos, d'autres outils ...



  En tant que "ex-nouveaux contributeur" (on l'est tous), est-ce
  que vous auriez apprci ce genre de prise de contact (j'y ai
  eu droit, et j'ai trouv a trs intressant), ou alors vous
  considrez que c'est trop "intrusif" ?


Une ide sur une manire efficace de procder ?


-- 
ab_fab
"Il n'y a pas de pas perdus"
  
  
  
  
  ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr


  


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

[OSM-talk-fr] Coastline

[djo_man]

Title: Philippe Saill et Stven Aoustin, architectes  Nantes pour
  un architecture contemporaine

  
  

bonjour, 

Je crois avoir un problme avec la coastline modifie par mes soins
dans l'embouchure des traits (tiers) qui amne l'eau de mer au
marais salant de Gurande (le reste est en cours) :

  j'ai retrac la coastline  partir des orthophoto geolittoral
et de la carte bing (et de mes connaissances du site bien sur,
correctes mais pas exhaustives, mais ce n'est pas le sujet)
  pour cela j'ai cr une ligne toute neuve commenant sur un
noeud d'une fin de segment de coastline. ici:
http://www.openstreetmap.org/browse/node/28260889. je n'ai pas
dplac ce nud. Ma ligne de cte finie sur un autre point de
fin de segment existant de la coastline, ici:
http://www.openstreetmap.org/browse/node/28261086
  j'ai supprim sur l'ancien tronon (l'ancienne coastline entre
ses 2 points) le tag coastline
  mais je n'ai pas supprim les relations administatives
boundary, admin_level etc. ni dplac les nuds
  
  cela fait bien 2 mois que j'ai fais la premire version de
cette coastline (hier la dernire)
  
  Donc depuis 2 mois, je ne vois aucune modification du trait de
cte. la mer semble toujours coller aux limites administratives
  
  pour info "la mer s'est colle" sur le nouveau trait de cte
modifie par mes soins aux abords de la plage de M. Hulot 
Saint-marc sur Mer effectue  peut prt en mme temps
  

ou est-ce que j'ai fais une erreur ?
merci  vous
djoman
  


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

Re: [OSM-talk-fr] Coastline

[djo_man]

Title: Philippe Saill et Stven Aoustin, architectes 
Nantes pour un architecture contemporaine

  
  
merci  toi Vlad
Je vais tenter la technique force de mise  jour

D'aprs ce que je comprend cela peut arriver si la zone ne subie pas
trop de modification. 
Mais ici ce n'est pas le cas car je contribue assez fortement autour
et sur le marais salant de Gurande depuis plusieurs semaines deja
et tous mes changeset sont rapidement visibles meme a des zooms
larges.

Ce qui m'tonne moi c'est que la mer semble "se coller" plutt aux
limites administratives et non pas simplement a la pure coastline
simple. 

Mauvaises deductions ?

djoman



Le 14/10/2011 17:08, Vladimir Vyskocil a crit:
Quand les modifications sur la coastline sont
  incorpores dans la base en production ce qui peut prendre un
  certain temps, souvent mme un temps certains (se compte en
  semaines), les dalles correspondantes ne sont pas automatiquement
  recalcules si rien d'autre a chang depuis le moment ou la
  coastline a t intgr dans la base !
  Pour voir apparaitre les modifications lies a la coastline
il faut soit :
  - attendre un hypothtique recalcule du fond de carte (cela
arrive vraiment a ?)
  - modifier le contenu de la zone correspondante (ways,
node,relations autre que la coastline), et l'update normale de
cette zone va aussi mettre a jour le fond de la carte.
  - forcer le recalcule de ces dalles en utilisant /dirty sur
l'url d'une des tiles, ce qui va provoquer le recalcule de cette
dalle et de quelques voisines. Un exemple d'url est le suivant :
  http://a.tile.openstreetmap.org/17/43115/59679.png/dirty
  
  
  Vlad.
  

  
On 14 oct. 2011, at 12:29, djo_man wrote:


  
  
   
bonjour, 

Je crois avoir un problme avec la coastline modifie
par mes soins dans l'embouchure des traits (tiers) qui
amne l'eau de mer au marais salant de Gurande (le
reste est en cours) :

  j'ai retrac la coastline  partir des orthophoto
geolittoral et de la carte bing (et de mes
connaissances du site bien sur, correctes mais pas
exhaustives, mais ce n'est pas le sujet)
  pour cela j'ai cr une ligne toute neuve
commenant sur un noeud d'une fin de segment de
coastline. ici: http://www.openstreetmap.org/browse/node/28260889.
je n'ai pas dplac ce nud. Ma ligne de cte finie
sur un autre point de fin de segment existant de la
coastline, ici: http://www.openstreetmap.org/browse/node/28261086
  j'ai supprim sur l'ancien tronon (l'ancienne
coastline entre ses 2 points) le tag coastline
  mais je n'ai pas supprim les relations
administatives boundary, admin_level etc. ni dplac
les nuds
  
  cela fait bien 2 mois que j'ai fais la premire
version de cette coastline (hier la dernire)
  
  Donc depuis 2 mois, je ne vois aucune modification
du trait de cte. la mer semble toujours coller aux
limites administratives
  
  pour info "la mer s'est colle" sur le nouveau
trait de cte modifie par mes soins aux abords de
la plage de M. Hulot  Saint-marc sur Mer effectue
 peut prt en mme temps
  

ou est-ce que j'ai fais une erreur ?
merci  vous
djoman
  
  ___
  Talk-fr mailing list
  Talk-fr@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-fr

  
  

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


  


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

Re: [OSM-talk-fr] Besoin de bêta-testeurs pour mon site

[djo_man]

  
  
bonjour  tous,

Trs beau travail en effet
question bte ? : N'y a t'il pas de droit d'auteur sur le style IGN
top25 ?

djoman

Le 27/09/2011 07:50, Ab_fab a crit:
Magnifique travail sur le style !
  Srieux et raffin ...
  Je ne suis pas all dans les dtails, c'est ma premire
impression
  
  
  Il faut un peu de temps (30 secondes quoi ;-) ) pour
dcouvrir les possibilits d'affichage/occultation des infos.
Mais on en comprend vite le potentiel.
  J'ai perdu l'habitude d'appuyer sur des boutons pour zoomer /
dzoomer. C'est volontaire de ne pas avoir activ la molette ?
  
  
  La catgorisation des POI  afficher (faon OSM interest) est
top.
  On s'attend juste  avoir un pop-up pour une description plus
prcise (type de boutique, nom de l'htel)
  
  
  Vu la qualit graphique et la possibilit de faire ses
annotations, est-ce que l'impression  une bonne dfinition (par
ex. au format PDF) d'une zone est envisageable ?
  Est-ce une fonction que tu rserveras  ton activit pro ?
  
  
  Bien vu pour la section "en savoir plus". Cela va t'pargner
beaucoup de questions !

Le 27 septembre 2011 04:07, Krysst krysstauf...@laposte.net
  a crit :
  Bonjour 
tous,


Je tiens, en guise de prliminaires,  vous avertir des
choses suivantes :
1) Je ne veux tromper personne : un des buts assums du site
que je prsente ici sera de devenir la porte d'entre de ma
mienne socit de Gomatique. La page d'accueil restera a
priori en l'tat, la cartographie sera toujours sous licence
libre, mais j'ajouterai dans un futur plus ou moins proche
de quoi conduire mon business personnel, probablement sous
la forme d'un ou deux boutons situs en haut  droite. Pas
plus, mais pas moins.
2) Si besoin est, je ne me priverai pas non plus de mettre
une bannire de pub en haut de page pour financer une partie
de l'normissime cot du serveur
3) Tout ce que vous verrez est en bta : cela va faire 1
mois que je recule sans cesse l'ouverture au public pour
corriger des petites choses  droite et  gauche et... et
j'en ai marre ! Donc je craque, et j'envoie tout maintenant,
en l'tat, fautes d'orthographes et bogues  l'appui. :-/
Pourquoi ? Parce que j'ai grand besoin d'enfin savoir si mon
serveur tient ou pas le coup.

Au chapitre informations (en vrac et j'en oublie
certainement, vu l'heure vous ne m'en voudrez pas...) :
- la qualit tant une de mes priorits, la cartographie est
intgralement rendue en PNG 24 bits (avec alpha sur 8 bits,
il va de soi :-o). Ce qui veut dire qu'une connexion 
2Mbits est souhaitable, que votre cache navigateur risque de
se remplir  la vitesse de la lumire, et que les petites
configs risquent de ramer. Merci de me le signaler si c'est
inutilisable.
- le rendu a, au pire, une semaine d'ge : sachez qu'il faut
1 semaine entire de calculs pour mettre  jour ce que vous
voyez, le dernier niveau de zoom demandant  lui seul 4
jours...
- le rendu "carte topographique" est optimis pour le ~1:10
000,
- le rendu "plan" devrait  terme bnficier d'un voire deux
niveaux de zoom supplmentaires (qui devront tre calculs 
la demande, d'o leur absence pour le moment)
- le rendu "plan" prsente pour l'instant d'importants bugs
sur le bti en multipolygon, je n'y peux rien, c'est a ou
pas d'effet 3D. Si le prochain Mapnik 2 ne corrige pas le
problme, vous m'aiderez probablement  faire une choix...
- j'ai fait en sorte de coller au plus prs  la lgende et
n'ai donc fait aucune concession au rendu : si une carrire
apparat au milieu d'un cours d'eau, c'est que son primtre
doit tre corrig ; si des highway=pedestrian linaires
apparaissent au dessus de polygones
highway=pedestrian+area=yes, c'est qu'ils n'ont rien  faire
l ; etc.
- la cartographie est en Lambert 93 et non en Mercator.
Parce que ma nature masochiste me fait adorer ne pouvoir
utiliser les meilleurs outils disponibles actuellement (MAJ
auto du rendu  partir d'osm2pgsql, mod_tile...), mais
surtout parce que, je vous l'assure, le Groenland n'est pas
plus grand que l'Afrique.
- la choucroute c'est bon, mangez-en
- mapnik 0.7 est utilis pour le rendu
- tilecache (en 

Re: [OSM-talk-fr] precautions d'usages avant modification ?

[djo_man]

bonjour,

En fait il s'agit d'une petite Ville touristique que je connais bien: 
Guérande dans le 44

http://www.openstreetmap.org/?lat=47.3254108428955lon=-2.42407321929932zoom=15

les boulevards autour des fortifications ne sont pas à mon avis en 
secondary vu que les indications routières forcent à l'usage des 
boulevards plus périphériques


un avis ?

djoman


Le 19/09/2011 10:29, Pieren a écrit :

2011/9/18 djo_mandjo_...@laposte.net:

bonjour,

Faut-il toujours prendre quelques précautions auprès du précédent
contributeur avant de modifier la hiérarchie des voies ?

Si l'erreur est grossière, comme le dit Nicolas, tu peux rectifier
directement. Contacte la personne si tu veux mais c'est un plus.
Regarde d'abord s'il est encore actif
(http://www.openstreetmap.org/user/son compte/edits). Si c'est le
cas, c'est peut-être une erreur de jeunesse qu'il sera capable de
rectifier lui-même.


Encore plus précisément à cette endroit de la page du wiki : Voies dans les
agglomérations/Grands axes de circulation, rues principales/exemple 1) ?

L'exemple est assez clair. L'excès de surclassification est
immédiatement identifiable. Par contre, retrouver les voies de transit
qui méritent cette sur-classification (en tertiary, secondary ou
primary), c'est autre chose... Il ne faut pas uniquement se fier aux
références (RN départementale, nationale) même si dans la plupart des
cas, cela correspond. Une connaissance du terrain est encore plus
nécessaire que d'habitude dans ce domaine.
Tu pourrais aussi nous envoyer un permalink pour voir si quelqu'un de
la liste peut aider.

Pieren

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



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

Re: [OSM-talk-fr] cale et ponton de rivière

[djo_man]

  
  
bonjour

Et le tout bte man_made=pier ?
il serait pas correct ?
http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dpier

djoman


Le 17/09/2011 19:31, nono a crit:

  Salut

Je note les cales et les pontons le long des rivires de mon coin.

J'utilise :
 leisure=slipway pour les cales de ce type
http://wiki.openstreetmap.org/wiki/File:Slipway.jpg

Pour les pontons, du genre en bois et de petite taille 1,5 mtres sur 3
mtres (souvent juste avant l'cluse), je ne sais pas trop quel tag
mettre. J'aimerai galement ajout une mention de type  accessible
kayak et cano .

Quelqu'un a une ide ?

nono


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


  


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

[OSM-talk-fr] precautions d'usages avant modification ?

[djo_man]

bonjour,

Faut-il toujours prendre quelques précautions auprès du précédent 
contributeur avant de modifier la hiérarchie des voies ?


Plus précisément lorsque les tag ne respectent pas la page 
http://wiki.openstreetmap.org/wiki/FR:France_roads_tagging,
Encore plus précisément à cette endroit de la page du wiki : Voies dans 
les agglomérations/Grands axes de circulation, rues principales/exemple 1) ?


merci à vous
djoman


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

[OSM-talk-fr] où prévenir en cas de travail d’ampleur ?

[djo_man]

bonjour,
Je me dis souvent que cela serait vraiment dommage de travailler sur le 
même endroit qu'un autre utilisateur.


existe-il une page ou bien est-ce ici même que l'on pourrait prévenir de 
l'endroit de nos efforts afin de ne pas se couper l'herbe sous le pied ?


Travail d'ampleur à mon échelle de débutant quand même, comme
- une commune du 44, genre Dréféac
- les marais salant de guérande (sur plusieurs communes)
- compléter les hierarchies des voies (secondary/tertiary/unclassifed) 
dans le l'espace moitié vide Redon/Roche-Bernard/Héric/Nozay


djoman

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

[OSM-talk-fr] précautions d'usages avant modification ?

[djo_man]

bonjour,

Je reposte car j'ai fait repondre au lieu de nouveau, mon precedent 
mail doit etre mal rangé maintenant... :-(


Faut-il toujours prendre quelques précautions auprès du précédent 
contributeur avant de modifier la hiérarchie des voies ?


Plus précisément lorsque les tag ne respectent pas la page 
http://wiki.openstreetmap.org/wiki/FR:France_roads_tagging,
Encore plus précisément à cette endroit de la page du wiki : Voies dans 
les agglomérations/Grands axes de circulation, rues principales/exemple 
1) ?


merci à vous
djoman



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

Re: [OSM-talk-fr] Avenue perdue à Nantes

[djo_man]

bonjour,

oui effectivement, particularité locale, les avenues à Nantes sont 
historiquement plutôt des impasses privées !
Je ne me rappelle plus mes cours d'histoire urbaine, j'ai donc oublié la 
raison à cela...


djoman


Le 16/09/2011 06:59, Jean Couteau a écrit :

Le 15/09/2011 23:06, Vincent de Chateau-Thierry a écrit :

Bonsoir,

Le 15/09/2011 22:32, Christian Rogel a écrit :

J'avais repéré, grâce à l'Artesi, le géocodeur BatchGeoCode. Il y a
deux ou trois ans, il fonctionnait avec
l'API de Yahoo!, maintenant, il s'appelle Batchgeo (batchgeo.com) et
il fonctionne avec Google.

J'avais à géocoder une liste et je vois qu'une adresse de Nantes,
l'avenue Louis Vasseur pointe entre
le 6 et le 8 de la rue Gabriel Luneau, exactement dans une cour privée
et close.

Ce qui est le plus curieux, c'est que Nominatim et Yahoo donnent le
même résultat?
L'adresse semble exacte, puisqu'elle figure dans un CV en ligne avec
le nom de personne correct.

1/ Un Nantais peut-il dire où est l'avenue Louis Vasseur

D'autres sources disent la même chose :
- sur le site du cadastre, les parcelles associées à l'avenue Louis
Vasseur sont bien dans un tout petit périmètre qui débouche entre le 6
et le 8 de la rue Gabriel Luneau,
- StreetView [1] permet d'apercevoir, au même endroit, même si c'est
derrière une grille, la plaque de rue Avenue Louis Vasseur.

Je ne connais pas ce cas particulier, mais à Nantes, il y a plein de
rues très courtes, privées et fermées par une grille. Des petits havres
de paix en plein centre ville, plutôt des impasse mais à l'origine ça a
été créé pour les bourgeois et c'est quand même plus classe d'habiter
dans une avenue, même si c'est une allée de 20m ;).

J'espère que ça explique un peu.

Jean

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



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

[OSM-talk-fr] tag motorway contre trunk - autoroute à 3 lettres gratuite

[djo_man]

Title: Philippe Saill et Stven Aoustin, architectes  Nantes pour
  un architecture contemporaine

  
  

bonjour,
Nouveau venu sur la liste et pas tellement plus vieux
  contributeur sur OSM...
Le tag motorway est-il toujours obligatoire dans le cas suivant ?
  :


  une autoroute  3 lettres (donc un barreau autoroutier ) 
  
  en liaison avec une rocade, 
  
  gratuite, 
  
  limite  110 et 90, 
  
  grer par la DDE et non pas un concessionnaire habituel 
  


le tag trunk n'est il pas plus indiqu, plus raliste, proche de
l'in-situ, moins ambigu ?

surtout quant-aux logiciels libre de navigation comme NAVIT ou
OSMAND qui ne gre pas bien le tag toll (d'exprience personnelle du
moins)

Je pense  la A844 qui est le tronon nord du priph de Nantes


merci  vous tous.
djoman
  


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