Re: [OSM-talk-fr] Fwd: Re: Tagguer des abris pour tente au sommet d'un pic

[Philippe Verdy]

N'est-ce pas ce que recouvre les mots abri ou refuge ? Le mot "cover" en
anglais a les mêmes interprétations, et shelter les mêmes usages qu'en
français, si ce n'est qu'un refuge animal n'est pas forcément un abri mais
comprend peut-être un abri. Je traduirais donc "shelter" par "abri".

Si on parle en français de "refuges" en montagne, c'est un peu plus qu'un
simple abri, ça peut même être presque un hôtel-restaurant (même si le
couchage est rarement individuel et se fait en chambrée, et qu'on n'a que
ses sacs de couchage parce que le refuge n'a pas les moyens de faire le
linge tous les jours, et que les repas sont à menu unique et pris en
commun, mais on trouve des exceptions avec quelques "refuges" à usage
surtout touristique dans les stations d'altitude faciles d'accès et qui
sont livrées tous les jours par télécabine ou même par la route avec juste
quelques minutes de moto-neige)...

Si on parle d'abris non couverts, ils existent aussi en anglais, mais par
défaut sans précision ils impliquent une couverture (un toit)... mais pas
forcément des murs (example des abris bus); on précise alors toujours en
anglais, même si pour les arrêts de transport on se contente de mettre
shelter=yes dans OSM.

La couverture devrait être en dur et pas en toile, et l'installation
devrait être fixe (dont pas une caravane) mais on a des cas limites avec
les mobile-homes et containers qui sont parfois utilisés comme les autres
abris. Pourtant pour l'accueil de sans-abris on peut trouver des abris ou
refuges sous tentes.

Le mot refuge peut aussi être juste le fait de se mettre à l'abri (hors de
portée) de régions ou personnes violentes ou de régimes persécuteurs, il
désigne alors la région ou les personnes d'accueil qui vont protéger une
personne, mais il n'y a pas nécessairement de fourniture d'un abri
physique. En anglais on parle dans ce sens de "refugees" et de "shelters"
ou "to take refuge at"

2017-09-07 23:11 GMT+02:00 jabali :

> La définition de "shelter" n'est-ce pas plutôt:
> /a basic architectural structure or building that provides* cover*/
> https://en.wikipedia.org/wiki/Shelter
>
>
>
>
>
>
>
>
>
> --
> Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Fwd: Re: Tagguer des abris pour tente au sommet d'un pic

[jabali]

La définition de "shelter" n'est-ce pas plutôt:
/a basic architectural structure or building that provides* cover*/
https://en.wikipedia.org/wiki/Shelter









--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] Présentation OSM et cartopartie avec CD63 et Comcom Billom

[François Lacombe]

Bonsoir Nicolas,

Le 7 septembre 2017 à 16:48, Nicolas Dumoulin  a
écrit :

>
>  - une proposition des POI et attributs les plus pertinents vis-à-vis des
> centres d'intérêt du projet : mobilité, patrimoine (Label pays d'art et
> d'histoire), culture et loisirs
>

Au risque d’être l'original de l'étape, ne pas oublier les trucs qui font
de la fumée et des étincelles, comme les transfos électriques, les
pipelines, les bornes à incendie, les réservoirs d'eau, les armoires de rue.

Quoi que tu as raison, je le classe dans "culture et loisirs" ;)


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

Re: [OSM-talk-fr] Petites Antilles, Irma: un point à faire...

[Philippe Verdy]

Première étape pour ce qui va suivre, il s'agit des tâches HOT dans le
secteur (pour l'instant cartographie avant désastre):

https://wiki.openstreetmap.org/wiki/2017_Hurricane_Irma_Response

La page est encore à compléter, il n'y a que la structure de base
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Petites Antilles, Irma: un point à faire...

[Augustin Doury]

Salut,

@marc marc pour récupérer de la donnée OSM en shapefile tu as des pistes 
sur le Wiki [1]


Pour le besoin de Martin j'ai testé OSM Boundaries [2] mais j'ai eu une 
erreur, je ne sais pas si ce service fonctionne encore.


Du coup je suis juste passé par Overpass Turbo [3] avec une requête du 
genre "admin_level=* in "Saint-Barthelemy"" puis exporté le résultat en 
GeoJSON et importé dans QGIS avant de faire "Enregistrer Sous" en 
choisissant le format shapefile. Tu peux aussi utiliser directement le 
plugin QuickOSM sous QGIS pour exécuter la requête depuis QGIS


Tu as aussi le HOT Export [4], bizarrement chez moi le fond de plan ne 
s'affiche plus, pourtant c'est le rendu humanitaire qui a l'air de bien 
se porter.


++

[1] 
https://wiki.openstreetmap.org/wiki/Shapefiles#Obtaining_shapefiles_from_OSM_data

[2] https://wambachers-osm.website/boundaries/
[3] http://overpass-turbo.eu/s/rxI
[4] http://overpass-turbo.eu/s/rxI

Le 07/09/2017 à 18:51, Martin Noblecourt a écrit :


Augustin vient de le faire, merci à lui !

On a aussi eu une question sur le cadastre, j'ai renvoyé vers le 
Géoportail, je pense que c'est le plus simple.


Martin


On 07/09/2017 18:17, talk-fr-requ...@openstreetmap.org wrote:

Subject:
Re: [OSM-talk-fr] Petites Antilles, Irma: un point à faire...
From:
marc marc 
Date:
07/09/2017 17:24

To:
"talk-fr@openstreetmap.org" 


Le 07. 09. 17 à 17:12, Martin Noblecourt a écrit :

on m'a demandé les limites administratives de Saint-Barthélémy et
Saint-Martin, si quelqu'un a 5 min pour les extraire de data.gouv.fr ou
OSM ou me les renvoyer en shapefile, cela serait très apprécié.

Saint-Barthélémy
https://www.openstreetmap.org/relation/537967

Saint-MArtin (France)
https://www.openstreetmap.org/relation/1891583
Saint-Martin (Pays-Bas)
https://www.openstreetmap.org/relation/1231790

Aucune idée comment convertir cela en shapefile...




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


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

Re: [OSM-talk-fr] Petites Antilles, Irma: un point à faire...

[Philippe Verdy]

Je pense que ces limites sont déjà connues en chape file car il y a déjà
des tâches HOT maintenant sur #irma avec la délimitation et le découpage en
carreaux couvrants pour les premières demande de base (en attendant des
tâches plus précises basées sur les photos d'après catastrophe que HOT et
les partenaires humanitaires doivent être en train de négocier avec les
producteurs d'images satellites et des aides financières demandées à la
France et à l'Union européenne via les comités de gestion de crise).

Je pense que la question ne se pose pas: les gouvernements français,
néerlandais, britanniques et américains doivent aider financièrement, les
gens sur place ne peuvent pas attendre et il y a urgence à intervenir dans
de bonnes conditions et savoir comment planifier le travail à faire ne
serait-ce que déjà indiquer quels endroits permettront le débarquement des
matériels et où envoyer les hélicos qui déposeront les groupes
électrogènes, les citernes de carburant, les colis d'eau potable et où
pouvoir aller chercher les personnes à déplacer et qu'on ne peut pas
héberger sur place et enfin guider les sauveteurs sur place ou qui
arrivent, et leur indiquer les chemins les plus praticables pour y parvenir
avant que n'arrive les engins de déblaiement.

Les deux aéroports de Saint-Martin sont pour l'instant impraticables sauf
peut-être de tous petits avions et les hélicos, les installations
portuaires sont encombrées, il faut certainement envoyer des bateaux à
proximité des plages et des canots pneumatiques pour faire les navettes, il
y a peu de bateau de plaisance encore en état de naviguer dans le coin pour
s'approcher assez des plages sans risque. Mais au delà de ça il faut savoir
où envoyer les personnes déplacées car il y en a dans toute la région (on
ne va pas leur demander de camper sur les collines elles aussi ravagées par
la boue, les arbres tombés et à tous les vents). La Barbade n'a
certainement pas la capacité d'agir seule malgré le courage et la volonté
de ceux qui sont encore sur place et doivent faire tout leur possible pour
dégager des rues, prêter leurs embarcations, donner du matériel comme des
tronçonneuses et sinon la force de leurs bras.

Et tous ces gens sont dans des maisons ravagées aussi, certaines effondrées
ou sans toit, plus ou moins inondées et pouvant s'effondrer. Rester dans
l'eau pendant des heures, ils vont vite avoir froid même dans une zone
tropicale. Boire va être un problème, et les sanitaires hors d'usage et
inondés ont dû tout polluer.

Ils n'ont plus d'électricité, pas de quoi se sécher, pas de quoi cuisiner
convenablement, ils n'ont pas tous des réserves de gaz ou de charbon encore
sec, les bois morts autour sont trompés et inutilisables. Et même des
réserves alimentaires ont pu être ravagées aussi. Même la police ou la
gendarmerie ou les secours sur place n'ont pas la capacité de répondre et
sont eux-même exposés aux mêmes problèmes et n'ont plus forcément non plus
de véhicule en état.

S'il reste des zones encore un peu épargnées, elles doivent être prises
d'assaut (comme les plus belles résidences dans les hauteurs) et il doit se
poser des problème de sécurité, voire de violence et de pillage. Difficile
de faire entendre raison à des milliers de sans-abris qui doivent se
demander où sont les secours et que font les autorités pour venir
réorganiser cette pagaille et qui voient à côté d'eaux des drames humains
avec des morts ou des blessés laissés sans soin approprié, et tous en train
de s'interroger où sont partis leurs amis, leurs voisins, et où trouver un
téléphone ou une radio qui marche.

Le téléphone normal ne marche plus il y a trop de dégâts sur le réseau
électrique qui est hors d'usage et les stations sont à l'arrêt, donc plus
de téléphone mobile non plus, les plus chanceux ont des téléphones par
satellite ou les radios des bateaux et avions cloués au sol et qui ont
encore assez de carburant ou de batterie). Seuls les hôpitaux doivent avoir
des groupes électrogènes mais ils ne sont pas forcément en état de démarrer
s'ils ont été inondés aussi sans intervention d'électriciens qualifiés pour
isoler les court-circuits ou poser des câbles de secours avec ceux qu'ils
peuvent récupérer autour.

Il y a eu forcement des gens beaucoup plus touchés que d'autres juste à
côté et beaucoup de colère quand ils verront qu'ils ne sont pas tous égaux
et que tout le monde ne se démène pas de la même façon ou n'a pas les mêmes
priorités ni les mêmes soutiens familiaux ou les mêmes moyens matériels qui
leur restent. Mais amener du personnel sur place ne suffira pas, il faut du
matériel en état et pouvoir les débarquer, la mer est encore dangereuse
avec des creux importants et des plages détruites difficiles à approcher ou
même difficile d'accès depuis le reste de l'île à cause des débris, des
zones inondées et des courants d'eau boueuse qui doivent barrer les chemins
d'accès et des glissements de terrain qui ont enseveli ou détruit les
routes. Et les tentatives de déplacement sur 

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[Christian Quest]

Le 7 septembre 2017 à 17:19, JB  a écrit :

> Je ne suis pas persuadé qu'on fera évoluer les idées des uns ou des
> autres. Mais…
>
> Ce qui m'ennuie régulièrement dans le projet OSM, c'est la hausse
> constante de la barrière à l'entrée à la contribution. À chaque couche de
> complexité qu'on ajoute, je pense qu'on perd des nouveaux contributeurs.
> « Alors, comment j'ajoute le nom du rond-point ?
>  - Facile, tu le sélectionnes, puis tu ajoutes le tag name=*.
>  - Heu, pourquoi quand je clique dessus, il n'y a qu'un morceau qui vient
> ? »
>
> Un autre souci, c'est la maintenabilité des éléments. Je n'ai pas de
> stats, mais qui a déjà trouvé une ligne de bus dont tous les éléments sont
> connectés dans la relation ? Combien de temps le sont-ils restés ?
>
> Bon, maintenant les arguments moins élégants, avec une touche de mauvaise
> foi :
>  - Découper des rond-point c'est tellement élégant, et tellement attrayant
> du point de vue intellectuel. Un peu comme le public_transport V2, quoi…
>  - PT_Assistant, c'est cool, mais quel pourcentage de contributeurs
> l'utilise ?
>  - La contribution PT deviendra-t-elle réservée aux plus acharnés de la
> thématique ?
>
> JB.
>
>

Je suis sur la même ligne que JB... les inconvénients à découper me
semblent nettement supérieurs aux avantages.

La complexification (pas que de ça) rend la contribution à OSM de plus en
plus difficile d'accès pour des débutants alors évitons-la quand ce n'est
pas indispensable... et là ça ne me semble pas du tout indispensable.

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

Re: [OSM-talk-fr] comment cartographier un marais ?

[Philippe Verdy]

Les canaux n'ont pas de sens de circulation de l'eau imposé, on met le sens
qu'on veut saauf ceux qui sont alimentés en amont par des drains et où
l'eau cirrucle dans le sens des retenues par les écluses et passes à
débordement, la plupart cependant des petits canaux peuvent voir l'eau
circuler dans un sens ou dans l'autre selon les besoins et les variations
hydriques des eaux qui y sont amenées, et aussi en fonction des heures de
marées pour les marais en bordure de mer (à marée basse le flux va vers la
mer jusqu'à atteindre le seuil minimal de débordement, sinon la marée
montante retient les eaux sur place et le niveau remonte même si l'eau de
mer ne passe pas les seuils des barrages de sel. et de l'eau douce apportée
en aval par d'autres cours d'eau au bassin de retenue peut donc remonter
aussi les autres cours d'eau et canaux.

Le sens utilisé devrait correspondre à celui quand le niveau d'eau baisse
et c'est le sens des rivières naturelles, mais entre deux écluses de
barrage sur les canaux et les rivières canalisées, le niveau varient en
fonction des portes qui sont ouvertes d'un côté ou l'autre et quand les
portes sont fermées, il monte petit à petit de part et d'autre de l'arrivée
des eaux des drains d'alimentation tant que leurs vannes sont ouvertes.
Toutes les portes des écluses ne sont jamais ouvertes en même temps, le
niveau d'eau est donc plus élevé (que si c'était des cours d'eau naturels,
moins dépendant des marées, mais dont le sens est alors surtout fonction du
relief traversé).

Si tu tagues en waterway=canal, il n'y a aucune nécessité que cela forme un
réseau unidirectionnel vers la mer: ce sens ne sera donc pas vérifié par
les outils d'analyse pour ces waterway=canal, ou même waterway=drain ou
même waterway=ditch où l'eau est la pluaprt du temps intermittente ou ne
consiste qu'en quelques flaques immobiles ou terres humides.

Sinon il reste aussi le cas des bras transversaux qui relient deux bras
parallèles d'une rivière naturelle, mais le plus souvent on n'en trace pas
ce filaire détaillé, on se contente de tracer lers riverbanks pour les
rendre visibles, et sinon de tracer les iles ou les bancs de sable ou
galets affleurants.

Le 7 septembre 2017 à 18:07, Adrien Grellier  a écrit :

> Bonjour,
>
> Je viens demander de l'aide pour cartographier proprement le marais de
> St-Mars, au Nord de l'Erdre :
>
> https://www.openstreetmap.org/relation/7422809#map=13/47.
> 3703/-1.4775=D
>
> Dans le marais il y a :
> – des zones de marais (wetland=marsh)
> – des zones de tourbière (wetland=bog)
> – des îles (place=islet)
> – des zones d'eau (étang, canaux)
>
> Je pensais faire un multi-polygone, avec en outter le marais, et inner
> les zones d'eau libre, les îles mais ça ne fonctionne pas tellement (cf
> au sud du marais, près de l'île St-Denis).
>
> Pour les canaux, il faudrait indiquer un sens de circulation de l'eau
> (waterway=stream)… En l’occurrence, c'est tout plat, l'eau ne court pas
> comme dans une rivière ! Comment doit-on procéder dans le cas présent ?
>
> Sur le wiki, je n'ai pas tellement trouvé de méthode pour cartographier
> ça tout bien, j'ai essayé de m'inspirer du marais de Brière, au nord de
> St Nazaire, sans que ça soit concluant.
>
> Si vous avez des conseils, je serais heureux de les entendre.
>
> Bonne journée
>
> Adrien
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Petites Antilles, Irma: un point à faire...

[Martin Noblecourt]

Augustin vient de le faire, merci à lui !

On a aussi eu une question sur le cadastre, j'ai renvoyé vers le 
Géoportail, je pense que c'est le plus simple.


Martin


On 07/09/2017 18:17, talk-fr-requ...@openstreetmap.org wrote:

Subject:
Re: [OSM-talk-fr] Petites Antilles, Irma: un point à faire...
From:
marc marc 
Date:
07/09/2017 17:24

To:
"talk-fr@openstreetmap.org" 


Le 07. 09. 17 à 17:12, Martin Noblecourt a écrit :

on m'a demandé les limites administratives de Saint-Barthélémy et
Saint-Martin, si quelqu'un a 5 min pour les extraire de data.gouv.fr ou
OSM ou me les renvoyer en shapefile, cela serait très apprécié.

Saint-Barthélémy
https://www.openstreetmap.org/relation/537967

Saint-MArtin (France)
https://www.openstreetmap.org/relation/1891583
Saint-Martin (Pays-Bas)
https://www.openstreetmap.org/relation/1231790

Aucune idée comment convertir cela en shapefile...


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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[Jo]

Il faut d'abord créer l'outil avant de pouvoir promouvoir son utilisation.

Pour sélectionner le rond point complet:
Ctrl-f
junction=roundabout inview

Maintenant sûrement on va me dire: mais quel pourcentage de débutants
utilise JOSM?

De toute façon PT_Assistant a été conçu justement pour faire plus abordable
de participer à l'édition de transports en commun. Le problème que j'avais
ici en Belgique à un moment donné, c'était que j'étais quasi le seul qui
osait toucher ces relations route.
L'autre aspect est que PT_Assistant avertit les mappeurs qu'il y a des
problèmes avec les objet que l'utilisateur a modifié. Il faut, bien sûr,
l'installer.

La v2 du PT, j'ai des problèmes avec, moi aussi. Comme il est interprété
maintenant, il est trop complexe. Pourquoi devons-nous ajouter chaque arrêt
2 fois aux relations route? Mais bon, ça c'est une autre discussion.

Jo

2017-09-07 17:19 GMT+02:00 JB :

> Je ne suis pas persuadé qu'on fera évoluer les idées des uns ou des
> autres. Mais…
>
> Ce qui m'ennuie régulièrement dans le projet OSM, c'est la hausse
> constante de la barrière à l'entrée à la contribution. À chaque couche de
> complexité qu'on ajoute, je pense qu'on perd des nouveaux contributeurs.
> « Alors, comment j'ajoute le nom du rond-point ?
>  - Facile, tu le sélectionnes, puis tu ajoutes le tag name=*.
>  - Heu, pourquoi quand je clique dessus, il n'y a qu'un morceau qui vient
> ? »
>
> Un autre souci, c'est la maintenabilité des éléments. Je n'ai pas de
> stats, mais qui a déjà trouvé une ligne de bus dont tous les éléments sont
> connectés dans la relation ? Combien de temps le sont-ils restés ?
>
> Bon, maintenant les arguments moins élégants, avec une touche de mauvaise
> foi :
>  - Découper des rond-point c'est tellement élégant, et tellement attrayant
> du point de vue intellectuel. Un peu comme le public_transport V2, quoi…
>  - PT_Assistant, c'est cool, mais quel pourcentage de contributeurs
> l'utilise ?
>  - La contribution PT deviendra-t-elle réservée aux plus acharnés de la
> thématique ?
>
> JB.
>
>
>
> Le 07/09/2017 à 14:08, Jo a écrit :
>
> J'en ai découpé une bonne partie les dernières semaines ... 3 mois.L'année
> dernière j'ai surtout testé PT_Assistant sur un réseau 'clean', celui que
> j'avais cartographié en bonne partie moi-même en Belgique. Cette année-ci
> je me suis concentré de le tester un peu partout dans le monde pour être
> confident que le plugin en soi ne cause pas de dégâts imprévus et qu'il
> avertit en cas de 'vrais problèmes'.
>
> Ma préférence est de découper les giratoires, donc je l'ai fait, mais bien
> sûr, avant d'envoyer vers le serveur, le plugin m'avertissait d'éventuelles
> ruptures. dans toutes les lignes affectées. Je suis donc certain que toutes
> les relations ont été verifiées.
>
> Jo
>
>
>
> 2017-09-07 12:52 GMT+02:00 lenny.libre :
>
>>
>>
>> Le 07/09/2017 à 09:44, Vincent Pottier a écrit :
>>
>>> Le 07/09/2017 à 08:54, JB a écrit :
>>>
 Bof.
 Je pense que la valeur ajoutée du mappeur est plus dans le repérage et
 la saisie des données au plus simple, et que les tâches ingrates comme le
 découpage des rond-point devraient être sous-traitées aux outils.
 Personnellement, après avoir commencé à trifouiller un rendu transport,
 je me demande presque si les trajets ne devraient pas être carrément
 recalculés intégralement par un routeur pour aboutir à quelque chose de
 cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des voies
 en propres et un réseau évoluant peu), j'ai été désespéré dans certains cas
 par les relations existantes. Alors quand j'imagine ce que ça pourrait
 donner pour les bus…
 JB.

>>> Il me semblait que la question avait été traitée, discutée et résolue il
>>> y a quelques années. De mémoire, voici la synthèse des résultats de
>>> discussions.
>>>
>>> Comme le disait Philippe, les ronds-points sont à considérer comme
>>> points un peu gros, sauf cas particuliers de constitution (genre :
>>> https://osm.org/go/0CUlN2EHd?m= ).
>>>
>>> C'est au logiciel de navigation (ou de rendu) de calculer la portion
>>> empruntée (ce que savent bien faire les logiciels de navigation), portion
>>> changeante qu'on soit à pied, à cheval ou en voiture.
>>>
>>> Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont
>>> pas de l'ordre du routage.
>>>
>>> Ces discussions ont changé ma pratique. Et maintenant, je fusionne les
>>> ronds-points fractionnés pour raisons de routage (trajets de bus ou
>>> itinéraires pédestres).
>>>
>>> FrViPofm
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>> Peut-être faut-il poser des question simples, les réponses ne concernant
>> que ce que j'ai vu, ce sont mes statistiques.
>>
>> Qui découpe les giratoires ?
>> - le contributeur qui décrit des différence entre les différents 

[OSM-talk-fr] comment cartographier un marais ?

[Adrien Grellier]

Bonjour,

Je viens demander de l'aide pour cartographier proprement le marais de
St-Mars, au Nord de l'Erdre :

https://www.openstreetmap.org/relation/7422809#map=13/47.3703/-1.4775=D

Dans le marais il y a :
– des zones de marais (wetland=marsh)
– des zones de tourbière (wetland=bog)
– des îles (place=islet)
– des zones d'eau (étang, canaux)

Je pensais faire un multi-polygone, avec en outter le marais, et inner
les zones d'eau libre, les îles mais ça ne fonctionne pas tellement (cf
au sud du marais, près de l'île St-Denis).

Pour les canaux, il faudrait indiquer un sens de circulation de l'eau
(waterway=stream)… En l’occurrence, c'est tout plat, l'eau ne court pas
comme dans une rivière ! Comment doit-on procéder dans le cas présent ?

Sur le wiki, je n'ai pas tellement trouvé de méthode pour cartographier
ça tout bien, j'ai essayé de m'inspirer du marais de Brière, au nord de
St Nazaire, sans que ça soit concluant.

Si vous avez des conseils, je serais heureux de les entendre.

Bonne journée

Adrien




signature.asc
Description: OpenPGP digital signature
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Petites Antilles, Irma: un point à faire...

[marc marc]

Le 07. 09. 17 à 17:12, Martin Noblecourt a écrit :
> on m'a demandé les limites administratives de Saint-Barthélémy et 
> Saint-Martin, si quelqu'un a 5 min pour les extraire de data.gouv.fr ou 
> OSM ou me les renvoyer en shapefile, cela serait très apprécié.

Saint-Barthélémy
https://www.openstreetmap.org/relation/537967

Saint-MArtin (France)
https://www.openstreetmap.org/relation/1891583
Saint-Martin (Pays-Bas)
https://www.openstreetmap.org/relation/1231790

Aucune idée comment convertir cela en shapefile...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[JB]

Je ne suis pas persuadé qu'on fera évoluer les idées des uns ou des 
autres. Mais…


Ce qui m'ennuie régulièrement dans le projet OSM, c'est la hausse 
constante de la barrière à l'entrée à la contribution. À chaque couche 
de complexité qu'on ajoute, je pense qu'on perd des nouveaux contributeurs.

« Alors, comment j'ajoute le nom du rond-point ?
 - Facile, tu le sélectionnes, puis tu ajoutes le tag name=*.
 - Heu, pourquoi quand je clique dessus, il n'y a qu'un morceau qui 
vient ? »


Un autre souci, c'est la maintenabilité des éléments. Je n'ai pas de 
stats, mais qui a déjà trouvé une ligne de bus dont tous les éléments 
sont connectés dans la relation ? Combien de temps le sont-ils restés ?


Bon, maintenant les arguments moins élégants, avec une touche de 
mauvaise foi :
 - Découper des rond-point c'est tellement élégant, et tellement 
attrayant du point de vue intellectuel. Un peu comme le public_transport 
V2, quoi…
 - PT_Assistant, c'est cool, mais quel pourcentage de contributeurs 
l'utilise ?
 - La contribution PT deviendra-t-elle réservée aux plus acharnés de la 
thématique ?


JB.


Le 07/09/2017 à 14:08, Jo a écrit :
J'en ai découpé une bonne partie les dernières semaines ... 3 
mois.L'année dernière j'ai surtout testé PT_Assistant sur un réseau 
'clean', celui que j'avais cartographié en bonne partie moi-même en 
Belgique. Cette année-ci je me suis concentré de le tester un peu 
partout dans le monde pour être confident que le plugin en soi ne 
cause pas de dégâts imprévus et qu'il avertit en cas de 'vrais problèmes'.


Ma préférence est de découper les giratoires, donc je l'ai fait, mais 
bien sûr, avant d'envoyer vers le serveur, le plugin m'avertissait 
d'éventuelles ruptures. dans toutes les lignes affectées. Je suis donc 
certain que toutes les relations ont été verifiées.


Jo



2017-09-07 12:52 GMT+02:00 lenny.libre >:




Le 07/09/2017 à 09:44, Vincent Pottier a écrit :

Le 07/09/2017 à 08:54, JB a écrit :

Bof.
Je pense que la valeur ajoutée du mappeur est plus dans le
repérage et la saisie des données au plus simple, et que
les tâches ingrates comme le découpage des rond-point
devraient être sous-traitées aux outils.
Personnellement, après avoir commencé à trifouiller un
rendu transport, je me demande presque si les trajets ne
devraient pas être carrément recalculés intégralement par
un routeur pour aboutir à quelque chose de cohérent. Pour
exemple sur les réseaux tram (donc avec vraiment des voies
en propres et un réseau évoluant peu), j'ai été désespéré
dans certains cas par les relations existantes. Alors
quand j'imagine ce que ça pourrait donner pour les bus…
JB.

Il me semblait que la question avait été traitée, discutée et
résolue il y a quelques années. De mémoire, voici la synthèse
des résultats de discussions.

Comme le disait Philippe, les ronds-points sont à considérer
comme points un peu gros, sauf cas particuliers de
constitution (genre : https://osm.org/go/0CUlN2EHd?m=
 ).

C'est au logiciel de navigation (ou de rendu) de calculer la
portion empruntée (ce que savent bien faire les logiciels de
navigation), portion changeante qu'on soit à pied, à cheval ou
en voiture.

Donc, non, on ne les fractionne pas, sauf cas particuliers,
qui ne sont pas de l'ordre du routage.

Ces discussions ont changé ma pratique. Et maintenant, je
fusionne les ronds-points fractionnés pour raisons de routage
(trajets de bus ou itinéraires pédestres).

FrViPofm

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


Peut-être faut-il poser des question simples, les réponses ne
concernant que ce que j'ai vu, ce sont mes statistiques.

Qui découpe les giratoires ?
- le contributeur qui décrit des différence entre les différents
tronçons : c'est la même logique que la découpe de tronçons de
voirie avec des différences (type de voie, vitesse ...)
- le contributeur de lignes de transport public qui veut voir le
routage exact.

Quelles applications ont besoin de giratoires découpés ?
- aucune : les applis de routage savent fonctionner avec ou sans
découpage

Quel est l'impact du découpage/fusion ?
- lorsque je consultais certaines lignes de transport public qui
me tenaient à cœur, je trouvais qu'elles n'avaient plus de
continuité parce qu'un contributeur avait découpé un giratoire
pour voir afficher la ligne qui intéressait 

Re: [OSM-talk-fr] Petites Antilles, Irma: un point à faire...

[Martin Noblecourt]

Si quelqu'un veut donner un coup de main : on m'a demandé les limites 
administratives de Saint-Barthélémy et Saint-Martin, si quelqu'un a 5 
min pour les extraire de data.gouv.fr ou OSM ou me les renvoyer en 
shapefile, cela serait très apprécié.


Merci !

Martin


On 07/09/2017 11:08, talk-fr-requ...@openstreetmap.org wrote:

Subject:
[OSM-talk-fr] Petites Antilles, Irma: un point à faire...
From:
Philippe Verdy 
Date:
07/09/2017 11:07

To:
Discussions sur OSM en français 


On devrait vite avoir un gros projet à faire concernant les Antilles 
après la catastrophe Irma (et le passage annoncé de José dans quelques 
jours). Tout ce qui est cartographié à Saint-Barth, Saint-Martin 
(parties françaises ou néerlandaises), Antigua et Barbuda, Anguilla, 
les iles Vierges (britanniques et américaines), et sans doute encore 
Haiti sera à revoir et vu l'ampleur, il va falloir identifier vite les 
zones permettant d'établir les secours et les liens de communication 
utilisables.


Porto Rico, la Floride et la République dominicaine ont d'autres 
moyens de gérer la crise et plus d'espace.


Je pense qu'une bonne partie de la population encore à Saint-Barth ou 
Saint-Martin va être relogée en Guadeloupe, et en Martinique et qu'il 
va s'établir une solidarité régionale avec aussi les iles voisines 
ayant des capacités d'accueil (Dominique, Sainte-Lucie, la Barbade): 
un pont aérien et maritime international d'évacuation va s'imposer ne 
tenant pas compte des frontières administratives, et cela va perdurer 
pendant des mois ou des années.


Espérons que les autorités locales des différents pays sauront trouver 
le moyen de coexister même si temporairement elles doivent s'établir 
sur des territoires mis en partage. On peut se souvenir par exemple de 
ce qui s'est passé il y a quelques années avec le volcan de l'ile 
britannique de Montserrat : la solidarité régionale avait bien marché 
pour que les autres îles accueillent les personnes déplacées. Déjà 
cela devrait être facilité entre les îles françaises, néerlandaises et 
britanniques.


On devrait vite avoir besoin d'images aériennes pour voir ce qui peut 
être fait. HOT devrait être déclenché sans ces petites Antilles 
ravagées à plus de 90% (Saint-Martin, Saint-Barthélemy, Anguilla, 
Antigua et Barbuda).


Et ne pas oublier que ce n'est pas terminé et que José arrive juste 
derrière dans quelques jours (même s'il semble un peu moins puissant, 
il arrive sur une zone déjà ravagée et retarder le retrait des eaux en 
amenant à nouveau des précipitations importantes et des submersions)


Les secours aériens semblent difficiles, très coûteux et pas suffisant 
en capacité (en hélico), ça commencera d'abord par la voie maritime et 
le dégagement des plages et des ports quand ils pourront accoster: 
peut-on identifier les plages accessibles au delà des ports 
actuellement ravagés ?Combien d'immeubles sont encore debout et 
capables de servir d'abris? Où sont les stations électriques, les 
ressources en eau utilisables?




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


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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[Topographe Fou]

Merci Lenny, me voila rassuré, désolé si j'ai pu mal interpréter ton propos
:-) .

Le 7 septembre 2017 à 15:14, lenny.libre  a écrit :

>
>
> Le 07/09/2017 à 13:59, Topographe Fou a écrit :
>
>
>
> Le 7 septembre 2017 à 12:52, lenny.libre  a écrit :
>
>>
>>
>> Le 07/09/2017 à 09:44, Vincent Pottier a écrit :
>>
>>> Le 07/09/2017 à 08:54, JB a écrit :
>>>
 Bof.
 Je pense que la valeur ajoutée du mappeur est plus dans le repérage et
 la saisie des données au plus simple, et que les tâches ingrates comme le
 découpage des rond-point devraient être sous-traitées aux outils.
 Personnellement, après avoir commencé à trifouiller un rendu transport,
 je me demande presque si les trajets ne devraient pas être carrément
 recalculés intégralement par un routeur pour aboutir à quelque chose de
 cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des voies
 en propres et un réseau évoluant peu), j'ai été désespéré dans certains cas
 par les relations existantes. Alors quand j'imagine ce que ça pourrait
 donner pour les bus…
 JB.

>>> Il me semblait que la question avait été traitée, discutée et résolue il
>>> y a quelques années. De mémoire, voici la synthèse des résultats de
>>> discussions.
>>>
>>> Comme le disait Philippe, les ronds-points sont à considérer comme
>>> points un peu gros, sauf cas particuliers de constitution (genre :
>>> https://osm.org/go/0CUlN2EHd?m= ).
>>>
>>> C'est au logiciel de navigation (ou de rendu) de calculer la portion
>>> empruntée (ce que savent bien faire les logiciels de navigation), portion
>>> changeante qu'on soit à pied, à cheval ou en voiture.
>>>
>>> Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont
>>> pas de l'ordre du routage.
>>>
>>> Ces discussions ont changé ma pratique. Et maintenant, je fusionne les
>>> ronds-points fractionnés pour raisons de routage (trajets de bus ou
>>> itinéraires pédestres).
>>>
>>> FrViPofm
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>> Peut-être faut-il poser des question simples, les réponses ne concernant
>> que ce que j'ai vu, ce sont mes statistiques.
>>
>> Qui découpe les giratoires ?
>> - le contributeur qui décrit des différence entre les différents tronçons
>> : c'est la même logique que la découpe de tronçons de voirie avec des
>> différences (type de voie, vitesse ...)
>> - le contributeur de lignes de transport public qui veut voir le routage
>> exact.
>>
>
> Exactement et ce sont pour moi des contributions recevables dans la mesure
> où elles affinent le modèle sans le détruire.
>
>
>>
>> Quelles applications ont besoin de giratoires découpés ?
>> - aucune : les applis de routage savent fonctionner avec ou sans découpage
>>
>
> Ne jamais dire "aucun", OSM est un projet libre, pas fermé. Je suis certes
> incapable d'un citer une avec précision mais je ne vois pas pourquoi il ne
> devrait pas en exister, qui plus est quand cela rentrerait dans des calculs
> internes dont l'utilisateur n'aurait même pas connaissance.
>
> J'ai bien précisé que cela ne concernait que ce que j'ai pu voir " *les
> réponses ne concernant que ce que j'ai vu, ce sont mes statistiques*"
>
>
>
>>
>> Quel est l'impact du découpage/fusion ?
>> - lorsque je consultais certaines lignes de transport public qui me
>> tenaient à cœur, je trouvais qu'elles n'avaient plus de continuité parce
>> qu'un contributeur avait découpé un giratoire pour voir afficher la ligne
>> qui intéressait sans s'occuper des autres lignes.
>>
>
> Et c'est une erreur de la part de celui qui découpe nous sommes
> d'accord... Il doit vérifier toutes les relations (pas juste les bus) pour
> s'assurer qu'il ne créé pas d'erreur.
>
>
>> - Je ne fusionnais pas systématiquement les giratoires, mais quand je le
>> faisais, je partais du segment qui avait l'historique le plus complet et je
>> vérifiais qu'il n'y avait pas de rupture de continuité sur les autres
>> lignes. Je n'ai pas vu de rupture provoquée par contributeur qui regroupent
>
>
> Pardonnez-moi mais là je lis des choses qui me dérangent et je voudrais
> une clarification.
>
> Que l'on apprécie ou pas l'utilité d'aller au niveau de détail des
> "sections" de rond points, de manière générale (pour toute way) :
>
>- Découper une way pour appliquer des attributs différents/relations
>différentes aux deux morceaux cela s'appelle affiner le modèle et c'est
>considéré comme une contribution utile, à fortiori quand c'est en utilisant
>le schéma de tag conventionnel (à supposer que les infos soient bonnes et
>libres, ce qui n'est pas la question ici)
>- Fusionner deux ways qui ne sont pas strictement identiques
>(attributs et relations), et donc supprimer un niveau de détail (et à
>fortiori utilisant le schéma de tag conventionnel), sous le prétexte que
>

[OSM-talk-fr] Présentation OSM et cartopartie avec CD63 et Comcom Billom

[Nicolas Dumoulin]

Bonjour,

Nous avons était contactés par le conseil départemental du Puy-de-Dôme 
(via la pub du SOTM-Fr 2016) pour intervenir dans le cadre d'un 
programme de concertation d'aménagement du territoire (visant les PADD 
et PLUI mais pas que) sur la ComCom de Billom (qui jouxte celle de 
Clermont).


Je sors d'un entretien avec 2 chargés du développement culturel 
territorial au CD63 et un chargé urbanisme de la comcom de Billom. Outre 
le défibrillateur supplémentaire saisi à l'entrée du bâtiment et un 
contact au CD pour avoir une liste pour le 63, l'échange a été fort 
intéressant. J'interviendrai donc le 11/10 pour présenter OSM et 
impliquer l'audience via une carto-partie :


 - Comment contribuer pour mieux partager la connaissance du territoire

 - les outils permettant d'exploiter les données (overpass et umap)

 - une proposition des POI et attributs les plus pertinents vis-à-vis 
des centres d'intérêt du projet : mobilité, patrimoine (Label pays d'art 
et d'histoire), culture et loisirs


L'idée est d'enchaîner sur un débat sur cette dernière proposition pour 
préparer une carto-partie qui devrait suivre 2 semaines plus tard (date 
à préciser).


Voilà l'info. Si je suis pas trop à la bourre, j'essaierai de vous 
envoyer une pré-version de ma présentation, mais je suis preneur de 
retour d'expérience ou d'idées, surtout pour la dernière partie.


--
Nicolas Dumoulin


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

[OSM-talk-fr] Directive européenne sur le GDPR - il reste 9 mois pour se préparer

[Philippe Verdy]

GDRP - General Data Protection Regulation

Autrement dit la protection des données personnelles.

Consulter :

https://www.lesechos.fr/idees-debats/cercle/cercle-147684-la-gdpr-au-dela-des-obligations-une-opportunite-pour-les-entreprises-1196000.php

Est-on complètement prêt à OSM, et pleinement en conformité ?

OSM en tant qu'organisation établie au Royaume-Uni doit s'y conformer,
sinon des sanctions pénales sont prévues en cas de manquement à cette
protection (et en France c'est la CNIL qui se chargera d'y veiller).

Entrée en vigueur en mai 2018 (9 mois).
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[lenny.libre]

Le 07/09/2017 à 13:59, Topographe Fou a écrit :



Le 7 septembre 2017 à 12:52, lenny.libre > a écrit :




Le 07/09/2017 à 09:44, Vincent Pottier a écrit :

Le 07/09/2017 à 08:54, JB a écrit :

Bof.
Je pense que la valeur ajoutée du mappeur est plus dans le
repérage et la saisie des données au plus simple, et que
les tâches ingrates comme le découpage des rond-point
devraient être sous-traitées aux outils.
Personnellement, après avoir commencé à trifouiller un
rendu transport, je me demande presque si les trajets ne
devraient pas être carrément recalculés intégralement par
un routeur pour aboutir à quelque chose de cohérent. Pour
exemple sur les réseaux tram (donc avec vraiment des voies
en propres et un réseau évoluant peu), j'ai été désespéré
dans certains cas par les relations existantes. Alors
quand j'imagine ce que ça pourrait donner pour les bus…
JB.

Il me semblait que la question avait été traitée, discutée et
résolue il y a quelques années. De mémoire, voici la synthèse
des résultats de discussions.

Comme le disait Philippe, les ronds-points sont à considérer
comme points un peu gros, sauf cas particuliers de
constitution (genre : https://osm.org/go/0CUlN2EHd?m=
 ).

C'est au logiciel de navigation (ou de rendu) de calculer la
portion empruntée (ce que savent bien faire les logiciels de
navigation), portion changeante qu'on soit à pied, à cheval ou
en voiture.

Donc, non, on ne les fractionne pas, sauf cas particuliers,
qui ne sont pas de l'ordre du routage.

Ces discussions ont changé ma pratique. Et maintenant, je
fusionne les ronds-points fractionnés pour raisons de routage
(trajets de bus ou itinéraires pédestres).

FrViPofm

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


Peut-être faut-il poser des question simples, les réponses ne
concernant que ce que j'ai vu, ce sont mes statistiques.

Qui découpe les giratoires ?
- le contributeur qui décrit des différence entre les différents
tronçons : c'est la même logique que la découpe de tronçons de
voirie avec des différences (type de voie, vitesse ...)
- le contributeur de lignes de transport public qui veut voir le
routage exact.


Exactement et ce sont pour moi des contributions recevables dans la 
mesure où elles affinent le modèle sans le détruire.



Quelles applications ont besoin de giratoires découpés ?
- aucune : les applis de routage savent fonctionner avec ou sans
découpage


Ne jamais dire "aucun", OSM est un projet libre, pas fermé. Je suis 
certes incapable d'un citer une avec précision mais je ne vois pas 
pourquoi il ne devrait pas en exister, qui plus est quand cela 
rentrerait dans des calculs internes dont l'utilisateur n'aurait même 
pas connaissance.
J'ai bien précisé que cela ne concernait que ce que j'ai pu voir " /les 
réponses ne concernant que ce que j'ai vu, ce sont mes statistiques/"



Quel est l'impact du découpage/fusion ?
- lorsque je consultais certaines lignes de transport public qui
me tenaient à cœur, je trouvais qu'elles n'avaient plus de
continuité parce qu'un contributeur avait découpé un giratoire
pour voir afficher la ligne qui intéressait sans s'occuper des
autres lignes.


Et c'est une erreur de la part de celui qui découpe nous sommes 
d'accord... Il doit vérifier toutes les relations (pas juste les bus) 
pour s'assurer qu'il ne créé pas d'erreur.


- Je ne fusionnais pas systématiquement les giratoires, mais quand
je le faisais, je partais du segment qui avait l'historique le
plus complet et je vérifiais qu'il n'y avait pas de rupture de
continuité sur les autres lignes. Je n'ai pas vu de rupture
provoquée par contributeur qui regroupent


Pardonnez-moi mais là je lis des choses qui me dérangent et je 
voudrais une clarification.


Que l'on apprécie ou pas l'utilité d'aller au niveau de détail des 
"sections" de rond points, de manière générale (pour toute way) :


  * Découper une way pour appliquer des attributs différents/relations
différentes aux deux morceaux cela s'appelle affiner le modèle et
c'est considéré comme une contribution utile, à fortiori quand
c'est en utilisant le schéma de tag conventionnel (à supposer que
les infos soient bonnes et libres, ce qui n'est pas la question ici)
  * Fusionner deux ways qui ne sont pas strictement identiques
(attributs et 

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[Jo]

J'en ai découpé une bonne partie les dernières semaines ... 3 mois.L'année
dernière j'ai surtout testé PT_Assistant sur un réseau 'clean', celui que
j'avais cartographié en bonne partie moi-même en Belgique. Cette année-ci
je me suis concentré de le tester un peu partout dans le monde pour être
confident que le plugin en soi ne cause pas de dégâts imprévus et qu'il
avertit en cas de 'vrais problèmes'.

Ma préférence est de découper les giratoires, donc je l'ai fait, mais bien
sûr, avant d'envoyer vers le serveur, le plugin m'avertissait d'éventuelles
ruptures. dans toutes les lignes affectées. Je suis donc certain que toutes
les relations ont été verifiées.

Jo



2017-09-07 12:52 GMT+02:00 lenny.libre :

>
>
> Le 07/09/2017 à 09:44, Vincent Pottier a écrit :
>
>> Le 07/09/2017 à 08:54, JB a écrit :
>>
>>> Bof.
>>> Je pense que la valeur ajoutée du mappeur est plus dans le repérage et
>>> la saisie des données au plus simple, et que les tâches ingrates comme le
>>> découpage des rond-point devraient être sous-traitées aux outils.
>>> Personnellement, après avoir commencé à trifouiller un rendu transport,
>>> je me demande presque si les trajets ne devraient pas être carrément
>>> recalculés intégralement par un routeur pour aboutir à quelque chose de
>>> cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des voies
>>> en propres et un réseau évoluant peu), j'ai été désespéré dans certains cas
>>> par les relations existantes. Alors quand j'imagine ce que ça pourrait
>>> donner pour les bus…
>>> JB.
>>>
>> Il me semblait que la question avait été traitée, discutée et résolue il
>> y a quelques années. De mémoire, voici la synthèse des résultats de
>> discussions.
>>
>> Comme le disait Philippe, les ronds-points sont à considérer comme points
>> un peu gros, sauf cas particuliers de constitution (genre :
>> https://osm.org/go/0CUlN2EHd?m= ).
>>
>> C'est au logiciel de navigation (ou de rendu) de calculer la portion
>> empruntée (ce que savent bien faire les logiciels de navigation), portion
>> changeante qu'on soit à pied, à cheval ou en voiture.
>>
>> Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont
>> pas de l'ordre du routage.
>>
>> Ces discussions ont changé ma pratique. Et maintenant, je fusionne les
>> ronds-points fractionnés pour raisons de routage (trajets de bus ou
>> itinéraires pédestres).
>>
>> FrViPofm
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> Peut-être faut-il poser des question simples, les réponses ne concernant
> que ce que j'ai vu, ce sont mes statistiques.
>
> Qui découpe les giratoires ?
> - le contributeur qui décrit des différence entre les différents tronçons
> : c'est la même logique que la découpe de tronçons de voirie avec des
> différences (type de voie, vitesse ...)
> - le contributeur de lignes de transport public qui veut voir le routage
> exact.
>
> Quelles applications ont besoin de giratoires découpés ?
> - aucune : les applis de routage savent fonctionner avec ou sans découpage
>
> Quel est l'impact du découpage/fusion ?
> - lorsque je consultais certaines lignes de transport public qui me
> tenaient à cœur, je trouvais qu'elles n'avaient plus de continuité parce
> qu'un contributeur avait découpé un giratoire pour voir afficher la ligne
> qui intéressait sans s'occuper des autres lignes.
> - Je ne fusionnais pas systématiquement les giratoires, mais quand je le
> faisais, je partais du segment qui avait l'historique le plus complet et je
> vérifiais qu'il n'y avait pas de rupture de continuité sur les autres
> lignes. Je n'ai pas vu de rupture provoquée par contributeur qui regroupent
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[Topographe Fou]

Le 7 septembre 2017 à 12:52, lenny.libre  a écrit :

>
>
> Le 07/09/2017 à 09:44, Vincent Pottier a écrit :
>
>> Le 07/09/2017 à 08:54, JB a écrit :
>>
>>> Bof.
>>> Je pense que la valeur ajoutée du mappeur est plus dans le repérage et
>>> la saisie des données au plus simple, et que les tâches ingrates comme le
>>> découpage des rond-point devraient être sous-traitées aux outils.
>>> Personnellement, après avoir commencé à trifouiller un rendu transport,
>>> je me demande presque si les trajets ne devraient pas être carrément
>>> recalculés intégralement par un routeur pour aboutir à quelque chose de
>>> cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des voies
>>> en propres et un réseau évoluant peu), j'ai été désespéré dans certains cas
>>> par les relations existantes. Alors quand j'imagine ce que ça pourrait
>>> donner pour les bus…
>>> JB.
>>>
>> Il me semblait que la question avait été traitée, discutée et résolue il
>> y a quelques années. De mémoire, voici la synthèse des résultats de
>> discussions.
>>
>> Comme le disait Philippe, les ronds-points sont à considérer comme points
>> un peu gros, sauf cas particuliers de constitution (genre :
>> https://osm.org/go/0CUlN2EHd?m= ).
>>
>> C'est au logiciel de navigation (ou de rendu) de calculer la portion
>> empruntée (ce que savent bien faire les logiciels de navigation), portion
>> changeante qu'on soit à pied, à cheval ou en voiture.
>>
>> Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont
>> pas de l'ordre du routage.
>>
>> Ces discussions ont changé ma pratique. Et maintenant, je fusionne les
>> ronds-points fractionnés pour raisons de routage (trajets de bus ou
>> itinéraires pédestres).
>>
>> FrViPofm
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> Peut-être faut-il poser des question simples, les réponses ne concernant
> que ce que j'ai vu, ce sont mes statistiques.
>
> Qui découpe les giratoires ?
> - le contributeur qui décrit des différence entre les différents tronçons
> : c'est la même logique que la découpe de tronçons de voirie avec des
> différences (type de voie, vitesse ...)
> - le contributeur de lignes de transport public qui veut voir le routage
> exact.
>

Exactement et ce sont pour moi des contributions recevables dans la mesure
où elles affinent le modèle sans le détruire.


>
> Quelles applications ont besoin de giratoires découpés ?
> - aucune : les applis de routage savent fonctionner avec ou sans découpage
>

Ne jamais dire "aucun", OSM est un projet libre, pas fermé. Je suis certes
incapable d'un citer une avec précision mais je ne vois pas pourquoi il ne
devrait pas en exister, qui plus est quand cela rentrerait dans des calculs
internes dont l'utilisateur n'aurait même pas connaissance.


>
> Quel est l'impact du découpage/fusion ?
> - lorsque je consultais certaines lignes de transport public qui me
> tenaient à cœur, je trouvais qu'elles n'avaient plus de continuité parce
> qu'un contributeur avait découpé un giratoire pour voir afficher la ligne
> qui intéressait sans s'occuper des autres lignes.
>

Et c'est une erreur de la part de celui qui découpe nous sommes d'accord...
Il doit vérifier toutes les relations (pas juste les bus) pour s'assurer
qu'il ne créé pas d'erreur.


> - Je ne fusionnais pas systématiquement les giratoires, mais quand je le
> faisais, je partais du segment qui avait l'historique le plus complet et je
> vérifiais qu'il n'y avait pas de rupture de continuité sur les autres
> lignes. Je n'ai pas vu de rupture provoquée par contributeur qui regroupent


Pardonnez-moi mais là je lis des choses qui me dérangent et je voudrais une
clarification.

Que l'on apprécie ou pas l'utilité d'aller au niveau de détail des
"sections" de rond points, de manière générale (pour toute way) :

   - Découper une way pour appliquer des attributs différents/relations
   différentes aux deux morceaux cela s'appelle affiner le modèle et c'est
   considéré comme une contribution utile, à fortiori quand c'est en utilisant
   le schéma de tag conventionnel (à supposer que les infos soient bonnes et
   libres, ce qui n'est pas la question ici)
   - Fusionner deux ways qui ne sont pas strictement identiques (attributs
   et relations), et donc supprimer un niveau de détail (et à fortiori
   utilisant le schéma de tag conventionnel), sous le prétexte que personne
   (?) n'a besoin de descendre à ce niveau de détail, c'est supprimer une
   contribution sans justification rationnelle. Et quand c'est pour faire
   plaisir à son outils préféré, que ce soit du rendu, de navigation... cela
   s'appelle tagguer pour l'outil (ce qui n'est pas dans les règles convenues
   il me semble).

En bref je voudrais m'assurer qu'il n'est pas question ici de promouvoir la
suppression (que je juge abusive) de telles contributions.


>
>
> 

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[lenny.libre]

Le 07/09/2017 à 09:44, Vincent Pottier a écrit :

Le 07/09/2017 à 08:54, JB a écrit :

Bof.
Je pense que la valeur ajoutée du mappeur est plus dans le repérage 
et la saisie des données au plus simple, et que les tâches ingrates 
comme le découpage des rond-point devraient être sous-traitées aux 
outils.
Personnellement, après avoir commencé à trifouiller un rendu 
transport, je me demande presque si les trajets ne devraient pas être 
carrément recalculés intégralement par un routeur pour aboutir à 
quelque chose de cohérent. Pour exemple sur les réseaux tram (donc 
avec vraiment des voies en propres et un réseau évoluant peu), j'ai 
été désespéré dans certains cas par les relations existantes. Alors 
quand j'imagine ce que ça pourrait donner pour les bus…

JB.
Il me semblait que la question avait été traitée, discutée et résolue 
il y a quelques années. De mémoire, voici la synthèse des résultats de 
discussions.


Comme le disait Philippe, les ronds-points sont à considérer comme 
points un peu gros, sauf cas particuliers de constitution (genre : 
https://osm.org/go/0CUlN2EHd?m= ).


C'est au logiciel de navigation (ou de rendu) de calculer la portion 
empruntée (ce que savent bien faire les logiciels de navigation), 
portion changeante qu'on soit à pied, à cheval ou en voiture.


Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne 
sont pas de l'ordre du routage.


Ces discussions ont changé ma pratique. Et maintenant, je fusionne les 
ronds-points fractionnés pour raisons de routage (trajets de bus ou 
itinéraires pédestres).


FrViPofm

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Peut-être faut-il poser des question simples, les réponses ne concernant 
que ce que j'ai vu, ce sont mes statistiques.


Qui découpe les giratoires ?
- le contributeur qui décrit des différence entre les différents 
tronçons : c'est la même logique que la découpe de tronçons de voirie 
avec des différences (type de voie, vitesse ...)
- le contributeur de lignes de transport public qui veut voir le routage 
exact.


Quelles applications ont besoin de giratoires découpés ?
- aucune : les applis de routage savent fonctionner avec ou sans découpage

Quel est l'impact du découpage/fusion ?
- lorsque je consultais certaines lignes de transport public qui me 
tenaient à cœur, je trouvais qu'elles n'avaient plus de continuité parce 
qu'un contributeur avait découpé un giratoire pour voir afficher la 
ligne qui intéressait sans s'occuper des autres lignes.
- Je ne fusionnais pas systématiquement les giratoires, mais quand je le 
faisais, je partais du segment qui avait l'historique le plus complet et 
je vérifiais qu'il n'y avait pas de rupture de continuité sur les autres 
lignes. Je n'ai pas vu de rupture provoquée par contributeur qui regroupent



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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[marc marc]

Le 07. 09. 17 à 11:42, Axelos a écrit :
> la globalité de certains de ces giratoires étaient empruntés 
> par les itinéraires sans que je m'en rende compte, 
> et JOSM ne râle pas au contraire il semble content.

c'est une approximation/simplification de l'espace.
exemple avec un simple carrefour : le fait que c'est un point
dans osm, ne veux pas dire que le bus passe au mètre près
au même endroit pour le trajet aller que pour le trajet retour.
Personne ne voit (pour le moment) le besoin de couper cela en 4.
De même une route est une approximation des 2 bandes de circulation,
cela ne signifie pas que le bus a "les roues" au même endroit
à l'aller et au retour.
Cela ne choque personne pour les voitures !
Je n'ai jamais compris pq certains trouvent cela indispensable
lorsqu'il s'agit du rendu d'un trajet de bus

De la même manière qu'on a un noeud highway=turning_circle
le plus aurait été d'avoir un noeud highway=roundabout
avec un "width" pour le rendu.
mais cela n'existe pas, on a fait plus précis,
avec les yop-yop du au manque d’unanimité.

pendant ce temps, cfr la semaine passée, y a des relations de bus
en version > 100 en autre pour des optimisations d'itinéraires
mais qui n'ont aucun arrêt de bus... si cela se trouve le bus
ne passe même plus là depuis longtemps...
Pour moi, le trajet d'un bus ne peux se faire qu'en ayant pris
le bus ou en ayant uns source opendata qui le décrit (je n'en
connais pas)
Encoder le trajet d'un bus en supposant qu'il fait le trajet
par défaut de mapzen donne une impression de qualité...
alors que c'est qu'une hypothèse.
Je troue cela un excès de micro-maping, surtout quand on voit
qu'il y a tant à améliorer de + fondamental (les arrêts)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Petites Antilles, Irma: un point à faire...

[Vincent de Château-Thierry]

Bonjour,

> De: "Philippe Verdy" 
> 
> On devrait vite avoir besoin d'images aériennes pour voir ce qui peut
> être fait. HOT devrait être déclenché sans ces petites Antilles
> ravagées à plus de 90% (Saint-Martin, Saint-Barthélemy, Anguilla,
> Antigua et Barbuda).

À noter, les tâches amorcées en début de semaine justement : 
http://tasks.hotosm.org/?direction=desc=irma_by=created

vincent

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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[Axelos]

Coucou,

Le 07/09/2017 à 09:44, Vincent Pottier a écrit :
> Il me semblait que la question avait été traitée, discutée et résolue il
> y a quelques années. De mémoire, voici la synthèse des résultats de
> discussions.
> 
> Comme le disait Philippe, les ronds-points sont à considérer comme
> points un peu gros, sauf cas particuliers de constitution (genre :
> https://osm.org/go/0CUlN2EHd?m= ).
> 
> C'est au logiciel de navigation (ou de rendu) de calculer la portion
> empruntée (ce que savent bien faire les logiciels de navigation),
> portion changeante qu'on soit à pied, à cheval ou en voiture.

Est-il possible d'ajouter cette décision sur le wiki OSM ?
Car si je regarde la page osm.org/wiki/FR:Key:public_transport = aucune
référence
Si je regarde la page osm.org/wiki/FR:Relation:route = "Il n'y a pas de
consensus"

Aussi préciser si concerne les rond-points, giratoires, les deux ? Car
en France il s'agit de deux types de carrefours différents. (les autres
pays francophones je sais pas)

> Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont
> pas de l'ordre du routage.
> 
> Ces discussions ont changé ma pratique. Et maintenant, je fusionne les
> ronds-points fractionnés pour raisons de routage (trajets de bus ou
> itinéraires pédestres).

J'ai toujours eu l'habitude (et la logique personnelle) de découper ces
carrefours. Et en effet je viens de m'apercevoir qu'en actualisant
certains itinéraires ces derniers jours, la globalité de certains de ces
giratoires étaient empruntés par les itinéraires sans que je m'en rende
compte, et JOSM ne râle pas au contraire il semble content.

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

[OSM-talk-fr] Petites Antilles, Irma: un point à faire...

[Philippe Verdy]

On devrait vite avoir un gros projet à faire concernant les Antilles après
la catastrophe Irma (et le passage annoncé de José dans quelques jours).
Tout ce qui est cartographié à Saint-Barth, Saint-Martin (parties
françaises ou néerlandaises), Antigua et Barbuda, Anguilla, les iles
Vierges (britanniques et américaines), et sans doute encore Haiti sera à
revoir et vu l'ampleur, il va falloir identifier vite les zones permettant
d'établir les secours et les liens de communication utilisables.

Porto Rico, la Floride et la République dominicaine ont d'autres moyens de
gérer la crise et plus d'espace.

Je pense qu'une bonne partie de la population encore à Saint-Barth ou
Saint-Martin va être relogée en Guadeloupe, et en Martinique et qu'il va
s'établir une solidarité régionale avec aussi les iles voisines ayant des
capacités d'accueil (Dominique, Sainte-Lucie, la Barbade): un pont aérien
et maritime international d'évacuation va s'imposer ne tenant pas compte
des frontières administratives, et cela va perdurer pendant des mois ou des
années.

Espérons que les autorités locales des différents pays sauront trouver le
moyen de coexister même si temporairement elles doivent s'établir sur des
territoires mis en partage. On peut se souvenir par exemple de ce qui s'est
passé il y a quelques années avec le volcan de l'ile britannique de
Montserrat : la solidarité régionale avait bien marché pour que les autres
îles accueillent les personnes déplacées. Déjà cela devrait être facilité
entre les îles françaises, néerlandaises et britanniques.

On devrait vite avoir besoin d'images aériennes pour voir ce qui peut être
fait. HOT devrait être déclenché sans ces petites Antilles ravagées à plus
de 90% (Saint-Martin, Saint-Barthélemy, Anguilla, Antigua et Barbuda).

Et ne pas oublier que ce n'est pas terminé et que José arrive juste
derrière dans quelques jours (même s'il semble un peu moins puissant, il
arrive sur une zone déjà ravagée et retarder le retrait des eaux en amenant
à nouveau des précipitations importantes et des submersions)

Les secours aériens semblent difficiles, très coûteux et pas suffisant en
capacité (en hélico), ça commencera d'abord par la voie maritime et le
dégagement des plages et des ports quand ils pourront accoster: peut-on
identifier les plages accessibles au delà des ports actuellement ravagés
?Combien d'immeubles sont encore debout et capables de servir d'abris? Où
sont les stations électriques, les ressources en eau utilisables?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[Philippe Verdy]

Le 7 septembre 2017 à 09:51, Vincent Pottier  a écrit :

> Le 07/09/2017 à 09:35, Jo a écrit :
>
>> Et chaque rendu transport devra donc refaire ce calcul d'itinéraire
>> denouveau et denouveau?
>>
> Oui.
>
>> Avec possiblement des résultats divergents entre un moteur de routage bus
>> et un autre?
>>
> Avec nécessairement un rendu différent pour bus et piéton ! Le piéton, il
> peut prendre le rond-point à contre-sens !


Oui mais découpage ou pas cela n'a aucune conséquence pour les piétons. Ils
ne sont pas le problème du tout. La seule raison de découper est la
nécessité de mettre des tags différents sur certaines parties. De plus les
piétons ont très des chemins particuliers préférés évitant la boucle et
leur demandant d'utiliser des passage protégés écartés du rond-point
lui-même: ce sont ces chemins qu'il est intéressant de marquer, ne
serait-ce que pour l'accessibilité et la sécurité (donc même les trottoirs
périphériques devraient être tracés séparément, la boucle de la chaussée
restant dangereuse pour eux même s'ils peuvent en principe l'utiliser on ne
peut pas le leur recommander et là il faut être réaliste.

>
>
>> PT_Assistant est là maintenant pour aider à faire la cartographie des
>> routes de bus et les maintenir. Je ne dirai pas que c'est tout facile, mais
>> ce n'est certainement pas impossible.
>>
> L'éditeur de relations de JOSM gère très bien les ronds-points (entiers)
> intégrés dans un itinéraire, qu'il soit pédestre ou lié aux transports en
> commun.


Tout à fait d'accord et ce n'est pas le seul outil. Etant donné comment on
a fait le choix initial de ne pas taguer les highways comme surfaces mais
comme lignes, uniquement pour les véhicules en laissant les piétons à part,
que ce soit découpé ou pas cela ne change rien au routage des véhicules sur
leur chemin imposé, ni aux piétons qui s'écartent systématiquement de ce
chemin théorique "moyen" et qui ne leur correspond pas du tout.

OSM progressant en niveau de détail, on en viendra assez vite à tracer
*aussi* les surfaces de voiries, tout en gardant le tracé filaire, comme on
l'a fait pour les rivières en traçant en plus les "riverbanks". Le filaire
pourra encore servir pour des usages plus limités ou moins précis. Mais
cela arrivera beaucoup plus lentement en commençant par des zones
localisées où le seul filaire est problématique et trop ambigu (et ne
permet toujours pas de préciser certains itinéraires autorisés ou ceux qui
sont interdits pour les véhicules, ou ceux qui ne sont pas recommandés ou
dangereux pour les piétons et pas assez précis en terme d'accessibilité).

Car il faut bien admettre que la représentation filaire a aussi ses limites
et que ce n'est qu'une modélisation approximative d'une réalité en fait
différente et dont la géométrie de base est très difficilement
représentable avec juste des tags sur le filaire, dont l'interprétation
géométrique devient de plus en plus difficile et ultracompliquée: on a déjà
vu le problème récemment pour la représentation cartographique des largeurs
de routes et du changement du nombre de "lanes" : comment obtenir une
représentation réaliste quand on zoome sur le détail est particulièrement
difficile, et jusqu'à présent on n'a que des heuristiques déterminant une
largeur estimée moyenne selon le type de route (primary, secondary...) et
ne tenant d'ailleurs même pas compte de tags simple comme "oneway=*" qui
devrait normalement aussi réduire l'estimation de largeur moyenne. Le tracé
uniquement filaire est aussi problématique pour les ponts à chaussées
séparés (on a une solution qui commence à s'établir qui consiste à tracer
le contour polygonal autour du pont avec man_made=bridge+layer=1, en plus
des routes et barrières posées dessus)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[Vincent Pottier]

Le 07/09/2017 à 09:35, Jo a écrit :
Et chaque rendu transport devra donc refaire ce calcul d'itinéraire 
denouveau et denouveau?

Oui.
Avec possiblement des résultats divergents entre un moteur de routage 
bus et un autre?
Avec nécessairement un rendu différent pour bus et piéton ! Le piéton, 
il peut prendre le rond-point à contre-sens !


PT_Assistant est là maintenant pour aider à faire la cartographie des 
routes de bus et les maintenir. Je ne dirai pas que c'est tout facile, 
mais ce n'est certainement pas impossible.
L'éditeur de relations de JOSM gère très bien les ronds-points (entiers) 
intégrés dans un itinéraire, qu'il soit pédestre ou lié aux transports 
en commun.


Jo


FrViPofm

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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[Vincent Pottier]

Le 07/09/2017 à 08:54, JB a écrit :

Bof.
Je pense que la valeur ajoutée du mappeur est plus dans le repérage et 
la saisie des données au plus simple, et que les tâches ingrates comme 
le découpage des rond-point devraient être sous-traitées aux outils.
Personnellement, après avoir commencé à trifouiller un rendu 
transport, je me demande presque si les trajets ne devraient pas être 
carrément recalculés intégralement par un routeur pour aboutir à 
quelque chose de cohérent. Pour exemple sur les réseaux tram (donc 
avec vraiment des voies en propres et un réseau évoluant peu), j'ai 
été désespéré dans certains cas par les relations existantes. Alors 
quand j'imagine ce que ça pourrait donner pour les bus…

JB.
Il me semblait que la question avait été traitée, discutée et résolue il 
y a quelques années. De mémoire, voici la synthèse des résultats de 
discussions.


Comme le disait Philippe, les ronds-points sont à considérer comme 
points un peu gros, sauf cas particuliers de constitution (genre : 
https://osm.org/go/0CUlN2EHd?m= ).


C'est au logiciel de navigation (ou de rendu) de calculer la portion 
empruntée (ce que savent bien faire les logiciels de navigation), 
portion changeante qu'on soit à pied, à cheval ou en voiture.


Donc, non, on ne les fractionne pas, sauf cas particuliers, qui ne sont 
pas de l'ordre du routage.


Ces discussions ont changé ma pratique. Et maintenant, je fusionne les 
ronds-points fractionnés pour raisons de routage (trajets de bus ou 
itinéraires pédestres).


FrViPofm

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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[Jo]

Et chaque rendu transport devra donc refaire ce calcul d'itinéraire
denouveau et denouveau? Avec possiblement des résultats divergents entre un
moteur de routage bus et un autre?

PT_Assistant est là maintenant pour aider à faire la cartographie des
routes de bus et les maintenir. Je ne dirai pas que c'est tout facile, mais
ce n'est certainement pas impossible.

Jo


2017-09-07 8:54 GMT+02:00 JB :

> Bof.
> Je pense que la valeur ajoutée du mappeur est plus dans le repérage et la
> saisie des données au plus simple, et que les tâches ingrates comme le
> découpage des rond-point devraient être sous-traitées aux outils.
> Personnellement, après avoir commencé à trifouiller un rendu transport, je
> me demande presque si les trajets ne devraient pas être carrément
> recalculés intégralement par un routeur pour aboutir à quelque chose de
> cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des voies
> en propres et un réseau évoluant peu), j'ai été désespéré dans certains cas
> par les relations existantes. Alors quand j'imagine ce que ça pourrait
> donner pour les bus…
> JB.
>
>
> Le 07/09/2017 à 06:35, Jo a écrit :
>
> Depuis quelques mois nous avons enfin une façon de taguer les bus_bay.
> Pour les ajouter le chemin est également découpé deux fois. S'il se trouve
> sur le rond-point c'est une autre raison pour le découper.
>
> Dire que c'est au rendu de dessiner les lignes de bus en partiel sur les
> rond-points, c'est facile. Néanmoins, ce n'est pas quelque chose qui sera
> implémenté dans un futur proche. Probablement jamais. Diviser les
> rond-points, c'est quelque chose qu'un mappeur peut faire facilement et ça
> ne heurte personne. Ça décrit très précisement les trajets des bus, surtout
> quand la même ligne emprunte le rond-point plusieurs fois, ou s'il
> n'emprunte pas certaines parties, parce qu'il y a des 'fourches' en oneway
> avant ou derrière.
>
> Polyglot
>
> 2017-09-07 1:52 GMT+02:00 Philippe Verdy :
>
>> Je le pense aussi. Un giratoire sur le tracé d'un ligne est très aisément
>> détectable même et surtout si c'est un way fermé. Si le dessin du cercle
>> est "gênant" en zoom avant, il suffit de le considérer comme si ce n'était
>> pas une ligne mais un disque, assimilable à un point un peu plis gros en
>> son centre. De plus un bus peut encore être amené à faire plus que 1 tour
>> s'il est gêné pour sortir, cela ne remet pas en cause le trajet de la
>> ligne.
>>
>> C'est pareil pour les itinéraires routiers pour automobiles, camions ou
>> cyclistes, et même pour les piétons (s'il y a peur eux un chemin permettant
>> de passer par le centre d'un grand giratoire en passant par des passages
>> protégés, ce chemin sera marqué de même que les connexions aux rues
>> arrivant au rond point, et dans ce cas le piéton n'utilisera pas le tracé
>> circulaire du giratoire.
>>
>> Dans tous les cas, on sait par où on y entre et par où en en sort. Briser
>> les giratoires ne sert pas à grand chose.
>>
>> Je n'ai vus que quelques seul cas où ça peut être utile
>> - : si le giratoire passe emprunte des ponts au dessus d'autres voies
>> routières/ferrée/cyclistes ou un avec cours d'eau passant dessous et
>> évitant le giratoire. Le but étant alors de mettre des attributs différents
>> sur des sections du giratoire, notamment les barrières de sécurité (mais on
>> peut aussi représenter ces barrières sur des chemins parallèles.) mais
>> surtout les l'attributs "layer" et "bridge=yes" (dont on peut pourtant se
>> passer en mettant le layer sur les voies qui traversent en dessous.
>> - Si le giratoire passe sous d'autres ponts il n'est jamais nécessaire de
>> le couper (ce sont ces ponts qu'on va découper éventuellement)
>> - Si le giratoire passe dans des sections en tunnel (exemple en Andorre)
>> voire sous un bâtiment un "layer=-n" sera éventuellement nécessaire mais on
>> pourrait être gêné par le fait que ce layer passe alors aussi en dessous
>> des "landuse" environnants s'ils englobent la surface du giratoire
>>
>> Certains veulent découper les giratoires à ponts pour uniquement le rendu
>> (qui détoure les voies des ponts par un filet noir : à mon avis ça se règle
>> par une correction dans le moteur de rendu, pour que ce filet ne vienne pas
>> en surimpression des voies connectées (comme si ce filet noir était des
>> barrières barrant les accès). On peut faire autrement en évitant
>> "bridge=yes" sur ces sections de giratoire, et mettant plutôt tunnel pour
>> les voies en dessous, et en ajoutant les barrières de sécurité de chaque
>> côté du pont. Dans ce cas plus besoin de "bridge" et "layer" sur le
>> giratoire".
>>
>> Pour les assistants de navigation GPS, ils disent "entrez dans le
>> giratoire/rond-point, prenez la deuxième sortie" et ça suffit car il n'y a
>> pas d'autres chemins possibles et si celui qui ne connait pas bien le coin
>> rate la bonne sortie, il sait qu'il va devoir faire le tour complet pour la
>> retrouver et n'a pas besoin de 

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[Topographe Fou]

  Bonjour,J'avoue que ayant pas mal travaillé sur les lignes et arrêts de bus dans la région de Paris je fais partie de ceux qui découpent les rond-points (et sans vérifier si précédemment ils n'avaient pas été soudés). Je trouve que donner un tracé exact est plus juste par rapport à la réalité du terrain. C'est mon seul argument.Quoiqu'il arrive les outils doivent pouvoir gérer des ronds-points découpés car il peut y avoir d'autres raisons à cela que les lignes de bus (changement de revêtement ? Passage dans un tunnel (rare) ? Sur un pont (plus fréquent) ? Piste cyclable que sur une partie ?...). Donc si les lignes de bus augmentent les occurrences interdire ou déconseiller cette pratique ne résoudra pas fondamentalement le problème. Quelque soit la solution il faudra que les outils s'adaptent aux deux. On ne tag pas pour eux (ou pour le rendu comme on a tendance à simplifier ;-) ). Un outils gérant les deux sera capable de gérer bien plus qu'un problème de bus.Cordialement, LeTopographeFouDe: f.gar...@gmail.comEnvoyé: 7 septembre 2017 12:27 AMÀ: talk-fr@openstreetmap.orgRépondre à: talk-fr@openstreetmap.orgObjet: [OSM-talk-fr] Trajets de bus et ronds--points  Bonsoir,Je pense qu'il faudrait se mettre d'accord une bonne fois pour toutes, avec les ronds-points empruntés par les lignes de bus...À chaque fois, ça ne loupe pas : je trouve des ronds-points morcelés, ou refusionnés, puis remorcelés, ... Bref, à cause de tout ça, les tracés des lignes de bus sont incorrects, au niveau des ronds-points.Personnellement, je pense que ça n'a pas de sens de couper un rond-point, étant donné que l'entrée et la sortie sont connues. Charge au logiciel de dessin de tenir compte de ça...-- Cordialement,Francescu GAROBY

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

[OSM-talk-fr] Nouvelle modélisation des transformateurs électriques

[François Lacombe]

Bonjour à tous,

Cette été a été l'occasion de produire une nouvelle étape dans la carto des
réseaux électriques et de leur fonctionnement.
La proposition est en cours de vote sur le wiki et une annonce a été
envoyée sur la ML internationale, que je reporte ici pour les francophones
(même si la propal est en anglais)

https://wiki.openstreetmap.org/wiki/Proposed_features/Transformer_extension_proposal

C'est certes très technique, le but est de décrire l'architecture et
fonctions de beaucoup de transformateurs électriques différents. Ce sont
des appareils chargés de modifier la tension du courant électrique dans le
réseau.

Tout le monde est invité à regarder la cohérence et définition des tags,
avec ou sans approche technique. Rendez-vous ensuite au bas de la page dans
la section Voting.

Merci par avance pour votre contribution


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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[JB]

Bof.
Je pense que la valeur ajoutée du mappeur est plus dans le repérage et 
la saisie des données au plus simple, et que les tâches ingrates comme 
le découpage des rond-point devraient être sous-traitées aux outils.
Personnellement, après avoir commencé à trifouiller un rendu transport, 
je me demande presque si les trajets ne devraient pas être carrément 
recalculés intégralement par un routeur pour aboutir à quelque chose de 
cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des 
voies en propres et un réseau évoluant peu), j'ai été désespéré dans 
certains cas par les relations existantes. Alors quand j'imagine ce que 
ça pourrait donner pour les bus…

JB.

Le 07/09/2017 à 06:35, Jo a écrit :
Depuis quelques mois nous avons enfin une façon de taguer les bus_bay. 
Pour les ajouter le chemin est également découpé deux fois. S'il se 
trouve sur le rond-point c'est une autre raison pour le découper.


Dire que c'est au rendu de dessiner les lignes de bus en partiel sur 
les rond-points, c'est facile. Néanmoins, ce n'est pas quelque chose 
qui sera implémenté dans un futur proche. Probablement jamais. Diviser 
les rond-points, c'est quelque chose qu'un mappeur peut faire 
facilement et ça ne heurte personne. Ça décrit très précisement les 
trajets des bus, surtout quand la même ligne emprunte le rond-point 
plusieurs fois, ou s'il n'emprunte pas certaines parties, parce qu'il 
y a des 'fourches' en oneway avant ou derrière.


Polyglot

2017-09-07 1:52 GMT+02:00 Philippe Verdy >:


Je le pense aussi. Un giratoire sur le tracé d'un ligne est très
aisément détectable même et surtout si c'est un way fermé. Si le
dessin du cercle est "gênant" en zoom avant, il suffit de le
considérer comme si ce n'était pas une ligne mais un disque,
assimilable à un point un peu plis gros en son centre. De plus un
bus peut encore être amené à faire plus que 1 tour s'il est gêné
pour sortir, cela ne remet pas en cause le trajet de la ligne.

C'est pareil pour les itinéraires routiers pour automobiles,
camions ou cyclistes, et même pour les piétons (s'il y a peur eux
un chemin permettant de passer par le centre d'un grand giratoire
en passant par des passages protégés, ce chemin sera marqué de
même que les connexions aux rues arrivant au rond point, et dans
ce cas le piéton n'utilisera pas le tracé circulaire du giratoire.

Dans tous les cas, on sait par où on y entre et par où en en sort.
Briser les giratoires ne sert pas à grand chose.

Je n'ai vus que quelques seul cas où ça peut être utile
- : si le giratoire passe emprunte des ponts au dessus d'autres
voies routières/ferrée/cyclistes ou un avec cours d'eau passant
dessous et évitant le giratoire. Le but étant alors de mettre des
attributs différents sur des sections du giratoire, notamment les
barrières de sécurité (mais on peut aussi représenter ces
barrières sur des chemins parallèles.) mais surtout les
l'attributs "layer" et "bridge=yes" (dont on peut pourtant se
passer en mettant le layer sur les voies qui traversent en dessous.
- Si le giratoire passe sous d'autres ponts il n'est jamais
nécessaire de le couper (ce sont ces ponts qu'on va découper
éventuellement)
- Si le giratoire passe dans des sections en tunnel (exemple en
Andorre) voire sous un bâtiment un "layer=-n" sera éventuellement
nécessaire mais on pourrait être gêné par le fait que ce layer
passe alors aussi en dessous des "landuse" environnants s'ils
englobent la surface du giratoire

Certains veulent découper les giratoires à ponts pour uniquement
le rendu (qui détoure les voies des ponts par un filet noir : à
mon avis ça se règle par une correction dans le moteur de rendu,
pour que ce filet ne vienne pas en surimpression des voies
connectées (comme si ce filet noir était des barrières barrant les
accès). On peut faire autrement en évitant "bridge=yes" sur ces
sections de giratoire, et mettant plutôt tunnel pour les voies en
dessous, et en ajoutant les barrières de sécurité de chaque côté
du pont. Dans ce cas plus besoin de "bridge" et "layer" sur le
giratoire".

Pour les assistants de navigation GPS, ils disent "entrez dans le
giratoire/rond-point, prenez la deuxième sortie" et ça suffit car
il n'y a pas d'autres chemins possibles et si celui qui ne connait
pas bien le coin rate la bonne sortie, il sait qu'il va devoir
faire le tour complet pour la retrouver et n'a pas besoin de
toucher à son GPS!

Il reste les rares cas de giratoires avec des feux temporaires
(fonctionnant en giratoire la plupart du temps quand les feux sont
éteints mais en carrefour avec des voies plus prioritaires qui les
traversent quand les feux sont allumés). Cela ne concerne que de
rares giratoires qui ont une voie centrale pour les transports en
commun