date:20120727

Les arrêts de bus dans chaque sens d'une ligne sont rarement au même
endroit, sauf dans quelques endroits privilégiés pour les bus. Mais
dans les rues ouvertes à tout véhicule, ou sur la route, il y a des
tas de contraintes (surtout liés à la sécurité pour l'accès et la
traversée des piétons, et au manque de place pour ne pas bloquer la
circulation ou tout un trottoir) qui font que les arrêts sont souvent
décalés, ou desservis dans un seul sens.

Le 27 juillet 2012 13:55, Francescu GAROBY  a écrit :
> Nouveau problème à signaler : si on suit la recommandation concernant les
> itinéraires de bus on se retrouve avec N lignes de bus du même numéro pour
> un même arrêt, vu qu'il peut y avoir le chemin aller, le retour voire des
> itinéraires alternatifs.
> Je pense qu'il faudrait ne faire apparaitre qu'une fois (par arrêt) un
> numéro de ligne.

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

Re: [OSM-talk-fr] les mosquées de france

L'intégration sur le site de ses données géolocalisée (des POI's du
KML) sur un fond de carte fourni par Google n'en fait pas la propriété
de Google qui ne demande que d'utiliser son API pour obtenir son fond
de carte mais n'acquière pas les droits sur les POIs géolocalisés.

Mais celui qui a fait ce site a du commencer par utiliser ce qu'il
connaissait. Si son site reçoit trop de visites et que Google lui
demande de payer pour supporter plus d'affichages de son fond de
carte, on peut déjà contacter l'auteur pour lui montrer comment les
outils OSM savent aussi utiliser et intégrer les mêmes données qu'on
intègre avec l'API Google. La migration est possible.

Ensuite si le site veut ou non libérer ses données c'est autre chose
(à mon avis, faire connaitre les mosquées aux musulmans par tous les
moyens est une obligation morale, et si on leur montre comment faire,
il pourrait décider de fournit son fichier KML en OpenData, même s'il
en reste la source sur son site. Le plus tpot il le fera, plus il aura
les chances d'être crédité dans OSM (et donc garder de la visibilité
de son site). Car sinon l'essentiel sera porté par les contributeurs
individuels (ou par les assos locales qui chacune gère sa mosquée ou
son lieu de prière, et va vite avoir aussi des adhérents ou voisins
qui vont géolocaliser dans OSM ces lieux).

L'intérêt du site reste tout de même les infos supplémentaires qu'il
peut donner : heures d'ouverture, évènements et fêtes supportés (dans
ou hors les murs, par exemple dans des lieux d'exposition ou
manifestations culturelles), accueil ou non des femmes, capacité
d'accueil et équipements, cours d'arabe ou sur l'islam, activités
interconfessionelles (entre musulmans ou avec d'autres cultes),
activités civiles ou humanitaires, photos intérieures des lieux (car
ils ne sont pas toujours ouverts aux non-croyants, ou pas à certaines
heures ni partout), montant des cotisations demandées (pour
l'organisation du culte, la location des lieux, ou les remboursements
d'emprunts pour travaux), appels aux dons en cas de difficultés
financières pour réaliser des travaux de sécurité obligatoire (sinon
risque de fermeture administrative), recherche de lieux d'accueils,
concours pour l'aménagement et la décoration des lieux... et
discussions sur son forum interne. De quoi assurer plein de nouvelles
choses et de contenus qui vont intéresser autant les musulmans que les
non-musulmans, venus de France ou d'ailleurs.

Je ne crois pas que la question de la licence soit si bloquante que
ça. Déjà on peut lui demander. Je doute fort que l'auteur ait donné
une licence exclusive à Google.. Et puis il doit bien y avoir des
musulmans inscrits ici qui découvrent ce site, et qui pourront aussi
le convaincre d'ouvrir ses données. Sinon on peut aller en parler
aussi sur le forum du site.

Le 27 juillet 2012 15:57, Christian Quest  a écrit :
> Même question que pour le site masjids-map.com dont on avait parlé il y a un
> an... comment les données ont été constituées ? Par relevé ? Par géocodage ?
> Avec quel service de géocodage? Problème de licence, etc...
>
> Le site http://www.trouvetamosquee.fr/ utilisant des fond de carte Google,
> je crains que ça coince encore une fois quelque part.

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

Re: [OSM-talk-fr] Tagguer une résidence (était : Tagguer un bâtiment à usage multiple)

On peut effectivement argumenter sur le fait que la notion de
"résidence" est plutôt du domaine privé (la copropriété) tandis que
celle de "zone résidentielle" tient plus à celle de zone d'aménagement
décidée ou réglementée par une collectivité non pas pour prendre en
compte l'existant mais planifier les aménagements à réaliser ou
l'évolution souhaitée d'une zone pour le futur.

Cependant 'landuse" traduit plutôt ***l'utilisation actuelle*** du
terrain, qu'un plan d'aménagement.

Si on prend en compte l'existant, rien n'empêche d'avoir des zones
actuelles qui se touchent (façon puzzle), dont certaines sont nommées
et privées et clairement délimitées, d'autres n'ont rien d'autre que
la référence à une zone de définition plus floue dans ses limites.

Corine est sensé plutôt représenter l'existant (moyennant une
résolution faible qui ignore des tas de détails locaux et un retard
certain dans la prise en compte des évolutions, un écart qu'on devrait
pouvoir corriger). Si on a une résidence privée clairement délimitée,
c'est un usage du terrain qui va rester persistant pendant longtemps,
quel que soit l'interprétation qu'on donne d'une zone plus grande au
contour flou, et même dont les plans d'aménagements urbains pour le
futur (par exemple les nouveaux PLU réglementaires qui ont remplacé
les anciens POS) ne vont pas effacer avant longtemps.

Il me semble que les PLU et autres plan d'aménagement réglementaires
résultent d'avantage d'un découpage administratif local (les ilotages,
les IRIS, les PLU) qui ont peu de rapport avec ce qu'on trouve dans
Corine (qui ignore totalement les découpages adminstratifs mais est
nettement plus proche de la réalité actuelle ou garde la trace encore
du passé faute de mise à jour).

Etant donné le peu de détail apporté par Corine, on peut se permettre
de modifier ces données pour mieux coller à la réalité : ce n'est pas
parce que Corine a dessiné une zone commerciale large qu'on doit
oublier que cette zone inclue des zones plus petites effectivement
plus résidentielles comme les résidences privées qui ne vont pas
bouger avant des décennnies, quel que soit les changement de
propriétaires.

(des copropriétés existent dans de nombreuses villes depuis le début
du XXe siècle voire un peu avant, au départ c'était souvent une
propriété unique d'un seul aménageur, avant que les successions et
reventes partielles ne morcellent ces propriétés tout en conservant
des zones communes qu'il a bien fallu gérer en commun entre les
propriétaires restants, la destination pouvant changer éventuellement
entre une résidence pure et une utilisation comme local commercial ou
loué par une collectivité, parfois devenant copropriétaire aussi, pour
y installer un local administratif, une crèche municipale, un bureau
de police municipale, des bureaux d'appoint, une réserve de matériel
pour les jardiniers municipaux, des salles de formation, etc... de
façon temporaire ou permanente...).

Si la copropriété fonctionne correctement, est entretenue, il n'y a
pas de raison pour qu'un plan d'aménagement urbain vienne en déloger
les occupants (propriétaires et locataires, résidents ou entreprises
et organismes publics ou mixtes). L'aménagement public ses fera autour
et pourra éventuellement limiter l'extension d'usage de ces résidences
ou les obliger à ne le permettre que dans certaines conditions. Mais
la destination résidentielle ne changera pas avant longtemps même si
maintenant cela forme un ilôt au milieu d'une zone plus grande qui n'a
plus vocation résidentielle : on résoud cela en morcelant aussi les
landuse.

Le "puzzle" de ces zones est inévitable, mais cela ne pose pas de
difficultés particulières notamment entre Corine et l'existant
cartographié.

Mais les PLU (et zonages décidés adminstrativement) sont d'une autre
nature, car ils représentent plus une évolution future qui n'existe
pas encore (et peut-être ne verra jamais le jour tel que projeté)
résultant juste d'une volonté politique locale, dépendante totalement
aussi de la volonté ou non des aménageurs ou acquéreur à y venir (cela
peut rester longtemps en l'état, sauf en cas de règlement obligatoire
imposé aux occupants pour se conformer à une règle environnementale ou
sanitaire d'ordre général). L'évolution de ces zones sera très lente,
sauf en cas d'expropriation par la collectivité (ce qui coûte très
cher et rencontre de nombreuses résistances juridiques).

Le 28 juillet 2012 00:50, Vincent de Chateau-Thierry
 a écrit :
>
> Le 28/07/2012 00:20, Philippe Verdy a écrit :
>
>> Le 27 juillet 2012 23:51, Vincent de Chateau-Thierry
>>  a écrit :
>>>
>>> Le 27/07/2012 23:42, Philippe Verdy a écrit :

 Aussi je ne vois pas pourquoi landuse=residential doit être
 obligatoirement lié à Corine (dont la couverture n'est qu'européenne
 ou dans certaines dépendances d'outre-mer des pays européens).

>>>
>>> Moi non plus, mais ça tombe bien, ça n'est pas le sujet ici. Le sujet, ce
>>> sont les résidences, telles que celles que tu décrivais d'a

Re: [OSM-talk-fr] Tag d'une intersection avec priorité à droite ?

Le 27 juillet 2012 22:05, panierAvide  a écrit :
> Le 27/07/2012 21:32, Vincent de Chateau-Thierry a écrit :
>
>>
>> Le 27/07/2012 21:04, Yannick VOYEAUD a écrit :
>>>
>>>
>>> La priorité à droite étant la règle je ne vois pas pourquoi il faudrait
>>> la tagguer?
>>
>>
>> Où alors la formuler dans cette relation :
>> http://www.openstreetmap.org/browse/relation/934933
>>
> C'est une bonne idée. Je ne connais pas la réglementation routière "par
> défaut" des autres pays, mais ça m'étonnerait que tous utilisent la règle de
> la priorité à droite.

Déjà pas au Royaume-Uni...

Je m'étonne de ne pas trouver dans cette relation des "defaults" pour
le code de la route en France, l'indication du fait qu'on circule du
côté droit de la route, alors que cela a des conséquences évidentes
pour la navigation pour prévenir où se placer sur la route.

Les voies ne sont pas toujours séparées mais bien en usage
bidirectionnel assez souvent, à l'approche d'un carrefour ou d'un
rétrécissement de chaussée qui ne permet le passage que dans un seul
sens (pas toujours matérialisé par une priorité de passage pour un
sens ou l'autre, notamment en ville aujourd'hui où les municipalités
mettent en place un peu partout des places de stationnement et ilots
passant tous les 50 mètres ou moins d'un côté à l'autre pour obliger à
faire un slalom et se mettre en attente pour les croisements, mais
surtout pour forcer à rouler très en dessous même de la vitesse limite
de 50 km/h et inciter les automobilistes à rester en dehors des
centre-ville, et utiliser les transports en commun ou le vélo.

[sidenote]
Parfois ces aménagements se font même là où circulent les bus urbains
: eux-même sont gênés, et se multiplient les collisions de bus avec
les véhicules qui se garent dans les emplacements construits exprès,
où je n'oserais pas aller me garer, et les véhicules qui défoncent ou
plantent leurs bas de caisse sur les îlots, et tous les accidents avec
les rétros arrachés, et même les vélos qui se font reverser ou
accrocher. Avant ça les mêmes rues avaient un stationnement d'un seul
côté, autrefois alterné par quinzaine, voire aucun stationnement mais
deux voies contraires parfaitement roulantes, mais plus maintenant :
une seule file utilisable; et parfois même on trouve ces slaloms
ajoutés dans des rues où il n'y avait déjà qu'une seule voie mais où
on pouvait se croiser relativement facilement, dans des rues où même
un véhicule tout seul a même du mal à passer ou risque d'accrocher ses
ailes sur les bornes et panneaux posés sur les ilots ; de même ces
slaloms compliquent la signalisation des carrefours et traversées
piétons qui sont moins visibles à cause justement des véhicules garés
maintenant des deux côtés qui limitent la longueur de visibilité.

Bref on commence à se demander en France de quel côté on doit rouler
si on trouve de plus en plus de ces voies uniques bidirectionnelles
(même pas des sens uniques, c'est visiblement fait exprès pour
compliquer la circulation, mais je je suis pas certain que ça améliore
la sécurité : il y a plus d'accidents, même s'ils sont moins grave à
priori, mais une collision ou chute dans ces slaloms, par manque de
visibilité ou parce qu'un véhicule ne peut pas physiquement braquer de
façon aussi serrée sans accrocher quelquechose peut aussi être fatale,
même à 30 km/h !).

Longtemps la "mode" c'était de supprimer les règles de priorité à
droite dans les carrefours se croisant à angle droit, en mettant des
ronds-points partout. Maintenant même hors des intersection, la "mode"
c'est de créer des slaloms et réduire le nombre de voies et multiplier
la circulation alternée, et supprimer la notion de rue plus
prioritaire qu'une autre en rendant les segments prioritaires moins
longs (la priorité à droite est une espèce en voie rapide d'extinction
avec ces aménagements...)
[/sidenote]

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

Re: [OSM-talk-fr] Tagguer une résidence (était : Tagguer un bâtiment à usage multiple)



Le 28/07/2012 00:20, Philippe Verdy a écrit :

Le 27 juillet 2012 23:51, Vincent de Chateau-Thierry
 a écrit :

Le 27/07/2012 23:42, Philippe Verdy a écrit :

Aussi je ne vois pas pourquoi landuse=residential doit être
obligatoirement lié à Corine (dont la couverture n'est qu'européenne
ou dans certaines dépendances d'outre-mer des pays européens).



Moi non plus, mais ça tombe bien, ça n'est pas le sujet ici. Le sujet, ce
sont les résidences, telles que celles que tu décrivais d'ailleurs ce matin
même :
http://lists.openstreetmap.org/pipermail/talk-fr/2012-July/045919.html
Quel(s) tag(s), plutôt que landuse=residential, coller sur ce genre
d'emprise ?


Ben justement c'est le sujet, et landuse=residential colle très bien à
ce qu'on appelle une "résidence"



Je trouve, au contraire, que ça ne colle pas. Un polygone 
landuse=residential décrit plutôt, dans la base, une notion un peu floue 
(je parlais d'échelle "macro") qui entoure, au sens propre, la zone 
d'habitat regroupé d'une commune, pas loin de ce que l'INSEE appelle les 
zones urbaines :

http://insee.fr/fr/methodes/default.asp?page=definitions/unite-urbaine.htm
Je pense que ce type de landuse=residential a toute sa place avec ce tag 
dans la base, et avec une précision géométrique bien loin du 
micro-mapping. Ses limites restent subjectives, chacun façonnant le 
contour selon son appréciation des bâtiments à inclure. Par comparaison, 
je trouve que recourir au même tag pour des emprises à la limite pas du 
tout floue, et d'étendue bien plus petite, que sont les résidences, est 
regrettable.


Je peux reformuler sous l'angle de l'exploitation des données : 
imaginons que je veux faire un plan de ville qui mette en évidence les 
résidences, et qui représente aussi le contour de la zone urbaine. Et, 
évidemment, je ne veux pas représenter de la même manière les résidences 
et la zone urbaine. Si j'ai d'un côté "landuse=residential" (pour les 
résidences) et de l'autre "landuse=residential" (pour la zone urbaine), 
je suis bloqué pour charter distinctement les 2 notions. D'où le sujet.


vincent

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

Re: [OSM-talk-fr] Le sandre aussi a changé de peau


Le 27/07/2012 23:08, Eric a écrit :

Donc, on peut les utiliser directement ou juste comme moyen de contrôle
? C'est super intéressant comme source et ca a l'air précis pour ce que
j'ai essayé autour de chez moi. Peut-on décalquer ces SHP si on crédite
Sandre ?
Et tous ces tags sont-ils à garder ?


Attention la source n'est pas le sandre. Il y a tout ces tags et encore 
plus de bazar, mais l'on utilise ce que l'on veut. Enfin si on peu 
utiliser cette source.


Frédéric.


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

Re: [OSM-talk-fr] Tagguer une résidence (était : Tagguer un bâtiment à usage multiple)

Le 27 juillet 2012 23:51, Vincent de Chateau-Thierry
 a écrit :
> Le 27/07/2012 23:42, Philippe Verdy a écrit :
>> Aussi je ne vois pas pourquoi landuse=residential doit être
>> obligatoirement lié à Corine (dont la couverture n'est qu'européenne
>> ou dans certaines dépendances d'outre-mer des pays européens).
>>
>
> Moi non plus, mais ça tombe bien, ça n'est pas le sujet ici. Le sujet, ce
> sont les résidences, telles que celles que tu décrivais d'ailleurs ce matin
> même :
> http://lists.openstreetmap.org/pipermail/talk-fr/2012-July/045919.html
> Quel(s) tag(s), plutôt que landuse=residential, coller sur ce genre
> d'emprise ?

Ben justement c'est le sujet, et landuse=residential colle très bien à
ce qu'on appelle une "résidence" (administrée par une copropriété) qui
inclue dans sa surface divers objets: bâtiments d'habitation ou
d'activité commerciale, voies et rues de service souvent privées, même
si parfois la voie d'accès principale traverse en partie la surface ou
est une impasse se terminant dans la résidence, chemins piétons,
jardins, aires de jeux ou de sport, une clôture éventuelle, une
barrière d'entrée gardée ou non, des parkings ou garages, locaux de
service (poubelles, installations de climatisation, postes de
transformation d'énergie), tous tagués selon le besoin, et tous les
bâtiments ne sont pas forcément au même numéro, et il y a souvent
aussi une numérotation interne des bâtiments ou portes d'entrées et
escaliers.

L'import des données Corine a consisté à réutilise des tags les plus
proches comme landuse=* mais ces données restent toujours à affiner
partout car la résolution de Corine est assez faible et a été faite
pour donner une couverture continentale dans un volume exploitable
pour afficher une carte au mieux à l'échelle d'une ville de 20 000
habitants. Le tracé contient trop de segments rectilignes d'une
longueur allant de 100 mètres à plusieurs kilomètres, on est très loin
de l'échelle ce qu'on a à mettre dans OSM où on cherche de plus en
plus à approcher la résolution décamétrique, ou métrique dans nombre
de villes, voire décimétrique dans les zones très denses en
informations avec des voies de communication qui se croisent ou se
superposent sur plusieurs niveaux.

Corine c'est juste bien pour avoir un fond de carte pour la France
entière par exemple ou un de ses départements. Dès qu'on va en
dessous, les problèmes pour recoller les autres éléments commencent...
En plus les polygones Corine, quand ils sont très grands
(particulièrements les forêts) sont très souvent fractionnés avec des
lignes de coupe totalement arbitraires (souvent pour maintenair le
nombre de nœuds en dessous de 500 voire 200, sachant que les moteurs
de rendus d'OSM ont aussi du mal à gérer rapidement des polygones de
plus de 2000 sommets).

De plus les données Corine sont souvent anciennes, même dans la base
2006 importée ces données venaient en faite de relevés bien plus
anciens voire mal interprétées car réalisés sur des imageries à basse
résolution et souvent encore plus anciennes (ce n'est pas comme
aujourd'hui où l'imagerie a connu un essor fulgurant avec plein de
sources disponibles et qui aujourd'hui s'échangent de plus en plus et
sont rafraîchies bien plus souvent avec des coûts bien moindres car
plus facilement cofinancés pour diverses activités humaines, sociales,
environnementales, économiques, voire légales pour la prévention des
risques, la sécurité intérieure ou extérieure, et la planification ou
l'optimisation de nombreux projets).

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

Re: [OSM-talk-fr] Tagguer une résidence (était : Tagguer un bâtiment à usage multiple)


Le 27/07/2012 23:42, Philippe Verdy a écrit :



Aussi je ne vois pas pourquoi landuse=residential doit être
obligatoirement lié à Corine (dont la couverture n'est qu'européenne
ou dans certaines dépendances d'outre-mer des pays européens).



Moi non plus, mais ça tombe bien, ça n'est pas le sujet ici. Le sujet, 
ce sont les résidences, telles que celles que tu décrivais d'ailleurs ce 
matin même :

http://lists.openstreetmap.org/pipermail/talk-fr/2012-July/045919.html
Quel(s) tag(s), plutôt que landuse=residential, coller sur ce genre 
d'emprise ?


vincent

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

Re: [OSM-talk-fr] Tagguer une résidence (était : Tagguer un bâtiment à usage multiple)

Le 27 juillet 2012 23:21, Vincent de Chateau-Thierry
 a écrit :
>
> Le 27/07/2012 21:53, Pieren a écrit :
>>
>> 2012/7/27 Mathieu Rajerison :
>>>
>>> une zone englobant les différents bâtiments ayant ces attributs:
>>> name = [nom de la résidence]
>>> landuse = residential
>>> [autres clés possibles pour la zone?]
>>>
>>> Et pour les bâtiments:
>>> name = [bat. A, nom de l'immeuble]
>>> building = residentiel
>>> éventuellement, nb de niveaux, etc..
>>
>>
>> C'est aussi comme ça que je procède.
>>
>
> L'usage, au moins en France, de landuse=residential correspond à une échelle
> plus macro, propagée entre autre par les polygones Corine : une zone
> continue de bâti à vocation essentiellement d'habitation. On est là sur des
> zones plus vastes que le simple pâté de maisons/immeubles nommé "Résidence
> xxx".
> Du coup en utilisant landuse=residential pour une résidence, je trouve qu'on
> décrit 2 notions distinctes, d'échelles assez éloignées, avec le même tag.
> Dommage. Est-ce qu'on ne trouverait pas un autre couple clé/valeur, soit en
> plus, soit (mieux) à la place, de landuse=residential, pour décrire une
> résidence ?
>
> Je dis ça et en même temps, je n'ai rien à proposer :-(

Les polygones Corine étant très informels et assez imprécis peuvent
être fractionnés si nécessaire pour prendre en compte des réalités
plus tangibles.

Le fractionnerment ne posera pas de problème particulier (sauf en ce
qui concerne les CLC-ID qui devraient être partagés en cas de
fractionnement, sans pour autant la nécessité de les regrouper dans
une autre relation qui ne représente pas grand chose d'utile hormis le
fait de marquer qu'une zone a bien été importée (si nécessaire on peut
toujours faire l'union géométrique des zones landuse ayant le même
CLC-ID pour retrouver l'original). Il affinera même le contour très
vague et tracé à la hache de ces zones Corine dont la résolution
effecive est très faible et passe allégrement à travers toutes les
structures physiques (bâtiments, rues, routes, et même les éléments
naturels que ces zones sont sensées couvrir).

On peut largement le faire car les polygones Corine ne demandent qu'à
être affinés, et leur géométrie ne colle pas avec ce qu'on tague à des
résolution plus élevées, et produisent à ces résolution une
représentation assez foullie à un point même qu'on est souvent amené
justement à éviter de représenter ces grands polygones imprécis Corine
sur une carte pour laisser mieux voir les éléments plus détaillés
qu'ils recouvrent (sinon c'est illisible sur n'importe quelle carte,
même si on ne colore ces polygones Corine que comme un arrière-plan
sur lequel on pose le reste)

Aussi je ne vois pas pourquoi landuse=residential doit être
obligatoirement lié à Corine (dont la couverture n'est qu'européenne
ou dans certaines dépendances d'outre-mer des pays européens).

De même pour la couverture forestière Corine, trop vague pour
correspondre à la réalité plus détaillée des bois et forêts et qui
incluent trop de petites zones qui ne sont pas de la forêt... On
affine les tracés, on redécoupe quitte à éclater une même zone Corine
en plusieurs morceaux qu'il n'est pas nécessaire de conserver ensemble
dans le même objet.

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

Re: [OSM-talk-fr] Tagguer une résidence (était : Tagguer un bâtiment à usage multiple)



Le 27/07/2012 21:53, Pieren a écrit :

2012/7/27 Mathieu Rajerison :

une zone englobant les différents bâtiments ayant ces attributs:
name = [nom de la résidence]
landuse = residential
[autres clés possibles pour la zone?]

Et pour les bâtiments:
name = [bat. A, nom de l'immeuble]
building = residentiel
éventuellement, nb de niveaux, etc..


C'est aussi comme ça que je procède.



L'usage, au moins en France, de landuse=residential correspond à une 
échelle plus macro, propagée entre autre par les polygones Corine : une 
zone continue de bâti à vocation essentiellement d'habitation. On est là 
sur des zones plus vastes que le simple pâté de maisons/immeubles nommé 
"Résidence xxx".
Du coup en utilisant landuse=residential pour une résidence, je trouve 
qu'on décrit 2 notions distinctes, d'échelles assez éloignées, avec le 
même tag. Dommage. Est-ce qu'on ne trouverait pas un autre couple 
clé/valeur, soit en plus, soit (mieux) à la place, de 
landuse=residential, pour décrire une résidence ?


Je dis ça et en même temps, je n'ai rien à proposer :-(

vincent

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

Re: [OSM-talk-fr] Le sandre aussi a changé de peau



par contre attention à bien lire les métadonnées de la couche 
avant de

l'utiliser pour ajouter des infos dans OSM, la plupart des données
cartographiques sont dérivées de la BDCarthage, donc avec les mêmes
restrictions d'utilisation
(http://wiki.openstreetmap.org/wiki/FR:Potential_Datasources/France#Sandre.2FBD_CarTHAgE)


Oui ça je savais ;)



Ça veut dire quoi ?

Sur le portail data.gouv.fr

http://www.data.gouv.fr/donnees/view/Couche-SIG-des-caract%C3%A9ristiques-des-bassins-2010-%3A-eaux-de-surface---Adour-Garonne-30381839?xtmc=caract%C3%A9ristiques+des+bassins+2010&xtcr=2 



Il est marqué : Licence Ouverte/Open Licence
pour ce jeu de donné qui ne contient que les polygones et les 
références. Pour moi tel que c'est présenté, et sans méta-info sans 
rien d'autres, c'est libre sous LOOP.


Frédéric.


Donc, on peut les utiliser directement ou juste comme moyen de contrôle 
? C'est super intéressant comme source et ca a l'air précis pour ce que 
j'ai essayé autour de chez moi. Peut-on décalquer ces SHP si on crédite 
Sandre ?

Et tous ces tags sont-ils à garder ?

   ALT_CAT=MID
   ARTIFICIAL=N
   BASIN_CD=FR
   CRITMDO=N
   CTX_PISCI=0
   DATAFROM=18690155900069
   EU_CD=FRDR12061
   GEOL_CAT=C
   HYDROECOR=6
   ID=7430.0
   INS_BY=AERM&C
   ITEM001=1
   LAT=44.70353
   LON=4.84882
   MODIFIED=N
   MS_CD=DR12061
   NAME=rivière la tessonne
   REF_IBD=0.0
   REF_IBGN=0.0
   REF_IBMR=0.0
   REF_IP=0.0
   REGION_CD=13
   RWBODY_ID=6627
   SIZE=10.915
   SIZE_CAT=S
   STATUS_YR=2006
   STRAHLER_M=2
   SYSTEM=B
   TAILLE_FR=TP
   TYPE_FR=46

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

Re: [OSM-talk-fr] Tag d'une intersection avec priorité à droite ?

2012-07-27 Par sujet panierAvide


Le 27/07/2012 21:32, Vincent de Chateau-Thierry a écrit :


Le 27/07/2012 21:04, Yannick VOYEAUD a écrit :


La priorité à droite étant la règle je ne vois pas pourquoi il faudrait
la tagguer?


Où alors la formuler dans cette relation :
http://www.openstreetmap.org/browse/relation/934933

C'est une bonne idée. Je ne connais pas la réglementation routière "par 
défaut" des autres pays, mais ça m'étonnerait que tous utilisent la 
règle de la priorité à droite.


Cordialement.

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

Re: [OSM-talk-fr] Tagguer un bâtiment à usage multiple (était: Re: Quelques questions d'un débutant OSM)

2012-07-27 Par sujet Éric Gillet

Voilà c'est ça, après rien ne vous empêche de faire une relation de type
site en plus pour lier de manière sure les éléments entre-eux, au pire elle
sera ignorée par les outils.

Je pense tout de même qu'elle est nécessaire, surtout dans le cas de
plusieurs niveaux, comme par exemple une station de métro sous une
résidence.

2012/7/27 Mathieu Rajerison 

> Je suis d'accord avec votre approche.
>
> Je débute sous OSM. Si je comprends bien, pas de relation de type site
> mais une zone englobant les différents bâtiments ayant ces attributs:
> name = [nom de la résidence]
> landuse = residential
> [autres clés possibles pour la zone?]
>
> Et pour les bâtiments:
> name = [bat. A, nom de l'immeuble]
> building = residentiel
> éventuellement, nb de niveaux, etc..
>
>
> Le 27 juillet 2012 10:35, Philippe Verdy  a écrit :
>
> Oui mais là il a voulu dire qu'une résidence c'est souvent une emprise
>> avec du terrain autour, parfois aussi une barrière, et dedans
>> plusieurs batiments, avec plusieurs entrées et donc plusieurs numéros,
>> mais aussi souvent des parkings, des équipements paysagers ou aires de
>> jeux, voire aussi des locaux de service (poubelles par exemple). Ainsi
>> que les voies de circulation (auto, chemins piétons/vélos) dans la
>> résidence Le tout s'entendant souvent sur plusieurs parcelles
>> cadastrales (que d'habitude on ne représente pas)
>>
>> On tague alors la résidence sur la surface de la totalité de son
>> emprise en lu donnant son nom.
>>
>> On inclut dedans le tracé séparé des bâtiments (imports du cadastre),
>> et on peut y ajouter les POIs supplémentaires (s'il y a des commerces
>> ou entreprises à géolocaliser dedans). Il n'est pas nécessaire de les
>> lier. La résidence est ni plus ni moins qu'un landuse=residential
>> auquel on inclut un tag name, mais pas les noms de rues (privées) ni
>> aucun tag de ce qui a été dessiné dedans. Et pas besoin non plus d'y
>> mettre un place représentant la résidence (les POIs pour les commerces
>> ou entreprises, ou voies de circulation ou jardins et aires de jeux ou
>> équipements sportifs n'ont pas nécessité non plus de rappeler le nom
>> de la résidence qui les contient, on se contente de leur donner leur
>> propre nom au cas où il se distingue du nom de la résidence elle-même,
>> sinon les tags du type d'objet ou pour leur destination ou utilisation
>> suffisent).
>>
>> Il ne me semble pas nécessaire pour autant de créer une relation
>> regroupant le tout si l'emprise totale de la résidence suffit (dans
>> laquelle il reste permis d'avoir des ilots internes avec une frontière
>> de rôle "inner", en cas de besoin de les sortir de cette emprise. Le
>> principe est alors le même que pour les communes, quartiers, et ilots
>> de quartiers, sauf que la bordure peut avoir des tags pour désigner le
>> mur ou la clôture elle-même (s'il y en a une) et les barrières
>> d'entrée, en segmentant cette ligne de bordure externe.
>>
>> Le 27 juillet 2012 09:41, Christian Quest  a
>> écrit :
>> > +1 avec Eric
>> >
>> > A mon avis le principe général doit rester: un objet un tag...
>> >
>> > Il n'y a qu'une résidence XXX, donc les attributs la décrivant doivent
>> > être présent une fois et une seule dans la base dans la mesure du
>> > possible, d'où le tracé de son emprise que l'o va tagguer en
>> > conséquence.
>> >
>> > --
>> > 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
>>
>
>
> ___
> 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] Tagguer un bâtiment à usage multiple (était: Re: Quelques questions d'un débutant OSM)

2012-07-27 Par sujet Pieren

2012/7/27 Mathieu Rajerison :
> une zone englobant les différents bâtiments ayant ces attributs:
> name = [nom de la résidence]
> landuse = residential
> [autres clés possibles pour la zone?]
>
> Et pour les bâtiments:
> name = [bat. A, nom de l'immeuble]
> building = residentiel
> éventuellement, nb de niveaux, etc..

C'est aussi comme ça que je procède. Je réserve la relation de type
"site" pour les "sites" dispersés en différents endroits (genre
universités, administrations, ec) donc impossibles à encadrer dans un
seul polygone.
Cf la doc de la relation
(http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site):
"However, this relation is not to be used in simple cases. If all the
elements contained within an area (the perimeter) belong to the site,
and no elements of the site exist outside the area, then it is
inappropriate to use this relation. Simply tag the perimeter with all
the appropriate tags, and implementations can perform an is-in-polygon
test to determine what elements belong to the site."

Traduc:
"Cependant, cette relation ne doit pas être utilisée dans les cas
simples. Si tous les éléments contenus dans le périmètre unique
appartiennent au site, et qu'aucun élément du site ne se trouve en
dehors de ce périmètre, l'utilisation de la relation est inappropriée.
Tagguez simplement le périmètre avec tous les attributs nécessaires,
etc..."

Pieren

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

Re: [OSM-talk-fr] Tag d'une intersection avec priorité à droite ?



Le 27/07/2012 21:04, Yannick VOYEAUD a écrit :


La priorité à droite étant la règle je ne vois pas pourquoi il faudrait
la tagguer?


Où alors la formuler dans cette relation :
http://www.openstreetmap.org/browse/relation/934933

vincent

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

Re: [OSM-talk-fr] Taggage vol libre

Voir déjà ici: http://wiki.openstreetmap.org/wiki/Key:monitoring:weather

On peut rajouter le tag operator pour indiquer qui la gère.


Le 27 juillet 2012 20:06, Eric Pommereau  a écrit :
> A ce sujet, il est prévu de tagger les balises météo ?
>
> ++
>
> Le 27 juillet 2012 15:33, Eric Pommereau  a écrit
> :
>
>> Bonjour,
>>
>> Après la traduction de la page dédié au vol libre je me suis fait la main
>> sur la côte des deux amants en taggant les deux décos et l'atterrissage...
>> n'hésitez pas si vous avez des remarques.
>>
>> l'emplacement :
>> http://www.openstreetmap.org/?lat=49.31588&lon=1.24478&zoom=16&layers=M
>> La page FFVL : http://federation.ffvl.fr/structure/993/sites/27001
>>
>> J'ai pris le parti de créer une zone et non un point pour représenter les
>> sites (landuse:grass) et j'ai essayé d'être le plus exhaustif possible.
>>
>> Si il n'y a pas de tag name c'est le tag operator qui est pris pour nommer
>> l'emplacement (le nom du club reponsable du site). Ce n'est pas pertinent.
>> J'ai choisi de nommer chaque lieu comme c'est le cas sur le site de la FFVL
>> ce qui a plus de sens...
>>
>> Voilà
>>
>> @++
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] Tag d'une intersection avec priorité à droite ?

2012-07-27 Par sujet Yannick VOYEAUD

Le 27/07/2012 20:01, panierAvide a écrit :

Bonsoir,

Je me suis rendu aujourd'hui dans un village où tous les carrefours sont
des priorités à droite, et sont signalés comme tel (avec le panneau AB 1
[1]). En cas d'absence de signalisation à un carrefour, on doit
appliquer la priorité à droite, et ce principe est peut-être déjà
utilisé pour le routage dans OSM. Mais existe t'il un tag qui permet
d'indiquer que la priorité à droite à une intersection n'est pas
implicite, du fait de la présence de la signalisation ? Mes recherches
sur le wiki n'ont rien donné, la page des correspondances pour la
signalisation en France [2] ne propose pas non plus le cas du panneau AB 1.
S'il n'existe aucun tag approprié, quelle serait la meilleure solution ?
Un junction=priority_to_the_right ? Ou un highway=priority_to_the_right
? Ou autre chose ?

Cordialement.

[1] http://wiki.openstreetmap.org/wiki/File:Fr-AB1-Intersection.gif
[2]
http://wiki.openstreetmap.org/wiki/FR:Road_signs_in_France#Signaux_d.E2.80.99intersection_et_de_priorit.C3.A9_de_type_AB

Bonsoir,

La priorité à droite étant la règle je ne vois pas pourquoi il faudrait
la tagguer? C'est un choix contraire qu'il convient de tagguer! En
créant des ronds points on sait que la priorité est à gauche pour entrer
et à droite pour en sortir.
Le fait que tu rencontres ce panneau te préviens simplement d'une
intersection.
Amha ce panneau devrait être systématiquement utilisé dès que le
carrefour n'est pas parfaitement visible à 150m y compris en ville mais
bon nos élites préfèrent faire des travaux ahurissant soit disant pour
la sécurité plutot que de déjà utiliser les moyens basiques d'alerte sur
un danger potentiel.

Amitiés

--
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org

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

Re: [OSM-talk-fr] Taggage vol libre

2012-07-27 Par sujet Eric Pommereau

A ce sujet, il est prévu de tagger les balises météo ?

++

Le 27 juillet 2012 15:33, Eric Pommereau  a écrit
:

> Bonjour,
>
> Après la traduction de la page dédié au vol libre je me suis fait la main
> sur la côte des deux amants en taggant les deux décos et l'atterrissage...
> n'hésitez pas si vous avez des remarques.
>
>- l'emplacement :
>http://www.openstreetmap.org/?lat=49.31588&lon=1.24478&zoom=16&layers=M
>- La page FFVL : http://federation.ffvl.fr/structure/993/sites/27001
>
> J'ai pris le parti de créer une zone et non un point pour représenter les
> sites (landuse:grass) et j'ai essayé d'être le plus exhaustif possible.
>
> Si il n'y a pas de tag name c'est le tag operator qui est pris pour nommer
> l'emplacement (le nom du club reponsable du site). Ce n'est pas pertinent.
> J'ai choisi de nommer chaque lieu comme c'est le cas sur le site de la FFVL
> ce qui a plus de sens...
>
> Voilà
>
> @++
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Tag d'une intersection avec priorité à droite ?

2012-07-27 Par sujet panierAvide


Bonsoir,

Je me suis rendu aujourd'hui dans un village où tous les carrefours sont 
des priorités à droite, et sont signalés comme tel (avec le panneau AB 1 
[1]). En cas d'absence de signalisation à un carrefour, on doit 
appliquer la priorité à droite, et ce principe est peut-être déjà 
utilisé pour le routage dans OSM. Mais existe t'il un tag qui permet 
d'indiquer que la priorité à droite à une intersection n'est pas 
implicite, du fait de la présence de la signalisation ? Mes recherches 
sur le wiki n'ont rien donné, la page des correspondances pour la 
signalisation en France [2] ne propose pas non plus le cas du panneau AB 1.
S'il n'existe aucun tag approprié, quelle serait la meilleure solution ? 
Un junction=priority_to_the_right ? Ou un highway=priority_to_the_right 
? Ou autre chose ?


Cordialement.

[1] http://wiki.openstreetmap.org/wiki/File:Fr-AB1-Intersection.gif
[2] 
http://wiki.openstreetmap.org/wiki/FR:Road_signs_in_France#Signaux_d.E2.80.99intersection_et_de_priorit.C3.A9_de_type_AB


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

Re: [OSM-talk-fr] Import bâti avec trop de points

2012-07-27 Par sujet didier2020

Le vendredi 27 juillet 2012 à 18:32 +0200, Jean-Claude Repetto a écrit :
> On 27/07/2012 15:28, didier2020 wrote:
> > on parle de moi? je rougis ;)
> > 
> > Faille/ce que le script ne sais pas faire:
> > - corriger les erreurs des batiments suisses (ce n'est pas une blague)
> > - suivant la précision du bati (7 ou 6 décimales), le script est plus ou
> > moins performant
> > - faire comme si un trait a une épaisseur de 15/20 cm pour "simuler" la
> > largeur du mur afin de raccrocher les nodes éloignées tout en ayant un
> > mur "droit". De plus, c'est difficile (pour moi...) a identifier: un
> > coin de mur en commun, ou 2 traits ayant un angle tres proche 
> 
> Un algorithme genre Douglas-Peucker ne serait-il pas utilisable pour la
> simplification ?
merci, je ne connaissais pas. voir l'image jointe. le resultat voulu
etant a droite.

> 
> Jean-Claude
> 
> ___
> 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] Import bâti avec trop de points

2012-07-27 Par sujet Jean-Claude Repetto

On 27/07/2012 15:28, didier2020 wrote:
> on parle de moi? je rougis ;)
> 
> Faille/ce que le script ne sais pas faire:
> - corriger les erreurs des batiments suisses (ce n'est pas une blague)
> - suivant la précision du bati (7 ou 6 décimales), le script est plus ou
> moins performant
> - faire comme si un trait a une épaisseur de 15/20 cm pour "simuler" la
> largeur du mur afin de raccrocher les nodes éloignées tout en ayant un
> mur "droit". De plus, c'est difficile (pour moi...) a identifier: un
> coin de mur en commun, ou 2 traits ayant un angle tres proche 

Un algorithme genre Douglas-Peucker ne serait-il pas utilisable pour la
simplification ?

Jean-Claude

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

Re: [OSM-talk-fr] petit bug dans josm ?



Le 27/07/2012 17:38, Hélène PETIT a écrit :

+il n'y a plus d'icones du tout, on dirait :
+__ni sur l'église :
Cache de styles pour "Église d'Ys ‎(42.8978491, 0.396576) [identifiant :
1 277 435 095]" :

 > style xml "JOSM Internal Style" appliqué

Intervalle:|s0.0-Infinity
  default:
Cascade{ }

 > ignore "Potlatch 2" (inactif)

Liste des styles générés :
  * NodeElemStyle{z_idx=[4.1/0.0/0.0] }
  * BoxTextElemStyle{z_idx=[5.0/0.0/0.0]
labelCompositionStrategy={DeriveLabelFromNameTagsCompositionStrategy}
font=java.awt.Font[family=SansSerif,name=Helvetica,style=plain,size=8]
color=#ff box=java.awt.Rectangle[x=-2,y=-2,width=5,height=5]
hAlign=RIGHT vAlign=BOTTOM}

+__ni la-dessus :
Cache de styles pour "1837040350 ‎(42.898785, 0.3567176) [identifiant :
1 837 040 350]" :

 > style xml "JOSM Internal Style" appliqué

Intervalle:|s0.0-Infinity
  default:
Cascade{ }

 > ignore "Potlatch 2" (inactif)

Liste des styles générés :
  * NodeElemStyle{z_idx=[4.1/0.0/0.0] }



Je viens d'essayer avec la même relation, mais aussi avec celle de Coëx 
(85), vu que :

http://www.openstreetmap.org/browse/way/77705293

Mais dans les 2 cas je n'ai pas de souci.

vincent

*---
Cache de styles pour "Pailhac ‎(42.90765, 0.36812) [identifiant : 
1 706 148 514]" :


> style xml "JOSM Internal Style" appliqué

Intervalle:|s0.0-Infinity
 default:
Cascade{ text:Keyword{auto}; 
icon-image:IconReference{iconName='place/settlement/town.png' 
source='JOSM Internal Style'}; }


> ignore "Potlatch 2" (inactif)

Liste des styles générés :
 * NodeElemStyle{z_idx=[4.0/0.0/0.0]  icon=[place/settlement/town.png]}
 * BoxTextElemStyle{z_idx=[5.0/0.0/0.0] 
labelCompositionStrategy={DeriveLabelFromNameTagsCompositionStrategy} 
font=java.awt.Font[family=SansSerif,name=Helvetica,style=plain,size=8] 
color=#ff box=java.awt.Rectangle[x=-8,y=-8,width=16,height=16] 
hAlign=RIGHT vAlign=BOTTOM}


*---
Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2012-07-23 01:31:06
Last Changed Author: Don-vip
Revision: 5356
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2012-07-22 22:36:44 +0200 (Sun, 22 Jul 2012)
Last Changed Rev: 5356

Identification: JOSM/1.5 (5356 fr)
Memory Usage: 53 MB / 1160 MB (13 MB allocated, but free)
Java version: 1.6.0_31, Sun Microsystems Inc., Java HotSpot(TM) Client VM
Operating system: Windows Vista
Dataset consistency test: No problems found


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

Re: [OSM-talk-fr] petit bug dans josm ?


+il n'y a plus d'icones du tout, on dirait :
+__ni sur l'église :
Cache de styles pour "Église d'Ys ‎(42.8978491, 0.396576) [identifiant : 
1 277 435 095]" :


> style xml "JOSM Internal Style" appliqué

Intervalle:|s0.0-Infinity
 default:
Cascade{ }

> ignore "Potlatch 2" (inactif)

Liste des styles générés :
 * NodeElemStyle{z_idx=[4.1/0.0/0.0] }
 * BoxTextElemStyle{z_idx=[5.0/0.0/0.0] 
labelCompositionStrategy={DeriveLabelFromNameTagsCompositionStrategy} 
font=java.awt.Font[family=SansSerif,name=Helvetica,style=plain,size=8] 
color=#ff box=java.awt.Rectangle[x=-2,y=-2,width=5,height=5] 
hAlign=RIGHT vAlign=BOTTOM}


+__ni la-dessus :
Cache de styles pour "1837040350 ‎(42.898785, 0.3567176) [identifiant : 
1 837 040 350]" :


> style xml "JOSM Internal Style" appliqué

Intervalle:|s0.0-Infinity
 default:
Cascade{ }

> ignore "Potlatch 2" (inactif)

Liste des styles générés :
 * NodeElemStyle{z_idx=[4.1/0.0/0.0] }





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

Re: [OSM-talk-fr] petit bug dans josm ?

et alors, sans fermer josm, et sans supprimer le calque actuel, je 
recharge la zone ;
et là, toutes les icônes place=village et place=hamlet de la zone sont 
remplacées par le petit carré.


Pfou.

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

Re: [OSM-talk-fr] petit bug dans josm ?


Le 27/07/2012 16:24, Vincent Privat a écrit :

ça c'est intéressant. Est-ce que le noeud ou la relation font l'objet
d'avertissement du validateur ?


+ je charge la zone dans une nouvelle occurrence de josm : l'icône est 
présente.

+ depuis le panneau "Relations", je sélectionne la relation "Pailhac"
+ depuis le panneau "Résultats de validation", je clique le Btn "Valider"
Résultat :
Autre
   Pas de style pour un multipolygone(1)
   frontière[8]("Pailhac",4 membres etc

et si je copie-colle :
org.openstreetmap.josm.data.validation.TestError@54a4bc69

ET LA, TOUT DE SUITE, je refais la manip sélection-modifier-valider, et 
l'icône se conserve .


Alors je ferme josm, je le relance, je charge la zone, et je refais la 
manip sélection-modifier-valider, et l'icône se conserve : je clique sur 
l'icône de la voisine, "Jéseau", et cloc, son icône disparait.


Je jette les ponges (ponges, ponges, serviettes et ponges) pour 
aujourd’hui, je n'ai pas d'idée pour un autre jeu de tests.


à plus,

Hélène


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

Re: [OSM-talk-fr] petit bug dans josm ?

2012-07-27 Par sujet Vincent Privat

Le 27 juillet 2012 15:20, Hélène PETIT  a écrit :

> sans faire aucun changement, je clique sur le Btn "Valider"
> aussitôt l'icône disparait et est remplacée par le microbique carré.
>

ça c'est intéressant. Est-ce que le noeud ou la relation font l'objet
d'avertissement du validateur ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] les mosquées de france

Même question que pour le site masjids-map.com dont on avait parlé il y a
un an... comment les données ont été constituées ? Par relevé ? Par
géocodage ? Avec quel service de géocodage? Problème de licence, etc...

Le site http://www.trouvetamosquee.fr/ utilisant des fond de carte Google,
je crains que ça coince encore une fois quelque part.

-- 
Christian Quest - OpenStreetMap France -
http://openstreetmap.fr/u/cquest
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] les mosquées de france

2012-07-27 Par sujet Ab_fab

Encore une mission pour XapiViewer :
http://osm.dumoulin63.net/xapiviewer/?zoom=12&lat=48.85819&lon=2.3478&layers=B0T&icon=icons%2Fplace_of_worship_islamic3.n.32.png&request=religion%3Dmuslim

La requête ne porte que sur religion = muslim, je ne sais pas comment
combiner avec "amenity = place_of_worship"

Le 27 juillet 2012 15:39, Florian LAINEZ  a écrit :

> Salut,
> Un musulman a fait la carto de toutes les mosquées de france :
> http://www.lemonde.fr/societe/article/2012/07/27/trouvetamosquee-fr-le-ramadan-road-trip-d-un-jeune-musulman_1739146_3224.html
>
> Si ça intéresse quelqu'un de parler d'open-data à ce jeune homme ... Moi
> la flemme sorry
> salut
>
> --
>
> *Florian Lainez*
> http://twitter.com/overflorian
> http://www.nouslesgeeks.fr
>
> ___
> 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

[OSM-talk-fr] les mosquées de france

2012-07-27 Par sujet Florian LAINEZ

Salut,
Un musulman a fait la carto de toutes les mosquées de france :
http://www.lemonde.fr/societe/article/2012/07/27/trouvetamosquee-fr-le-ramadan-road-trip-d-un-jeune-musulman_1739146_3224.html

Si ça intéresse quelqu'un de parler d'open-data à ce jeune homme ... Moi la
flemme sorry
salut

-- 

*Florian Lainez*
http://twitter.com/overflorian
http://www.nouslesgeeks.fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Taggage vol libre

2012-07-27 Par sujet Eric Pommereau

Bonjour,

Après la traduction de la page dédié au vol libre je me suis fait la main
sur la côte des deux amants en taggant les deux décos et l'atterrissage...
n'hésitez pas si vous avez des remarques.

   - l'emplacement :
   http://www.openstreetmap.org/?lat=49.31588&lon=1.24478&zoom=16&layers=M
   - La page FFVL : http://federation.ffvl.fr/structure/993/sites/27001

J'ai pris le parti de créer une zone et non un point pour représenter les
sites (landuse:grass) et j'ai essayé d'être le plus exhaustif possible.

Si il n'y a pas de tag name c'est le tag operator qui est pris pour nommer
l'emplacement (le nom du club reponsable du site). Ce n'est pas pertinent.
J'ai choisi de nommer chaque lieu comme c'est le cas sur le site de la FFVL
ce qui a plus de sens...

Voilà

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

Re: [OSM-talk-fr] Import bâti avec trop de points

2012-07-27 Par sujet didier2020

on parle de moi? je rougis ;)

Faille/ce que le script ne sais pas faire:
- corriger les erreurs des batiments suisses (ce n'est pas une blague)
- suivant la précision du bati (7 ou 6 décimales), le script est plus ou
moins performant
- faire comme si un trait a une épaisseur de 15/20 cm pour "simuler" la
largeur du mur afin de raccrocher les nodes éloignées tout en ayant un
mur "droit". De plus, c'est difficile (pour moi...) a identifier: un
coin de mur en commun, ou 2 traits ayant un angle tres proche 

Le vendredi 27 juillet 2012 à 14:37 +0200, Stéphane Péneau a écrit :
> C'est bien le script de didier2020 que j'essaie
> 
> Le 27/07/2012 14:28, Christian Quest a écrit :
> > didier2020 a bien avancé sur la question, ça approche..
> > Le 27 juillet 2012 13:23, Bruno Cortial  a écrit 
> > :
> >> Sur les chevauchements de bâtiment, je pense qu'il ne faut pas trop s'en
> >> préoccuper: je ne doute pas qu'on aboutisse à un automate de correction
> >> d'ici quelques temps.
> >>
> >>
> >
> 
> 
> ___
> 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 josm ?


Le 27/07/2012 14:24, Vincent Privat a écrit :

on a un bug pas encore totalement bien compréhensible qui semble
correspondre à ton problème:
http://josm.openstreetmap.de/ticket/7789

Pas de solution pour l'instant... Tu peux poster toutes tes observations
là bas ? (version OS, Java, et tout ce qui est affiché dans le second
onglet des informations avancées (Ctrl-I) de l'objet avant et après
disparition de l'icone)


En attendant de poster là-bas (un peu de révise de mon anglais écrit est 
requis) voici mes traces :


+_1er onglet :
Nœud : Pailhac (1706148514)
  Jeu de données : 5de41dcb
  Modifié à : 2012-04-07T18:51:47Z
  Modifié par : cquest (158826)
  Version : 1
  Dans le groupe de modifications : 11217590
  Attributs :
"place"="hamlet"
"ref:INSEE"="65354"
"name"="Pailhac"
"population"="74"
  Coordonnées : 42.90765, 0.36812
  Coordonnées (projetées): 439249.74639730924, 69459.32745023842
  Fait partie de:
Relation : Pailhac (2276860)

+___2ème onglet avant disparition :
Cache de styles pour "Pailhac ‎(42.90765, 0.36812) [identifiant : 
1 706 148 514]" :


> style xml "JOSM Internal Style" appliqué

Intervalle:|s0.0-Infinity
 default:
Cascade{ }

> ignore "Potlatch 2" (inactif)

Liste des styles générés :
 * NodeElemStyle{z_idx=[4.0/0.0/0.0]  icon=[place/settlement/town.png]}
 * BoxTextElemStyle{z_idx=[5.0/0.0/0.0] 
labelCompositionStrategy={DeriveLabelFromNameTagsCompositionStrategy} 
font=java.awt.Font[family=SansSerif,name=Helvetica,style=plain,size=8] 
color=#ff box=java.awt.Rectangle[x=-8,y=-8,width=16,height=16] 
hAlign=RIGHT vAlign=BOTTOM}


+__dans le panneau "Relations" je sélectionne la ligne :
+__ frontière[8]("Paihac",4 membres)
+__je clique sur le Btn "Modifier"
+_sans faire aucun changement, je clique sur le Btn "Valider"
+___aussitôt l'icône disparait et est remplacée par le microbique carré.
+le deuxième onglet affiche alors :
Cache de styles pour "Pailhac ‎(42.90765, 0.36812) [identifiant : 
1 706 148 514]" :


> style xml "JOSM Internal Style" appliqué

Intervalle:|s0.0-Infinity
 default:
Cascade{ }

> ignore "Potlatch 2" (inactif)

Liste des styles générés :
 * NodeElemStyle{z_idx=[4.1/0.0/0.0] }
 * BoxTextElemStyle{z_idx=[5.0/0.0/0.0] 
labelCompositionStrategy={DeriveLabelFromNameTagsCompositionStrategy} 
font=java.awt.Font[family=SansSerif,name=Helvetica,style=plain,size=8] 
color=#ff box=java.awt.Rectangle[x=-2,y=-2,width=5,height=5] 
hAlign=RIGHT vAlign=BOTTOM}


+OS et autres abbatis :
Identification: JOSM/1.5 (5356 fr)
Memory Usage: 1494 MB / 3640 MB (653 MB allocated, but free)
Java version: 1.7.0_05, Oracle Corporation, Java HotSpot(TM) 64-Bit 
Server VM

Operating system: Windows 7
Dataset consistency test: No problems found





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

Re: [OSM-talk-fr] Le sandre aussi a changé de peau


Le 27/07/2012 15:08, Romain MEHUT a écrit :

Le 27 juillet 2012 15:03, Sylvain Maillard mailto:sylvain.maill...@gmail.com>> a écrit :


par contre attention à bien lire les métadonnées de la couche avant de
l'utiliser pour ajouter des infos dans OSM, la plupart des données
cartographiques sont dérivées de la BDCarthage, donc avec les mêmes
restrictions d'utilisation

(http://wiki.openstreetmap.org/wiki/FR:Potential_Datasources/France#Sandre.2FBD_CarTHAgE)


Oui ça je savais ;)



Ça veut dire quoi ?

Sur le portail data.gouv.fr

http://www.data.gouv.fr/donnees/view/Couche-SIG-des-caract%C3%A9ristiques-des-bassins-2010-%3A-eaux-de-surface---Adour-Garonne-30381839?xtmc=caract%C3%A9ristiques+des+bassins+2010&xtcr=2

Il est marqué : Licence Ouverte/Open Licence
pour ce jeu de donné qui ne contient que les polygones et les 
références. Pour moi tel que c'est présenté, et sans méta-info sans rien 
d'autres, c'est libre sous LOOP.


Frédéric.


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

Re: [OSM-talk-fr] Le sandre aussi a changé de peau

2012-07-27 Par sujet Romain MEHUT

Le 27 juillet 2012 15:03, Sylvain Maillard  a
écrit :

>
> par contre attention à bien lire les métadonnées de la couche avant de
> l'utiliser pour ajouter des infos dans OSM, la plupart des données
> cartographiques sont dérivées de la BDCarthage, donc avec les mêmes
> restrictions d'utilisation
> (
> http://wiki.openstreetmap.org/wiki/FR:Potential_Datasources/France#Sandre.2FBD_CarTHAgE
> )
>

Oui ça je savais ;)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Le sandre aussi a changé de peau

2012-07-27 Par sujet Sylvain Maillard

c'est sur que que le site du sandre pourrait gagner en simplicité ..
et encore dans la partie atlas les données sont super simple à trouver
par rapport à la recherche sur le site en lui-même ...

en fait il y a plusieurs entrées possibles:-
- soit par mot clef générique (pas par nom de rivière)
- soit par type de données INSPIRE

une fois sélectionné / rempli, tu clique sur recherche et il t'affiche
la liste des données disponibles.
Si tu clique sur la petite carte de la france qui dit "ajouter la
couche à la carte", ça permet de visuelaiser les données de cette
couche ...

par contre attention à bien lire les métadonnées de la couche avant de
l'utiliser pour ajouter des infos dans OSM, la plupart des données
cartographiques sont dérivées de la BDCarthage, donc avec les mêmes
restrictions d'utilisation
(http://wiki.openstreetmap.org/wiki/FR:Potential_Datasources/France#Sandre.2FBD_CarTHAgE)


Sylvain


Le 27 juillet 2012 14:48, Frédéric Rodrigo  a écrit :
> Le 27/07/2012 14:37, Romain MEHUT a écrit :
>>
>> Le 27 juillet 2012 14:30, Sylvain Maillard > > a écrit :
>>
>>
>>
>> d'ailleurs pour un accès cartographique aux données, il y a
>> http://www.sandre.eaufrance.fr/atlascatalogue/
>>
>>
>> Il n'est pas très intuitif ce portail.
>> Qu'est ce qui est attendu comme mot clé dans le champ en haut à gauche
>> "Titre, Résumé et Mot-Clé"?
>> Sinon en "Thème INSPIRE", j'ai mis "Hydrographie" et après avoir lancer
>> la recherche, il y a plusieurs résultats et après on fait quoi?
>> Merci.
>
>
> En fait il faut chercher "Masses d'eau cours d'eau Métropole" et "Masses
> d'eau plan d'eau Métropole" puis cliqué sur la petite France...
>
>
>
> ___
> 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] Le sandre aussi a changé de peau

2012-07-27 Par sujet Romain MEHUT

Le 27 juillet 2012 14:48, Frédéric Rodrigo  a écrit
:

>
> En fait il faut chercher "Masses d'eau cours d'eau Métropole" et "Masses
> d'eau plan d'eau Métropole" puis cliqué sur la petite France...
>

Super! Effectivement, il faut le deviner qu'il faut cliquer sur le logo de
la France.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Le sandre aussi a changé de peau


Le 27/07/2012 14:37, Romain MEHUT a écrit :

Le 27 juillet 2012 14:30, Sylvain Maillard mailto:sylvain.maill...@gmail.com>> a écrit :


d'ailleurs pour un accès cartographique aux données, il y a
http://www.sandre.eaufrance.fr/atlascatalogue/


Il n'est pas très intuitif ce portail.
Qu'est ce qui est attendu comme mot clé dans le champ en haut à gauche
"Titre, Résumé et Mot-Clé"?
Sinon en "Thème INSPIRE", j'ai mis "Hydrographie" et après avoir lancer
la recherche, il y a plusieurs résultats et après on fait quoi?
Merci.


En fait il faut chercher "Masses d'eau cours d'eau Métropole" et "Masses 
d'eau plan d'eau Métropole" puis cliqué sur la petite France...



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

Re: [OSM-talk-fr] Import bâti avec trop de points


C'est bien le script de didier2020 que j'essaie

Le 27/07/2012 14:28, Christian Quest a écrit :

didier2020 a bien avancé sur la question, ça approche...

Le 27 juillet 2012 13:23, Bruno Cortial  a écrit :

Sur les chevauchements de bâtiment, je pense qu'il ne faut pas trop s'en
préoccuper: je ne doute pas qu'on aboutisse à un automate de correction
d'ici quelques temps.







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

Re: [OSM-talk-fr] Le sandre aussi a changé de peau

2012-07-27 Par sujet Romain MEHUT

Le 27 juillet 2012 14:30, Sylvain Maillard  a
écrit :

>
> d'ailleurs pour un accès cartographique aux données, il y a
> http://www.sandre.eaufrance.fr/atlascatalogue/
>

Il n'est pas très intuitif ce portail.
Qu'est ce qui est attendu comme mot clé dans le champ en haut à gauche
"Titre, Résumé et Mot-Clé"?
Sinon en "Thème INSPIRE", j'ai mis "Hydrographie" et après avoir lancer la
recherche, il y a plusieurs résultats et après on fait quoi?
Merci.

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

Re: [OSM-talk-fr] Le sandre aussi a changé de peau

2012-07-27 Par sujet Sylvain Maillard

> Au sujet de cours d'eau je voudrais signaler qu'une nouvelle source de
> données est disponible sur data.gouv.fr
> J'ai commencé a créer un page wiki pour explorer ces données :
> http://wiki.openstreetmap.org/wiki/WikiProject_France/Cours_d%27eau/Caract%C3%A9ristiques_des_bassins_2010
>
> Pour l'instant j'ai reconstruit depuis ces données un shape "mondial" des
> lacs et étangs avec les attributs pertinent des shapes et des fichiers xml.
> De ce que j'en ai vu ils sont déjà quasiment tous dans OSM. Mais ces données
> apportent une référence (a quoi elle correspond ?) et un nom/description.

Ah tiens je ne le savais pas, je vais essayer de trouver un peu de
temps pour étoffer la page du wiki ;)

d'un coup d'oeil rapide sur ce qui est décrit dans le wiki, il s'agit
du référentiel des Masses d'Eau (au sens de la Directive Cadres sur
l'Eau), dans sa version 2010 qui est la référence officielle jusqu'en
2015.
Les codes EU_x (en FRxXxx ) correspondent aux identifiants (uniques)
de chacun des bassin versants de masse d'eau.
C'est ce code qu'il faut utiliser pour retrouver les infos plus
"détaillée" sur une masse d'eau (par exemple
http://www.sandre.eaufrance.fr/?urn=urn:sandre:referentiel:MDO:2:CdMasseDEau:DR11752::html)

d'ailleurs pour un accès cartographique aux données, il y a
http://www.sandre.eaufrance.fr/atlascatalogue/


@+
Sylvain

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

Re: [OSM-talk-fr] Import bâti avec trop de points

didier2020 a bien avancé sur la question, ça approche...

Le 27 juillet 2012 13:23, Bruno Cortial  a écrit :
> Sur les chevauchements de bâtiment, je pense qu'il ne faut pas trop s'en
> préoccuper: je ne doute pas qu'on aboutisse à un automate de correction
> d'ici quelques temps.
>
>


-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] petit bug dans josm ?

2012-07-27 Par sujet Vincent Privat

on a un bug pas encore totalement bien compréhensible qui semble
correspondre à ton problème:
http://josm.openstreetmap.de/ticket/7789

Pas de solution pour l'instant... Tu peux poster toutes tes observations là
bas ? (version OS, Java, et tout ce qui est affiché dans le second onglet
des informations avancées (Ctrl-I) de l'objet avant et après disparition de
l'icone)

ça pourrait nous aider à corriger :)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Le sandre aussi a changé de peau

2012-07-27 Par sujet Sylvain Maillard

Attention, le site du sandre et de l'agence de l'eau Adour-Garonne
sont bien des sites distincts !

Il y a sans doute des liens à mettre à jour, par exemple la page "qui
sommes nous" est accessible sur
http://www.eau-adour-garonne.fr/fr/qui-sommes-nous.html ...


pour ce qui est de l'accès aux infos, la page "Données sur l'Eau"
(http://www.eau-adour-garonne.fr/fr/informations-et-donnees/donnees-sur-l-eau.html)
pointe correctement vers le site SIE
(http://adour-garonne.eaufrance.fr/) qui permet de faire toutes les
recherches ...

Travaillant à l'AE RM&C je n'ai pas l'habitude du site de l'AE
Adour-Garonne, mais si je peux donner un coup de main pour retrouver
l'accès aux donnée,s il ne faut aps hésiter ;)

@+
Sylvain



Le 27 juillet 2012 14:03, THEVENON Julien  a écrit :
> De : Hélène PETIT 
>
> tout est dans le titre ;
> j'ai un mal fou à retrouver les ref des ruisseaux de montagne, il
> semble qu'il n'indexe plus (ou pas encore) les noms alternatifs ; en plus 
> je
> cartographie en ce moment dans le bassin adour garonne, qui a l'air de
> prendre en charge certains groupes de données, mais il y a encore du 404
> dans l'air :
> http://www.eau-adour-garonne.fr/fr/qui-sommes-nous/fiche5.html
>
> Bon, c'est juste pour vous soyez prévenus ...
>
> Je me suis apercu de ca aussi il y a quelques jours et c est assez penible
> de ne plus avoir acces a la fiche detaillee de certains cours d eau, j
> esperais que se soit juste passager mais cela semble durer un peu
>
> Julien
>
>
> ___
> 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] Le sandre aussi a changé de peau


Le 27/07/2012 14:03, THEVENON Julien a écrit :

* De :* Hélène PETIT 
**
* *tout est dans le titre ;
* *j'ai un mal fou à retrouver les ref des ruisseaux de montagne, il
semble qu'il n'indexe plus (ou pas encore) les noms alternatifs ; en
plus je cartographie en ce moment dans le bassin adour garonne, qui a
l'air de prendre en charge certains groupes de données, mais il y a
encore du 404 dans l'air :*
*
* *http://www.eau-adour-garonne.fr/fr/qui-sommes-nous/fiche5.html

* *Bon, c'est juste pour vous soyez prévenus ...

Je me suis apercu de ca aussi il y a quelques jours et c est assez
penible de ne plus avoir acces a la fiche detaillee de certains cours d
eau, j esperais que se soit juste passager mais cela semble durer un peu

Julien


Au sujet de cours d'eau je voudrais signaler qu'une nouvelle source de 
données est disponible sur data.gouv.fr

J'ai commencé a créer un page wiki pour explorer ces données :
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cours_d%27eau/Caract%C3%A9ristiques_des_bassins_2010

Pour l'instant j'ai reconstruit depuis ces données un shape "mondial" 
des lacs et étangs avec les attributs pertinent des shapes et des 
fichiers xml. De ce que j'en ai vu ils sont déjà quasiment tous dans 
OSM. Mais ces données apportent une référence (a quoi elle correspond ?) 
et un nom/description.


Frédéric.



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

Re: [OSM-talk-fr] Import bâti avec trop de points


Salut Bruno,

Je suis en train d'en essayer un, mais je ne suis pas vraiment 
convaincu. Oui, ça corrige les chevauchements, donc les erreurs 
affichées par osmose, mais ça ne corrige pas le bâti en lui-même.


L'exemple le plus courant, c'est l'avancée de toit d'une maison 
particulière. Assez régulièrement, l'outil de conversion ne joint pas 
les 2 morceaux. S'il y a une petite inclinaison, alors il y a un premier 
point qui génère le chevauchement, et un autre qui n'est pas rattaché au 
bâti principal. Le premier est corrigé, mais pas le second, et ça ne me 
plait pas puisqu'on se retrouve avec une avancée de toit partiellement 
dans le vide.


Le 27/07/2012 13:23, Bruno Cortial a écrit :
Le 27 juillet 2012 11:45, Stéphane Péneau > a écrit :


Bonjour,

Je vous lis via l'interface Nabble depuis un moment, et je me suis
décidé à m'inscrire car je suis face à une problème que je ne sais
pas résoudre :

Je me suis attelé depuis quelque temps à la correction des
chevauchements de bâtiments sur la région des pays de la loire,



Bonjour Stéphane,
Sur les chevauchements de bâtiment, je pense qu'il ne faut pas trop 
s'en préoccuper: je ne doute pas qu'on aboutisse à un automate de 
correction d'ici quelques temps.



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

[OSM-talk-fr] petit bug dans josm ?

depuis que j'utilise la 5356, les nœuds "place=village" et place=hamlet" 
perdent leur icone en forme de petite flaque verte quand ils sont inclus 
dans une relation ; parfois l’icône n’apparaît pas non plus juste après 
le téléchargement de la zone, il n'apparaît que si on trafique un peu 
autour ; le nœuds est représenté par un petit carré microscopique, pas 
très facile à trouver (sauf avec un filtre).


et chez vous c'est comment ?



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

Re: [OSM-talk-fr] Import bâti avec trop de points

Honnêtement, je ne sais pas ce qu'il s'est passé lors de cet import car 
sur ceux que j'ai fait, je n'ai jamais rencontré ce problème de 
profusion de point inutiles.



Le 27/07/2012 13:27, Jean-Claude Repetto a écrit :

On 27/07/2012 12:43, Stéphane Péneau wrote:

Je m'en suis sorti avec le plugin Simplify Area. 6000 points en moins.

Je vais contacter le contributeur, mais il va falloir que je le prenne
avec des pincettes, je lui ai déjà fait remarqué toutes les erreurs de
chevauchement il y a quelques jours, il va croire que je le poursuis...


Bonjour,

L'élimination des points en trop ne pourrait-elle pas se faire dans
l'outil d'importation du cadastre ?

Jean-Claude


___
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] Le sandre aussi a changé de peau

2012-07-27 Par sujet THEVENON Julien

 De : Hélène PETIT 

 tout est dans le titre ;
 j'ai un mal fou à retrouver les ref des ruisseaux de montagne, il semble 
qu'il n'indexe plus (ou pas encore) les noms alternatifs ; en plus je 
cartographie en ce moment dans le bassin adour garonne, qui a l'air de 
prendre en charge certains groupes de données, mais il y a encore du 404 dans 
l'air :

 http://www.eau-adour-garonne.fr/fr/qui-sommes-nous/fiche5.html

 Bon, c'est juste pour vous soyez prévenus ...

Je me suis apercu de ca aussi il y a quelques jours et c est assez penible de 
ne plus avoir acces a la fiche detaillee de certains cours d eau, j esperais 
que se soit juste passager mais cela semble durer un peu


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

Re: [OSM-talk-fr] OSMTransport change de peau

2012-07-27 Par sujet Francescu GAROBY

Comme la recommandation dit que le nom d'un itinéraire doit être de la
forme "* :  => ", *ça serait selon moi parfait (mais p-e un peu long...) !

Francescu

Le 27 juillet 2012 13:58, rldhont  a écrit :

>  Et si en plus du numéro j'affiche le nom de chaque relation ça irait,
> non ?
>
>
> Le 27/07/2012 13:55, Francescu GAROBY a écrit :
>
> Nouveau problème à signaler : si on suit la recommandation concernant les
> itinéraires de 
> buson
>  se retrouve avec N lignes de bus du même numéro pour un même arrêt, vu
> qu'il peut y avoir le chemin aller, le retour voire des itinéraires
> alternatifs.
> Je pense qu'il faudrait ne faire apparaitre qu'une fois (par arrêt) un
> numéro de ligne.
>
> Francescu
>
> Le 26 juillet 2012 18:19, rldhont  a écrit :
>
>> Au début du projet n'importe qui et sans contrôle pouvait créer une
>> localisation d'où toutes les erreurs que tu peux avoir noté.
>>
>> L'objectif de départ est d'afficher la donné OSM dans sa structure la
>> plus brutes afin d'aider les contributeurs à visualiser des erreurs, des
>> manques, etc.
>>
>> Ensuite j'aime bien l'idée d'afficher les terminus, mais existent-il un
>> rôle pour cela ?
>>
>>
>> Le 26/07/2012 18:13, Philippe Verdy a écrit :
>>
>>  Pour les couleurs de lignes, certaines agglomération ont un schéma
>>> uniforme aussi bien dans la signalisation, les panneaux des arrpet
>>> comme les bus, et les plans papier diffusés ou affichés. LA couleur
>>> concerne autant la couleur de fond de l'étiquette que celle des
>>> caractères, la couleur de fond devant correspondre si possible à la
>>> couleur du tracé sur la carte comme tu le fais.
>>>
>>> Sans aller jusqu'à reproduire aussi les logos, il y a aussi des
>>> différences de forme pour ces numéros (par exemple dans un cercle ou
>>> un carré). Enfin il ne serait pas inutile de repérer les terminus sur
>>> la carte (ce sont des arrêts où le bus change de sens ou bien où il
>>> dépose tout le monde et poursuit sans passagers vers son dépôt) en
>>> affichant les numéros de ligne sur la carte. Cela demanderait une
>>> collection de petites icônes (faciles à générer de façon vectorielle à
>>> partir d'une forme de base, des couleurs de fond, de bordure et de
>>> texte et le numéro ou à défaut une abbréviation du nom ou un symbole
>>> générique) en mettant en libellé le nom de la destination à partir de
>>> ce terminus (si la ligne est jsute un cycle, un seul point est
>>> rensiegné, le point d'arrêt principal, souvent sur une place centrale
>>> d'échange, et en libellé on mettrait le nom de la ligne.
>>>
>>> Selon les références que tu trouves, on pourrait avoir pour ton rendu,
>>> dans ta propre base, des noms adaptés à ta carte pour remplacer ceux
>>> trouvés dans la base quand ils ne conviennent pas bien (pas besoin
>>> forcément de mettre à jour la base OSM), dans la délimitation
>>> géographique de l'agglomération que tu as définie.
>>>
>>> Note: une des villes est nommée avec le préfixe abrégé "Agglo", à mon
>>> avis inutile et perturbant dans la liste. Tout dans cette liste de
>>> sélection concerne une agglomération (parfois un peu plus sur des
>>> réseaux étendus tels que "Paris Est", où on se demande pourquoi on n'a
>>> pas aussi "Paris Ouest" pour tout ce qui est autour du réseau au
>>> départ de Saint-Lazare et des lignes de bus en correspondance dans les
>>> villes traversées, et "Paris Sud" depuis Montparnasse ou la Gare de
>>> Lyon).
>>>
>>> Enfin certaines villes manquent de traits d'union dans la liste affichée.
>>>
>>> Le 26 juillet 2012 17:53, rldhont  a écrit :
>>>
 Bonjour Philippe,

 Tout d'abord OSMTransport a été construit il y a 3 ans, à l'époque il
 n'y
 avait qu'un seul modèle pour les lignes de bus un seul relations par
 ligne
 et il n'était pas question de s'amuser à définir une relation par sens
 de
 circulation ni de super-relation par ligne référence toutes les
 relations
 formant toutes les variations d'une ligne. Sachant cela :
 * la référence est pour moi la clef d'identification d'une ligne donc
 si il
 y a plusieurs relations portant le même tag ref, je les colles ensembles
 * l'affichage du tag name vient d'être ajouté pour voir, celui-ci comme
 la
 couleur de la ligne est extrait de la première relation que je rencontre
 avec ce ref en particulier

 Donc tout problème de répétition de la référence dans le nom est à
 mettre à
 l'actif des contributeurs.

 Enfin la sélection en se fait pas par operator mais par emprise
 géographique.

 René-Luc


 Le 26/07/2012 17:44, Philippe Verdy a écrit :

> Petits commentaires suppélmentaires.
>
> Les noms des lignes sont assez bizarre à Rennes. Par exemple:
>
> 64: Bus Rennes Ligne 64 Direction Rennes
> 65: Bus Rennes Ligne 65 Direction Rennes
>
> ->  Il semble qu'il y ait confusion entre

Re: [OSM-talk-fr] OSMTransport change de peau

2012-07-27 Par sujet rldhont


Et si en plus du numéro j'affiche le nom de chaque relation ça irait, non ?


Le 27/07/2012 13:55, Francescu GAROBY a écrit :
Nouveau problème à signaler : si on suit la recommandation concernant 
les itinéraires de bus 
 
on se retrouve avec N lignes de bus du même numéro pour un même arrêt, 
vu qu'il peut y avoir le chemin aller, le retour voire des itinéraires 
alternatifs.
Je pense qu'il faudrait ne faire apparaitre qu'une fois (par arrêt) un 
numéro de ligne.


Francescu

Le 26 juillet 2012 18:19, rldhont > a écrit :


Au début du projet n'importe qui et sans contrôle pouvait créer
une localisation d'où toutes les erreurs que tu peux avoir noté.

L'objectif de départ est d'afficher la donné OSM dans sa structure
la plus brutes afin d'aider les contributeurs à visualiser des
erreurs, des manques, etc.

Ensuite j'aime bien l'idée d'afficher les terminus, mais
existent-il un rôle pour cela ?


Le 26/07/2012 18:13, Philippe Verdy a écrit :

Pour les couleurs de lignes, certaines agglomération ont un schéma
uniforme aussi bien dans la signalisation, les panneaux des arrpet
comme les bus, et les plans papier diffusés ou affichés. LA
couleur
concerne autant la couleur de fond de l'étiquette que celle des
caractères, la couleur de fond devant correspondre si possible
à la
couleur du tracé sur la carte comme tu le fais.

Sans aller jusqu'à reproduire aussi les logos, il y a aussi des
différences de forme pour ces numéros (par exemple dans un
cercle ou
un carré). Enfin il ne serait pas inutile de repérer les
terminus sur
la carte (ce sont des arrêts où le bus change de sens ou bien
où il
dépose tout le monde et poursuit sans passagers vers son dépôt) en
affichant les numéros de ligne sur la carte. Cela demanderait une
collection de petites icônes (faciles à générer de façon
vectorielle à
partir d'une forme de base, des couleurs de fond, de bordure et de
texte et le numéro ou à défaut une abbréviation du nom ou un
symbole
générique) en mettant en libellé le nom de la destination à
partir de
ce terminus (si la ligne est jsute un cycle, un seul point est
rensiegné, le point d'arrêt principal, souvent sur une place
centrale
d'échange, et en libellé on mettrait le nom de la ligne.

Selon les références que tu trouves, on pourrait avoir pour
ton rendu,
dans ta propre base, des noms adaptés à ta carte pour
remplacer ceux
trouvés dans la base quand ils ne conviennent pas bien (pas besoin
forcément de mettre à jour la base OSM), dans la délimitation
géographique de l'agglomération que tu as définie.

Note: une des villes est nommée avec le préfixe abrégé
"Agglo", à mon
avis inutile et perturbant dans la liste. Tout dans cette liste de
sélection concerne une agglomération (parfois un peu plus sur des
réseaux étendus tels que "Paris Est", où on se demande
pourquoi on n'a
pas aussi "Paris Ouest" pour tout ce qui est autour du réseau au
départ de Saint-Lazare et des lignes de bus en correspondance
dans les
villes traversées, et "Paris Sud" depuis Montparnasse ou la
Gare de
Lyon).

Enfin certaines villes manquent de traits d'union dans la
liste affichée.

Le 26 juillet 2012 17:53, rldhont mailto:rldh...@gmail.com>> a écrit :

Bonjour Philippe,

Tout d'abord OSMTransport a été construit il y a 3 ans, à
l'époque il n'y
avait qu'un seul modèle pour les lignes de bus un seul
relations par ligne
et il n'était pas question de s'amuser à définir une
relation par sens de
circulation ni de super-relation par ligne référence
toutes les relations
formant toutes les variations d'une ligne. Sachant cela :
* la référence est pour moi la clef d'identification d'une
ligne donc si il
y a plusieurs relations portant le même tag ref, je les
colles ensembles
* l'affichage du tag name vient d'être ajouté pour voir,
celui-ci comme la
couleur de la ligne est extrait de la première relation
que je rencontre
avec ce ref en particulier

Donc tout problème de répétition de la référence dans le
nom est à mettre à
l'actif des contributeurs.

Enfin la sélection en se fait pas par operator mais par
emprise
géographique.

René-Luc


Le 26/07/2012 17:44, Philippe Verdy a écrit :

Petits com

Re: [OSM-talk-fr] OSMTransport change de peau

2012-07-27 Par sujet Francescu GAROBY

Nouveau problème à signaler : si on suit la recommandation concernant les
itinéraires de 
buson
se retrouve avec N lignes de bus du même numéro pour un même arrêt, vu
qu'il peut y avoir le chemin aller, le retour voire des itinéraires
alternatifs.
Je pense qu'il faudrait ne faire apparaitre qu'une fois (par arrêt) un
numéro de ligne.

Francescu

Le 26 juillet 2012 18:19, rldhont  a écrit :

> Au début du projet n'importe qui et sans contrôle pouvait créer une
> localisation d'où toutes les erreurs que tu peux avoir noté.
>
> L'objectif de départ est d'afficher la donné OSM dans sa structure la plus
> brutes afin d'aider les contributeurs à visualiser des erreurs, des
> manques, etc.
>
> Ensuite j'aime bien l'idée d'afficher les terminus, mais existent-il un
> rôle pour cela ?
>
>
> Le 26/07/2012 18:13, Philippe Verdy a écrit :
>
>  Pour les couleurs de lignes, certaines agglomération ont un schéma
>> uniforme aussi bien dans la signalisation, les panneaux des arrpet
>> comme les bus, et les plans papier diffusés ou affichés. LA couleur
>> concerne autant la couleur de fond de l'étiquette que celle des
>> caractères, la couleur de fond devant correspondre si possible à la
>> couleur du tracé sur la carte comme tu le fais.
>>
>> Sans aller jusqu'à reproduire aussi les logos, il y a aussi des
>> différences de forme pour ces numéros (par exemple dans un cercle ou
>> un carré). Enfin il ne serait pas inutile de repérer les terminus sur
>> la carte (ce sont des arrêts où le bus change de sens ou bien où il
>> dépose tout le monde et poursuit sans passagers vers son dépôt) en
>> affichant les numéros de ligne sur la carte. Cela demanderait une
>> collection de petites icônes (faciles à générer de façon vectorielle à
>> partir d'une forme de base, des couleurs de fond, de bordure et de
>> texte et le numéro ou à défaut une abbréviation du nom ou un symbole
>> générique) en mettant en libellé le nom de la destination à partir de
>> ce terminus (si la ligne est jsute un cycle, un seul point est
>> rensiegné, le point d'arrêt principal, souvent sur une place centrale
>> d'échange, et en libellé on mettrait le nom de la ligne.
>>
>> Selon les références que tu trouves, on pourrait avoir pour ton rendu,
>> dans ta propre base, des noms adaptés à ta carte pour remplacer ceux
>> trouvés dans la base quand ils ne conviennent pas bien (pas besoin
>> forcément de mettre à jour la base OSM), dans la délimitation
>> géographique de l'agglomération que tu as définie.
>>
>> Note: une des villes est nommée avec le préfixe abrégé "Agglo", à mon
>> avis inutile et perturbant dans la liste. Tout dans cette liste de
>> sélection concerne une agglomération (parfois un peu plus sur des
>> réseaux étendus tels que "Paris Est", où on se demande pourquoi on n'a
>> pas aussi "Paris Ouest" pour tout ce qui est autour du réseau au
>> départ de Saint-Lazare et des lignes de bus en correspondance dans les
>> villes traversées, et "Paris Sud" depuis Montparnasse ou la Gare de
>> Lyon).
>>
>> Enfin certaines villes manquent de traits d'union dans la liste affichée.
>>
>> Le 26 juillet 2012 17:53, rldhont  a écrit :
>>
>>> Bonjour Philippe,
>>>
>>> Tout d'abord OSMTransport a été construit il y a 3 ans, à l'époque il n'y
>>> avait qu'un seul modèle pour les lignes de bus un seul relations par
>>> ligne
>>> et il n'était pas question de s'amuser à définir une relation par sens de
>>> circulation ni de super-relation par ligne référence toutes les relations
>>> formant toutes les variations d'une ligne. Sachant cela :
>>> * la référence est pour moi la clef d'identification d'une ligne donc si
>>> il
>>> y a plusieurs relations portant le même tag ref, je les colles ensembles
>>> * l'affichage du tag name vient d'être ajouté pour voir, celui-ci comme
>>> la
>>> couleur de la ligne est extrait de la première relation que je rencontre
>>> avec ce ref en particulier
>>>
>>> Donc tout problème de répétition de la référence dans le nom est à
>>> mettre à
>>> l'actif des contributeurs.
>>>
>>> Enfin la sélection en se fait pas par operator mais par emprise
>>> géographique.
>>>
>>> René-Luc
>>>
>>>
>>> Le 26/07/2012 17:44, Philippe Verdy a écrit :
>>>
 Petits commentaires suppélmentaires.

 Les noms des lignes sont assez bizarre à Rennes. Par exemple:

 64: Bus Rennes Ligne 64 Direction Rennes
 65: Bus Rennes Ligne 65 Direction Rennes

 ->  Il semble qu'il y ait confusion entre le nom du sens de
 circulation et le nom de la ligne (quand les deux parcours ne passent
 pas par le même chemin, les deux sens sont regroupés dans une même
 relation donnant le nom de l'ensemble).
 -> Est-ce utile aussi de rappeler le numéro de la ligne dans le nom
 alors que le numéro est affiché dans un rectangle en tête ?
 -> Ces mêmes cas se rencontrent aussi dans d'autres villes.

 52 Bus Rennes Ligne 52 Direction Saint-Gilles

[OSM-talk-fr] Le sandre aussi a changé de peau


tout est dans le titre ;
j'ai un mal fou à retrouver les ref des ruisseaux de montagne, il semble 
qu'il n'indexe plus (ou pas encore) les noms alternatifs ; en plus je 
cartographie en ce moment dans le bassin adour garonne, qui a l'air de 
prendre en charge certains groupes de données, mais il y a encore du 404 
dans l'air :

http://www.eau-adour-garonne.fr/fr/qui-sommes-nous/fiche5.html

Bon, c'est juste pour vous soyez prévenus ...

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

Re: [OSM-talk-fr] Import bâti avec trop de points

2012-07-27 Par sujet Jean-Claude Repetto

On 27/07/2012 12:43, Stéphane Péneau wrote:
> Je m'en suis sorti avec le plugin Simplify Area. 6000 points en moins.
> 
> Je vais contacter le contributeur, mais il va falloir que je le prenne
> avec des pincettes, je lui ai déjà fait remarqué toutes les erreurs de
> chevauchement il y a quelques jours, il va croire que je le poursuis...
> 

Bonjour,

L'élimination des points en trop ne pourrait-elle pas se faire dans
l'outil d'importation du cadastre ?

Jean-Claude


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

Re: [OSM-talk-fr] Import bâti avec trop de points

2012-07-27 Par sujet Bruno Cortial

Le 27 juillet 2012 11:45, Stéphane Péneau  a
écrit :

> Bonjour,
>
> Je vous lis via l'interface Nabble depuis un moment, et je me suis décidé
> à m'inscrire car je suis face à une problème que je ne sais pas résoudre :
>
> Je me suis attelé depuis quelque temps à la correction des chevauchements
> de bâtiments sur la région des pays de la loire,
>


Bonjour Stéphane,
Sur les chevauchements de bâtiment, je pense qu'il ne faut pas trop s'en
préoccuper: je ne doute pas qu'on aboutisse à un automate de correction
d'ici quelques temps.


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

Re: [OSM-talk-fr] Tagguer un bâtiment à usage multiple (était: Re: Quelques questions d'un débutant OSM)

2012-07-27 Par sujet Mathieu Rajerison

Je suis d'accord avec votre approche.

Je débute sous OSM. Si je comprends bien, pas de relation de type site mais
une zone englobant les différents bâtiments ayant ces attributs:
name = [nom de la résidence]
landuse = residential
[autres clés possibles pour la zone?]

Et pour les bâtiments:
name = [bat. A, nom de l'immeuble]
building = residentiel
éventuellement, nb de niveaux, etc..


Le 27 juillet 2012 10:35, Philippe Verdy  a écrit :

> Oui mais là il a voulu dire qu'une résidence c'est souvent une emprise
> avec du terrain autour, parfois aussi une barrière, et dedans
> plusieurs batiments, avec plusieurs entrées et donc plusieurs numéros,
> mais aussi souvent des parkings, des équipements paysagers ou aires de
> jeux, voire aussi des locaux de service (poubelles par exemple). Ainsi
> que les voies de circulation (auto, chemins piétons/vélos) dans la
> résidence Le tout s'entendant souvent sur plusieurs parcelles
> cadastrales (que d'habitude on ne représente pas)
>
> On tague alors la résidence sur la surface de la totalité de son
> emprise en lu donnant son nom.
>
> On inclut dedans le tracé séparé des bâtiments (imports du cadastre),
> et on peut y ajouter les POIs supplémentaires (s'il y a des commerces
> ou entreprises à géolocaliser dedans). Il n'est pas nécessaire de les
> lier. La résidence est ni plus ni moins qu'un landuse=residential
> auquel on inclut un tag name, mais pas les noms de rues (privées) ni
> aucun tag de ce qui a été dessiné dedans. Et pas besoin non plus d'y
> mettre un place représentant la résidence (les POIs pour les commerces
> ou entreprises, ou voies de circulation ou jardins et aires de jeux ou
> équipements sportifs n'ont pas nécessité non plus de rappeler le nom
> de la résidence qui les contient, on se contente de leur donner leur
> propre nom au cas où il se distingue du nom de la résidence elle-même,
> sinon les tags du type d'objet ou pour leur destination ou utilisation
> suffisent).
>
> Il ne me semble pas nécessaire pour autant de créer une relation
> regroupant le tout si l'emprise totale de la résidence suffit (dans
> laquelle il reste permis d'avoir des ilots internes avec une frontière
> de rôle "inner", en cas de besoin de les sortir de cette emprise. Le
> principe est alors le même que pour les communes, quartiers, et ilots
> de quartiers, sauf que la bordure peut avoir des tags pour désigner le
> mur ou la clôture elle-même (s'il y en a une) et les barrières
> d'entrée, en segmentant cette ligne de bordure externe.
>
> Le 27 juillet 2012 09:41, Christian Quest  a
> écrit :
> > +1 avec Eric
> >
> > A mon avis le principe général doit rester: un objet un tag...
> >
> > Il n'y a qu'une résidence XXX, donc les attributs la décrivant doivent
> > être présent une fois et une seule dans la base dans la mesure du
> > possible, d'où le tracé de son emprise que l'o va tagguer en
> > conséquence.
> >
> > --
> > 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Import bâti avec trop de points


Je m'en suis sorti avec le plugin Simplify Area. 6000 points en moins.

Je vais contacter le contributeur, mais il va falloir que je le prenne 
avec des pincettes, je lui ai déjà fait remarqué toutes les erreurs de 
chevauchement il y a quelques jours, il va croire que je le poursuis...


Le 27/07/2012 12:33, Christian Quest a écrit :

Il y a l'outil de simplification intégré à JOSM, ainsi qu'un second
sous forme de plugin qui fonctionne un peu différemment qui a
l'avantage de savoir simplifier les noeuds communs à plusieurs
chemins.

Entre les deux, on obtient de bons résultats.

Ce boulot de simplification fait partie des tâches à accomplir avant
envoi vers OSM... comme c'est expliqué sur le wiki:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_bâtiments#Traitements_des_b.C3.A2timents_avec_JOSM_avant_envoi_vers_serveur_OSM

Dommage de le faire après un premier envoi car cela crée inutilement
des noeuds de façon très temporaire sur des serveurs d'OSM et génère
beaucoup de modifications à importer sur toutes les bases qui se
mettent à jour à l'aide des fichiers diff.

Un petit rappel du contenu de cette page du wiki au contributeur qui a
importé ces bâtiments ne fera pas de mal.


Le 27 juillet 2012 11:57, Ab_fab  a écrit :

Il y a une fonction de simplification de tracé qui marche pas mal dans JOSM

La plupart du temps, les grosses quantités de points se retrouvent pour les
formes courbes et circulaires.
Genre une centaine de points pour un pylône d'éolienne [1]

Mais là, c'est sur des formes rectilignes, ce qui est moins fréquent.
Il y aurait peut être du brainstorming à faire pour trouver de bonnes
analyses pour détecter ce genre de choses [2].

Est-ce que tu arrives à une bonne simplification avec l'outil de JOSM décrit
dans [1] ?

@+

[1]
http://lists.openstreetmap.org/pipermail/talk-fr/2011-November/038088.html
[2] http://lists.openstreetmap.org/pipermail/talk-fr/2012-May/043886.html

Le 27 juillet 2012 11:45, Stéphane Péneau  a
écrit :


Bonjour,

Je vous lis via l'interface Nabble depuis un moment, et je me suis décidé
à m'inscrire car je suis face à une problème que je ne sais pas résoudre :

Je me suis attelé depuis quelque temps à la correction des chevauchements
de bâtiments sur la région des pays de la loire, et je viens de tomber sur
un import du bâti assez récent, et qui comporte énormément de points pour
chaque building. voyez-vous même ici :
http://www.openstreetmap.org/?lat=46.676555&lon=-0.848492&zoom=18&layers=M

Je voulais contacter l'auteur du changeset, mais franchement, je ne vois
pas trop quoi lui dire puisque je ne comprends pas comment celà a pu
arriver, ni comment corriger.

Voici le changeset :
http://www.openstreetmap.org/browse/changeset/12195453

Au passage, si certains font des imports du bâti sur les pays de la loire,
et sans corriger les erreurs de chevauchement, attendez-vous à ce que je
vous tombe dessus. Mais j'imagine que ça n'arrive pas pour les membres de
cette liste, non ;-)

A bientôt

StephaneP

___
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] Import bâti avec trop de points

Il y a l'outil de simplification intégré à JOSM, ainsi qu'un second
sous forme de plugin qui fonctionne un peu différemment qui a
l'avantage de savoir simplifier les noeuds communs à plusieurs
chemins.

Entre les deux, on obtient de bons résultats.

Ce boulot de simplification fait partie des tâches à accomplir avant
envoi vers OSM... comme c'est expliqué sur le wiki:
http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_bâtiments#Traitements_des_b.C3.A2timents_avec_JOSM_avant_envoi_vers_serveur_OSM

Dommage de le faire après un premier envoi car cela crée inutilement
des noeuds de façon très temporaire sur des serveurs d'OSM et génère
beaucoup de modifications à importer sur toutes les bases qui se
mettent à jour à l'aide des fichiers diff.

Un petit rappel du contenu de cette page du wiki au contributeur qui a
importé ces bâtiments ne fera pas de mal.


Le 27 juillet 2012 11:57, Ab_fab  a écrit :
> Il y a une fonction de simplification de tracé qui marche pas mal dans JOSM
>
> La plupart du temps, les grosses quantités de points se retrouvent pour les
> formes courbes et circulaires.
> Genre une centaine de points pour un pylône d'éolienne [1]
>
> Mais là, c'est sur des formes rectilignes, ce qui est moins fréquent.
> Il y aurait peut être du brainstorming à faire pour trouver de bonnes
> analyses pour détecter ce genre de choses [2].
>
> Est-ce que tu arrives à une bonne simplification avec l'outil de JOSM décrit
> dans [1] ?
>
> @+
>
> [1]
> http://lists.openstreetmap.org/pipermail/talk-fr/2011-November/038088.html
> [2] http://lists.openstreetmap.org/pipermail/talk-fr/2012-May/043886.html
>
> Le 27 juillet 2012 11:45, Stéphane Péneau  a
> écrit :
>
>> Bonjour,
>>
>> Je vous lis via l'interface Nabble depuis un moment, et je me suis décidé
>> à m'inscrire car je suis face à une problème que je ne sais pas résoudre :
>>
>> Je me suis attelé depuis quelque temps à la correction des chevauchements
>> de bâtiments sur la région des pays de la loire, et je viens de tomber sur
>> un import du bâti assez récent, et qui comporte énormément de points pour
>> chaque building. voyez-vous même ici :
>> http://www.openstreetmap.org/?lat=46.676555&lon=-0.848492&zoom=18&layers=M
>>
>> Je voulais contacter l'auteur du changeset, mais franchement, je ne vois
>> pas trop quoi lui dire puisque je ne comprends pas comment celà a pu
>> arriver, ni comment corriger.
>>
>> Voici le changeset :
>> http://www.openstreetmap.org/browse/changeset/12195453
>>
>> Au passage, si certains font des imports du bâti sur les pays de la loire,
>> et sans corriger les erreurs de chevauchement, attendez-vous à ce que je
>> vous tombe dessus. Mais j'imagine que ça n'arrive pas pour les membres de
>> cette liste, non ;-)
>>
>> A bientôt
>>
>> StephaneP
>>
>> ___
>> 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
>



-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] Import bâti avec trop de points

2012-07-27 Par sujet Ab_fab

Il y a une fonction de simplification de tracé qui marche pas mal dans JOSM

La plupart du temps, les grosses quantités de points se retrouvent pour les
formes courbes et circulaires.
Genre une centaine de points pour un pylône d'éolienne [1]

Mais là, c'est sur des formes rectilignes, ce qui est moins fréquent.
Il y aurait peut être du brainstorming à faire pour trouver de bonnes
analyses pour détecter ce genre de choses [2].

Est-ce que tu arrives à une bonne simplification avec l'outil de JOSM
décrit dans [1] ?

@+

[1]
http://lists.openstreetmap.org/pipermail/talk-fr/2011-November/038088.html
[2] http://lists.openstreetmap.org/pipermail/talk-fr/2012-May/043886.html

Le 27 juillet 2012 11:45, Stéphane Péneau  a
écrit :

> Bonjour,
>
> Je vous lis via l'interface Nabble depuis un moment, et je me suis décidé
> à m'inscrire car je suis face à une problème que je ne sais pas résoudre :
>
> Je me suis attelé depuis quelque temps à la correction des chevauchements
> de bâtiments sur la région des pays de la loire, et je viens de tomber sur
> un import du bâti assez récent, et qui comporte énormément de points pour
> chaque building. voyez-vous même ici :
> http://www.openstreetmap.org/?**lat=46.676555&lon=-0.848492&**
> zoom=18&layers=M
>
> Je voulais contacter l'auteur du changeset, mais franchement, je ne vois
> pas trop quoi lui dire puisque je ne comprends pas comment celà a pu
> arriver, ni comment corriger.
>
> Voici le changeset :
> http://www.openstreetmap.org/**browse/changeset/12195453
>
> Au passage, si certains font des imports du bâti sur les pays de la loire,
> et sans corriger les erreurs de chevauchement, attendez-vous à ce que je
> vous tombe dessus. Mais j'imagine que ça n'arrive pas pour les membres de
> cette liste, non ;-)
>
> A bientôt
>
> StephaneP
>
> __**_
> 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

[OSM-talk-fr] Import bâti avec trop de points


Bonjour,

Je vous lis via l'interface Nabble depuis un moment, et je me suis 
décidé à m'inscrire car je suis face à une problème que je ne sais pas 
résoudre :


Je me suis attelé depuis quelque temps à la correction des 
chevauchements de bâtiments sur la région des pays de la loire, et je 
viens de tomber sur un import du bâti assez récent, et qui comporte 
énormément de points pour chaque building. voyez-vous même ici :

http://www.openstreetmap.org/?lat=46.676555&lon=-0.848492&zoom=18&layers=M

Je voulais contacter l'auteur du changeset, mais franchement, je ne vois 
pas trop quoi lui dire puisque je ne comprends pas comment celà a pu 
arriver, ni comment corriger.


Voici le changeset :
http://www.openstreetmap.org/browse/changeset/12195453

Au passage, si certains font des imports du bâti sur les pays de la 
loire, et sans corriger les erreurs de chevauchement, attendez-vous à ce 
que je vous tombe dessus. Mais j'imagine que ça n'arrive pas pour les 
membres de cette liste, non ;-)


A bientôt

StephaneP

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

Re: [OSM-talk-fr] Plug-in Cadastre

>
>  Peut etre que le fait d'avoir 10x10 comme taille augmente la conso du
>> cache et que du coup il explose très vite, c'est peut etre une piste, je
>> contrôlerai ca sur mon PC ce soir.
>>
>
> Possible. Chez moi une image 10x10 fait environ 1.5 Mo.
>
>
Oui, j'ai aussi dans le cache des images d'environ 1.5 Mo. Il y en avait 4.


>
>  Question subsidiaire : si je veux travailler sur un autre PC sans
>> refaire ces manips d’étalonnage, je peux copier / coller  le répertoire
>> "cache" et hériter de mon travail précédent ?
>>
>>  Oui, tout à fait.


Nickel. Merci pour tes réponses.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] [Merkaartor]Impossible de sélection les relations

2012-07-27 Par sujet Francescu GAROBY

Bonjour à tous,
Utilisateur de Merkaartor (version 0.17.2) sur Windows 7, je remarque un
bug assez étrange : je ne peux pas sélectionner une relation en cliquant
sur le contour en pointillés bleus !
Je peux la sélectionner en la recherchant, ou dans la liste des relations
visibles à l'écran, dans le panneau "objets", onglet "relations", mais
c'est tout !
Y aurait-il un réglage particulier à faire ou suis-je tombé sur un bug ?
Mes (rapides) recherches n'ont rien donné.
La où ça devient "cocasse", c'est que la même version sur un Windows XP ne
pose aucun pb !

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

Re: [OSM-talk-fr] Plug-in Cadastre


Le 27/07/2012 10:11, Eric a écrit :


Peut etre que le fait d'avoir 10x10 comme taille augmente la conso du
cache et que du coup il explose très vite, c'est peut etre une piste, je
contrôlerai ca sur mon PC ce soir.


Possible. Chez moi une image 10x10 fait environ 1.5 Mo.


Question subsidiaire : si je veux travailler sur un autre PC sans
refaire ces manips d’étalonnage, je peux copier / coller  le répertoire
"cache" et hériter de mon travail précédent ?


Oui, tout à fait.

vincent

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

Re: [OSM-talk-fr] Tagguer un bâtiment à usage multiple (était: Re: Quelques questions d'un débutant OSM)

Oui mais là il a voulu dire qu'une résidence c'est souvent une emprise
avec du terrain autour, parfois aussi une barrière, et dedans
plusieurs batiments, avec plusieurs entrées et donc plusieurs numéros,
mais aussi souvent des parkings, des équipements paysagers ou aires de
jeux, voire aussi des locaux de service (poubelles par exemple). Ainsi
que les voies de circulation (auto, chemins piétons/vélos) dans la
résidence Le tout s'entendant souvent sur plusieurs parcelles
cadastrales (que d'habitude on ne représente pas)

On tague alors la résidence sur la surface de la totalité de son
emprise en lu donnant son nom.

On inclut dedans le tracé séparé des bâtiments (imports du cadastre),
et on peut y ajouter les POIs supplémentaires (s'il y a des commerces
ou entreprises à géolocaliser dedans). Il n'est pas nécessaire de les
lier. La résidence est ni plus ni moins qu'un landuse=residential
auquel on inclut un tag name, mais pas les noms de rues (privées) ni
aucun tag de ce qui a été dessiné dedans. Et pas besoin non plus d'y
mettre un place représentant la résidence (les POIs pour les commerces
ou entreprises, ou voies de circulation ou jardins et aires de jeux ou
équipements sportifs n'ont pas nécessité non plus de rappeler le nom
de la résidence qui les contient, on se contente de leur donner leur
propre nom au cas où il se distingue du nom de la résidence elle-même,
sinon les tags du type d'objet ou pour leur destination ou utilisation
suffisent).

Il ne me semble pas nécessaire pour autant de créer une relation
regroupant le tout si l'emprise totale de la résidence suffit (dans
laquelle il reste permis d'avoir des ilots internes avec une frontière
de rôle "inner", en cas de besoin de les sortir de cette emprise. Le
principe est alors le même que pour les communes, quartiers, et ilots
de quartiers, sauf que la bordure peut avoir des tags pour désigner le
mur ou la clôture elle-même (s'il y en a une) et les barrières
d'entrée, en segmentant cette ligne de bordure externe.

Le 27 juillet 2012 09:41, Christian Quest  a écrit :
> +1 avec Eric
>
> A mon avis le principe général doit rester: un objet un tag...
>
> Il n'y a qu'une résidence XXX, donc les attributs la décrivant doivent
> être présent une fois et une seule dans la base dans la mesure du
> possible, d'où le tracé de son emprise que l'o va tagguer en
> conséquence.
>
> --
> 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] Plug-in Cadastre

Merci pour ces pistes. Voici des précisions :
* Coté enregistrement, j'ai laissé le mode par défaut et ça doit être actif
puisque à chaque fois il me propose bien de recharger depuis le cache ou de
télécharger une version nouvelle.
* La taille max est elle aussi à sa valeur par défaut, je regarderai ce
soir sa valeur. Le seul paramètre que j'ai modifié est que j'ai mis une
grille 10x10 (au lieu de 5 par défaut je crois). Le wiki dit que ca procure
des images de meilleure qualité et comme le texte est souvent dur à lire
j'ai augmenté cette valeur au max.
* Les étalonnages se sont toujours déroulés jusqu'au bout et le résultat
était bon donc le process s'etait bien passé.
Et j'avais effectivement suivi pas à pas le wiki  ...
Peut etre que le fait d'avoir 10x10 comme taille augmente la conso du cache
et que du coup il explose très vite, c'est peut etre une piste, je
contrôlerai ca sur mon PC ce soir.

Question subsidiaire : si je veux travailler sur un autre PC sans refaire
ces manips d’étalonnage, je peux copier / coller  le répertoire "cache" et
hériter de mon travail précédent ?

Le 27 juillet 2012 09:41, Vincent de Chateau-Thierry  a
écrit :

> Bonjour,
>
> Le 27/07/2012 09:24, Eric a écrit :
>
>
>> J'ai une question relative au plugin cadastre que j'utilise pas mal en
>> ce moment : est ce qu'une fois qu'une planche est croppée et
>> géoréferencée, c'est sauvegardé et réutilisable entre deux sessions ou
>> pas ? Par moment, même si je demande à recharger la version en cache,
>> j'arrive sur les fenêtres de georeferencement. je ne comprends pas trop
>> pourquoi alors que parfois, je récupère ma dalle nickel.
>> J'ai regardé dans le répertoire "cache" et je n'ai pas vu de fichier qui
>> ressemble au fichier d'étalonnage donc il faut peut être le refaire à
>> chaque fois ? Ou alors c'est suite à la MAJ JOSM qu'il faut le refaire ?
>> J'avoue que j'ai pas trouvé de règle à tout ça pour l'instant...
>>
>
> Plusieurs points à regarder :
> - dans les préférences (F12 > Cadastre, en bas) l'option "enregistrer
> automatiquement le calque" est-elle cochée ? Il faut qu'elle le soit pour
> que tu conserves les fichiers téléchargés;
> - toujours dans ces préférences, as tu une taille de cache max renseignée
> ? "0" signifie "pas de taille max", dans le cas contraire, une taille (par
> ex. 100 Mo) indique qu'au delà, les plus anciennes planches seront effacées
> pour laisser la place aux nouvelles. Ça pourrait expliquer des disparitions
> de fichiers (avec le temps);
> - enfin, pour qu'un fichier soit sauvegardé il faut que les étapes de
> calage se soient bien passées, jusqu'à l'affichage du raster calé.
>
> La littérature est par ici :
> http://wiki.openstreetmap.org/**wiki/FR:JOSM/Fr:Plugin/**
> Cadastre-fr#Configuration_du_**plugin
>
> vincent
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tagguer un bâtiment à usage multiple (était: Re: Quelques questions d'un débutant OSM)

+1 avec Eric

A mon avis le principe général doit rester: un objet un tag...

Il n'y a qu'une résidence XXX, donc les attributs la décrivant doivent
être présent une fois et une seule dans la base dans la mesure du
possible, d'où le tracé de son emprise que l'o va tagguer en
conséquence.

-- 
Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

Re: [OSM-talk-fr] Plug-in Cadastre


Bonjour,

Le 27/07/2012 09:24, Eric a écrit :


J'ai une question relative au plugin cadastre que j'utilise pas mal en
ce moment : est ce qu'une fois qu'une planche est croppée et
géoréferencée, c'est sauvegardé et réutilisable entre deux sessions ou
pas ? Par moment, même si je demande à recharger la version en cache,
j'arrive sur les fenêtres de georeferencement. je ne comprends pas trop
pourquoi alors que parfois, je récupère ma dalle nickel.
J'ai regardé dans le répertoire "cache" et je n'ai pas vu de fichier qui
ressemble au fichier d'étalonnage donc il faut peut être le refaire à
chaque fois ? Ou alors c'est suite à la MAJ JOSM qu'il faut le refaire ?
J'avoue que j'ai pas trouvé de règle à tout ça pour l'instant...



Plusieurs points à regarder :
- dans les préférences (F12 > Cadastre, en bas) l'option "enregistrer 
automatiquement le calque" est-elle cochée ? Il faut qu'elle le soit 
pour que tu conserves les fichiers téléchargés;
- toujours dans ces préférences, as tu une taille de cache max 
renseignée ? "0" signifie "pas de taille max", dans le cas contraire, 
une taille (par ex. 100 Mo) indique qu'au delà, les plus anciennes 
planches seront effacées pour laisser la place aux nouvelles. Ça 
pourrait expliquer des disparitions de fichiers (avec le temps);
- enfin, pour qu'un fichier soit sauvegardé il faut que les étapes de 
calage se soient bien passées, jusqu'à l'affichage du raster calé.


La littérature est par ici :
http://wiki.openstreetmap.org/wiki/FR:JOSM/Fr:Plugin/Cadastre-fr#Configuration_du_plugin

vincent

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

Re: [OSM-talk-fr] Quelques questions d'un débutant OSM

Et pour le cas du RER, les tensions sont différentes sur les sections
SNCF et RATP... les rames sont "bi-courant" (25000V monophasé et 1500V
continu). Il y a des tags pour ça il me semble...

Source: 
http://fr.wikipedia.org/wiki/Ligne_B_du_RER_d'Île-de-France#Tensions_d.27alimentation

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

[OSM-talk-fr] Plug-in Cadastre

Bonjour,

J'ai une question relative au plugin cadastre que j'utilise pas mal en ce
moment : est ce qu'une fois qu'une planche est croppée et géoréferencée,
c'est sauvegardé et réutilisable entre deux sessions ou pas ? Par moment,
même si je demande à recharger la version en cache, j'arrive sur les
fenêtres de georeferencement. je ne comprends pas trop pourquoi alors que
parfois, je récupère ma dalle nickel.
J'ai regardé dans le répertoire "cache" et je n'ai pas vu de fichier qui
ressemble au fichier d'étalonnage donc il faut peut être le refaire à
chaque fois ? Ou alors c'est suite à la MAJ JOSM qu'il faut le refaire ?
J'avoue que j'ai pas trouvé de règle à tout ça pour l'instant...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Nouveautés Open Data