Re: [OSM-talk-fr] Calcul d'itinéraire avec OSRM - questionnement calcul

[Violaine_Do]

Merci pour les retours! J'ai fais un test sur un itinéraire plutôt 
rectiligne c'est pour ça que je comprends pas le calcul. Après je 
comprends les différences entre usage et limites max..


@Rodrigo, super intéressant et inspirant ton article!

Bonne soirée


On 15/03/2019 04:10, Rpnpif wrote:

Le 14 mars 2019, Violaine_Do a écrit :


Bonjour tout le monde,

Je me demandais comment améliorer le calcul d'itinéraire, avec OSRM (sur
osm.org) en fonction de conditions locales (cf profil voiture utilisé
sur OSM.org 1)

Pour le moment primary, secondary et tertiary ne montent par défaut pas
a plus de 65km/h, les exceptions rurales sont souvent au dessus.. (cf
wiki speed limits : 2, par exemple pour les routes rurales en france on
a comme tag maxspeed=80 + source:maxspeed=FR:rural) Donc avec maxspeed
on dépasse la vitesse par défaut du type de route tertiary, secondary,
primary. Mais pour avoir fait un petit test, je comprends pas le calcul,
par exemple avec un tronçon en particulier (3) : je ne trouve pas la
vitesse attendue (j'aimerais que le calcul prenne en compte la vitesse
rurale c'est à dire 80km/h plutôt que la vitesse du type de route
secondary qui est à 55km/h, information qui est présente sur ce
tronçon). Est-ce que c'est parce que primary/secondary/tertiary sont
prioritaires/contraignent le reste? (en gros faudrait il changer les
vitesses par defaut primary/secondary/tertiary pour permettre
l'utilisation des maxspeed?). J'espère que je suis assez compréhensible...

Sur une route à 80 km/h, on ne roule pas à 80 km/h en moyenne sauf si
on dépasse la vitesse légale, à cause des décélérations, etc. C'est
peut-être pourquoi la vitesse est calculée en dessous, peut-être 5 à 20% en 
dessous.


--
Violaine_Do


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

Re: [OSM-talk-fr] Quartiers à Paris

[althio]

marc marc :

De: "althio"
 > si quelqu'un veut supprimer le quartier administratif

c'est une caricature surement volontaire pour provoquer
les partisans de l'inverse mais cela n'a aucun sens.
[…]
c'est déjà parfois difficile de se comprendre sans 2ieme ou 3ieme degré,
alors évitons les :)


Vincent de Château-Thierry :


Donc le fait qu'une donnée n'aie "aucune existence de terrain" et/ou se
"retrouve en open data" serait une raison suffisante pour la saccager dans
OSM : renommage inconsidéré, suppression... Avec une logique pareille, […]


Effectivement, mea culpa, je retire ce que j'ai écrit.
J'aurais pu entourer ces passages avec des balises "ironie", "provocation"
ou "troll", ajouter des smileys… et au final j'aurais du m'abstenir tout
simplement.
En outre, la vérité est que je ne me moque pas tout à fait de ces données
de limites administratives.

Là où je suis rassuré, c'est qu'il y a du monde pour les défendre :)



D'un autre côté, des données ont été effacées pour de vrai, dans une autre
gamme de provocation, ont échauffé les esprits et font dépenser beaucoup
d'énergie dans ces discussions.
Je vais profiter du week-end pour souffler un bon coup ;)


En élargissant, je pense que tous les découpages ont leur place dans OSM :
administratifs, religieux, militaires, académiques et j'en passe, dès lors
qu'on dispose d'une source précise et compatible pour leur délimitation.


Un avis sur les quartiers qui n'ont pas de délimitation, sans source
précise ? C'est un des gros sujets de ce fil, et on demande l'avis de tout
le monde.

Bonne soirée et bon week-end à tout le monde.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] GogoCarto

[Cédric Frayssinet]

Le 15/03/2019 à 09:03, allegre.guilla...@free.fr a écrit :
> Le 14/03/2019 21:28, Cédric Frayssinet a écrit :
>> Bonsoir à tous,
>>
>> Le projet ne semble pas être passé par cette liste. Voici GogoCarto,
>> un chouette projet, très joli, un peu à la uMap, qui permet de faire
>> de jolies cartes : https://gogocarto.fr/projects
>
> Pour les gens qui connaissent déjà uMap, pourrais-tu donner succintement
> les principales différences ?

Je me suis posé la même question. Il y en a 1 évidente, c'est vraiment
plus joli :)

Vincent B. m'a répondu cela sur une autre liste :

/je n'ai pas encore assez exploré gogocarto pour faire une revue
complète. Cependant parmi les différences que je vois :/

//

  * /esthétique indéniable/
  * /un système de vote pour valider des ajouts de points/
  * /un sous domaine généré et non une adresse/

//

/Ce que je ne sais pas c'est :/

//

  * /quel volume de carte cela peut gérer (300 000 cartes umap sur les
serveurs osm-fr pour la seule instance umap.openstreetmap.fr)//
/
  * /les diverses interopérabilités (mais Sébastian, le dev, est très
favorable et attentif à cela)/


Cédric

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

Re: [OSM-talk-fr] schéma pour renseigner les découpages [était : Quartiers à Paris]

[Léo El Amri via Talk-fr]

On 15/03/2019 18:21, marc marc wrote:
> Le 15.03.19 à 17:34, Léo El Amri via Talk-fr a écrit :
>> Les aires sont définies <...> avec area=yes.
> 
> pas nécessairement.
> De nombreux objet définissent automatiquement une aire implicitement
> natural=wood landuse=* place=* building=* les relations polygone, etc
> Pas besoin par exemple de mettre building=yes area=yes parce qu'il 
> n'existe pas de building=yes area=no
> 
> area=yes s'ajoute uniquement sur les objets pouvant parfois décrire
> une ligne, parfois une aire :
> ex highway=footway, si le way est fermé, c'est un chemin qui fait une 
> boucle ou c'est une aire ? on considère par défaut que c'est une ligne 
> et on ajoute area=yes pour préciser quand c'est une aire.

Tu semblais dire que c'était un tag qui définissait si un objet était
une aire ou non. Je donnais l'exemple explicite de area=yes en précisant
que seuls les ways pouvaient être des area. ;)

On est sur la même longueur d'onde en fait.

>> catégoriser la relation, area ou node, par exemple:
>> "type_decoupage=admin" pour les infos tirées du cadastre
> 
> la façon actuelle de faire est :
> relation type=boundary bounary=administrative
> et source=cadastre sur le changeset
> 
>> ou "type_decoupage=usuel" pour les découpages "populaires"
>> (Les fameux quartiers de Paris).
> 
> place=* et source=local_knownledge ou survey sur le changeset selon que 
> c'est une connaissance ou vu sur le terrain

On pourrait donc étendre un peu les valeurs de `source`, et peut-être
rajouter un tag pour certaines précisions. Par exemple,
source=local_knowledge englobe les types "populaire" (Que j'ai décris
plus tôt) et "académique" (Décris superficiellement par Vincent de
Château-Thierry).

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

Re: [OSM-talk-fr] Quartiers à Paris

[osm . sanspourriel]

Souvent dans ce cas on peut utiliser un landuse=residential et le nommer.

Le 15/03/2019 à 17:34, Léo El Amri via Talk-fr - 
talk-fr@openstreetmap.org a écrit :

On 15/03/2019 16:59, marc marc wrote:

Le 15.03.19 à 16:29, Léo El Amri via Talk-fr a écrit :

catégoriser les découpages

je pense que la majorité existent déjà.

Par exemple pour le quartier de Paris,
le populaire (celui avec un place=*) ayant une limite
que personne ne semble contester, il peux facilement
être tagé comme une aire : c'est la seule façon de transformer
l'étendue bleue de l'image précédente en donnée osm.

sinon on arrive à un résultat incohérent : on dit que le quartier
populaire mérite d'être ajouté dans osm car différent du découpage
administratif du même nom, mais l'ajout dans osm ne montre pas cette
différence et mettre une note sur les 2 objets ne permet pas plus
"d'utiliser" cette différence.

Les aires sont définies par des ways fermés et tagués avec area=yes.

Techniquement, dans mon exemple, je souhaitais taguer les relations, ou
si il n'y en a pas, les area ou les nodes. L'idée est d'avoir un tag qui
permette de catégoriser la relation, area ou node, par exemple:
"type_decoupage=admin" pour les infos tirées du cadastre, la maire ou
que sais-je ou "type_decoupage=usuel" pour les découpages "populaires"
(Les fameux quartiers de Paris).

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

Re: [OSM-talk-fr] Tuiles cadatsre sans réponse sur JOSM

[osm . sanspourriel]

Tu le lances comment ?

Si c'est via le .jnlp, tu peux ajouter le paramètre dedans.

Si c'est via le jar, tu ajoutes l'argument indiqué en lançant la 
commande (typiquement dans un .bat sur PC, dans un .sh sur Linux).


Si c'est par un exécutable, tu te ramènes au cas précédent ;-). Il y a 
peut-être moyen de mettre l'argument si tu crées un raccourci.


Le 15/03/2019 à 17:37, Jérôme Seigneuret - jerome.seigneu...@gmail.com a 
écrit :

tu es sous quoi? windows linux mac?


Le ven. 15 mars 2019 à 15:20, Jozeph via Talk-fr 
mailto:talk-fr@openstreetmap.org>> a écrit :


Bonjour,

Oui je rencontre ce problème depuis hier avec le message :

"Erreur lors du chargement des tuiles :
javax.net.ssl.SSLProtocolException handshake alert: unrecognized_name"

Je ne sais pas introduire le paramètre supplémentaire dans le lancement de 
JOSM comme indiqué par Denis.

Que me conseillez-vous ?

Avec mes remerciements.

Joseph

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



--
Cordialement,
Jérôme Seigneuret

___
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] schéma pour renseigner les découpages [était : Quartiers à Paris]

[marc marc]

Le 15.03.19 à 17:34, Léo El Amri via Talk-fr a écrit :
> Les aires sont définies <...> avec area=yes.

pas nécessairement.
De nombreux objet définissent automatiquement une aire implicitement
natural=wood landuse=* place=* building=* les relations polygone, etc
Pas besoin par exemple de mettre building=yes area=yes parce qu'il 
n'existe pas de building=yes area=no

area=yes s'ajoute uniquement sur les objets pouvant parfois décrire
une ligne, parfois une aire :
ex highway=footway, si le way est fermé, c'est un chemin qui fait une 
boucle ou c'est une aire ? on considère par défaut que c'est une ligne 
et on ajoute area=yes pour préciser quand c'est une aire.

> catégoriser la relation, area ou node, par exemple:
> "type_decoupage=admin" pour les infos tirées du cadastre

la façon actuelle de faire est :
relation type=boundary bounary=administrative
et source=cadastre sur le changeset

> ou "type_decoupage=usuel" pour les découpages "populaires"
> (Les fameux quartiers de Paris).

place=* et source=local_knownledge ou survey sur le changeset selon que 
c'est une connaissance ou vu sur le terrain
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Places PMR ?

[PanierAvide]

Bonjour,

Pour info :

3. amenity=parking_space + disabled=* -> 524
4. amenity=parking_space + access:disabled=*  -> 1627

Donc effectivement les méthodes 1. ou 2. sont majoritaires, le 1 étant 
raccord avec la logique des amenity=parking, et le 2 avec la logique 
sémantique. Et d'accord pour que le wheelchair reste centré sur 
l'accessibilité physique de la place. Malgré que le 4 soit techniquement 
recommandé par le wiki, l'usage ne suit pas.


J'ai mis à jour la page wiki [1] pour indiquer l'état actuel des tags, 
mais ce serait bien qu'on fasse un peu de ménage sur les tags 
minoritaires pour que ce soit un peu moins le bazar :-) On part sur 
capacity:disabled=* ?


Cordialement,

Adrien.

[1] https://wiki.openstreetmap.org/wiki/FR:Handicaps/R%C3%A9f%C3%A9rentiel


Le 15/03/2019 à 17:56, Vincent Bergeot a écrit :

Bonjour,

bon du coup je boucle et je ne sais pas trop comment déboucler :)

Je parle ici seulement du tag amenity=parking_space pour 1 seule place 
de parking réservée pour des personnes à mobilité réduite (titulaire 
d'un macaron)


Plusieurs schémas (je mets de coté wheelchair qui va qualifier 
l'effectivité de l'accessibilité en fauteuil) et si on regarde les 
combinaisons : 
https://taginfo.openstreetmap.org/tags/amenity=parking_space#combinations


 1. amenity=parking_space + capacity:disabled=*-> un peu plus de 10
000 occurrence
 2. amenity=parking_space + parking_space=disabled -> un peu moins de
10 000 occurences
 3. amenity=parking_space + disabled=yes/designated -> ?
 4. amenity=parking_space + access:disabled=designated  -> ?
 5. amenity=parking_space + wheelchair -> 19500 avec 16000 yes

5 -> c'est l'effectivité de l'accessibilité en fauteuil donc à part.

3 et 4 pas beaucoup d'occurrences, du moins sur la page

1 et 2 assez proche

1 -> le tag capacity:disabled=* est plus adapté à un ensemble de 
places dont une partie capacity:disabled=*


2 -> "pas cohérent avec parking=surface/sous-terrain" mais une place 
de parking en souterrain ou silo fera partie d'un amenity=parking qui 
lui sera taggué parking=surface/sous-terrain -> je ne suis pas sur que 
les valeurs des clés parking et parking_space aient besoin d'être 
cohérentes.


Il est fait référence dans la page de proposition 
(https://wiki.openstreetmap.org/wiki/Proposed_features/parking#Parking_space) 
à la fois au place de parking pour le carpool, disabled, ...


Bon j'arrête, je ne suis pas sur d'avoir fini de boucler !!!

à vous lire !




Le 11/03/2019 à 11:30, PanierAvide a écrit :


Bonjour,

Le tag capacity=* sur amenity=parking_space est utilisable si 
l'emprise comporte plusieurs places. Mais le wiki précise aussi que 
les tags capacity:*=* ne sont pas utilisables sur les parking_space, 
qu'il faut plutôt utiliser access:*=*...


Donc à priori ce serait amenity=parking_space + access=no + 
access:disabled=designated + wheelchair=* (+ capacity=* si plusieurs 
places collées). Ça en fait des tags pour indiquer une place PMR ! 
Utiliser parking_space=disabled simplifierait la chose, ou pas si on 
se retrouve à devoir le combiner avec les "anciens" tags.


Cordialement,

Adrien P.
Le 11/03/2019 à 10:32, Vincent Bergeot a écrit :

Bonjour,
je reprends ce fil car la question me hante (au moins !!!)/

Dans le cas d'une *place individuelle de parking de type 
stationnement réservé pour les personnes handicapées ou à mobilité 
réduite* :


  * amenity=parking_space OK -> cela décrit 1 place
  * capacity:disabled=1 je ne comprends pas car on vient déjà de
dire que c'est 1 avec parking_space (puisque que cela décrit
justement une place), donc j'ai tendance à penser que c'est par
défaut capacity=1 et que dans le cas de amenity=parking_space
cela n'a pas de "sens" de définir des capacity
  * parking_space=disabled (effectivement peu renseigné sur le wiki
et utilisé surtout en europe),
  * wheelchair venant renseigner alors l'effectivité de
l'accessibilité en fauteuil

Ce que je ne vois pas c'est pourquoi parking_space=* ne serait pas 
plus utilisé (pour disabled mais sans doute aussi pour les places 
familles devant les supermarchés, les places réservées, carpool, 
comme d'ailleurs l'illustre la photo de la page wiki :

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space)

au plaisir de vous lire




Le 19/03/2018 à 11:06, PanierAvide a écrit :


Bonjour Marc et Jérôme,

Merci pour vos deux réponses, ça montre bien une divergence des 
pratiques :-) Effectivement l'ambiguïté de la représentation porte 
sur les places individuelles, le cas du décompte sur un parking 
global est pour le coup explicite avec capacity:disabled=*.


Malgré la confusion, de ce que je comprends, il y a quand même 
consensus sur les points suivants :


- wheelchair=yes indique l'accessibilité réelle sur le terrain de 
la place

- Il vaudrait mieux se baser des tags orientés access=*

Après je vois qu'il y a pléthore de valeurs possibles si on part 
sur la logique access. Pourquoi un combo amenity=parking_space 

Re: [OSM-talk-fr] Places PMR ?

[Vincent Bergeot]

Bonjour,

bon du coup je boucle et je ne sais pas trop comment déboucler :)

Je parle ici seulement du tag amenity=parking_space pour 1 seule place 
de parking réservée pour des personnes à mobilité réduite (titulaire 
d'un macaron)


Plusieurs schémas (je mets de coté wheelchair qui va qualifier 
l'effectivité de l'accessibilité en fauteuil) et si on regarde les 
combinaisons : 
https://taginfo.openstreetmap.org/tags/amenity=parking_space#combinations


1. amenity=parking_space + capacity:disabled=*-> un peu plus de 10 000
   occurrence
2. amenity=parking_space + parking_space=disabled -> un peu moins de 10
   000 occurences
3. amenity=parking_space + disabled=yes/designated -> ?
4. amenity=parking_space + access:disabled=designated  -> ?
5. amenity=parking_space + wheelchair -> 19500 avec 16000 yes

5 -> c'est l'effectivité de l'accessibilité en fauteuil donc à part.

3 et 4 pas beaucoup d'occurrences, du moins sur la page

1 et 2 assez proche

1 -> le tag capacity:disabled=* est plus adapté à un ensemble de places 
dont une partie capacity:disabled=*


2 -> "pas cohérent avec parking=surface/sous-terrain" mais une place de 
parking en souterrain ou silo fera partie d'un amenity=parking qui lui 
sera taggué parking=surface/sous-terrain -> je ne suis pas sur que les 
valeurs des clés parking et parking_space aient besoin d'être cohérentes.


Il est fait référence dans la page de proposition 
(https://wiki.openstreetmap.org/wiki/Proposed_features/parking#Parking_space) 
à la fois au place de parking pour le carpool, disabled, ...


Bon j'arrête, je ne suis pas sur d'avoir fini de boucler !!!

à vous lire !




Le 11/03/2019 à 11:30, PanierAvide a écrit :


Bonjour,

Le tag capacity=* sur amenity=parking_space est utilisable si 
l'emprise comporte plusieurs places. Mais le wiki précise aussi que 
les tags capacity:*=* ne sont pas utilisables sur les parking_space, 
qu'il faut plutôt utiliser access:*=*...


Donc à priori ce serait amenity=parking_space + access=no + 
access:disabled=designated + wheelchair=* (+ capacity=* si plusieurs 
places collées). Ça en fait des tags pour indiquer une place PMR ! 
Utiliser parking_space=disabled simplifierait la chose, ou pas si on 
se retrouve à devoir le combiner avec les "anciens" tags.


Cordialement,

Adrien P.
Le 11/03/2019 à 10:32, Vincent Bergeot a écrit :

Bonjour,
je reprends ce fil car la question me hante (au moins !!!)/

Dans le cas d'une *place individuelle de parking de type 
stationnement réservé pour les personnes handicapées ou à mobilité 
réduite* :


  * amenity=parking_space OK -> cela décrit 1 place
  * capacity:disabled=1 je ne comprends pas car on vient déjà de dire
que c'est 1 avec parking_space (puisque que cela décrit justement
une place), donc j'ai tendance à penser que c'est par défaut
capacity=1 et que dans le cas de amenity=parking_space cela n'a
pas de "sens" de définir des capacity
  * parking_space=disabled (effectivement peu renseigné sur le wiki
et utilisé surtout en europe),
  * wheelchair venant renseigner alors l'effectivité de
l'accessibilité en fauteuil

Ce que je ne vois pas c'est pourquoi parking_space=* ne serait pas 
plus utilisé (pour disabled mais sans doute aussi pour les places 
familles devant les supermarchés, les places réservées, carpool, 
comme d'ailleurs l'illustre la photo de la page wiki :

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dparking_space)

au plaisir de vous lire




Le 19/03/2018 à 11:06, PanierAvide a écrit :


Bonjour Marc et Jérôme,

Merci pour vos deux réponses, ça montre bien une divergence des 
pratiques :-) Effectivement l'ambiguïté de la représentation porte 
sur les places individuelles, le cas du décompte sur un parking 
global est pour le coup explicite avec capacity:disabled=*.


Malgré la confusion, de ce que je comprends, il y a quand même 
consensus sur les points suivants :


- wheelchair=yes indique l'accessibilité réelle sur le terrain de la 
place

- Il vaudrait mieux se baser des tags orientés access=*

Après je vois qu'il y a pléthore de valeurs possibles si on part sur 
la logique access. Pourquoi un combo amenity=parking_space + 
access=no + disabled=yes/designated ne serait-il pas suffisant (en 
ajoutant éventuellement du capacity:disabled pour un groupe de places) ?


Cordialement,

Adrien.


Le 19/03/2018 à 10:51, Jérôme Seigneuret a écrit :

salut,

En clair on utilise capacity:disabled=1 sur la zone de parking ou 
un espace.  Le truc c'est que si tu englobes les capacités sur la 
zone et sur la place c'est une double info et un double comptage. 
En clair,
si tu mixes les deux il faut enlever les espaces dans la zone 
général et les décompter. parking_space utilise la relation site 
pour regrouper les places d'un parking. C'est du micro mapping


Pour info, le stationnement avec la CMI n'est pas Franco-Français 
et les règles à établir sont Européenne. Donc si le sujet coince il 
faudra le remonter sur  osm-talk


Pour le reste ça se base sur 

[OSM-talk-fr] améliorer les panneaux entrée et sortie de ville

[Jérôme Seigneuret]

Salut,

J'aimerai améliorer les affichage pour les panneaux d'entrée et sortie de
ville.


voici un cas  sur le même panneaux
direction=310
highway=traffic_sign
name:2=Jouy-en-Josas (sortie)
name=Les Loges-en-Josas (entrée)
traffic_sign=city_limit

merci

Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Tuiles cadatsre sans réponse sur JOSM

[Jérôme Seigneuret]

tu es sous quoi? windows linux mac?


Le ven. 15 mars 2019 à 15:20, Jozeph via Talk-fr 
a écrit :

> Bonjour,
>
> Oui je rencontre ce problème depuis hier avec le message :
>
> "Erreur lors du chargement des tuiles :
> javax.net.ssl.SSLProtocolException handshake alert: unrecognized_name"
>
> Je ne sais pas introduire le paramètre supplémentaire dans le lancement de 
> JOSM comme indiqué par Denis.
>
> Que me conseillez-vous ?
>
> Avec mes remerciements.
>
> Joseph
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quartiers à Paris

[Léo El Amri via Talk-fr]

On 15/03/2019 16:59, marc marc wrote:
> Le 15.03.19 à 16:29, Léo El Amri via Talk-fr a écrit :
>> catégoriser les découpages
> 
> je pense que la majorité existent déjà.
> 
> Par exemple pour le quartier de Paris,
> le populaire (celui avec un place=*) ayant une limite
> que personne ne semble contester, il peux facilement
> être tagé comme une aire : c'est la seule façon de transformer
> l'étendue bleue de l'image précédente en donnée osm.
> 
> sinon on arrive à un résultat incohérent : on dit que le quartier 
> populaire mérite d'être ajouté dans osm car différent du découpage 
> administratif du même nom, mais l'ajout dans osm ne montre pas cette 
> différence et mettre une note sur les 2 objets ne permet pas plus
> "d'utiliser" cette différence.

Les aires sont définies par des ways fermés et tagués avec area=yes.

Techniquement, dans mon exemple, je souhaitais taguer les relations, ou
si il n'y en a pas, les area ou les nodes. L'idée est d'avoir un tag qui
permette de catégoriser la relation, area ou node, par exemple:
"type_decoupage=admin" pour les infos tirées du cadastre, la maire ou
que sais-je ou "type_decoupage=usuel" pour les découpages "populaires"
(Les fameux quartiers de Paris).

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

Re: [OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[Jérôme Seigneuret]

Marc, J'ai standardisé tous les nom de résidence ainsi. J'ai pas de
consenssus à ce niveau et c'est aussi le même problème pour les ZI, ZA, ZAC
...

 place=neighbourhood est trop aléatoire en niveau. Je l'ai utilisé et j'en
reviens. Problème de définition entre quartier et info en grande ville ou
village... après je suis d'accord sur le fait de changer en addr:place +
place=city_block ou residential

Le ven. 15 mars 2019 à 16:55, marc marc  a
écrit :

> de l'exemple de ton ticket, par ex
> https://www.openstreetmap.org/node/6332817525
> je pense qu'il est + correcte de changer
> addr:street="Résidence l'Orée de Marly" en addr:place
> et mettre un place=neighbourhood name=Résidence l'Orée de Marly.
> Dans certains autres cas place=city_block peux être + adapté.
>
> Le 15.03.19 à 16:19, Jérôme Seigneuret a écrit :
> > ok c'est fait
> >
> > Le ven. 15 mars 2019 à 14:16, Vincent de Château-Thierry
> > mailto:osm.v...@free.fr>> a écrit :
> >
> >
> >  > De: "Jérôme Seigneuret"  > >
> >  >
> >  > PS hors optique Lieudit tu as le même problème sur les gros
> complexes
> >  > résidentielle avec numéro voir numéro + Lettre, Numéro plus nom de
> >  > batiment et sans pour autant avoir un nm de rue. En région
> >  > parisienne je suis confronté régulièrement à ce problème. Certains
> >  > on patché ça en mettant le nom de la résidence sur la voirie et
> fait
> >  > de même sur les numéros d'adresse. Ducoup il y a pas mal de nom de
> >  > voie dans BANO avec lotissement * ou résidence * qui n'ont pas de
> >  > réelle existance.
> >  >
> >  > As tu pris ça en compte dans la V2?
> >
> > Je n'ai pas touché aux logiques métier dans la v2, c'est surtout une
> > version qui permet de mieux coller aux versions courantes de Fantoir
> > et Cadastre durablement, en profitant des publications sur
> > data.gouv.fr . Donc je ne pense pas que ça soit
> > plus géré qu'avant, mais je veux bien les exemples dont tu parles
> > histoire d'appréhender le sujet concrètement. Tu peux en indiquer
> > ici, ou directement créer un ticket =>
> > https://github.com/osm-fr/bano/issues/new
> >
> > merci
> > vincent
> >
> > ___
> > Talk-fr mailing list
> > Talk-fr@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-fr
> >
> >
> >
> > --
> > Cordialement,
> > Jérôme Seigneuret
> >
> > ___
> > 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
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quartiers à Paris

[marc marc]

De: "althio" 
 > si quelqu'un veut supprimer le quartier administratif

c'est une caricature surement volontaire pour provoquer
les partisans de l'inverse mais cela n'a aucun sens.
on supprime toutes les addr des villes oü tu ne vas pas ?
elle sont dispo en opendata après tout.
c'est déjà parfois difficile de se comprendre sans 2ieme ou 3ieme degré,
alors évitons les :)

Le 15.03.19 à 16:29, Léo El Amri via Talk-fr a écrit :
> catégoriser les découpages

je pense que la majorité existent déjà.

Par exemple pour le quartier de Paris,
le populaire (celui avec un place=*) ayant une limite
que personne ne semble contester, il peux facilement
être tagé comme une aire : c'est la seule façon de transformer
l'étendue bleue de l'image précédente en donnée osm.

sinon on arrive à un résultat incohérent : on dit que le quartier 
populaire mérite d'être ajouté dans osm car différent du découpage 
administratif du même nom, mais l'ajout dans osm ne montre pas cette 
différence et mettre une note sur les 2 objets ne permet pas plus
"d'utiliser" cette différence.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[marc marc]

de l'exemple de ton ticket, par ex
https://www.openstreetmap.org/node/6332817525
je pense qu'il est + correcte de changer
addr:street="Résidence l'Orée de Marly" en addr:place
et mettre un place=neighbourhood name=Résidence l'Orée de Marly.
Dans certains autres cas place=city_block peux être + adapté.

Le 15.03.19 à 16:19, Jérôme Seigneuret a écrit :
> ok c'est fait
> 
> Le ven. 15 mars 2019 à 14:16, Vincent de Château-Thierry 
> mailto:osm.v...@free.fr>> a écrit :
> 
> 
>  > De: "Jérôme Seigneuret"  >
>  >
>  > PS hors optique Lieudit tu as le même problème sur les gros complexes
>  > résidentielle avec numéro voir numéro + Lettre, Numéro plus nom de
>  > batiment et sans pour autant avoir un nm de rue. En région
>  > parisienne je suis confronté régulièrement à ce problème. Certains
>  > on patché ça en mettant le nom de la résidence sur la voirie et fait
>  > de même sur les numéros d'adresse. Ducoup il y a pas mal de nom de
>  > voie dans BANO avec lotissement * ou résidence * qui n'ont pas de
>  > réelle existance.
>  >
>  > As tu pris ça en compte dans la V2?
> 
> Je n'ai pas touché aux logiques métier dans la v2, c'est surtout une
> version qui permet de mieux coller aux versions courantes de Fantoir
> et Cadastre durablement, en profitant des publications sur
> data.gouv.fr . Donc je ne pense pas que ça soit
> plus géré qu'avant, mais je veux bien les exemples dont tu parles
> histoire d'appréhender le sujet concrètement. Tu peux en indiquer
> ici, ou directement créer un ticket =>
> https://github.com/osm-fr/bano/issues/new
> 
> merci
> vincent
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> -- 
> Cordialement,
> Jérôme Seigneuret
> 
> ___
> 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] Création de communes nouvelles

[Donat ROBAUX]

Bonjour,

Un arrêté du 8 mars 2019 porte création de 20 communes nouvelles au 1er
janvier 2019.
https://www.service-public.fr/particuliers/actualites/A13282

Je crois qu'on aura pas fait pire dans le WTF administratif. Les arrêtés
préfectoraux ont bien été pris en 2018 pour un démarrage au 1er janvier et
donc intégrés dans OSM par Christian avec sa moulinette. Mais la
publication au JO date du 8 mars!
Je n'ai pas regardé si elles y étaient toutes.

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

Re: [OSM-talk-fr] [vélo] Introduction d'un tag complexe pour décrire les DSC sur bande dans le wiki

[Phyks]

Salut,

> En tant que structuraliste opposite_* est intolérable.

Il y a un certain nombre de cas comme ça d'ailleurs sur les attributs
vélos. J'ai en tête par exemple aussi le `bicycle_parking` dont la
variante `motorcycle_parking` n'existe pas. On se retrouve donc avec des
`amenity=motorcycle_parking` et `bicycle_parking=stands` qui ne sont
absolument pas ouverts ou prévus pour des vélos.


> Dans tous les cas, aujourd'hui je ne ressens aucun besoin de changer le
> schéma opposite_*

Idem, je vois un petit intérêt à utiliser l'alternative avec
`cycleway:*:oneway`, mais cela ne vaut probablement pas de casser tout
l'écosystème basé sur le schéma actuel à mon avis (déjà que tous les
outils ne supportent pas les cycleway:left/right proprement…).



Il y avait récemment eu une discussion sur des différences entre la
version anglaise et française de la page "Bicycle" du wiki il me semble
(sur talk-fr, sur un autre cas, mais je ne le retrouve plus :/).

-- 
Phyks


> Le mer. 13 mars 2019 à 22:11, Charles MILLET  a
> écrit :
> 
>> Dans l'absolu sa proposition tient la route. C'est juste que c'est un peu
>> lourd et que dans la pratique le opposite_lane est bien utilisé et
>> parfaitement interprétable.
>>
>> Et comme le dis marc c'est pas la bonne pratique, même quand on est
>> convaincu qu'on a raison... parce qu'on est nombreux à être convaincu
>> d'avoir raison :D
>>
>> J'avais vu ta position sur la distinction entre le sens et l'infra et
>> effectivement vous tombé plutôt d'accord. J'avais la même position il y a
>> quelques années... et puis j'ai laissé tombé :) et en fait j'ai admis que
>> la clé cycleway c'est qu'une clé et du moment qu'on est d'accord sur ce que
>> signifient les tags qui l'utilisent et bien on peut renoncer un peu à cette
>> logique. Donc vois si tu veux rester sur cette position mais dis toi que si
>> elle n'est pas adoptée ça n'aura pas trop d'influence... on en reparle
>> peut-être de vive voix bientôt ? ;)
>>
>> Pour l'instant j'essaie de prendre un peu le pouls sur cette approche du
>> DSC puisque les calculateurs ne l'utilisent pas je pense alors que les
>> cycleway:left/right=opposite_* sont plutôt admis (il me semble qu'au moins
>> BRouter et Geovelo les prennent en compte mais je pense que d'autres le
>> font).
>> On 13/03/2019 21:14, Florimond Berthoux wrote:
>>
>> Bonsoir,
>>
>> Et par ici aussi
>> https://wiki.openstreetmap.org/w/index.php?title=Tag%3Acycleway%3Dopposite_lane=revision=1820887=1639352
>> mais pas ici
>> https://wiki.openstreetmap.org/wiki/Key:cycleway#Dedicated_cycle_lanes
>> Je trouve la communauté particulièrement coulante vis-à-vis de ce genre de
>> modification unipersonnelle.
>>
>> Après je comprend tout à fait son point de vue : la signification d'un tag
>> devrait être la plus simple possible et ne pas comporter deux
>> significations comme avec opposite_lane (sens et infrastructure).
>>
>>
>> Le mer. 13 mars 2019 à 15:04, Charles MILLET  a
>> écrit :
>>
>>> Bonjour à tous
>>>
>>> Un contributeur a mis à jour la page wiki concernant la manière de
>>> décrire les doubles sens cyclables sur bande :
>>>
>>>
>>> https://wiki.openstreetmap.org/w/index.php?title=FR:Bicycle=next=1780997
>>>
>>> Pour résumer, il a supprimé les cycleway:left/richt=opposite_lane car
>>> cette valeur n'est pas documentée dans les valeurs des clé
>>> cycleway:left/richt (même si elle l'est pour la clé cycleway)
>>>
>>> Il recommande donc :
>>>
>>> highway=* + oneway=yes + cycleway:left=lane + cycleway:left:oneway=-1
>>>
>>> plutôt que
>>>
>>> highway=* + oneway=yes + cycleway:left=opposite_lane
>>>
>>> :'(
>>>
>>> Je lui ai envoyé un message pour lui exprimé avec politesse que je pense
>>> qu'il vaudrait mieux admettre ou officialiser
>>> cycleway:left=opposite_lane mais je m'attend que ce type de contribution
>>> traduise une volonté de respecter rigoureusement le wiki...
>>>
>>> Je m'adresse à la liste pour avoir votre avis au regard de l'usage qu'on
>>> peut observer sur taginfo et quelle serait la démarche pour revoir cette
>>> modification et dans l'idéal valider dans les règles les tags
>>> cycleway:left/right=opposite_lane
>>>
>>> Bonne journée
>>>
>>> Charles
>>>
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>
>>
>> --
>> Florimond Berthoux
>>
>> ___
>> Talk-fr mailing 
>> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
> 
> 
> -- 
> Florimond Berthoux
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 



___
Talk-fr mailing list
Talk-fr@openstreetmap.org

Re: [OSM-talk-fr] Quartiers à Paris

[Léo El Amri via Talk-fr]

On 15/03/2019 15:46, Vincent de Château-Thierry wrote:
> En élargissant, je pense que tous les découpages ont leur place dans OSM : 
> administratifs, religieux, militaires, académiques et j'en passe, dès lors 
> qu'on dispose d'une source précise et compatible pour leur délimitation. Ils 
> sont une formidable porte d'entrée pour nombre de consommateurs des données 
> OSM, notamment pour de la cartographie statistique, mais sûrement pas que. 
> Alors évitons de données des idées contre-productives en suggérant la 
> dégradation voire la suppression de certains d'entre eux.

Je suis tout à fait d'accord, et je trouve que ça réconcilie par mal
d'avis "contraires" qui ont été évoqués au sujet de la délimitation des
quartiers (De Paris et d'ailleurs) et des bordures de la Bretagne sur
cette mailing-list.

Nous ne devrions pas élire et se reposer sur un seul découpage. Et on
peut se permettre de créer des tags pour catégoriser les découpages pour
OSM en France (À implémenter, voter et documenter dans ce cas).

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

Re: [OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[Jérôme Seigneuret]

ok c'est fait

Le ven. 15 mars 2019 à 14:16, Vincent de Château-Thierry 
a écrit :

>
> > De: "Jérôme Seigneuret" 
> >
> > PS hors optique Lieudit tu as le même problème sur les gros complexes
> > résidentielle avec numéro voir numéro + Lettre, Numéro plus nom de
> > batiment et sans pour autant avoir un nm de rue. En région
> > parisienne je suis confronté régulièrement à ce problème. Certains
> > on patché ça en mettant le nom de la résidence sur la voirie et fait
> > de même sur les numéros d'adresse. Ducoup il y a pas mal de nom de
> > voie dans BANO avec lotissement * ou résidence * qui n'ont pas de
> > réelle existance.
> >
> > As tu pris ça en compte dans la V2?
>
> Je n'ai pas touché aux logiques métier dans la v2, c'est surtout une
> version qui permet de mieux coller aux versions courantes de Fantoir et
> Cadastre durablement, en profitant des publications sur data.gouv.fr.
> Donc je ne pense pas que ça soit plus géré qu'avant, mais je veux bien les
> exemples dont tu parles histoire d'appréhender le sujet concrètement. Tu
> peux en indiquer ici, ou directement créer un ticket =>
> https://github.com/osm-fr/bano/issues/new
>
> merci
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quartiers à Paris

[Vincent de Château-Thierry]

> De: "althio" 
> 
> Et si quelqu'un veut renommer le quartier administratif de la
> Goutte-d'Or en :
> name=Quartier administratif de la Goutte-d'Or
> ou name=71e quartier administratif
> ou name=administratif_police_7511871
> Franchement... ça ne me dérange pas, ce truc n'a aucune existence de
> terrain.

> Et si quelqu'un veut supprimer le quartier administratif parce que
> [insérer ici une raison quelconque]... je dis "pourquoi pas", de
> toute façon c'est de la donnée de référence, on la retrouve en open
> data.

Donc le fait qu'une donnée n'aie "aucune existence de terrain" et/ou se 
"retrouve en open data" serait une raison suffisante pour la saccager dans OSM 
: renommage inconsidéré, suppression... Avec une logique pareille, j'ai peur 
pour la préservation des limites administratives (communales mais pas que, 
après tout) dans OSM. C'est vrai : aucune existence de terrain, et dispo en 
open data.

Est-ce qu'on peut arrêter ces divagations ?

Les limites administratives sont une des pépites d'OSM en France : une couche 
complète depuis fin 2013, un vrai travail collaboratif, une donnée à jour avant 
toutes les données concurrentes grâce à la maintenance impulsée à chaque fin 
d'année civile pour appréhender les fusions de communes et autres mouvements. 
Bref, une vraie valeur ajoutée dont on devrait être collectivement fiers.

En élargissant, je pense que tous les découpages ont leur place dans OSM : 
administratifs, religieux, militaires, académiques et j'en passe, dès lors 
qu'on dispose d'une source précise et compatible pour leur délimitation. Ils 
sont une formidable porte d'entrée pour nombre de consommateurs des données 
OSM, notamment pour de la cartographie statistique, mais sûrement pas que. 
Alors évitons de données des idées contre-productives en suggérant la 
dégradation voire la suppression de certains d'entre eux.

Plus généralement, je voudrais insister sur un point pas assez souvent rappelé 
: ça n'est pas parce qu'à titre individuel on n'a pas connaissance de la 
réutilisation d'une donnée que celle-ci n'est pas utile à d'autres. Le 
périmètre "rendu Mapnik / OSMAnd / OSRM / Geovelo" (pour faire un peu court) 
est loin de représenter tout ce qui peut bien se fabriquer à partir de données 
OSM. Ne réduisons pas les réutilisations possibles, potentielles, aux seules 
réutilisations connues, populaires. Notre méconnaissance de ce que font 
certains avec les données que nous produisons devrait nous inciter à la 
prudence et à la modération, pas aux suggestions bravaches de modifications 
inconsidérées.

merci
vincent

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

Re: [OSM-talk-fr] Tuiles cadatsre sans réponse sur JOSM

[Jozeph via Talk-fr]

Bonjour,

Oui je rencontre ce problème depuis hier avec le message :

"Erreur lors du chargement des tuiles :
javax.net.ssl.SSLProtocolException handshake alert: unrecognized_name"

Je ne sais pas introduire le paramètre supplémentaire dans le lancement de JOSM 
comme indiqué par Denis.

Que me conseillez-vous ?

Avec mes remerciements.

Joseph

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

Re: [OSM-talk-fr] Calcul d'itinéraire avec OSRM - questionnement calcul

[Rpnpif]

Le 14 mars 2019, Violaine_Do a écrit :

> Bonjour tout le monde,
> 
> Je me demandais comment améliorer le calcul d'itinéraire, avec OSRM (sur 
> osm.org) en fonction de conditions locales (cf profil voiture utilisé 
> sur OSM.org 1)
> 
> Pour le moment primary, secondary et tertiary ne montent par défaut pas 
> a plus de 65km/h, les exceptions rurales sont souvent au dessus.. (cf 
> wiki speed limits : 2, par exemple pour les routes rurales en france on 
> a comme tag maxspeed=80 + source:maxspeed=FR:rural) Donc avec maxspeed 
> on dépasse la vitesse par défaut du type de route tertiary, secondary, 
> primary. Mais pour avoir fait un petit test, je comprends pas le calcul, 
> par exemple avec un tronçon en particulier (3) : je ne trouve pas la 
> vitesse attendue (j'aimerais que le calcul prenne en compte la vitesse 
> rurale c'est à dire 80km/h plutôt que la vitesse du type de route 
> secondary qui est à 55km/h, information qui est présente sur ce 
> tronçon). Est-ce que c'est parce que primary/secondary/tertiary sont 
> prioritaires/contraignent le reste? (en gros faudrait il changer les 
> vitesses par defaut primary/secondary/tertiary pour permettre 
> l'utilisation des maxspeed?). J'espère que je suis assez compréhensible...

Sur une route à 80 km/h, on ne roule pas à 80 km/h en moyenne sauf si
on dépasse la vitesse légale, à cause des décélérations, etc. C'est
peut-être pourquoi la vitesse est calculée en dessous, peut-être 5 à 20% en 
dessous.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Quartiers à Paris

[althio]

> En représentation cela donne ceci aujourd'hui
https://overpass-turbo.eu/s/GZD

Je trouve cette représentation utile et la richesse des données géniale.
Elle me donne envie de vérifier ou d'ajouter d'autres quartiers, mais pas
d'en supprimer.
Je ne vois aucun doublon.

Et si quelqu'un veut renommer le quartier administratif de la Goutte-d'Or
en :
name=Quartier administratif de la Goutte-d'Or
ou name=71e quartier administratif
ou name=administratif_police_7511871
Franchement... ça ne me dérange pas, ce truc n'a aucune existence de
terrain.
On pourrait aussi faire des articles et des identifiants wikidata
différents pour le "quartier administratif de la Goutte-d'Or" et le
"quartier de la Goutte-d'Or", ce n'est pas la même chose. Vraiment.
Je répète : ce n'est pas la même chose.
Et si quelqu'un veut supprimer le quartier administratif parce que [insérer
ici une raison quelconque]... je dis "pourquoi pas", de toute façon c'est
de la donnée de référence, on la retrouve en open data.

Par contre, si quelqu'un commence à supprimer des quartiers (au sens
commun), des noeuds place=*, ça ne va pas.
On bascule dans la destruction de données de réel contributeur, de terrain,
ou de connaissance locale.
Une donnée qu'il est difficile de trouver (un peu sur wikipedia) mais
surtout présente dans la mémoire collective.

> La page wikipédia
https://fr.wikipedia.org/wiki/Quartier_de_la_Goutte-d%27Or ne m'aide pas
plus.

Même pas cet extrait ?
> Historiquement, et dans le langage courant, « la Goutte d'Or » fait
généralement référence au sud-ouest du quartier administratif, autour de la
rue de la Goutte-d'Or, entre le boulevard Barbès et les voies ferrées.

Et si on reste sur wikipedia, on a beaucoup de choses à lire...

Par exemple le quartier d'à côté :
https://fr.wikipedia.org/wiki/Ch%C3%A2teau_Rouge_(quartier_de_Paris)
> Château Rouge est un quartier de Paris [...]. De nature informelle, il
fait partie des quartiers administratifs de la Goutte d'Or et de
Clignancourt.

Donc dans le quartier administratif de la Goutte-d'Or, on trouve le
quartier (non-administratif) de la Goutte-d'Or et une partie du quartier
(non-administratif) de Château Rouge.

Sur un autre quartier encore, Batignolles, on trouve la distinction
quartier administratif et quartier (non-administratif)
https://fr.wikipedia.org/wiki/Quartier_des_Batignolles
> Le quartier administratif des Batignolles est délimité [... définition de
l'étendue]
> Aujourd'hui les Batignolles apparaissent souvent comme [... étendue
significativement différente]

Un autre quartier, aucun lien direct avec un quartier administratif :
https://fr.wikipedia.org/wiki/Faubourg_Saint-M%C3%A9dard
> Le faubourg Saint-Médard ou "quartier Mouffetard" est un quartier de
Paris dans le 5e à cheval sur les quartiers administratifs Jardin des
Plantes et Val-de-Grâce.
idem pour le Marais
https://fr.wikipedia.org/wiki/Le_Marais_(quartier_parisien) et
https://fr.wikipedia.org/wiki/Quartier_du_Temple
> Le Marais est un quartier parisien historique (et non pas quartier
administratif)
idem pour https://fr.wikipedia.org/wiki/Quartier_latin_(Paris)
idem pour https://fr.wikipedia.org/wiki/Olympiades_(quartier_parisien)

Pour certains arrondissements, le travail de détails des quartiers est
avancé :
https://fr.wikipedia.org/wiki/13e_arrondissement_de_Paris#Quartiers
https://fr.wikipedia.org/wiki/12e_arrondissement_de_Paris#Quartiers

Toujours sur wikipedia, un article plus général
https://fr.wikipedia.org/wiki/Quartier_de_Paris
> la notion de quartier prend plusieurs significations à Paris :
> dans le langage courant, un quartier désigne un espace urbain pourvu
d'une identité commune sur le plan architectural, social, fonctionnel mais
délimité sans précision : le quartier latin, le Marais, le quartier
asiatique [...].
> dans le champ administratif, chacun des vingt arrondissements est découpé
en quatre quartiers.
> enfin, la mise en place des conseils de quartier s'est basée sur un
nouveau découpage de l'espace parisien en 121 quartiers
[carte des conseils de quartier, pour consultation :
https://www.apur.org/sites/default/files/documents/54.pdf si quelqu'un veut
s'amuser à superposer quartier administratif de la Goutte-d'Or et
périmètres des conseils de quartiers sur la zone...]
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quartiers à Paris

[Romain MEHUT]

Ok je comprends mieux et je pense que ça vaudrait le coup d'ajouter un tag
note sur les nœuds pour expliquer la distinction avec les polygones.

Romain

Le jeu. 14 mars 2019 à 21:46, Florimond Berthoux <
florimond.berth...@gmail.com> a écrit :

>
> Voici en orange le périmètre du quartier administratif nommé la Goutte
> d'Or,
> en bleu le quartier usuel (limite floue) :
> https://imgur.com/WxrNrtw
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Quartiers

[Léo El Amri via Talk-fr]

On 15/03/2019 13:58, Rpnpif wrote:
> Le 14 mars 2019, marc marc a écrit :
>> Le 14.03.19 à 09:47, Rpnpif a écrit :
>>> Et quand une commune, assemblage de villages, devient une « place » dans
>>> le sens où son nom est utilisé dans la vie quotidienne des habitants
>>> comme un lieu géographique de vie (par exemple, un livreur veut un
>>> emplacement pour la nouvelle commune sachant que l'admin_center n'a
>>> pas le même nom), que fait-on ?  
>>
>> je comprend pas le problème.
>> si une commune A est un assemblage des villages B (l'admin_center) C D,
>> Rien n’empêche le livreur de chercher A.
>>
>> PS: j'ai la naïve impression que le livreur va plutôt chercher no,rue, 
>> village plut'ot que le nom de la commune :)
> 
> Parce que le niveau commune (nouvelle) est souvent mal géré par les
> applications clientes.
> 
> Le livreur ne cherchera pas le nom du village (ancienne commune) parce
> que de plus en plus il est absent des adresses.
> 
> Alors que l'on devrait avoir sur les adresses :
> N° rue (ou lieu-dit)
> Village (ancienne commune)
> Commune (nouvelle)
> 
> Les adresses comportent plus souvent :
> N° rue (ou lieu-dit)
> Commune (nouvelle)
> 
> De plus, comme il y a encore souvent des lieux-dits homonymes entre les
> anciennes communes d'une même commune nouvelle, bonjour le jeu de piste.

Personnellement je n'ai eu des problème de livraison qu'en ville, et
jamais en rase campagne altiligérienne, alors qu'on a pourtant le même
nom de village (Lieu-dit) dans deux communes qui portent quasiment le
même nom et qui ont le même code postal...

On a une norme pour les addresses assez potable en france. Et le N° rue
(ou lieu-dit) + Commune (nouvelle) est sensé être compatible.

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

Re: [OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[Vincent de Château-Thierry]

> De: "Jérôme Seigneuret" 
> 
> PS hors optique Lieudit tu as le même problème sur les gros complexes
> résidentielle avec numéro voir numéro + Lettre, Numéro plus nom de
> batiment et sans pour autant avoir un nm de rue. En région
> parisienne je suis confronté régulièrement à ce problème. Certains
> on patché ça en mettant le nom de la résidence sur la voirie et fait
> de même sur les numéros d'adresse. Ducoup il y a pas mal de nom de
> voie dans BANO avec lotissement * ou résidence * qui n'ont pas de
> réelle existance.
> 
> As tu pris ça en compte dans la V2?

Je n'ai pas touché aux logiques métier dans la v2, c'est surtout une version 
qui permet de mieux coller aux versions courantes de Fantoir et Cadastre 
durablement, en profitant des publications sur data.gouv.fr. Donc je ne pense 
pas que ça soit plus géré qu'avant, mais je veux bien les exemples dont tu 
parles histoire d'appréhender le sujet concrètement. Tu peux en indiquer ici, 
ou directement créer un ticket => https://github.com/osm-fr/bano/issues/new

merci
vincent

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

Re: [OSM-talk-fr] Quartiers

[Rpnpif]

Le 14 mars 2019, marc marc a écrit :

> Le 14.03.19 à 09:47, Rpnpif a écrit :
> > Et quand une commune, assemblage de villages, devient une « place » dans
> > le sens où son nom est utilisé dans la vie quotidienne des habitants
> > comme un lieu géographique de vie (par exemple, un livreur veut un
> > emplacement pour la nouvelle commune sachant que l'admin_center n'a
> > pas le même nom), que fait-on ?  
> 
> je comprend pas le problème.
> si une commune A est un assemblage des villages B (l'admin_center) C D,
> Rien n’empêche le livreur de chercher A.
> 
> PS: j'ai la naïve impression que le livreur va plutôt chercher no,rue, 
> village plut'ot que le nom de la commune :)

Parce que le niveau commune (nouvelle) est souvent mal géré par les
applications clientes.

Le livreur ne cherchera pas le nom du village (ancienne commune) parce
que de plus en plus il est absent des adresses.

Alors que l'on devrait avoir sur les adresses :
N° rue (ou lieu-dit)
Village (ancienne commune)
Commune (nouvelle)

Les adresses comportent plus souvent :
N° rue (ou lieu-dit)
Commune (nouvelle)

De plus, comme il y a encore souvent des lieux-dits homonymes entre les
anciennes communes d'une même commune nouvelle, bonjour le jeu de piste.

-- 
Alain Rpnpif

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

Re: [OSM-talk-fr] Calcul d'itinéraire avec OSRM - questionnement calcul

[Frédéric Rodrigo]

Le 15/03/2019 à 00:53, Violaine_Do a écrit :

Bonjour tout le monde,

Je me demandais comment améliorer le calcul d'itinéraire, avec OSRM 
(sur osm.org) en fonction de conditions locales (cf profil voiture 
utilisé sur OSM.org 1)


Pour le moment primary, secondary et tertiary ne montent par défaut 
pas a plus de 65km/h, les exceptions rurales sont souvent au dessus.. 
(cf wiki speed limits : 2, par exemple pour les routes rurales en 
france on a comme tag maxspeed=80 + source:maxspeed=FR:rural) Donc 
avec maxspeed on dépasse la vitesse par défaut du type de route 
tertiary, secondary, primary. Mais pour avoir fait un petit test, je 
comprends pas le calcul, par exemple avec un tronçon en particulier 
(3) : je ne trouve pas la vitesse attendue (j'aimerais que le calcul 
prenne en compte la vitesse rurale c'est à dire 80km/h plutôt que la 
vitesse du type de route secondary qui est à 55km/h, information qui 
est présente sur ce tronçon). Est-ce que c'est parce que 
primary/secondary/tertiary sont prioritaires/contraignent le reste? 
(en gros faudrait il changer les vitesses par defaut 
primary/secondary/tertiary pour permettre l'utilisation des 
maxspeed?). J'espère que je suis assez compréhensible...


Bonne soirée/journée,

Violaine

1: 
https://github.com/fossgis-routing-server/cbf-routing-profiles/blob/master/car.lua 



2:https://wiki.openstreetmap.org/wiki/Speed_limits

3: 
https://www.openstreetmap.org/directions?engine=fossgis_osrm_car=49.6435%2C3.3967%3B49.6206%2C3.4528#map=14/49.6343/3.4309 





OSRM ne va jamais te proposer de rouler à maxpseed. La vitesse retourné 
par OSRM est une vitesse moyenne de parcours. Sur un tronçon en ligne 
droite de nationale, tu va rouler à maxspeed, mais ça ne va pas être le 
cas pour un vrais trajet en prenant en compte un vitesse plus moyenne.


Ensuite OSRM n'est pas pas capable tout seule de faire la distinction 
entre zone urbaine et rurale. Même en utilisant les bons types de voies 
et bon maxspeed. On ne va pas rouler à la même vitesse moyenne en ville 
ou à la campagne pour une même limitation à 50km/h par ex.


Pour répondre à ce problème j'avais fait une modif du profil d'OSMR, 
mais en utilisant des données externes pour avoir un contexte urbain / 
non urbain :


https://github.com/Project-OSRM/osrm-profiles-contrib/tree/master/5/18/urban-density

https://www.mapotempo.com/calcul-itineraire-densite-urbaine-mapotempo-web/


Frédéric.



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

Re: [OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[Jérôme Seigneuret]

OK,

Bon dans tous les cas c'est fait pour les adresses de l'aérodrome il me
manque en effet l'ajout du fantoir car c'est aussi connu sous le nom
d'aéroport ( les panneaux affiche ça...)

Dans tous les cas Merci

PS hors optique Lieudit tu as le même problème sur les gros complexes
résidentielle avec numéro voir numéro + Lettre, Numéro plus nom de batiment
et sans pour autant avoir un nm de rue. En région parisienne je suis
confronté régulièrement à ce problème. Certains on patché ça en mettant le
nom de la résidence sur la voirie et fait de même sur les numéros
d'adresse. Ducoup il y a pas mal de nom de voie dans BANO avec lotissement
* ou résidence * qui n'ont pas de réelle existance.

As tu pris ça en compte dans la V2?

Merci

Le ven. 15 mars 2019 à 11:17, Vincent de Château-Thierry 
a écrit :

> Bonjour,
>
> > De: "Jérôme Seigneuret" 
> > Le jeu. 14 mars 2019 à 23:21, marc marc < marc_marc_...@hotmail.com >
> > a écrit :
> >
> >
> > Le 14.03.19 à 23:13, Jérôme Seigneuret a écrit :
> >
> > > définir des adresses dans un aéroport ou un aérodrome?
> >
> > si l'adresse n'as pas de nom de rue,
> > c'est addr:place qu'il convient d'utiliser
> > https://wiki.openstreetmap.org/wiki/Key:addr
> >
> > > J'ai des adresses mais ça match pas avec nomminatim et ça remonte
> > > pas
> > > correctement dans BANO.
> > >
> https://www.openstreetmap.org/#map=20/48.74816937651511/2.117237893582972
> >
> > un no sans rue/lieu ne peux à mon avis pas matcher.
> > nominatime gère addr:palce
> > aucune idée pour bano
>
> Pour BANO si le but est de dégommer le nom en rouge "Aerodrome Toussus le
> Noble" alors il suffit d'ajouter son code Fantoir sur l'aerodrome lui-même
> : https://www.openstreetmap.org/way/236395648
> Dans le cadastre je vois 42 adresses dont le nom de voie est "Aerodrome
> Toussus le Noble". Pour celles-ci en effet ça aurait du sens de modéliser
> avec addr:place="Aerodrome Toussus le Noble", mais indépendamment de BANO
> qui pour l'instant ne tient pas compte de ce tag. Ca a été évoqué ici :
> https://github.com/osm-fr/bano/issues/50 mais dans une optique lieu-dit,
> alors qu'on parle d'adresse numérotée pour l'aérodrome. Ca devrait faire
> l'objet d'un autre ticket, dont acte :
> https://github.com/osm-fr/bano/issues/149. Pas sûr que ça sorte avec la
> v2 de BANO qui apparaîtra dans quelques semaines mais au moins c'est tracé.
>
> vincent
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>


-- 
Cordialement,
Jérôme Seigneuret
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] adressage dans les zones sans nom de voie - exemple un aérodrome

[Vincent de Château-Thierry]

Bonjour,

> De: "Jérôme Seigneuret" 
> Le jeu. 14 mars 2019 à 23:21, marc marc < marc_marc_...@hotmail.com >
> a écrit :
> 
> 
> Le 14.03.19 à 23:13, Jérôme Seigneuret a écrit :
> 
> > définir des adresses dans un aéroport ou un aérodrome?
> 
> si l'adresse n'as pas de nom de rue,
> c'est addr:place qu'il convient d'utiliser
> https://wiki.openstreetmap.org/wiki/Key:addr
> 
> > J'ai des adresses mais ça match pas avec nomminatim et ça remonte
> > pas
> > correctement dans BANO.
> > https://www.openstreetmap.org/#map=20/48.74816937651511/2.117237893582972
> 
> un no sans rue/lieu ne peux à mon avis pas matcher.
> nominatime gère addr:palce
> aucune idée pour bano

Pour BANO si le but est de dégommer le nom en rouge "Aerodrome Toussus le 
Noble" alors il suffit d'ajouter son code Fantoir sur l'aerodrome lui-même : 
https://www.openstreetmap.org/way/236395648
Dans le cadastre je vois 42 adresses dont le nom de voie est "Aerodrome Toussus 
le Noble". Pour celles-ci en effet ça aurait du sens de modéliser avec 
addr:place="Aerodrome Toussus le Noble", mais indépendamment de BANO qui pour 
l'instant ne tient pas compte de ce tag. Ca a été évoqué ici : 
https://github.com/osm-fr/bano/issues/50 mais dans une optique lieu-dit, alors 
qu'on parle d'adresse numérotée pour l'aérodrome. Ca devrait faire l'objet d'un 
autre ticket, dont acte : https://github.com/osm-fr/bano/issues/149. Pas sûr 
que ça sorte avec la v2 de BANO qui apparaîtra dans quelques semaines mais au 
moins c'est tracé.

vincent

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

Re: [OSM-talk-fr] GogoCarto

[allegre . guillaume]

Le 14/03/2019 21:28, Cédric Frayssinet a écrit :

Bonsoir à tous,

Le projet ne semble pas être passé par cette liste. Voici GogoCarto,
un chouette projet, très joli, un peu à la uMap, qui permet de faire
de jolies cartes : https://gogocarto.fr/projects


Pour les gens qui connaissent déjà uMap, pourrais-tu donner succintement
les principales différences ?

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