Re: [OSM-talk-fr] Explosion d'un carrefour

2013-09-29 Par sujet Philippe Verdy 
Le 29 septembre 2013 20:16, Pieren  a écrit :

> 2013/9/29 Philippe Verdy :
>
> > Mais un multipolygone sans attribut n'a pas de sens: il faut remonter
> ceux
> > de la bordure externe si on veut exclure une zone "inner".
>
> Comme il y a des nouveaux qui nous lisent et qui ne connaissent pas
> encore Philippe (qui est filtré par la plupart des anciens abonnés de
> cette liste), je vais corriger au moins ce point.


Il n'y a rien à corriger du tout. Ce que tu décris ci-dessous est une
"recette de cuisine" faite par l'outil que tu décris, destinée à tenter de
corriger l'erreur, et qui pourtant n'arrive pas clairement à résoudre tous
les problèmes. Notamment sur le fait que cela conduit à créer des doublons
de tags en conflit, et qu'il est impossible alors de savoir lequel est
applicable.

Je maintiens que c'est une erreur de ne pas taguer le multipolygone
lui-même alors qu'il est crée spécifiquement pour créer un "trou" dans la
surface qu'il décrit, et que le tag sur le polygone "outer" oublit d'exlure
la surface des poygones "inner", et de fait ce poygone "outer" ne doit PAS
porter les tags correspondant à la surface **réellement** désignée mais ils
doivent être transférés au multipolygone...



> Il n'y a aucune
> "obligation" à reporter les tags sur la relation multipolygon; ça
> n'est pas une erreur ni une mauvaise pratique. Les multipolygons sont
> interprétés de la manière suivante par le principal outil de
> conversion des données osm en postGIS ([1]):
> - si un multipolygon n'est pas taggué (aucun tag principal), alors on
> prend tous les tags de tous les ways "outer" (mais le processus peut
> foirer si ces tags ont des valeurs différentes (->rejeté)). C'est
> facile lorsquil n'y a qu'un seul way outer (le cas de la plupart des
> multipolygons).
> - si un multipolygon est taggué, c'est uniquement ces tags qui seront
> pris en considération et pas ceux portés par les ways "outer"
> - si les tags d'un way "inner" est diffèrent des tags sur les ways
> "outer" ou ceux de la relation, alors ce way devient un nouveau
> polygone


Cet algo n'en est pas un. Tout cela n'est qu'une heuristique destinée à
tenter de corriger plus ou moins automatiquement certaines anomalies. Alors
qu'il n'y a strictement aucune anomalie ni heuristique à réaliser si on a
les tags sur le multipolygone directement.

Ce serait aussi vrai dans une base GIS si on taguait les "rings" (anneaux)
au lieu des multipolygones (dans une base GIS ce ne sont pas des "ways"
(chemins) qui sont membres, mais des bien des "rings" (autrement dit
uniquement des polygones fermés). Et c'est ce que tente de réaliser le
script de conversion avec plus ou moins de difficultés.

En plus tu te trompes dans la première partie : la conversion ne prend pas
TOUS les tags des chemins membres, mais SEULEMENT ceux qui sont en commun.
Et cela fait une grosse différence car tous les tags ne sont pas à
considérer. Et pourtant cela foire car certains ne devraient pas être
transférés, même s'ils sont communs (sinon cela entraine des conflits, par
exemple quand le multipolygone est créé pour une valeur de "natural=*"
différente de celle des chemins membres, un cas où il est parfois
nécessaire de créer un multipolygone ayant un seul membre).

Normalement seuls les tags du multipolygone devraient suffire, et ceux des
chemins membres ne sont là que pour combler un manque et à condition qu'ils
ne soient pas en conflit entre eux, et pas en conflit non plus avec ceux du
multupogone.

Alors tes approximations sont à metttre en parallèle de mes "prétendues"
erreurs qui n'en sont pas.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Du Fantoir

2013-09-29 Par sujet Philippe Verdy 
Il y a bien une description officielle du Fantoir:
http://www.collectivites-locales.gouv.fr/mise-a-disposition-fichier-fantoir-des-voies-et-lieux-dits
Pourtant ce fichier a une codification bien a lui utilisant des champs
multiples, et tous ces champs ne sont pas utilisés selon les sources qui le
référence. Si je reprend Saint-Etienne, on a des lignes comme:

 
+--+-+***++-++--+*+*+**+*+**+*+*+**+***+***+***+*+***+***+***+**+***++**+
>  |42|0|   || |LOIR|E | | |  | |  | | |  |
>   |000|000| |000|000|   |  |   ||
>|
>
>  
> +--+-+***++-++--+*+*+**+*+**+*+*+**+***+***+***+*+***+***+***+**+***++**+
>
>  
> +--+-+---++-++--+*+-+**+-+**+-+-+--+---+---+---+-+---+---+***+**+***++**+
>  |42|0|218||J|SAIN|T-ETIENNE | |R|  | |  | |*|
>  |0180773|000|000| |000|1987001|   |  |
>|  |
>
>  
> +--+-+---++-++--+*+-+**+-+**+-+-+--+---+---+---+-+---+---+***|**+***++**+
>
>  
> +--+-+---++-++--+*+-+**+-+**+-+-+--+---+---+---+-+---+---+---+--+***|+**+
>  |42|0|218|0010|B|PL  |ABBAYE| |R|  | |  |0| |  |
>   |000|000| |000|1987001|   |004351|   |ABBAYE  |
>|
>  |42|0|218|0020|M|RUE |DE L ABBAYE   | |R|  | |  |0| |  |
>   |000|000| |000|1987001|   |004361|   |ABBAYE  |
>|
>  |42|0|218|0025|T|RUE |DE L ABBE BREUIL  | |R|  | |  |0| |  |
>   |000|000| |000|1987001|   |004371|   |BREUIL  |
>|
>  |42|0|218|0030|Y|MTE |DE L ABBE DE L EPEE   | |R|  | |  |0| |  |
>   |000|000| |000|1987001|   |004381|   |EPEE|
>|
>
>  
> +--+-+---|+-++--**+-+--+-+**+-+-+--+---+---+---+-+---+---+---+--+***++**+


(Là j'ai découpé les champs pour la lisibilité, en utilisant des lignes de
bordures, mais si les bordures sont des astérisques, c'est juste un champ
"filler").

On voit des lignes de 3 types :
- pour la "direction" locale de la DGFiP (une seule dans ce département de
la Loire, portant le nom du département) ; toujours présente en tête de
chacun des fichiers; son code est "420" autrement dit le code département
plus la direction "0" (pas de découpage du département). Je n'ai pas
regardé tous les fichiers pour voir s'il y avait des départements découpés
en plusieurs directions c'est peut-être hsitorique).
- pour la commune ici le code est "420218" (et non "42218" comme le code
INSEE complet d'une commune) car le code de direction s'y insère
- pour les voies le code est "420218" suivi de 4 chiffres.

La lettre qui suit est incohérente, elle est sensée avoir une signification
de "clé RIVOLI" selon la lettre utilisée (la tranche où elle est allouée
donne normalement un statut, masi visiblement ce n'est pas le cas ici pour
la "Montée de l'Abbé de l'épée".

Malheureusement le fichier est écrit entièrement en capitales, sans aucun
accent ni apostrophe (les types de voies sont abrégés et codés sur 4
positions, ici "MTE " pour "Montée").
- Le nom des voies est limité à 26 caractères (lettre capitale sans accent,
ou espace qui remplace toute apostrophe ou trait d'union).
- Dans certains cas pour faire tenir le nom de la rue, il est abrégé. "RUE
DU DOCTEUR XYZ" pourra être écrit aussi "RUE DOCTEUR XYZ" ou "RUE DOC XYZ",
selon la longueur dy nom qui suit, et un prénom avant le nom pourra être
abrégé à sa première lettre...
- Quand un prénom est abrégé à son initiale, elle peut être ou pas suivie
d'un point abréviatif (le plus souvent non mais ce n'est apparemment pas
une règle)
- Parfois les apostrophes sont conservées et non remplacées par une espace,
parfois on trouve des traits d'union (éventuellement encadrés d'espaces).
- Les noms de lieux-dits suivent parfois la mention "LIEU-DIT " (abrégé
parfois "LIEUDIT " sans trait d'union, ou "LDT ") dans le nom de voie, mais
pas toujours (le type de voie sur 4 caractères est laissé vide).
- Les nombres dans les noms de rue sont écrits en toutes lettres ou en
chiffres, parfois en romains (aucune règle on trouve de tout, même pour les
dates).

Je souhaite bien du plaisir pour traiter ces noms de voies et les
rapprocher des noms dans OSM !!!

Le reste de la ligne donne
- une colon

Re: [OSM-talk-fr] Du Fantoir

2013-09-29 Par sujet Philippe Verdy 
A Saint-Etienne les code Fantoir sont à 10 caractères apparemment dans les
sources : 6 lettres "STEDGI" plus 4 chiffres.
Il semblerait que les 6 lettres initiales indiquent la source à l'origine
de la codification (DGI : le cadastre) et un code abrégé pour désigner la
commune (STE : Saint-Etienne).
On a donc un code abrégé à 4 chiffres mais il n'est pas suffisant.
Selon les communes le nombre de chiffres pourrait varier entre 3 et 4, et
il pourrait y avoir plusieurs sources selon les secteurs ou selon la
source, ou la collecticité qui a la charge de la voirie et fournit ses
données.
S c'est le cas, le code FANTOIR n'a pas un format unique ou bie il faut le
préfixer par les 6 lettres pour le rendre unique au moins dans la commune
ou plus grand si nécessaire (s'il y a des sources du département ou d'un
EPCI ou d'une autre administration de l'Etat, y compris l'armée, ou d'une
administration locale portuaire, voire un établissement mixte d'aménagement
local).
Y a-t-il une page de référence expliquant cette codification foutoir
pardon, FANTOIR ???



Le 29 septembre 2013 19:24, Frédéric Rodrigo  a
écrit :

> Le 26/09/2013 23:49, Frédéric Rodrigo a écrit :
>
>> A Nantes, c'est d'abord "rivoli" qui avait été retenu puis, à l'exemple
>>> de Toulouse, la conversion a "ref:FR:FANTOIR" a eu lieu le 8/2/2013..
>>> Le débat pour savoir si Nantes est en Bretagne semble évité mais si
>>> c'est pour mettre Nantes en Auvergne...
>>>
>>> Concernant la valeur à mettre, l'opendata fournit généralement les 4
>>> caractères alphanumérique identifiant la voie dans la commune.
>>> Le code FANTOIR complet comprend les codes du département et de la
>>> commune. Il peut donc être reconstitué à partir de la localisation de la
>>> rue sur OSM.
>>> Le code à 4 caractères est à préconiser dans le wiki d'OSM puisqu'il
>>> évite de la redondance d'information.
>>>
>>> Est-ce que la migration annoncée vers ref:FR:FANTOIR comporte également
>>> le recadrage de la valeur sur 4 caractères ?
>>>
>>
>> Je ne sais pas c'est avoir.
>>
>> Les ref:FR:fantoir sont ceux de Brest et du Finistère. Ces adresses ont
>> été rentré dans OSM sans relation associatedStreet (je ne sais pas même
>> si elles étaient d'usage à l'époque). Donc le tag ref:FR:fantoir est
>> présent pour chaque numéro et est sur quatre carcactères.
>> Il y a également des zones ou la tag ref:FR:fantoir est juste porté par
>> des ways, mais sans adresses dans le coin.
>>
>> ref:FR:FANTOIR doivent être à Nantes et à Toulouse sur les relations.
>>
>> Pour les relations
>> taille| count
>>+---
>>  1 |56
>>  2 |   673
>>  3 |  2464
>>  4 |  8980
>>  5 |   126
>> 11 |   423
>>
>> Pour l'Auvergne il s'agit en fait de 87 noeuds avec une référence sur 11
>> carcactères, avec des tags places village ou locality : 63081B076G
>> (sûrement département, commune et code à 5 caractères)
>>
>> Pour ce qui est de http://addr.openstreetmap.fr
>> Arles : ref:FR:FANTOIR 4 4 caractères
>>
>> Bordeaux : ref:FR:FANTOIR 5 caractères
>> Lyon : -
>> Montpellier : -
>> Nancy : ref:FR:FANTOIR 4 caractères
>> Rennes : -
>>
>
> Pour ce qui est de Bordeaux j'ai corrigé les codes fantoir dans l'outil
> http://addr.openstreetmap.fr et tout ceux qui étaient déjà en base pour
> passer à un code à 4 caractères.
>
> Je propose maintenant de combler les codes à mois de 4 caractères avec des
> zéros.
>
> btw, j'ai ajouté une petite page de stats là :
> http://addr.openstreetmap.fr/**stats.php
>
> J'ai également commencé la page sur le wiki :
> http://wiki.osm.org/wiki/FR:**Key:ref:FR:FANTOIR
>
>
> Frédéric.
>
>
> __**_
> 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] Matériel de promotion

2013-09-29 Par sujet Sébastien Dinot 
Bonsoir,

Ceux d'entre vous qui ont lu mon précédent message le savent, un stand
OSM est prévu à l'université Paul Sabatier de Toulouse à l'occasion de
la Novela le samedi 12 octobre prochain.

Je vais avoir besoin de matériel de promotion pour ce stand : flyers,
affiches, voire cartes et autres supports intéressants.

Connaissez-vous des supports en français, maintenus et diffusés sous
licence libre que je pourrais faire imprimer ?

Sébastien

 
-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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

[OSM-talk-fr] proposal : jeu de tags pour la hierarchie cyclable des voies

2013-09-29 Par sujet hamster 
j'ai fait un proposal de tags avec l'idee que j'avais lancee debut
juillet, vous pouvez le voir la :
http://wiki.openstreetmap.org/wiki/FR:Cycle_Hierarchy

Le 06/07/2013 23:10, hamster a écrit :
> Je pense plutot que les tags highway sont bases sur l'usage
> automobile de la route, ces tags ne sont donc pas du tout adaptes
> pour faire une carte a l'attention des cyclistes.
> 
> Il faudrait donc faire une serie de tags equivalents pour les velos, 
> bases sur les memes criteres : highway=cycle:primary --> voie qui 
> sert a relier 2 villes ou 2 regions a velo highway=cycle:secondary 
> --> voie qui sert a relier 2 quartiers d'une ville a velo 
> highway=cycle:tertiary --> voie principale de circulation cycliste a 
> l'interieur d'un quartier highway=cycle:unclassified --> voie de 
> moindre interet pour la circulation cycliste highway=cycle:bad --> 
> voie deconseillee pour l'usage cycliste parce que difficile ou 
> dangereuse
> 
> (Evidamment les exemples de tags proposes ci dessus sont a
> ameliorer, n'hesitez pas a faire d'autres propositions)
> 
> Ainsi les rues qui seraient notees cycle:secondary pourraient tout 
> aussi bien etres des "residential" ou des "cycleway" ou meme des 
> "path" au sens de l'usage automobile. Les rues qui sont notees 
> highway=primary seraient souvent des cycle:unclassified ou des 
> cycle:bad
> 
> Ca permettrait de faire un rendu cycliste ou : - Les autoroutes et 
> autres voies interdites aux velos apparaitraient comme des obstacles,
> avec un graphisme etroit pour ne pas encombrer la carte. - Les
> grosses arteres dangereuses a velo apparaitraient en petit et en 
> blanc. - Les voies a privilegier par les cyclistes apparaitraient en
> plus gros et en orange ou rouge selon leur importance, que ce soient
> des pistes cyclables, des rues ou des chemins.
> 
> Ca permettrait aussi d'avoir un rendu cycliste ou sont representes 
> les axes de circulation cycliste de facon continue, comme le sont
> les highway=primary pour les voitures. C'est a dire que quand on se 
> demanderait "par ou passer pour aller de l'autre cote de la ville"
> on verrait sur la carte un trait orange continu, passant par des
> pistes cyclables, des ruelles, des chemins, et qui traverse la ville.
> De la meme facon qu'a l'heure actuelle quand on veut aller de l'autre
> cote de la ville en voiture on voit un trait orange continu qui passe
> par des rues de centre ville, des rocades, des gros boulevards.
> 
> En conclusion je pense que les tags highway sont faits en supposant 
> un usage automobile. C'est mal parce que "il ne faut pas taguer pour 
> l'usage" de la meme facon que "il ne faut pas taguer pour le rendu".
> Il serait bon de corriger ca.
> 
> Je pense aussi que tant qu'on essaiera de faire des cartes cyclables
>  en rajoutant par surcharge les amenagements cyclables sur un fond de
>  carte dessine pour un usage automobile, on aura des difficultes et 
> ca sera pas terrible. Notamment parce qu'il nous manquera des infos 
> sur les voies qui n'ont pas d'amenagement cyclable et parce qu'on 
> sera encombres par des informations automobiles inutiles aux velos.

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

Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?

2013-09-29 Par sujet sylvain letuffe 

> Le problème des autres outils qui
> fonctionnent en flux (ala osm2pgsql),
> c'est que cette modélisation
> implique un double passage sur les relations au minimum ou un stockage
> séparé des relations-segments.

Je ne sais pas trop où tu veux en venir, mais si c'est pour préciser que 
l'algorithme de traitement entre une relation construite en pyramide de 
relation et celle sans ne sera pas le même, en effet, il n'y a pas de doute.

Mais osm2pgsql, tel qu'existant aujourd'hui, pour construire des géométries à 
partir de fichiers .osm et .pbf ne fonctionne pas en flux dans le sens "être 
capable de construire toutes les géométries en une lecture continue du fichier 
de donnée sans stockage"

ogr2ogr qui dispose aussi d'un drivers de lecture des fichiers .osm et .pbf 
passe, lui aussi par un stockage temporaire.

Enfin bref, avec ou sans modèle pyramide, que ça soit dans 400Go de RAM si on 
les as (osm2pgsql sans le --slim), une base sur disque (mode --slim) ou base 
sqlite temporaire (ogr2ogr) il faut de toute façon un algo avec stockage 
temporaire pour passer des données osm monde à des géométries (way, relation, 
ou pyramides de relations).

Et si ce sur quoi tu t'interroges à la fin c'est la vitesse de construction 
des géométries avec chaque modèles sur un ordinateur qui existe, bien que ça 
dépende de la manière de faire l'algo, je pense que de deux algo bien 
réalisés, celui qui traite la pyramide sera le plus rapide car il y a 
factorisation du stockage sur disque d'une relation de frontière et sa 
construction (car ré-utilisée par les deux polygones qui se touchent)

Mais je pense que ces considérations sont vraiment secondaires, laissons aux 
développeurs ces questions et posons nous plutôt la question du temps passé 
par le contributeur, sa difficulté à comprendre la construction, et les 
possibilités offerte pour maintenir des relations géantes avec les deux 
modèles.


-- 
sly (sylvain letuffe)
pour me contacter / to contact me : sylvain(A)letuffe(.)org




--
View this message in context: 
http://gis.19327.n5.nabble.com/Re-Limites-administratives-le-modele-pyramidal-un-echec-tp5779415.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-09-29 Par sujet Pieren 
2013/9/29 Philippe Verdy :

> Mais un multipolygone sans attribut n'a pas de sens: il faut remonter ceux
> de la bordure externe si on veut exclure une zone "inner".

Comme il y a des nouveaux qui nous lisent et qui ne connaissent pas
encore Philippe (qui est filtré par la plupart des anciens abonnés de
cette liste), je vais corriger au moins ce point. Il n'y a aucune
"obligation" à reporter les tags sur la relation multipolygon; ça
n'est pas une erreur ni une mauvaise pratique. Les multipolygons sont
interprétés de la manière suivante par le principal outil de
conversion des données osm en postGIS ([1]):
- si un multipolygon n'est pas taggué (aucun tag principal), alors on
prend tous les tags de tous les ways "outer" (mais le processus peut
foirer si ces tags ont des valeurs différentes (->rejeté)). C'est
facile lorsquil n'y a qu'un seul way outer (le cas de la plupart des
multipolygons).
- si un multipolygon est taggué, c'est uniquement ces tags qui seront
pris en considération et pas ceux portés par les ways "outer"
- si les tags d'un way "inner" est diffèrent des tags sur les ways
"outer" ou ceux de la relation, alors ce way devient un nouveau
polygone.

Pieren

PS: En plus, à donner des leçons ä tout le monde, tu fais encore des
erreurs de débutant. Sur ce way ([2]), tu ajoutes un "area=yes" à un
"landuse". Mais les "landuses" sont toujours des polygones, il n'y a
pas besoin de rajouter un "area=yes". C'est comme pour les "building".
C'est marrant, cette obsession du "area=yes". Déjà que j'ai beaucoup
de mal à avaler ton "landuse=traffic_island", jamais discuté, jamais
voté et utilisé 500 fois par 60 personnes, dont la moitié par un seul
contributeur, et pour toute la planète...:(

[1] https://lists.openstreetmap.org/pipermail/talk/2013-September/068191.html
[2] http://www.openstreetmap.org/browse/way/239302784

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

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-09-29 Par sujet Greg 
Effectivement, j'ai créé le multipolygon, mais j'avais oublié les détails
de report de tags. (Et je ne connaissait pas le landuse=traffic_island que
tu as ajouté.

Pour le reste, je plaide non coupable :)

(C'est un peu un casse-tête, on dirait, cette place. Je ne fais plus rien
jusqu'à ce qu'on tombe sur quelque chose qui fait consensus, que je
garderai sous le coude en tant que référence).



Greg


2013/9/29 Philippe Verdy 

> Je note aussi que quelqu'un a créé un multipolygone sans aucun attribut
> pour tenter de rendre visible le petit triangle au milieu.
> http://www.openstreetmap.org/browse/relation/3232953
> Mais un multipolygone sans attribut n'a pas de sens: il faut remonter ceux
> de la bordure externe si on veut exclure une zone "inner".
> Bref le contour en doublon qui a été ajouté par dessus celui visible
> actuellement n'apparait pas et c'est normal. Pire, il entre en conflit avec
> le poyfone un peu plus petit mais visible actuellement en blanc et non gris.
>
>
> ___
> 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] Du Fantoir

2013-09-29 Par sujet Frédéric Rodrigo 

Le 26/09/2013 23:49, Frédéric Rodrigo a écrit :

A Nantes, c'est d'abord "rivoli" qui avait été retenu puis, à l'exemple
de Toulouse, la conversion a "ref:FR:FANTOIR" a eu lieu le 8/2/2013..
Le débat pour savoir si Nantes est en Bretagne semble évité mais si
c'est pour mettre Nantes en Auvergne...

Concernant la valeur à mettre, l'opendata fournit généralement les 4
caractères alphanumérique identifiant la voie dans la commune.
Le code FANTOIR complet comprend les codes du département et de la
commune. Il peut donc être reconstitué à partir de la localisation de la
rue sur OSM.
Le code à 4 caractères est à préconiser dans le wiki d'OSM puisqu'il
évite de la redondance d'information.

Est-ce que la migration annoncée vers ref:FR:FANTOIR comporte également
le recadrage de la valeur sur 4 caractères ?


Je ne sais pas c'est avoir.

Les ref:FR:fantoir sont ceux de Brest et du Finistère. Ces adresses ont
été rentré dans OSM sans relation associatedStreet (je ne sais pas même
si elles étaient d'usage à l'époque). Donc le tag ref:FR:fantoir est
présent pour chaque numéro et est sur quatre carcactères.
Il y a également des zones ou la tag ref:FR:fantoir est juste porté par
des ways, mais sans adresses dans le coin.

ref:FR:FANTOIR doivent être à Nantes et à Toulouse sur les relations.

Pour les relations
taille| count
   +---
 1 |56
 2 |   673
 3 |  2464
 4 |  8980
 5 |   126
11 |   423

Pour l'Auvergne il s'agit en fait de 87 noeuds avec une référence sur 11
carcactères, avec des tags places village ou locality : 63081B076G
(sûrement département, commune et code à 5 caractères)

Pour ce qui est de http://addr.openstreetmap.fr
Arles : ref:FR:FANTOIR 4 4 caractères
Bordeaux : ref:FR:FANTOIR 5 caractères
Lyon : -
Montpellier : -
Nancy : ref:FR:FANTOIR 4 caractères
Rennes : -


Pour ce qui est de Bordeaux j'ai corrigé les codes fantoir dans l'outil 
http://addr.openstreetmap.fr et tout ceux qui étaient déjà en base pour 
passer à un code à 4 caractères.


Je propose maintenant de combler les codes à mois de 4 caractères avec 
des zéros.


btw, j'ai ajouté une petite page de stats là :
http://addr.openstreetmap.fr/stats.php

J'ai également commencé la page sur le wiki :
http://wiki.osm.org/wiki/FR:Key:ref:FR:FANTOIR

Frédéric.


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

Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?

2013-09-29 Par sujet Pieren 
2013/9/29 sylvain letuffe :
> http://osm102.openstreetmap.fr/~jocelyn/polygons/index.py
> https://github.com/jocelynj/osm/blob/master/tools/mega-relation-analyser.py

A noter que ces outils fonctionnent avec un identifiant en entrée, ce
qui rend la chose facile. Le problème des autres outils qui
fonctionnent en flux (ala osm2pgsql), c'est que cette modélisation
implique un double passage sur les relations au minimum ou un stockage
séparé des relations-segments.

Pieren

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

Re: [OSM-talk-fr] Limites administratives, le modèle "pyramidal", un échec ?

2013-09-29 Par sujet sylvain letuffe 
hello aux manieurs de balais (que je soutiens presque toujours) !



Pieren wrote
> L'idée remonte à début 2010 et 3 ans plus-tard, il n'y a toujours
> aucun logiciel qui s'en sert. Il faut parfois admettre que même les
> bonnnes idées peuvent ne pas être suivies d'effets.

L'outil développé par jocelyn accessible ici :
http://osm102.openstreetmap.fr/~jocelyn/polygons/index.py

permet depuis plus d'un an d'exporter tout type de relation représentant un
polygone que celle-ci utilise (ou pas) une construction pyramidale.
On s'en sert pour construire le polygone "France" (avec dom/tom) et
l'utiliser ensuite avec postresql et faire des requêtes limitées à la
france.

Pour vérifier ce type de relation pyramidale, on dispose aussi de :
https://github.com/jocelynj/osm/blob/master/tools/mega-relation-analyser.py
un autre, plus performant et accessible en ligne dont j'ai paumé l'adresse
et
osmose (il me semble) l'utilise dans un de ces tests.



Pieren wrote
> et nous distingue encore une fois de tous nos voisins du monde

Il est vrai que très peu de relation sont construites sur ce modèle mais on
trouve :
l'allemagne : http://www.openstreetmap.org/browse/relation/111
et l'ensemble des pays à majorité germanophone :
http://www.openstreetmap.org/browse/relation/2463632

en plus des deux nôtres, c'est quand même pas nouveau que France et
Allemagne soit le moteur de l'europe non ? ;-)

On peut même découvrir les prémisses d'une éventuelle future intégration
possible des mers dans osm :
http://www.openstreetmap.org/browse/relation/1628011

Beaucoup en rêve, personne ne sait comment faire, mais il me semble que ça
vaut le coup de continuer à laisser sa chance à ce modèle (c'est à dire sans
l'éradiquer trop vite) car je ne vois pas le modèle actuel relation<-ways
résoudre le cas des mers/océans.


Pieren wrote
> Des opinions ?

Oui, lui laisser encore du temps. La contre-indication d'avoir un way de
frontière qui appartient à une relation de plus qu'est la frontière entre
deux pays ne me semble pas suffisamment pénible (quand on sait qu'un way
admin_level=8 de frontière franco/italienne est membre de 12 relations :
http://www.openstreetmap.org/browse/way/202492188  ) 1 de plus me semble
tolérable compte tenu de l'espoir que cela porte à la simplification autant
qu'a l'expansion à des relation de plus grosse tailles
(mers/océans/continents/ensemble économique comme l'UE)

A noter qu'une telle discussion pourrait sans doute être portée sur tagging,
certains de nos voisins ayant semblent-il eux aussi des idées concernant
l'utilisation de ce modèle.

--
sly



--
View this message in context: 
http://gis.19327.n5.nabble.com/Limites-administratives-le-modele-pyramidal-un-echec-tp5778241p5779397.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Besoin de bénévoles pour un stand à Toulouse le 12 octobre

2013-09-29 Par sujet Sébastien Dinot 
Guilhem Bonnefille a écrit :
> Fichtre, mais c'est qu'il y a un sacré programme ce 12/10. Je vais me
> rendre dispo.

Comme les années précédentes, La Novela fait feu de tout bois ; le
programme fait 196 pages ! Seul hic, beaucoup d'animations sont en
journée et en semaine... L'animation du forum numérique des séniors me
contraint par exemple à prendre deux jours de congé.

> Si tu as des infos à partager pour les "animateurs" je suis intéressé
> (horaire ouverture, modalités d'accès, orga sur place...).

En ce qui nous concerne, cela va se passer à l'Université Paul Sabatier,
plus précisément dans le hall du bâtiment administratif, 118, route de
Narbonne. Le lieu sera ouvert au public de 10 h à 19 h.

> En particulier, serait-il raisonnable de trainer ma grande fille de
> 6 ans ;-)

Entre stand dédié aux jeux libres et atelier animé par Les Petits
Débrouillards, m'est avis qu'il y a de quoi l'occuper. Par contre, elle
ne tiendra certainement pas toute la journée. ;)

Sébastien


-- 
Sébastien Dinot, sebastien.di...@free.fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !

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

Re: [OSM-talk-fr] Besoin de bénévoles pour un stand à Toulouse le 12 octobre

2013-09-29 Par sujet Guilhem Bonnefille 
Fichtre, mais c'est qu'il y a un sacré programme ce 12/10. Je vais me
rendre dispo.

Si tu as des infos à partager pour les "animateurs" je suis intéressé
(horaire ouverture, modalités d'accès, orga sur place...). En particulier,
serait-il raisonnable de trainer ma grande fille de 6 ans ;-)


Le 24 septembre 2013 22:02, Sébastien Dinot  a
écrit :

> Bonsoir,
>
> J'ai proposé la tenue d'un stand OSM dans le cadre d'un événement grand
> public organisé par la mairie le 12 octobre à Toulouse. Si l'affluence
> est comparable à celle des années précédentes, un coup de main ne sera
> pas superflu. Des contributeurs toulousains (ou autres) seraient-ils
> prêts à donner de leur personne ? :)
>
> Le principal étant dit, voici quelques éléments de contexte :
>
> « La Novela », dit « festival des savoirs partagés », démarre cette
> semaine à Toulouse :
>
> http://www.fete-connaissance.fr/?cadre=festival-la-novela
>
> Comme chaque année, La Novela est structurée par plusieurs thèmes dont
> « Toulouse Numérique », thème concentré sur les journées du 9 au 12
> octobre.
>
> Une journée d'animation ouverte à tous est programmée le samedi 12 à
> l'université Paul Sabatier dans le cadre du thème « Toulouse
> Numérique ». Le public pourra découvrir au détour de stands, d'ateliers
> et de conférences les logiciels libres, la culture libre, les fablabs,
> le mouvement DIY, l'Open Data et... OpenStreetMap. Cf. pages 123 à 129
> du programme ci-dessous :
>
>
> http://www.fete-connaissance.fr/sites/default/files/Programme-Novela-2013-PAP.pdf
>
> C'est un bel événement et même si vous ne comptez pas participer à la
> tenue du stand OSM, je vous invite à passer pour découvrir ces
> différents thèmes et faire connaissance. :)
>
> A++, Sébastien
>
> --
> Sébastien Dinot, sebastien.di...@free.fr
> http://sebastien.dinot.free.fr/
> Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Guilhem BONNEFILLE
-=- JID: gu...@im.apinc.org MSN: guilhem_bonnefi...@hotmail.com
-=- mailto:guilhem.bonnefi...@gmail.com
-=- http://nathguil.free.fr/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-09-29 Par sujet Philippe Verdy 
Je note aussi que quelqu'un a créé un multipolygone sans aucun attribut
pour tenter de rendre visible le petit triangle au milieu.
http://www.openstreetmap.org/browse/relation/3232953
Mais un multipolygone sans attribut n'a pas de sens: il faut remonter ceux
de la bordure externe si on veut exclure une zone "inner".
Bref le contour en doublon qui a été ajouté par dessus celui visible
actuellement n'apparait pas et c'est normal. Pire, il entre en conflit avec
le poyfone un peu plus petit mais visible actuellement en blanc et non gris.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Camp de concentration, camps de prisonniers, lieux de massacres…

2013-09-29 Par sujet Philippe Verdy 
C'est vrai que c'est plutôt "disused" pour la fonction répressive; mais pas
"abandoned:" pour ce qui est du mémorial.
Par exemple on aurait "disused:building=jail/..." et
"building=memorial/museum/..." sur le même objet qui a effectivement changé
d'usage mais où il est important de retenir les deux fonctions, l'usage
actuel étant lié à l'ancien..
Le préfixe "abandoned:" serait pour des bâtiments laissés volontairement à
l'abandon au milieu d'un site visitable, et l'abandon les rend aussi
potentiellement dangereux sans un entretien.


Le 29 septembre 2013 12:46, Pieren  a écrit :

> Je pense que ce sujet dépasse nos frontières et devrait donc d'abord
> se dérouler sur la liste internationale tagg...@osm.org. Les
> discussions sur le wiki impliquent en général bien peu de monde s'il
> n'y a pas auparavant un appel sur un canal plus fréquenté.
> Je pense aussi qu'il faut distinguer par des tags différents les
> anciens camps et les camps actuels. Et effectivement, le préfixe
> "abandoned" est maladroit.
>
> Pieren
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-09-29 Par sujet Philippe Verdy 
En résumé:
- taguer le polygone de la place avec area=yes, highway=pedestrian
- ne pas toucher aux rues qui traversent la place (et n'ont pas besoin non
plus d'avoir un point d'intersection avec les bords du polygone SAUF si ce
point est marqué highway=crossing pour le passage piétons, ce qui n'est
visible que sur 2 rues mais pas toutes).
- ne pas toucher aux cheminements piétons (highway=footway) qui cependant
me semblent inutiles au milieu de cette place car ce ne sont pas des
cheminements imposés et marqués (si on en met sur une surface piétonne,
c'est juste pour les moteurs qui ne savent traiter que le filaire et
ignorent les surfaces).


Le 29 septembre 2013 15:12, Philippe Verdy  a écrit :

> Tu te trompes... Car il s'agit du contour de la place en tant que surface
> et pas d'un chemin qu'on peut prendre.
> Situation similiare ici à highway=perdestrian, sauf que cette place n'est
> pas que pédestre mais résidentielle.
>
> En fait ici cela devrait être quand même highway=pedestrian (surface
> utilisable par les piétons, mais pas par les véhicules qui doivent se
> limiter aux chemins filaire des rues qui traversent cette place mais ne
> peuvent pas .circuler partout).
>
> - Un routage de navigation pour véhicules ignorera cette surface interdite
> mais pourra encore prendre les rues tracées par le filaire. Situation
> similaire aux rues qui traversent des surfaces de parking et où la surface
> de parking est ignorée par le routage.
> - Un routage de navigation pour piétons circulera aussi bien le long des
> rues qu'au travers de la surface de la place, mais pour traverser les rues
> qui coupent la place, il devra si possible utiliser les passage piétons
> marqués (s'il y en a... sinon il suggère juste de "traverser avec
> prudence" la rue sans préciser où).
>
> Mais si on laisse highway=residential sur cette surface, par défaut les
> véhicules sont autorisés (on pourrait cependant utiliser
> highway=residential mais avec des restrictions d'accès interdisant les
> véhicules ce qui n'a pas grand sens car la surface est dédiée comle
> pédestre; le plus simples est donc highway=pedestrian...
>
> En quête donc de solution sur cet exemple. Il va fallloir l'évaluer avec
> différents moteurs de navigation.
>
>
> Le 29 septembre 2013 12:33, Pieren  a écrit :
>
>> Je suis étonné que tellement d'experts soient intervenus sur cette
>>
>> place et qu'aucun n'ai encore supprimé le "area=yes" sur le polygone
>> "highway=residential" ([1])
>> Je vais répéter ici ce qui est écrit dans le wiki depuis très longtemps
>> ([2]):
>>
>> "In the context of roads, area=yes indicates that an area has no
>> street lines within it (i.e., there is no given direction on the
>> area)."
>>
>> ce qui a été traduit en:
>> "Dans le contexte de routes, area=yes indique qu'une zone n'a pas de
>> lignes de rue au sein de celle-ci (c'est à dire qu'il n'y a pas de
>> direction donnée sur la zone)."
>>
>> On ne peut pas décrire une place comme "sans directions" (sans
>> filaire) et en même temps, y mettre du filaire parce qu'il y a
>> effectivement des directions...
>>
>> Pieren
>>
>> [1] http://www.openstreetmap.org/browse/way/45489876
>> [2] http://wiki.openstreetmap.org/wiki/Key:area
>>
>> ___
>> 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] Explosion d'un carrefour

2013-09-29 Par sujet Philippe Verdy 
Tu te trompes... Car il s'agit du contour de la place en tant que surface
et pas d'un chemin qu'on peut prendre.
Situation similiare ici à highway=perdestrian, sauf que cette place n'est
pas que pédestre mais résidentielle.

En fait ici cela devrait être quand même highway=pedestrian (surface
utilisable par les piétons, mais pas par les véhicules qui doivent se
limiter aux chemins filaire des rues qui traversent cette place mais ne
peuvent pas .circuler partout).

- Un routage de navigation pour véhicules ignorera cette surface interdite
mais pourra encore prendre les rues tracées par le filaire. Situation
similaire aux rues qui traversent des surfaces de parking et où la surface
de parking est ignorée par le routage.
- Un routage de navigation pour piétons circulera aussi bien le long des
rues qu'au travers de la surface de la place, mais pour traverser les rues
qui coupent la place, il devra si possible utiliser les passage piétons
marqués (s'il y en a... sinon il suggère juste de "traverser avec
prudence" la rue sans préciser où).

Mais si on laisse highway=residential sur cette surface, par défaut les
véhicules sont autorisés (on pourrait cependant utiliser
highway=residential mais avec des restrictions d'accès interdisant les
véhicules ce qui n'a pas grand sens car la surface est dédiée comle
pédestre; le plus simples est donc highway=pedestrian...

En quête donc de solution sur cet exemple. Il va fallloir l'évaluer avec
différents moteurs de navigation.


Le 29 septembre 2013 12:33, Pieren  a écrit :

> Je suis étonné que tellement d'experts soient intervenus sur cette
> place et qu'aucun n'ai encore supprimé le "area=yes" sur le polygone
> "highway=residential" ([1])
> Je vais répéter ici ce qui est écrit dans le wiki depuis très longtemps
> ([2]):
>
> "In the context of roads, area=yes indicates that an area has no
> street lines within it (i.e., there is no given direction on the
> area)."
>
> ce qui a été traduit en:
> "Dans le contexte de routes, area=yes indique qu'une zone n'a pas de
> lignes de rue au sein de celle-ci (c'est à dire qu'il n'y a pas de
> direction donnée sur la zone)."
>
> On ne peut pas décrire une place comme "sans directions" (sans
> filaire) et en même temps, y mettre du filaire parce qu'il y a
> effectivement des directions...
>
> Pieren
>
> [1] http://www.openstreetmap.org/browse/way/45489876
> [2] http://wiki.openstreetmap.org/wiki/Key:area
>
> ___
> 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] Explosion d'un carrefour

2013-09-29 Par sujet Pieren 
2013/9/29 Ista Pouss :
> Bon je vais supprimer ce area=yes... c'est fait.

Oui, mais non. Du coup, tu fais croire que ce polygone est une rue
résidentielle en boucle fermée (comme un rond-point) à double sens de
circulation (puisqu'il n'y a pas de "oneway"). Ca n'est pas non plus
la bonne solution ;-)

Pieren, taquin aujourd'hui

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

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-09-29 Par sujet Ista Pouss 
Le 29 septembre 2013 12:33, Pieren  a écrit :

> Je suis étonné que tellement d'experts soient intervenus sur cette
> place et qu'aucun n'ai encore supprimé le "area=yes" sur le polygone
> "highway=residential" ([1])
>

Super ! Génial ! Pourrais-tu chercher plus avant et expliquer pourquoi donc
il y a tant de problèmes !?...



> Je vais répéter ici ce qui est écrit dans le wiki depuis très longtemps
> ([2]):
>

Les experts ne sauraient donc pas lire le wiki ?



>
> "In the context of roads, area=yes indicates that an area has no
> street lines within it (i.e., there is no given direction on the
> area)."
>
> ce qui a été traduit en:
> "Dans le contexte de routes, area=yes indique qu'une zone n'a pas de
> lignes de rue au sein de celle-ci (c'est à dire qu'il n'y a pas de
> direction donnée sur la zone)."
>
> On ne peut pas décrire une place comme "sans directions" (sans
> filaire) et en même temps, y mettre du filaire parce qu'il y a
> effectivement des directions...
>

Merci.

Bon je vais supprimer ce area=yes... c'est fait.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Camp de concentration, camps de prisonniers, lieux de massacres…

2013-09-29 Par sujet Pieren 
Je pense que ce sujet dépasse nos frontières et devrait donc d'abord
se dérouler sur la liste internationale tagg...@osm.org. Les
discussions sur le wiki impliquent en général bien peu de monde s'il
n'y a pas auparavant un appel sur un canal plus fréquenté.
Je pense aussi qu'il faut distinguer par des tags différents les
anciens camps et les camps actuels. Et effectivement, le préfixe
"abandoned" est maladroit.

Pieren

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

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-09-29 Par sujet Pieren 
Je suis étonné que tellement d'experts soient intervenus sur cette
place et qu'aucun n'ai encore supprimé le "area=yes" sur le polygone
"highway=residential" ([1])
Je vais répéter ici ce qui est écrit dans le wiki depuis très longtemps ([2]):

"In the context of roads, area=yes indicates that an area has no
street lines within it (i.e., there is no given direction on the
area)."

ce qui a été traduit en:
"Dans le contexte de routes, area=yes indique qu'une zone n'a pas de
lignes de rue au sein de celle-ci (c'est à dire qu'il n'y a pas de
direction donnée sur la zone)."

On ne peut pas décrire une place comme "sans directions" (sans
filaire) et en même temps, y mettre du filaire parce qu'il y a
effectivement des directions...

Pieren

[1] http://www.openstreetmap.org/browse/way/45489876
[2] http://wiki.openstreetmap.org/wiki/Key:area

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