Re: [OSM-talk-fr] Infographie sur l'évolution de New-York sous la mandature Bloomberg

[Philippe Verdy]

Même si on veut avoir des données à jour, le minimum serait de pouvoir
renseigner une start_date=* pour voir ce qui exist auourd'hui et est le
plus ancien ou le plus récent. Ca donne une idée de l'age des structures,
et en considérnt une date de départ d'avoir une idée de la quantité de
structures récentes.
Note ue ce n'est pas la même hose qu'une date de mise à jour associée à une
source : cette date de mise à jour est plus récente que l'age des
structures, toutes les sources ayant du retard à prendre en compte une
modification ou un aménagement nouveau.
Il reste malgré tout des données historiques à préserver pendant une
période de "compatiblité", et cela devrait concerner le zonage
administratif ou statistique, afin de permettre les rapprochements de
données, au moins sur une période de 10 ans, même si ensuite une partie des
données va dans ces bases historiques spcialisées (qui pourront continuer à
être augmentées même si les données correspondantes n'ont jamais été dans
OSM).
Donc OK, OSM a vocation a représenter le mieux possible l'état actuel avec
une vision courte sur le passé, mais au delà, l'historisation par domaine
spécialisé devrait présenter plus d'intérêt, non pas de façon globalisée où
on mélange tout dans OSM (dans la partie la plus vivante et qui est en
constante modification et correction), mais pour les données historiques,
celles-ci ont vocation à devenir stables et finalisées.
Et c'est là qu'un fork d'OSM serait utile, avec un travail de supervision
de qualité et permettant de combler les trous avec un suivi qui permet de
dire que sur chaque année étudiée, on a finalement une carte complète dans
son domaine.

L'application de cela est ensuite de pouvoir produire des cartes liées à
l'histoire, ou à l'analyse des évolutions et à la planification du futur,
grace à des analyses plus poussées de l'existant (prenant en compte les
impasses, les travaux abandonnés ou les structures coûteuses délaissées
n'ayant pas produit leur objectif initial (et ensuite éciter de commettre à
nouveau les mêmes erreurs de planification, en évitant de se "raconter des
histoires" avec des projets surdimensionnés qui plomberont les comptes pour
l'aménagement des zones réellement prioritaires ou qui seront le plus
profitable globalement en générant moins de problèmes futurs d'exploitation
ou d'entretien, moins de bouchons, moins de pollution, une meilleure
utilisation des ressources, avec moins de gaspillage, plus de recyclage, ou
des possibilités d'adaption progressive plus intéressantes me^me en temps
de crise où les arbitrages sont nombreux et compliqués à décider...).
L'histoire nous en apprend beaucoup sur notre avenir, ignorer l'histoire
c'est continuer à perpétrer les mêmes erreurs.


Le 21 août 2013 11:03, Jean-Marc Liotier  a écrit :

> On 21/08/2013 10:56, François Lacombe wrote:
>
>> Ne pas avoir de distinction possible des éditions de maintenance (pour
>> corriger des erreurs ou des incohérences, des choses qui n'ont jamais
>> existé sur le terrain) des éditions de mise à jour (le terrain a
>> effectivement changé à une date bien précise et OSM doit suivre) est un
>> vrai handicap.
>>
>
> Certes, mais ça n'a jamais fait partie des besoins traités par
> Openstreetmap - tous les aspects du projet ont toujours été explicitement
> dédiés à fournir la vision à jour. Au-delà du problème de modélisation et
> d'outillage, l'exploitation serait une charge considérable: une vision
> historique est en pratique un empilement de visions instantanées qu'il faut
> toutes tenir à jour avec le même niveau d'effort que celle à jour.
> L'introduction de dates d'effet dans les métadonnées n'est que le premier
> pas qu'un tel Openhistorymap devrait franchir.
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Piscines - était : Re: Circuits vélotourisme en Vaucluse

[Vincent Pottier]

Le 21/08/2013 22:51, Yves Pratter a écrit :


Pour les piscines découvertes pour villageois en vacances, ce tag ne 
se justifie pas toujours. Alors qu'un access=*, lui...



Oui, dans tout ces exemples, il faut un access=private


mieux :
access=customers
--
FrViPofm

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

Re: [OSM-talk-fr] Piscines - était : Re: Circuits vélotourisme en Vaucluse

[Yves Pratter]

> En représentant leisure/amenity=swimming_pool, sans restriction d'accès 
> (no/private), voilà ce que ça donne : 
> http://osm107.openstreetmap.fr/jbtopo/piscines.PNG sur le nord-est d'Orange… 
> Y'a du travail de nettoyage.
> 
Effectivement, on se croirait en pleine mer :-D
> Je ne suis pas convaincu par la présence du tag sport=swimming pour indiquer 
> l'accessibilité au public…
> 
Non, il sert à indiquer — entre-autres à OpenSeaMap — qu'on y pratique la 
natation.
La piscine du "Loft", bien que privée avait d'autres usages ;-)
> Pour les piscines découvertes pour villageois en vacances, ce tag ne se 
> justifie pas toujours. Alors qu'un access=*, lui…
> 
Oui, dans tout ces exemples, il faut un access=private

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

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

[Philippe Verdy]

Le 21 août 2013 21:34, Christian Quest  a écrit :

> Le 21 août 2013 21:02, Philippe Verdy  a écrit :
>
>> Mais plus qu'une note pour ce cas il faudrait peut-être un tag
>> particulier "population:fictive=yes" pour ne pas perturber les utilisations
>> sur des rendus de cartes ou fichiers statistiques.
>>
>
> population:estimated=nnn serait préférable (ou un truc du genre).
>
> Si un rendu veut utiliser ce tag il le pourra, et il ne gênera pas ceux
> qui feraient des statistiques avec population=*
>

Pourquoi pas... De toute façon c'est mieux et plus objectif que les actuels
place=* qui sont assez mal fichus pour classer ce qu'on veut afficher sur
une carte quand les critères sont impossibles à établir clairement de façon
unique partout, et souvent trafiqués de façon incohérente.
A mon avis tous les place=city/town/village/suburb/hmalet/locality sont
condamnés à être traités de la même façon et on a besoin de critères à la
fois plus précis et plus souples non fondés sur des seuils arbitraires. Une
population précise ou estimée sera toujours mieux, surtout quand on sait
que mêmes les populations statistiques officielles sont aussi estimées avec
une marge d'erreur (et devraient toutes être datées car les statistiques ne
sont pas mises à jour partout en même temps, avec peut-être à terme aussi
le codage d'un taux de croissance annuel de population pour permettre
d'affiner les populations données à des dates très différentes).
En plus dans certains pays il n'y a pas de population donnée pour chaque
niveau adminsitratif mais sur un échelon supérieur ou seulement à une
échelle des unités urbaines (indépendamment du découpage administratif qui
n'évolue pas en même temps). Rien que la notion de "ville" est difficile à
établir (demandez-vous ce que désigne Paris, Londres, ou Moscou si on
retenait les critères de classification des villes d'un autre pays que le
leur, les échelles ne sont pas comparables entre elles au plan
administratif comme au plan du découpage urbain statistique national...)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Christian Quest]

Le 21 août 2013 21:02, Philippe Verdy  a écrit :

> Mais plus qu'une note pour ce cas il faudrait peut-être un tag particulier
> "population:fictive=yes" pour ne pas perturber les utilisations sur des
> rendus de cartes ou fichiers statistiques.
>
>

population:estimated=nnn serait préférable (ou un truc du genre).

Si un rendu veut utiliser ce tag il le pourra, et il ne gênera pas ceux qui
feraient des statistiques avec population=*


-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Philippe Verdy]

Même chose, je pense qu'on a beaucoup trop de "hamlet" notamment en milieu
rural car me^me si c'est une petite commune, on doit pouvoir repérer son
centre par rapport à tous ses hameaux.

Et pour les gros hameaux d'une commune, qui sont d'anciens villages
couvrant toute une série de petits hameaux environnants, je pense que la
classification avec "suburb" est utile (même si ce n'est pas à proprement
parler en zone urbaine, c'est quasiment un quartier à l'échelle de la
commune, qui inclut le gros bourg et ses petits hameaux et fermes isolées
tout autour). Ce cas se trouve facilement mais cela évite de les classer en
"village" avec pour conséquence de faire apparaitre sur la carte seulement
ne nom de ce bourg et pas celui de la commune sur son bourg le plus
important.

La carte devrait aussi malgré tout distinguer les "place=village" qui ont
une population indiquée (pour la commune entière), des autres
"place=village" qui n'ont pas de population indiquée (ni de numéro de
référence INSEE, sauf peut-être historique pour les anciennes communes)
elle n'est pas mesurée directement et car ce ne sont pas des unités
urbaines au plan statistique.

Les documentation des tags sont indicatives et il faut parfois les adapter,
surtout quand on a des données parcellaires, afin de pouvoir ensuite gérer
des priorités d'affichage avec des règles raisonnables.

Mais si les tags "place=*" sont pris de façon trop stricte, la seule façon
de gérer les priorités sera d'indiquer des chiffres de population fictifs
(juste grossièrement estimés, en indiquant en note qu'il ne s'agit que
d'une estimation grossière). C'est parfois utile lorsque le découpage
administratif est trop éloigné de la réalité urbaine actuelle. Mais plus
qu'une note pour ce cas il faudrait peut-être un tag particulier
"population:fictive=yes" pour ne pas perturber les utilisations sur des
rendus de cartes ou fichiers statistiques.



Le 21 août 2013 20:41, Christophe Merlet  a écrit :

> Le 21/08/2013 19:12, Tetsuo Shima a écrit :
>
>  Je demandais ca parce que j'ai du mal a savoir si les bizarrerie que je
>> trouve sont lié a un défaut dans les donnée, ou au rendu lui meme. En
>> fouillant je trouve pas mal de défaut dans les données des petite ville
>> et village, notamment la hiérarchisation village/hamlet qui semble très
>> flou. Pas mal d'agglomération sont taggé village - plus de 1000h - alors
>> quel devrai etre hamlet - quelques centaine d'habitant - au sens du wiki
>> notamment.
>>
>
> Je met systématiquement village au minimum pour toutes les communes
> quelques soit le nombre d'habitants.
>
> J'estime qu'un village de 50 habitants a plus d'importance sur une carte
> qu'un immeuble de 50 appartements !
>
>
>
> Librement,
> --
> Christophe Merlet (RedFox)
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] quai de fleuve = extra communalité ?!

[Philippe Verdy]

Le 21 août 2013 19:10, Yannick VOYEAUD  a écrit :

> Le 21/08/2013 17:37, David Crochet a écrit :
>
> Bonsoir,
>
> > Bonjour
> >
> > Le 21/08/2013 17:24, HParv a écrit :
> >> je
> >> n'ai pas connaissance du nom du quai d'après le cadastre et cette bande
> >> de quai n'appartient pas à la commune mais à l'Etat !
> >>
> >>
>
> Sur ce coup je doute de la véracité. Nous parlons bien d'un quai fluvial
>
> >
> > Ha, tiens, c'est drôle, cela me rappelle un ouï-dire tel que :
> >
> > - Le lac de Rabodange, les maires n'ont pas de compétences sur ce
> > domaine, il appartient à EDF
>
> Il faut vérifier le cadastre papier en mairie et selon toute
> vraisemblance c'est vrai. Il s'agit de propriété privée.
> EDF à même une portion de terre jouxtant tous ses ouvrages et rives
> liées à l'inondation des terres noyées. Théoriquement l'accès à tous ces
> plans d'eau est interdit du fait qu'il peut y avoir des lacher d'eau
> sans prévenir.
>
> >
> > Le Cimetière de Colleville-sur-Mer (scène mémorable du film "Il faut
> > sauver le Soldat Ryan") et ses dépendances sont territorialement à
> > l'état américain.
>
> C'est exact!
> L'ensemble des cimetières américains sont des territoires américains en
> tant que tel.


Extraterritorialité plutôt. C'est une propriété privée des Etats-Unis, non
soumise au droit et la fiscalité française. Un sorte de concession
perpétuelle donnée par la France aux Etats-Unis qui peuvent décider d'y
faire ce qu'ils veulent à condition de respecter le voisinage. Ce n'est pas
totalement sans condition, en particulier sur le respect de
l'environnement, la sécurité (pas de passe-droit pour y installer n'importe
quoi non plus, ni pour accorder de droit un corridor de transit
international.

A traiter de la même façon que les ambassades (qui ne sont pourtant pas des
concessions permanentes). Les accords ont prévu que la sécurité de ces
sites se fera en conformité avec le droit français : c'est le code de la
route français qui s'applique (il est appliqué par la justice américaine,
un juge américain est compétent à moins qu'il décide de déléguer à la
justice française).

Techniquement ces petits territoires (pas si petits que ça si on compare au
Vatican) n'ont pas d'activité économique ni de population suffisante pour
se gérer en dehors de la mission qui y a été installée. Mais les USA
pourraient aussi décider de rapatrier ces cimetières et réutiliser ces
territoires pour autre chose, y compris pour y installer une mission
diplomatique, ou le revendre en propriété privée (qui serait alors taxée
par les USA). Mais la question de la sécurité est largement déléguée à la
France qui s'est engagée à l'assurer. Mais la France ne peut rien dire (pas
plus que dans les ambassades) si des militaires américains viennent y
installer une base militaire et même un armement.

Mais dans les statuts constitutionnels américains, ces cimetières (qui
n'existent pas qu'en France, il y en a tout un tas en Asie et dans le
Pacifique aussi) ne sont pas recencés avec un statut comparable aux Etats
américains, ils n'ont pas d'autonomie. Ce sont des "possessions" plus que
des territoires américains, garanties par un traité (et un tel traité peut
être dénoncé si les parties en décident, et si cela devait avoir lieu cela
reviendra aussitôt à la France et à aucun autre pays, ce qui n'en fait donc
pas de vrais territoires américains puisque un droit français limité s'y
exerce toujours, même s'il est gelé par le traité que la France ne peut pas
décider seule de dénoncer, alors que les USA sont libres de le faire à tout
moment pour renoncer à leur possession et aux obligations qu'elles posent).

Il me semble aussi que pour les personnels employés sur place, c'est le
droit français qui s'applique (sauf que les prud'hommes français ne sont
pas compétents, à moins que le contrat précise le contraire), même si les
personnels ont un contrat signé aux USA, et sont payés en dollars
américains depuis un compte aux USA (cela n'a rien d'exceptionnel : on peut
être français et travailler essentiellement en France, dans la filiale
française d'une société étrangère, pourtant enregistrée en France, et être
payé dans une autre devise sur un compte siuté hors de France, et avec son
contrat signé aussi hors de France et qui pourtant précise une convention
collective française : ce sont des contrats privés de gré à gré ; tant que
les conditions françaises qui ne s'appliquent pas sont bien précisées dans
les contrats, c'est tout à fait légal).

Je pense que pour ces cimetières, il faut les voir comme des concessions
privées faite par l'Etat français à la fédération des USA, mais s'ils
décident de les abandonner, il ne peuvent pas les céder à qui ils veulent.
Mais si ils décident d'abandonner "l'activité cimetière" et d'en faire une
zone d'entreprises pour les taxer en dollars, et de les régir par le droit
privé américain avec un tribunal compétent quelque part en Europe, ou un
juge américain établi dans une ambassade américaine, ils le peuvent, et
s'il y a 

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

[Christophe Merlet]

Le 21/08/2013 19:12, Tetsuo Shima a écrit :

Je demandais ca parce que j'ai du mal a savoir si les bizarrerie que je
trouve sont lié a un défaut dans les donnée, ou au rendu lui meme. En
fouillant je trouve pas mal de défaut dans les données des petite ville
et village, notamment la hiérarchisation village/hamlet qui semble très
flou. Pas mal d'agglomération sont taggé village - plus de 1000h - alors
quel devrai etre hamlet - quelques centaine d'habitant - au sens du wiki
notamment.


Je met systématiquement village au minimum pour toutes les communes 
quelques soit le nombre d'habitants.


J'estime qu'un village de 50 habitants a plus d'importance sur une carte 
qu'un immeuble de 50 appartements !



Librement,
--
Christophe Merlet (RedFox)

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

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

[Pieren]

2013/8/21 Tetsuo Shima :

> Pas mal d'agglomération sont taggé village - plus de 1000h - alors quel
> devrai etre hamlet - quelques centaine d'habitant - au sens du wiki
> notamment.


Non. hamlet si <100 habitants, pas 1000. C'était 1000 dans le wiki
anglais par le passé mais 100 depuis toujours dans le wiki français.
Et ça a changé aussi dans le wiki anglais depuis pas mal de temps
maintenant.

Pieren

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

Re: [OSM-talk-fr] Piscines - était : Re: Circuits vélotourisme en Vaucluse

[JB]

 

En représentant leisure/amenity=swimming_pool, sans restriction d'accès
(no/private), voilà ce que ça donne :
http://osm107.openstreetmap.fr/jbtopo/piscines.PNG [5] sur le nord-est
d'Orange… Y'a du travail de nettoyage. 

Je ne suis pas convaincu par la présence du tag sport=swimming pour
indiquer l'accessibilité au public… Pour les piscines découvertes pour
villageois en vacances, ce tag ne se justifie pas toujours. Alors qu'un
access=*, lui… 

Et un sport=swimming sur ma piscine olympique privée ? 

JB. 

Le 21.08.2013 12:28, Yves Pratter a écrit : 

>> PS : t'ain, le nombre de piscines accessibles dans le sud… Ha, y'a p'têt des 
>> access=private qui manquent…
> J'ai regardé sur Orange avec OpenSeaMap, je n'en vois qu'une :-) 
> http://map.openseamap.org/map/?zoom=14&lat=44.13713&lon=4.80788&layers=BFTTFFT0TF
>  [2] 
> 
> Par contre à Châlon-sur-Saône, ça pleut des piscines :-D 
> 
> http://map.openseamap.org/map/?zoom=17&lat=46.77832&lon=4.80388&layers=BFTTFFT0TF
>  [3] 
> 
> Juste dans ce lotissement, il y a 13 piscines avec le tag SPORT=SWIMMING, et 
> dont seulement 7 ont ACCESS=PRIVATE. 
> 
> De plus celles qui ont ces attributs ne sont pas visibles dans le rendu 
> français et standard : 
> 
> * AMENITY=SWIMMING_POOL
> * sport=swimming
> 
> Alors que celles-ci sont bien visibles : 
> 
> * access=private
> * LEISURE=SWIMMING_POOL
> * sport=swimming
> 
> Le tag AMENITY=SWIMMING_POOL semble déprécié au profit de 
> LEISURE=SWIMMING_POOL. 
> Cf. http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dswimming_pool [4] 
> 
> Donc en résumé, 
> 
> Pour une piscine privée mettre uniquement : 
> 
> * access=private
> * LEISURE=SWIMMING_POOL
> 
> Pour un centre nautique où on peut pratiquer la natation : 
> 
> * LEISURE=SPORTS_CENTRE
> * sport=swimming
> 
> et ses bassins : 
> 
> * LEISURE=SWIMMING_POOL
> 
>   
> Une simple piscine publique faite pour nager : 
> 
> * LEISURE=SWIMMING_POOL
> * sport=swimming
> 
> Des plages ±aménagées où on peut pratiquer la natation : 
> 
> * LEISURE=BEACH_RESORT ou NATURAL=BEACH 
> * sport=swimming
> 
> -- 
> Yves 
> 
> PS: la couche sport d'OpenSeaMap ne se préoccupe que du tag sport=swimming 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr [1]

 

Links:
--
[1] http://lists.openstreetmap.org/listinfo/talk-fr
[2]
http://map.openseamap.org/map/?zoom=14&lat=44.13713&lon=4.80788&layers=BFTTFFT0TF
[3]
http://map.openseamap.org/map/?zoom=17&lat=46.77832&lon=4.80388&layers=BFTTFFT0TF
[4] http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dswimming_pool
[5] http://osm107.openstreetmap.fr/jbtopo/piscines.PNG
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] quai de fleuve = extra communalité ?!

[Yannick VOYEAUD]

Le 21/08/2013 17:37, David Crochet a écrit :

Bonsoir,

> Bonjour
> 
> Le 21/08/2013 17:24, HParv a écrit :
>> je
>> n'ai pas connaissance du nom du quai d'après le cadastre et cette bande
>> de quai n'appartient pas à la commune mais à l'Etat !
>>
>>

Sur ce coup je doute de la véracité. Nous parlons bien d'un quai fluvial

> 
> Ha, tiens, c'est drôle, cela me rappelle un ouï-dire tel que :
> 
> - Le lac de Rabodange, les maires n'ont pas de compétences sur ce
> domaine, il appartient à EDF

Il faut vérifier le cadastre papier en mairie et selon toute
vraisemblance c'est vrai. Il s'agit de propriété privée.
EDF à même une portion de terre jouxtant tous ses ouvrages et rives
liées à l'inondation des terres noyées. Théoriquement l'accès à tous ces
plans d'eau est interdit du fait qu'il peut y avoir des lacher d'eau
sans prévenir.

> 
> Le Cimetière de Colleville-sur-Mer (scène mémorable du film "Il faut
> sauver le Soldat Ryan") et ses dépendances sont territorialement à
> l'état américain.

C'est exact!
L'ensemble des cimetières américains sont des territoires américains en
tant que tel. Toutefois la sécurité publique est assurée par la France.
C'est le cas de TOUS les cimetières militaires étrangers en France.
Je dis bien cimetière militaire ET ne contenant exclusivement des
soldats étrangers de ce pays.

> 
> Bon d'accord, on est sur de l'extra-territorialité mais...
> 
> Je n'ai pas la certitude des information écrite précédemment, c'est
> fortement probable surtout pour le cimetière.
> 

Amitiés

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



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

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

[Tetsuo Shima]

Je demandais ca parce que j'ai du mal a savoir si les bizarrerie que je
trouve sont lié a un défaut dans les donnée, ou au rendu lui meme. En
fouillant je trouve pas mal de défaut dans les données des petite ville et
village, notamment la hiérarchisation village/hamlet qui semble très flou.
Pas mal d'agglomération sont taggé village - plus de 1000h - alors quel
devrai etre hamlet - quelques centaine d'habitant - au sens du wiki
notamment.


Le 21 août 2013 18:59, Christian Quest  a écrit :

> C'est trié par population décroissante, jusqu'à 0... par contre si c'est
> non renseigné (null) est-ce que ça ne sortirai pas en premier ?
> Pas impossible, et ça expliquerai ce désordre.
>
> J'ai encore fait une modif il n'y a pas 1h... et le zoom 12 est en
> recalcul.
>
> On va bientôt pouvoir démarrer le concours sur les coupures en bord de
> metatile ;)
>
> Petite nouveauté: une icône pour les bases aériennes...
>
> Je pense pouvoir bientôt basculer cette dernière version sur le rendu
> osmfr normal.
>
>
>
> Le 21 août 2013 17:38, Tetsuo Shima  a écrit :
>
> Christian,
>>
>> Comment fais tu pour trier les villages ayant le tag population rempli et
>> ceux ne l'ayant pas? Tu privilégie ceux qui l'ont? et jusqu'a qu'elle seuil
>> bas de population continues tu a trier? jusqu’à "0"?
>>
>> La derniere mouture est bien mieux mais je vois encore quelques
>> bizarrerie sur les petite agglomération, notament entre village et hamlet
>> et ceux ayant des population ou pas, certain étant tres proche les uns des
>> autres, parfois les "village" sans population semble prendre le pas sur le
>> village d’à coté avec un tag population même si celle ci est assez réduite
>> - genre 800h -.
>>
>>
>> Le 21 août 2013 13:27, Christian Quest  a écrit
>> :
>>
>> Ouille... ça pique les yeux !
>>>
>>> La faute aux ronds-points...
>>>
>>> J'ai rectifié le tir en revoyant complètement la façon de faire (une
>>> fois de plus). Finie la fusion des tronçons, maintenant je limite les
>>> cartouches en me basant sur la longueur de ceux-ci. C'est pas idéal (ça en
>>> retire beaucoup il où ils sont fortement segmentés) mais ça semble donner
>>> de bons résultats.
>>>
>>> Toulouse:
>>> http://tile.openstreetmap.fr/?zoom=12&lat=43.63783&lon=1.39339&layers=B00FFF
>>>
>>>
>>>
>>> Le 20 août 2013 21:24, Lord Awikatchikaen a 
>>> écrit :
>>>
>>> Sur toulouse, ca a l'effet inverse, il y a plus de cartouches qu'avant
 (exemple de la D1 et D2 en haut a gauche) et on ne voit plus les autoroutes
 A621 et A624.

 Le mar. 20 août 2013 19:44:55 CEST, Christian Quest a écrit :

> J'ai retravaillé le placement des noms de ville et des cartouches de
> références de route.
>
> Pour l'instant c'est visible sur le zoom 12 du layer
> "osmfr-lowzoom-test" à comparer avec osmfr et osm-defaut.
>
> Exemple (dans le même coin Evrux/Dreux):
> http://tile.openstreetmap.fr/?**zoom=12&lat=49.04611&lon=1.**
> 01288&layers=B00FFF
>
> Vous verrez que j'ai aussi fait apparaitre les tertiary à partir du
> zoom 12 (qui est en cours de recalcul sur l'hexagone, ça sera terminé
> vers 20h30).
>
> Un peu de cuisine:
> - les morceaux de routes portant le même type et ref sont regroupés
> pour éviter trop de répétition des cartouches
> - les cartouches sont placés par priorité de type de route (motorway >
> trunk > primary > secondary) puis par longueur de tronçon (regroupé
> donc) décroissante.
>
> Les plus curieux peuvent voir les commit sur github.
>
> Je lancerai un recalcul des zooms 9 à 11 dans la soirée... ça sera
> donc à jour demain matin pour le monde entier.
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... 
> http://donate.osm.org/**server2013/
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>



>>>
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>>>
>>> ___
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> http://lists.openstreetmap.org/listinfo/talk-fr
>>>
>>>
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-

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

[Christian Quest]

C'est trié par population décroissante, jusqu'à 0... par contre si c'est
non renseigné (null) est-ce que ça ne sortirai pas en premier ?
Pas impossible, et ça expliquerai ce désordre.

J'ai encore fait une modif il n'y a pas 1h... et le zoom 12 est en recalcul.

On va bientôt pouvoir démarrer le concours sur les coupures en bord de
metatile ;)

Petite nouveauté: une icône pour les bases aériennes...

Je pense pouvoir bientôt basculer cette dernière version sur le rendu osmfr
normal.



Le 21 août 2013 17:38, Tetsuo Shima  a écrit :

> Christian,
>
> Comment fais tu pour trier les villages ayant le tag population rempli et
> ceux ne l'ayant pas? Tu privilégie ceux qui l'ont? et jusqu'a qu'elle seuil
> bas de population continues tu a trier? jusqu’à "0"?
>
> La derniere mouture est bien mieux mais je vois encore quelques bizarrerie
> sur les petite agglomération, notament entre village et hamlet et ceux
> ayant des population ou pas, certain étant tres proche les uns des autres,
> parfois les "village" sans population semble prendre le pas sur le village
> d’à coté avec un tag population même si celle ci est assez réduite - genre
> 800h -.
>
>
> Le 21 août 2013 13:27, Christian Quest  a écrit :
>
> Ouille... ça pique les yeux !
>>
>> La faute aux ronds-points...
>>
>> J'ai rectifié le tir en revoyant complètement la façon de faire (une fois
>> de plus). Finie la fusion des tronçons, maintenant je limite les cartouches
>> en me basant sur la longueur de ceux-ci. C'est pas idéal (ça en retire
>> beaucoup il où ils sont fortement segmentés) mais ça semble donner de bons
>> résultats.
>>
>> Toulouse:
>> http://tile.openstreetmap.fr/?zoom=12&lat=43.63783&lon=1.39339&layers=B00FFF
>>
>>
>>
>> Le 20 août 2013 21:24, Lord Awikatchikaen a 
>> écrit :
>>
>> Sur toulouse, ca a l'effet inverse, il y a plus de cartouches qu'avant
>>> (exemple de la D1 et D2 en haut a gauche) et on ne voit plus les autoroutes
>>> A621 et A624.
>>>
>>> Le mar. 20 août 2013 19:44:55 CEST, Christian Quest a écrit :
>>>
 J'ai retravaillé le placement des noms de ville et des cartouches de
 références de route.

 Pour l'instant c'est visible sur le zoom 12 du layer
 "osmfr-lowzoom-test" à comparer avec osmfr et osm-defaut.

 Exemple (dans le même coin Evrux/Dreux):
 http://tile.openstreetmap.fr/?**zoom=12&lat=49.04611&lon=1.**
 01288&layers=B00FFF

 Vous verrez que j'ai aussi fait apparaitre les tertiary à partir du
 zoom 12 (qui est en cours de recalcul sur l'hexagone, ça sera terminé
 vers 20h30).

 Un peu de cuisine:
 - les morceaux de routes portant le même type et ref sont regroupés
 pour éviter trop de répétition des cartouches
 - les cartouches sont placés par priorité de type de route (motorway >
 trunk > primary > secondary) puis par longueur de tronçon (regroupé
 donc) décroissante.

 Les plus curieux peuvent voir les commit sur github.

 Je lancerai un recalcul des zooms 9 à 11 dans la soirée... ça sera
 donc à jour demain matin pour le monde entier.

 --
 Christian Quest - OpenStreetMap France
 Un nouveau serveur pour OSM... 
 http://donate.osm.org/**server2013/


 __**_
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-fr

>>>
>>>
>>>
>>
>>
>> --
>> Christian Quest - OpenStreetMap France
>> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Tetsuo Shima]

Christian,

Comment fais tu pour trier les villages ayant le tag population rempli et
ceux ne l'ayant pas? Tu privilégie ceux qui l'ont? et jusqu'a qu'elle seuil
bas de population continues tu a trier? jusqu’à "0"?

La derniere mouture est bien mieux mais je vois encore quelques bizarrerie
sur les petite agglomération, notament entre village et hamlet et ceux
ayant des population ou pas, certain étant tres proche les uns des autres,
parfois les "village" sans population semble prendre le pas sur le village
d’à coté avec un tag population même si celle ci est assez réduite - genre
800h -.


Le 21 août 2013 13:27, Christian Quest  a écrit :

> Ouille... ça pique les yeux !
>
> La faute aux ronds-points...
>
> J'ai rectifié le tir en revoyant complètement la façon de faire (une fois
> de plus). Finie la fusion des tronçons, maintenant je limite les cartouches
> en me basant sur la longueur de ceux-ci. C'est pas idéal (ça en retire
> beaucoup il où ils sont fortement segmentés) mais ça semble donner de bons
> résultats.
>
> Toulouse:
> http://tile.openstreetmap.fr/?zoom=12&lat=43.63783&lon=1.39339&layers=B00FFF
>
>
>
> Le 20 août 2013 21:24, Lord Awikatchikaen a 
> écrit :
>
> Sur toulouse, ca a l'effet inverse, il y a plus de cartouches qu'avant
>> (exemple de la D1 et D2 en haut a gauche) et on ne voit plus les autoroutes
>> A621 et A624.
>>
>> Le mar. 20 août 2013 19:44:55 CEST, Christian Quest a écrit :
>>
>>> J'ai retravaillé le placement des noms de ville et des cartouches de
>>> références de route.
>>>
>>> Pour l'instant c'est visible sur le zoom 12 du layer
>>> "osmfr-lowzoom-test" à comparer avec osmfr et osm-defaut.
>>>
>>> Exemple (dans le même coin Evrux/Dreux):
>>> http://tile.openstreetmap.fr/?**zoom=12&lat=49.04611&lon=1.**
>>> 01288&layers=B00FFF
>>>
>>> Vous verrez que j'ai aussi fait apparaitre les tertiary à partir du
>>> zoom 12 (qui est en cours de recalcul sur l'hexagone, ça sera terminé
>>> vers 20h30).
>>>
>>> Un peu de cuisine:
>>> - les morceaux de routes portant le même type et ref sont regroupés
>>> pour éviter trop de répétition des cartouches
>>> - les cartouches sont placés par priorité de type de route (motorway >
>>> trunk > primary > secondary) puis par longueur de tronçon (regroupé
>>> donc) décroissante.
>>>
>>> Les plus curieux peuvent voir les commit sur github.
>>>
>>> Je lancerai un recalcul des zooms 9 à 11 dans la soirée... ça sera
>>> donc à jour demain matin pour le monde entier.
>>>
>>> --
>>> Christian Quest - OpenStreetMap France
>>> Un nouveau serveur pour OSM... 
>>> http://donate.osm.org/**server2013/
>>>
>>>
>>> __**_
>>> Talk-fr mailing list
>>> Talk-fr@openstreetmap.org
>>> http://lists.openstreetmap.**org/listinfo/talk-fr
>>>
>>
>>
>>
>
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] quai de fleuve = extra communalité ?!

[David Crochet]

Bonjour

Le 21/08/2013 17:24, HParv a écrit :

je
n'ai pas connaissance du nom du quai d'après le cadastre et cette bande
de quai n'appartient pas à la commune mais à l'Etat !




Ha, tiens, c'est drôle, cela me rappelle un ouï-dire tel que :

- Le lac de Rabodange, les maires n'ont pas de compétences sur ce 
domaine, il appartient à EDF


Le Cimetière de Colleville-sur-Mer (scène mémorable du film "Il faut 
sauver le Soldat Ryan") et ses dépendances sont territorialement à 
l'état américain.


Bon d'accord, on est sur de l'extra-territorialité mais...

Je n'ai pas la certitude des information écrite précédemment, c'est 
fortement probable surtout pour le cimetière.


Cordialement


--
David Crochet

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

[OSM-talk-fr] quai de fleuve = extra communalité ?!

[HParv]

Bonjour,

Souhaitant vérifier le nom donné au quai de Seine sur Bonsecours 76103  
(limitrophe Rouen 76540) auprès de la Mairie, celle-ci me répond : je 
n'ai pas connaissance du nom du quai d'après le cadastre et cette bande 
de quai n'appartient pas à la commune mais à l'Etat !


Oups !
--
Hugues P. GCS RRAMUHN
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Arrets de bus, nouvelles conventions

[Tony Emery]

cquest wrote
> Cela conforte ma méfiance pour les beaux modèles de données qui sont des
> usines à gaz.

Oui, et encore, on n'a pas ajouté à tout ça le modèle de calcul d'itinéraire
multimodale type GTFS ou autre. Là, c'est plus une usine à gaz mais une zone
industrielle d'usines à gaz...



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Arrets-de-bus-nouvelles-conventions-tp5774231p5774381.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-fr] Arrets de bus, nouvelles conventions

[Christian Quest]

Bon... comment dire...

public_transport=platform ne contient aucune information sur le type de
transport. Ca peut donc être un arrêt de bus, de train, de tram, de métro...
Pour savoir à quoi on à affaire, il faut remonter la relation stop_area si
elle existe et voir si un des membres (lequel ?) a un bus=yes sur un des
stop_position.

Bref, un truc pas à la portée d'un schéma habituel osm2pgsql sauf à sortir
l'artillerie lourde (en temps d'exécution) et les hacks.

highway=bus_stop a encore de beaux jours devant lui et l'avantage de
pouvoir être facile à maintenir par un humain avec un éditeur simple !


Cela conforte ma méfiance pour les beaux modèles de données qui sont des
usines à gaz.




Le 20 août 2013 15:54, Christian Quest  a écrit :

> Ni le rendu OSM, ni le rendu OSMFR, ni celui de MapQuest ne gèrent le
> schéma public_transport.
>
> Ceci explique cela.
>
> En gros, j'ai plus qu'à m'y coller ;)
>
>
>
> Le 20 août 2013 15:39, Dominique Rousseau  a écrit :
>
> Hello,
>>
>> J'ai pas trouvé de sujet récent sur le sujet, n'hésitez pas à me
>> rediriger si le sujet a déjà été évoqué.
>>
>> Récemment, j'ai ajouté quelques arrets de bus, à Amiens.
>> Mais, tristement, ils n'apparaissent sur aucun des rendus accessibles
>> sur tile.osm.fr :
>>
>>
>> http://tile.openstreetmap.fr/?zoom=18&lat=49.87312&lon=2.32566&layers=B00FFF
>>
>> Là, au bout de la cité des castors, il devrait y en avoir 2, presque
>> face à face.
>> J'ai suivi la nouvelle convention évqouée là :
>> http://wiki.openstreetmap.org/wiki/Public_transport#Buses
>>
>> (d'ailleurs, j'ai encore bien fouillé la différence stop/platform)
>>
>> Quelqu'un a un avis sur le sujet ?
>>
>>
>> --
>> Dominique Rousseau
>> d...@lee-loo.net - 06 82 43 12 27
>>
>> A l'instant où l'esclave décide qu'il ne sera plus esclave,
>> ses chaînes tombent.  -- Mahatma Gandhi
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> Christian Quest - OpenStreetMap France
> Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
>



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Arrets de bus, nouvelles conventions

[Richard Genoud]

Le 21 août 2013 14:16, Francescu GAROBY  a écrit :
> Et ça, sur un arrêt un peu plus complexe :
> http://www.openstreetmap.org/#map=18/49.18051/-0.36297&layers=T

D'ailleurs, ça me rappelle qu'il doit y avoir une distance maximale ou
quelque chose du genre car ici :
http://www.openstreetmap.org/#map=17/45.84372/4.73509&layers=T
Il y a 3 arrêts "domartin - la chicotière" dans la stop area et
seulement 2 encerclés.
C'est vrai que la configuration n'est pas banale, mais bon, c'est comme ça...



-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?

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

Re: [OSM-talk-fr] Arrets de bus, nouvelles conventions

[Francescu GAROBY]

Et ça, sur un arrêt un peu plus complexe :
http://www.openstreetmap.org/#map=18/49.18051/-0.36297&layers=T

Francescu


Le 21 août 2013 14:10, Richard Genoud  a écrit :

> Le 21 août 2013 13:14, Pieren  a écrit :
> > 2013/8/21 Dominique Rousseau :
> >
> >> En fait, j'ai commencé à chercher comment représenter les cas comme
> >> celui que j'ai, où les arrêts portant le même nom ne sont pas en face
> >> l'un de l'autre.
> >> (et d'ailleurs, je suis en train de me dire qu'il faudrait un stop_area
> >> pour un sens, un pour l'autre, et un stop_area_group pour assembler les
> >> 2, pour ce cas là)
> >
> >
> > D'après le wiki, je cite:
> > http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area
> >
> > "A stop area for a simple bus stop with buses in both direction and
> > two bus stops would consist of a two bus stops (or 'platforms') which
> > can be tagged using (public_transport=platform or highway=bus_stop)
> > and two stop positions (using public_transport=stop_position)."
> >
> > Il faudrait donc une seule relation "stop_area" pour la station et ses
> > deux positions d'arrêt, un par direction. Si le bus s'arrête à des
> > endroits différents suivant la direction, il faut mettre un noeud par
> > direction sur le way "highway". La proximité géométrique déterminera
> > quel "stop" appartient à quelle "platform", je suppose.
>
> exact, et cela donne quelque chose comme ça :
> http://www.openstreetmap.org/#map=18/45.98438/4.72669&layers=T
> sur un arrêt de bus simple, à double sens.
>
>
> --
> for me, ck means con kolivas and not calvin klein... does it mean I'm a
> geek ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



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

Re: [OSM-talk-fr] Arrets de bus, nouvelles conventions

[Richard Genoud]

Le 21 août 2013 13:14, Pieren  a écrit :
> 2013/8/21 Dominique Rousseau :
>
>> En fait, j'ai commencé à chercher comment représenter les cas comme
>> celui que j'ai, où les arrêts portant le même nom ne sont pas en face
>> l'un de l'autre.
>> (et d'ailleurs, je suis en train de me dire qu'il faudrait un stop_area
>> pour un sens, un pour l'autre, et un stop_area_group pour assembler les
>> 2, pour ce cas là)
>
>
> D'après le wiki, je cite:
> http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area
>
> "A stop area for a simple bus stop with buses in both direction and
> two bus stops would consist of a two bus stops (or 'platforms') which
> can be tagged using (public_transport=platform or highway=bus_stop)
> and two stop positions (using public_transport=stop_position)."
>
> Il faudrait donc une seule relation "stop_area" pour la station et ses
> deux positions d'arrêt, un par direction. Si le bus s'arrête à des
> endroits différents suivant la direction, il faut mettre un noeud par
> direction sur le way "highway". La proximité géométrique déterminera
> quel "stop" appartient à quelle "platform", je suppose.

exact, et cela donne quelque chose comme ça :
http://www.openstreetmap.org/#map=18/45.98438/4.72669&layers=T
sur un arrêt de bus simple, à double sens.


-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?

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

Re: [OSM-talk-fr] Arrets de bus, nouvelles conventions

[Christian Quest]

Le 21 août 2013 13:14, Pieren  a écrit :

>
> Il faudrait donc une seule relation "stop_area" pour la station et ses
> deux positions d'arrêt, un par direction. Si le bus s'arrête à des
> endroits différents suivant la direction, il faut mettre un noeud par
> direction sur le way "highway". La proximité géométrique déterminera
> quel "stop" appartient à quelle "platform", je suppose.
>

Ce qui montre bien quelque part une certaine incohérence dans ce fatra de
relations.
J'avais aussi noté des problèmes avec les quais des gares pour indiquer à
quelle direction ils correspondaient.

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

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

[Christian Quest]

Ouille... ça pique les yeux !

La faute aux ronds-points...

J'ai rectifié le tir en revoyant complètement la façon de faire (une fois
de plus). Finie la fusion des tronçons, maintenant je limite les cartouches
en me basant sur la longueur de ceux-ci. C'est pas idéal (ça en retire
beaucoup il où ils sont fortement segmentés) mais ça semble donner de bons
résultats.

Toulouse:
http://tile.openstreetmap.fr/?zoom=12&lat=43.63783&lon=1.39339&layers=B00FFF



Le 20 août 2013 21:24, Lord Awikatchikaen  a
écrit :

> Sur toulouse, ca a l'effet inverse, il y a plus de cartouches qu'avant
> (exemple de la D1 et D2 en haut a gauche) et on ne voit plus les autoroutes
> A621 et A624.
>
> Le mar. 20 août 2013 19:44:55 CEST, Christian Quest a écrit :
>
>> J'ai retravaillé le placement des noms de ville et des cartouches de
>> références de route.
>>
>> Pour l'instant c'est visible sur le zoom 12 du layer
>> "osmfr-lowzoom-test" à comparer avec osmfr et osm-defaut.
>>
>> Exemple (dans le même coin Evrux/Dreux):
>> http://tile.openstreetmap.fr/?**zoom=12&lat=49.04611&lon=1.**
>> 01288&layers=B00FFF
>>
>> Vous verrez que j'ai aussi fait apparaitre les tertiary à partir du
>> zoom 12 (qui est en cours de recalcul sur l'hexagone, ça sera terminé
>> vers 20h30).
>>
>> Un peu de cuisine:
>> - les morceaux de routes portant le même type et ref sont regroupés
>> pour éviter trop de répétition des cartouches
>> - les cartouches sont placés par priorité de type de route (motorway >
>> trunk > primary > secondary) puis par longueur de tronçon (regroupé
>> donc) décroissante.
>>
>> Les plus curieux peuvent voir les commit sur github.
>>
>> Je lancerai un recalcul des zooms 9 à 11 dans la soirée... ça sera
>> donc à jour demain matin pour le monde entier.
>>
>> --
>> Christian Quest - OpenStreetMap France
>> Un nouveau serveur pour OSM... 
>> http://donate.osm.org/**server2013/
>>
>>
>> __**_
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.**org/listinfo/talk-fr
>>
>
>
>


-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Arrets de bus, nouvelles conventions

[Pieren]

2013/8/21 Dominique Rousseau :

> En fait, j'ai commencé à chercher comment représenter les cas comme
> celui que j'ai, où les arrêts portant le même nom ne sont pas en face
> l'un de l'autre.
> (et d'ailleurs, je suis en train de me dire qu'il faudrait un stop_area
> pour un sens, un pour l'autre, et un stop_area_group pour assembler les
> 2, pour ce cas là)


D'après le wiki, je cite:
http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area

"A stop area for a simple bus stop with buses in both direction and
two bus stops would consist of a two bus stops (or 'platforms') which
can be tagged using (public_transport=platform or highway=bus_stop)
and two stop positions (using public_transport=stop_position)."

Il faudrait donc une seule relation "stop_area" pour la station et ses
deux positions d'arrêt, un par direction. Si le bus s'arrête à des
endroits différents suivant la direction, il faut mettre un noeud par
direction sur le way "highway". La proximité géométrique déterminera
quel "stop" appartient à quelle "platform", je suppose.

Pieren

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

Re: [OSM-talk-fr] Arrets de bus, nouvelles conventions

[Pieren]

2013/8/21 Richard Genoud :

> une relation public transport=stop_area qui contient :
> - les 1 ou 2 stop_position (role=stop)
> - les 2 platform (role=platform)
> (2 pour les 2 sens de circulation, s'il n'y a qu'un sens, ben... ça
> tombe sous le sens)
> et le public transport= stop_position est sur le chemin et :
> - appartient à la relation stop area
> - appartient à la relation route (uniquement dans le sens que l'on veut)
>
> c'est juste un petit aide mémoire...

Et pour ceux qui ne veulent pas se prendre la tête avec 26 relations
et 45 noeuds pour un simple arrêt de bus mais qui veulent quand même
l'indiquer sur la carte, ils peuvent continuer à mettre simplement un
noeud à côté du way, là où les gens attendent le bus et mettre le tag
"highway=bus_stop". Ceux qui adoptent le nouveau schéma sauront mettre
à profit cette information et mettre les tags et relations ki faut.

Pieren

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

Re: [OSM-talk-fr] Arrets de bus, nouvelles conventions

[Dominique Rousseau]

Le Wed, Aug 21, 2013 at 12:53:29PM +0200, Christian Quest 
[cqu...@openstreetmap.fr] a écrit:
> Le highway_bus_stop devrait plutôt être sur le public_transport=platform,
> c'est à dire là où on attends le bus. 

C'est juste. Je modifierai dans ce sens.

[...]

> Le schéma public_transport est intéressant pour les cas compliqués, mais
> complique inutilement les cas simples que ce soit pour la saisie ET pour la
> réutilisation... vraiment dommage.

En fait, j'ai commencé à chercher comment représenter les cas comme
celui que j'ai, où les arrêts portant le même nom ne sont pas en face
l'un de l'autre.
(et d'ailleurs, je suis en train de me dire qu'il faudrait un stop_area
pour un sens, un pour l'autre, et un stop_area_group pour assembler les
2, pour ce cas là)


-- 
Dominique Rousseau
d...@lee-loo.net - 06 82 43 12 27

A l'instant où l'esclave décide qu'il ne sera plus esclave,
ses chaînes tombent.  -- Mahatma Gandhi

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

Re: [OSM-talk-fr] Arrets de bus, nouvelles conventions

[Christian Quest]

Le highway_bus_stop devrait plutôt être sur le public_transport=platform,
c'est à dire là où on attends le bus. On peut d'ailleurs déduire
topologiquement le stop si on a besoin en projetant sur le highway=*
emprunté par l'itinéraire, voire si pas d'itinéraire définit sur la route
la plus proche.

Le schéma public_transport est intéressant pour les cas compliqués, mais
complique inutilement les cas simples que ce soit pour la saisie ET pour la
réutilisation... vraiment dommage.
Je ne l'utilise donc que pour les cas compliqués comme les regroupements
d'arrêts ou les nœuds multimodaux (correspondances entre bus-metro, etc).



Le 21 août 2013 12:47, Dominique Rousseau  a écrit :

> Le Wed, Aug 21, 2013 at 11:18:32AM +0200, Richard Genoud [
> richard.gen...@gmail.com] a écrit:
> > Le 20 août 2013 16:06, Pieren  a écrit :
> > > 2013/8/20 Dominique Rousseau :
> > >
> > >> J'ai suivi la nouvelle convention évqouée là :
> > >> http://wiki.openstreetmap.org/wiki/Public_transport#Buses
> > >> (d'ailleurs, j'ai encore bien fouillé la différence stop/platform)
>
> [...]
>
> > une relation public transport=stop_area qui contient :
> > - les 1 ou 2 stop_position (role=stop)
> > - les 2 platform (role=platform)
> > (2 pour les 2 sens de circulation, s'il n'y a qu'un sens, ben... ça
> > tombe sous le sens)
> >
> > et le public transport= stop_position est sur le chemin et :
> > - appartient à la relation stop area
> > - appartient à la relation route (uniquement dans le sens que l'on veut)
>
> Merci à tous pour les réponses !
>
> J'ai essayé d'appliquer ça à l'arret "Edmond Rostand" :
>
>
> http://tile.openstreetmap.fr/?zoom=18&lat=49.87491&lon=2.32949&layers=00BFFF
>
> (et j'ai triché un peu en mettant bus_stop sur les "stop")
>
> Pour l'attribut "name", je l'ai collé sur tous les objets, mais ça me
> parait particulièrement redondant.
>
>
> --
> Dominique Rousseau
> d...@lee-loo.net - 06 82 43 12 27
>
> A l'instant où l'esclave décide qu'il ne sera plus esclave,
> ses chaînes tombent.  -- Mahatma Gandhi
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Arrets de bus, nouvelles conventions

[Dominique Rousseau]

Le Wed, Aug 21, 2013 at 11:18:32AM +0200, Richard Genoud 
[richard.gen...@gmail.com] a écrit:
> Le 20 août 2013 16:06, Pieren  a écrit :
> > 2013/8/20 Dominique Rousseau :
> >
> >> J'ai suivi la nouvelle convention évqouée là :
> >> http://wiki.openstreetmap.org/wiki/Public_transport#Buses
> >> (d'ailleurs, j'ai encore bien fouillé la différence stop/platform)

[...]

> une relation public transport=stop_area qui contient :
> - les 1 ou 2 stop_position (role=stop)
> - les 2 platform (role=platform)
> (2 pour les 2 sens de circulation, s'il n'y a qu'un sens, ben... ça
> tombe sous le sens)
> 
> et le public transport= stop_position est sur le chemin et :
> - appartient à la relation stop area
> - appartient à la relation route (uniquement dans le sens que l'on veut)

Merci à tous pour les réponses !

J'ai essayé d'appliquer ça à l'arret "Edmond Rostand" :

http://tile.openstreetmap.fr/?zoom=18&lat=49.87491&lon=2.32949&layers=00BFFF

(et j'ai triché un peu en mettant bus_stop sur les "stop")

Pour l'attribut "name", je l'ai collé sur tous les objets, mais ça me
parait particulièrement redondant.


-- 
Dominique Rousseau
d...@lee-loo.net - 06 82 43 12 27

A l'instant où l'esclave décide qu'il ne sera plus esclave,
ses chaînes tombent.  -- Mahatma Gandhi

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

Re: [OSM-talk-fr] Arrets de bus, nouvelles conventions

[Christian Quest]

Et sur la carte... je propose de représenter le public_transport=platform,
ok ?


Le 21 août 2013 11:18, Richard Genoud  a écrit :

> Le 20 août 2013 16:06, Pieren  a écrit :
> > 2013/8/20 Dominique Rousseau :
> >
> >> J'ai suivi la nouvelle convention évqouée là :
> >> http://wiki.openstreetmap.org/wiki/Public_transport#Buses
> >> (d'ailleurs, j'ai encore bien fouillé la différence stop/platform)
> >
> > Tu as mis un noeud sur le trottoir avec
> > "public_transport=stop_position". D'après la "nouvelle convention", il
> > faudrait mettre "public_transport=platform" si c'est là que les gens
> > attendent. Si tu veux aussi marquer l'endroit où le bus lui-même
> > s'arrête, tu as le bon tag "stop_position" mais je crois qu'il faut le
> > mettre sur le highway directement (pas à côté). Après, tu enrobes le
> > tout dans une relation de type "public_transport"+"stop_area" (les
> > experts me corrigeront ici si je me trompe)
> > Il est possible que la plupart des logiciels de rendu ne reconnaissent
> > que l'ancien tag "highway=bus_stop" qui indique l'arrêt pour les
> > usagers. Trop simple. Ce qui expliquerait que la motié des noeuds
> > tagguées en "public_transport=platform" le sont aussi en
> > "highway=bus_stop" (mais on ne taggue pas pour le rendu, hein) ;-)
> > Pour ceux qui ont raté le début du film, la proposition
> > "public_transport" est poussée par une petite partie de la communauté
> > qui s'intéresse à la représentation du réseau de transport et de ses
> > lignes dans le détail (vu côté transporteur) et est assez compliqué.
> > En plus avec la mauvaise idée de vouloir remplacer un tag déjà ancien
> > et largement utilisé "highway=bus_stop" par un autre sans réel
> > avantage (si ce n'est la cohérence, tient ça me rapelle une autre
> > affaire ;-).
> > L'identification complète d'une ligne de bus n'est pas quelque chose à
> > la portée des débutants.
>
> Il y a un exemple de ligne de bus que j'avais fait sur villefranche en
> essayant de respecter la nouvelle convention.
> mais, je confirme, c'est hardos pour un débutant (j'en avais un peu
> bavé... surtout qu'une ligne pouvait avoir 4 parcours différents !)
> http://wiki.openstreetmap.org/wiki/Villefranche-sur-Sa%C3%B4ne
> d'après ce que je m'étais noté à l'époque, on doit avoir :
>
> une relation public transport=stop_area qui contient :
> - les 1 ou 2 stop_position (role=stop)
> - les 2 platform (role=platform)
> (2 pour les 2 sens de circulation, s'il n'y a qu'un sens, ben... ça
> tombe sous le sens)
>
> et le public transport= stop_position est sur le chemin et :
> - appartient à la relation stop area
> - appartient à la relation route (uniquement dans le sens que l'on veut)
>
> c'est juste un petit aide mémoire...
>
>
> --
> for me, ck means con kolivas and not calvin klein... does it mean I'm a
> geek ?
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Piscines - était : Re: Circuits vélotourisme en Vaucluse

[Yves Pratter]

PS : t'ain, le nombre de piscines accessibles dans le sud… Ha, y'a p'têt des access=private qui manquent…J'ai regardé sur Orange avec OpenSeaMap, je n'en vois qu'une :-)http://map.openseamap.org/map/?zoom=14&lat=44.13713&lon=4.80788&layers=BFTTFFT0TFPar contre à Châlon-sur-Saône, ça pleut des piscines :-Dhttp://map.openseamap.org/map/?zoom=17&lat=46.77832&lon=4.80388&layers=BFTTFFT0TFJuste dans ce lotissement, il y a 13 piscines avec le tag sport=swimming, et dont seulement 7 ont access=private.De plus celles qui ont ces attributs ne sont pas visibles dans le rendu français et standard :amenity=swimming_poolsport=swimmingAlors que celles-ci sont bien visibles :access=privateleisure=swimming_poolsport=swimmingLe tag amenity=swimming_pool semble déprécié au profit de leisure=swimming_pool.Cf. http://wiki.openstreetmap.org/wiki/Tag:leisure%3Dswimming_poolDonc en résumé, Pour une piscine privée mettre uniquement :access=privateleisure=swimming_poolPour un centre nautique où on peut pratiquer la natation :leisure=sports_centresport=swimminget ses bassins :leisure=swimming_poolUne simple piscine publique faite pour nager :leisure=swimming_poolsport=swimmingDes plages ±aménagées où on peut pratiquer la natation :leisure=beach_resort ou natural=beach sport=swimming--YvesPS: la couche sport d'OpenSeaMap ne se préoccupe que du tag sport=swimming___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Infographie sur l'évolution de New-York sous la mandature Bloomberg

[Ista Pouss]

Le 21 août 2013 11:03, Jean-Marc Liotier  a écrit :

> On 21/08/2013 10:56, François Lacombe wrote:
>
>> Ne pas avoir de distinction possible des éditions de maintenance (pour
>> corriger des erreurs ou des incohérences, des choses qui n'ont jamais
>> existé sur le terrain) des éditions de mise à jour (le terrain a
>> effectivement changé à une date bien précise et OSM doit suivre) est un
>> vrai handicap.
>>
>
> Certes, mais ça n'a jamais fait partie des besoins traités par
> Openstreetmap - tous les aspects du projet ont toujours été explicitement
> dédiés à fournir la vision à jour. Au-delà du problème de modélisation et
> d'outillage, l'exploitation serait une charge considérable: une vision
> historique est en pratique un empilement de visions instantanées qu'il faut
> toutes tenir à jour avec le même niveau d'effort que celle à jour.
> L'introduction de dates d'effet dans les métadonnées n'est que le premier
> pas qu'un tel Openhistorymap devrait franchir.
>
>
>
+1.

Cependant il me semble qu'il faut appuyer l'usage du tag "source"
http://wiki.openstreetmap.org/wiki/Key:source ou
http://wiki.openstreetmap.org/wiki/FR:Key:source, particulièrement, pour le
terrain, l'usage de survey, tel que je comprends les choses, avec
"source=Survey 10 Nov 2012", qui correspond plus ou moins avec l'idée de
François Lacombe.

Avec ça on ne pourrait de toutes façons pas faire l'animation du nytimes,
mais au moins celle des observations terrain :-)

Toutefois du cependant, je n'ai vu nulle part dans les tags la notion "je
corrige une erreur" ? Ce serait utile, pas utile ?... Je médite...
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Arrets de bus, nouvelles conventions

[Richard Genoud]

Le 20 août 2013 16:06, Pieren  a écrit :
> 2013/8/20 Dominique Rousseau :
>
>> J'ai suivi la nouvelle convention évqouée là :
>> http://wiki.openstreetmap.org/wiki/Public_transport#Buses
>> (d'ailleurs, j'ai encore bien fouillé la différence stop/platform)
>
> Tu as mis un noeud sur le trottoir avec
> "public_transport=stop_position". D'après la "nouvelle convention", il
> faudrait mettre "public_transport=platform" si c'est là que les gens
> attendent. Si tu veux aussi marquer l'endroit où le bus lui-même
> s'arrête, tu as le bon tag "stop_position" mais je crois qu'il faut le
> mettre sur le highway directement (pas à côté). Après, tu enrobes le
> tout dans une relation de type "public_transport"+"stop_area" (les
> experts me corrigeront ici si je me trompe)
> Il est possible que la plupart des logiciels de rendu ne reconnaissent
> que l'ancien tag "highway=bus_stop" qui indique l'arrêt pour les
> usagers. Trop simple. Ce qui expliquerait que la motié des noeuds
> tagguées en "public_transport=platform" le sont aussi en
> "highway=bus_stop" (mais on ne taggue pas pour le rendu, hein) ;-)
> Pour ceux qui ont raté le début du film, la proposition
> "public_transport" est poussée par une petite partie de la communauté
> qui s'intéresse à la représentation du réseau de transport et de ses
> lignes dans le détail (vu côté transporteur) et est assez compliqué.
> En plus avec la mauvaise idée de vouloir remplacer un tag déjà ancien
> et largement utilisé "highway=bus_stop" par un autre sans réel
> avantage (si ce n'est la cohérence, tient ça me rapelle une autre
> affaire ;-).
> L'identification complète d'une ligne de bus n'est pas quelque chose à
> la portée des débutants.

Il y a un exemple de ligne de bus que j'avais fait sur villefranche en
essayant de respecter la nouvelle convention.
mais, je confirme, c'est hardos pour un débutant (j'en avais un peu
bavé... surtout qu'une ligne pouvait avoir 4 parcours différents !)
http://wiki.openstreetmap.org/wiki/Villefranche-sur-Sa%C3%B4ne
d'après ce que je m'étais noté à l'époque, on doit avoir :

une relation public transport=stop_area qui contient :
- les 1 ou 2 stop_position (role=stop)
- les 2 platform (role=platform)
(2 pour les 2 sens de circulation, s'il n'y a qu'un sens, ben... ça
tombe sous le sens)

et le public transport= stop_position est sur le chemin et :
- appartient à la relation stop area
- appartient à la relation route (uniquement dans le sens que l'on veut)

c'est juste un petit aide mémoire...


-- 
for me, ck means con kolivas and not calvin klein... does it mean I'm a geek ?

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

Re: [OSM-talk-fr] Infographie sur l'évolution de New-York sous la mandature Bloomberg

[Jean-Marc Liotier]

On 21/08/2013 10:56, François Lacombe wrote:
Ne pas avoir de distinction possible des éditions de maintenance (pour 
corriger des erreurs ou des incohérences, des choses qui n'ont jamais 
existé sur le terrain) des éditions de mise à jour (le terrain a 
effectivement changé à une date bien précise et OSM doit suivre) est 
un vrai handicap.


Certes, mais ça n'a jamais fait partie des besoins traités par 
Openstreetmap - tous les aspects du projet ont toujours été 
explicitement dédiés à fournir la vision à jour. Au-delà du problème de 
modélisation et d'outillage, l'exploitation serait une charge 
considérable: une vision historique est en pratique un empilement de 
visions instantanées qu'il faut toutes tenir à jour avec le même niveau 
d'effort que celle à jour. L'introduction de dates d'effet dans les 
métadonnées n'est que le premier pas qu'un tel Openhistorymap devrait 
franchir.


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

Re: [OSM-talk-fr] Infographie sur l'évolution de New-York sous la mandature Bloomberg

[François Lacombe]

+1 total et merci pour ce lien.

A condition d'avoir une gestion temporelle des données plus élaborée que
par de simples tags.

Ne pas avoir de distinction possible des éditions de maintenance (pour
corriger des erreurs ou des incohérences, des choses qui n'ont jamais
existé sur le terrain) des éditions de mise à jour (le terrain a
effectivement changé à une date bien précise et OSM doit suivre) est un
vrai handicap.

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


2013/8/21 Charles Nepote 

> Pas directement sur OSM mais un exemple d'usage de carto assez intéressant
> :
> http://www.nytimes.com/**newsgraphics/2013/08/18/**reshaping-new-york/
>
> Je pense que ce genre d'infographie doit être possible
> semi-automatiquement avec OSM. Les données sont là :
> * hauteur des bâtiments : 
> http://wiki.openstreetmap.org/**wiki/Key:height
> * la date de réalisation : http://wiki.openstreetmap.org/**
> wiki/Key:start_date 
> * pistes cyclables, etc.
> ... et les expérimentation 3D ne manquent pas avec OSM :
> http://wiki.openstreetmap.org/**wiki/3D
>
> ChN
>
>
> __**_
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Infographie sur l'évolution de New-York sous la mandature Bloomberg

[Charles Nepote]

Pas directement sur OSM mais un exemple d'usage de carto assez intéressant :
http://www.nytimes.com/newsgraphics/2013/08/18/reshaping-new-york/

Je pense que ce genre d'infographie doit être possible 
semi-automatiquement avec OSM. Les données sont là :

* hauteur des bâtiments : http://wiki.openstreetmap.org/wiki/Key:height
* la date de réalisation : http://wiki.openstreetmap.org/wiki/Key:start_date
* pistes cyclables, etc.
... et les expérimentation 3D ne manquent pas avec OSM : 
http://wiki.openstreetmap.org/wiki/3D


ChN


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