Re: [OSM-talk-fr] Open Data : des données de l'IGN disponibles sous licence Etalab

[yvecai]

Le 23/03/2012 18:26, Christian Quest a écrit :
Le 23 mars 2012 16:49, Michel SALESSES > a écrit :

> Bonjour à tous
>
> Je viens de tomber sur cet article dans le journal d'info de l'IGN:
> 
http://www.ign.fr/institut/documentArticle.do?idDoc=6909261&indexRoot=4&indexChild=1¤tRootSearch=&indexChildSearch= 


>
> Qui peux m'expliquer la difféffence entre cette licence etalab  et 
licence

> CC?
>


Le licence etalab est encore plus ouverte que notre CC-by-SA. On peut 
verser dans OSM des données sous licence etalab.


> D'autre part peut _on utiliser les données mises à disposition par l'ign
> dans notre projet ?
>


Si elles sont utile et de qualité... et ce n'est pas le cas au moins 
pour le deuxième point.

Le GEOFLA est un découpage administratif très grossier, dommage.

Le RGC contient la liste des communes, que l'on a déjà depuis 
longtemps sur le site de l'INSEE et qui nous sert à comparer les 
données présentes dans OSM avec celles que l'on devrait avoir. Ce 
n'est pas versable dans OSM en l'état.


La BD Alti avec un maillage de 250m... c'est aussi très grossier et de 
toute façon on ne rentre pas de modèle numérique de terrain dans OSM.


Hmmm... Une BD Alti de 250m pourrait permettre de combler quelques vides 
SRTM. Pas pour OSM, mais peut-être utile tout de même.

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

Re: [OSM-talk-fr] Apport du GeoFLA pour les nodes "place"

[Cyrille Giquello]

Merci Vincent,
Très bien cet outil.

Cyrille.

Le 23 mars 2012 22:16, Vincent de Chateau-Thierry  a écrit :
> Bonsoir,
> Je reviens sur des discussions récentes au sujet du GeoFLA et des nodes
> "place=*", notamment :
> http://lists.openstreetmap.org/pipermail/talk-fr/2012-March/041207.html
> et
> http://lists.openstreetmap.org/pipermail/talk-fr/2012-March/041225.html
> (et suivants).
>
> J'ai placé sur un fond Mapnik des points correspondant au "chef-lieu"
> tel qu'indiqué par le GeoFLA. Les points n'existent que pour 2
> catégories de communes :
> - celles ayant leur contour administratif dans OSM, mais aucun node place=*
> - celles n'ayant ni contour admin, ni nodes place=*.
> C'est le contour issu du GeoFLA qui m'aide pour la détection.
>
> C'est ici :
> http://osm.vdct.free.fr/geofla/index.html
>
> Je (re)lance du coup le sujet d'un possible apport du GeoFLA pour
> ajouter un node place pour des communes qui, aujourd'hui, n'existent
> d'aucune manière dans OSM. Il s'agit de la catégorie "Communes sans
> relation admin" sur la carte ci-dessus. Quid par ex. de la pertinence du
> positionnement ?
>
> Merci pour vos avis,
>
> vincent
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Cyrille.

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

Re: [OSM-talk-fr] Apport du GeoFLA pour les nodes "place"

[Cyrille Giquello]

J'oubliai, quelle est la fréquence de rafraîchissement ?

Le 23 mars 2012 22:16, Vincent de Chateau-Thierry  a écrit :
> Bonsoir,
> Je reviens sur des discussions récentes au sujet du GeoFLA et des nodes
> "place=*", notamment :
> http://lists.openstreetmap.org/pipermail/talk-fr/2012-March/041207.html
> et
> http://lists.openstreetmap.org/pipermail/talk-fr/2012-March/041225.html
> (et suivants).
>
> J'ai placé sur un fond Mapnik des points correspondant au "chef-lieu"
> tel qu'indiqué par le GeoFLA. Les points n'existent que pour 2
> catégories de communes :
> - celles ayant leur contour administratif dans OSM, mais aucun node place=*
> - celles n'ayant ni contour admin, ni nodes place=*.
> C'est le contour issu du GeoFLA qui m'aide pour la détection.
>
> C'est ici :
> http://osm.vdct.free.fr/geofla/index.html
>
> Je (re)lance du coup le sujet d'un possible apport du GeoFLA pour
> ajouter un node place pour des communes qui, aujourd'hui, n'existent
> d'aucune manière dans OSM. Il s'agit de la catégorie "Communes sans
> relation admin" sur la carte ci-dessus. Quid par ex. de la pertinence du
> positionnement ?
>
> Merci pour vos avis,
>
> vincent
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr



-- 
Cyrille.

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

Re: [OSM-talk-fr] Apport du GeoFLA pour les nodes "place"

[Marc Sibert]

Le 23/03/2012 22:16, Vincent de Chateau-Thierry a écrit :

Bonsoir,
Je reviens sur des discussions récentes au sujet du GeoFLA et des nodes
"place=*", notamment :
http://lists.openstreetmap.org/pipermail/talk-fr/2012-March/041207.html
et
http://lists.openstreetmap.org/pipermail/talk-fr/2012-March/041225.html
(et suivants).

J'ai placé sur un fond Mapnik des points correspondant au "chef-lieu"
tel qu'indiqué par le GeoFLA. Les points n'existent que pour 2
catégories de communes :
- celles ayant leur contour administratif dans OSM, mais aucun node 
place=*

- celles n'ayant ni contour admin, ni nodes place=*.
C'est le contour issu du GeoFLA qui m'aide pour la détection.

C'est ici :
http://osm.vdct.free.fr/geofla/index.html

Je (re)lance du coup le sujet d'un possible apport du GeoFLA pour
ajouter un node place pour des communes qui, aujourd'hui, n'existent
d'aucune manière dans OSM. Il s'agit de la catégorie "Communes sans
relation admin" sur la carte ci-dessus. Quid par ex. de la pertinence 
du positionnement ?


Merci pour vos avis,

vincent


Bonjour,

C'est pas mal en statique (je veux dire sans import automatique).
Par contre il faut un permalink pour faire un copier/coller vers josm ; 
l'idéal est une "télé-commande 
" qui 
envoie le noeud et les tags ad hoc vers JOSM.


A+

--
Marc Sibert
m...@sibert.fr

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

Re: [OSM-talk-fr] Apport du GeoFLA pour les nodes "place"

[Vincent de Chateau-Thierry]

Bonjour,

Le 24/03/2012 09:09, Cyrille Giquello a écrit :

J'oubliai, quelle est la fréquence de rafraîchissement ?



Merci Cyrille.

À vrai dire j'ai plutôt fait cette page pour proposer une "photo" de 
l'état des communes dont OSM ne connaît même pas le nom. C'est édifiant 
par exemple sur la Somme (80).
Je n'ai pas vraiment pensé à en faire un outil sur la durée, Osmose fait 
ça très bien :-).
Le propos est plutôt de dire : si on prenait l'info de positionnement 
des chef-lieu dans le GeoFLA, est-ce qu'on pourrait l'injecter, sous 
forme de nodes place, dans la base, afin de compléter notre couverture ?
Une conséquence palpable serait par exemple le fait que Nominatim 
saurait atteindre chaque commune de France sans attendre la couverture 
complète des limites admin. Même si, d'accord, on ne taggue pas pour 
Nominatim :-)


vincent

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

Re: [OSM-talk-fr] Apport du GeoFLA pour les nodes "place"

[didier2020]

Le samedi 24 mars 2012 à 10:01 +0100, Vincent de Chateau-Thierry a
écrit :
> Bonjour,
> 
> Le 24/03/2012 09:09, Cyrille Giquello a écrit :
> > J'oubliai, quelle est la fréquence de rafraîchissement ?
> >
> 
> Merci Cyrille.
> 
> À vrai dire j'ai plutôt fait cette page pour proposer une "photo" de 
> l'état des communes dont OSM ne connaît même pas le nom. C'est édifiant 
> par exemple sur la Somme (80).
effectivement
> Je n'ai pas vraiment pensé à en faire un outil sur la durée, Osmose fait 
> ça très bien :-).
> Le propos est plutôt de dire : si on prenait l'info de positionnement 
> des chef-lieu dans le GeoFLA, est-ce qu'on pourrait l'injecter, sous 
> forme de nodes place, dans la base, afin de compléter notre couverture ?
Pour les communes sans relation admin,
je n'ai trouvé qu'une commune que je connaissais pour verifier ou le
pointeur se trouvait: dept 15, POLMINHAC.
Le pointeur serait plutot au niveau de l'église, la mairie étant au nord
de la RN122. 
Pour cette commune ce n'est pas incorrect.

Sinon, joli travail.
et très instructif pour le code de la page html!

didier


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

Re: [OSM-talk-fr] OSM en aquarelle...

[Ophélie PETIT]

Il y a un sujet de thèse que propose l'ENSG (IGN) sur les les cartes "à la
mode de" qui rentre tout à fait dans ce principe là. Comme quoi OSM est un
précurseur^^

Le 22 mars 2012 08:53, Ab_fab  a écrit :

> Idem, les grands esprits se rencontrent ;-)
>
> Le 22 mars 2012 08:46, Christian Quest  a écrit :
>
> J'ai aussi pensé au rendu des cartes de Cassini.
>>
>> Ca serait formidable de boucler la boucle de cette façon !
>>
>>
>> Le 21 mars 2012 21:17, DH  a écrit :
>> > C'est marrant, je songeais aussi à un rendu d'OSM façon Cassini, ou
>> d'autres
>> > Michelin-like d'avant les 70's.
>> >
>> > Nous sommes tous The Artist.
>> >
>>
>> Rendu en noir et blanc alors ? ;)
>>
>> --
>> Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest
>>
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-fr
>>
>
>
>
> --
> ab_fab 
> "Il n'y a pas de pas perdus"
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


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

Re: [OSM-talk-fr] filtre à multipolygone

[Frédéric Rodrigo]

On 23/03/2012 22:03, Vincent Privat wrote:

Tu dois pouvoir t'en tirer avec ces deux filtres: "id:288703" et "child
id:288703".
Vincent


Il existe aussi la fonction de "Purge" qui permet de supprimer des 
objets de l'éditeur sans pour autant les supprimer de OSM.


http://josm.openstreetmap.de/wiki/Help/Action/Purge

Frédéric.

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

[OSM-talk-fr] Position du noeud "Marseille"

[Sylvain Maillard]

Bonjour à tous,

en faisant quelques tests de routage, je me suis rendu compte d'un problème
avec un noeud un peu particulier: le noeud "Marseille" qui est admin_centre
de plusieurs relations (http://www.openstreetmap.org/browse/node/26761400)

Ce noeud se trouve en plein sur le centre historique de la ville: le vieux
port. Le problème c'est qu'un port, c'est de l'eau, et les outils de
routages n'aime pas du tout ça ! La majorité d'entre eux sortent un message
d'erreur lorsqu'on demande une route qui a pour origine "Marseille" =>
normal puisque jusqu'à preuve du contraire les voitures ne flottent pas
bien ...
Je voudrais donc déplacer le noeud pour le ramener sur terre (ce qui me
semble cartographiquement plus réel), par exemple sur le quai du vieux port
au bout de la Canebière. Étant donné que je n'ai jamais vraiment touché de
noeud faisant partie de grosses relations, je préfère poser la question
avant de faire une modification d'importance ... est-ce que je peux bouger
le noeud simplement comme ça sans conséquences, ou est-ce qu'il y a des
choses à prendre en considération avant ?

je sais qu'on ne cartographie ni pour le rendu ni pour le routage, mais là
il semblerait que la position initiale soit justement faite pour le rendu :D


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

[OSM-talk-fr] FranceTopo: Message à destination du pirate breton qui se reconnaîtra

[Romain MEHUT]

Bonjour,

Je vous à lire le message d'avertissement à l'ouverture de
http://francetopo.fr/
Je pense que nous pouvons lui accorder notre soutien.

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

Re: [OSM-talk-fr] OSM en aquarelle...

[Sidonie Christophe]

Bonsoir à tous,

Je réagis car non seulement j'adore ces cartes faites par Stamen sur des 
données OSM, mais aussi car ce sujet fait partie de mon travail de recherche.

Pour répondre à Ophélie (car je crois qu'il s'agit de ça ?), je propose 
effectivement un sujet de thèse sur la construction et la perception de styles 
cartographiques (styles carto existants : européens, journalistiques, anciens, 
etc. ou styles artistiques) au laboratoire COGIT de l'IGN : le sujet est ici : 
http://recherche.ign.fr/labos/cogit/pdf/PROPOSITIONS/2012_these_Semio.pdf Si 
certains sont intéressés, candidatez, attention la date limite de candidature 
est le 31 Mars 2012 !

Pour info, j'ai fait une thèse sur l'aide au choix des couleurs en cartographie 
(2006-2009), où je proposais de faire des cartes à la manière d'autres cartes, 
ou à la manière de peintures célèbres. Si ça vous intéresse, la thèse est ici, 
vous pourrez y trouver des exemples de rendus : 
http://tel.archives-ouvertes.fr/tel-00515333/fr/


Depuis je continue à travailler avec d'autres chercheurs du COGIT et des 
collègues en informatique graphique sur de nouvelles possibilités de rendus, 
sur les styles en cartographie, et sur l'aide à la personnalisation des cartes.


Au plaisir!

Sidonie


--

Il y a un sujet de thèse que propose l'ENSG (IGN) sur les les cartes "à la
mode de" qui rentre tout à fait dans ce principe là. Comme quoi OSM est un
précurseur^^___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] FranceTopo: Message à destination du pirate breton qui se reconnaîtra

[DH]

Le 24/03/2012 20:08, Romain MEHUT a écrit :

Bonjour,

Je vous à lire le message d'avertissement à l'ouverture de 
http://francetopo.fr/

Je pense que nous pouvons lui accorder notre soutien.

Romain


J'ai également lu cela (je kiffe trop ce rendu).
Plein soutien aux artistes|artisants du site.
Une mention dans le prochain -excellent- bulletin d'OSM-FR ? 
http://dev.www.openstreetmap.fr/bulletin-OSM-FR-6 sur les risques de 
piratage de l'effort collectif fourmi ?
Si d'autres pompent impunément, c'est que nous sommes une source de 
données, de créativité -what else ?- ; c'est flatteur mais ceux qui 
souhaitent vivre de l'apport qu'ils font au projet commun ne 
subsisteront avec des flatteries, encore moins avec des pratiques de 
margoulins.


Denis

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

Re: [OSM-talk-fr] FranceTopo: Message à destination du pirate breton qui se reconnaîtra

[Pierre-André Le Ny]

Bonsoir,
"parfois peuplée de gens de votre espèce"

C'est quoi cet amalgame entre l'origine de l'IP et le peuple breton ?
Je comprends l'avertissement mais je le trouve personnellement super limite.
Et je suis également perplexe sur la méthode menaçante.


Le 24 mars 2012 21:13, DH  a écrit :

> Le 24/03/2012 20:08, Romain MEHUT a écrit :
>
>> Bonjour,
>>
>> Je vous à lire le message d'avertissement à l'ouverture de
>> http://francetopo.fr/
>> Je pense que nous pouvons lui accorder notre soutien.
>>
>> Romain
>>
>
> J'ai également lu cela (je kiffe trop ce rendu).
> Plein soutien aux artistes|artisants du site.
> Une mention dans le prochain -excellent- bulletin d'OSM-FR ?
> http://dev.www.openstreetmap.**fr/bulletin-OSM-FR-6sur
>  les risques de piratage de l'effort collectif fourmi ?
> Si d'autres pompent impunément, c'est que nous sommes une source de
> données, de créativité -what else ?- ; c'est flatteur mais ceux qui
> souhaitent vivre de l'apport qu'ils font au projet commun ne subsisteront
> avec des flatteries, encore moins avec des pratiques de margoulins.
>
> Denis
>
> __**_
> 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] Position du noeud "Marseille"

[Vincent de Chateau-Thierry]

Le 24/03/2012 19:56, Sylvain Maillard a écrit :


Je voudrais donc déplacer le noeud pour le ramener sur terre (ce qui me
semble cartographiquement plus réel), par exemple sur le quai du vieux
port au bout de la Canebière. Étant donné que je n'ai jamais vraiment
touché de noeud faisant partie de grosses relations, je préfère poser la
question avant de faire une modification d'importance ... est-ce que je
peux bouger le noeud simplement comme ça sans conséquences, ou est-ce
qu'il y a des choses à prendre en considération avant ?



Le noeud participe aux relations via son ID. Modifier sa position ou ses 
tags n'a donc pas d'incidence sur les relations, tu peux y aller.
Pour info, ce qui modifierait les relations, c'est soit : effacer la 
référence du noeud dans la relation, mais pour ça il faut explicitement 
éditer la relation, soit effacer le noeud, ce qui en cascade modifiera 
la relation.


vincent

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

Re: [OSM-talk-fr] Apport du GeoFLA pour les nodes "place"

[Vincent de Chateau-Thierry]

Le 24/03/2012 10:00, Marc Sibert a écrit :


C'est pas mal en statique (je veux dire sans import automatique).
Par contre il faut un permalink pour faire un copier/coller vers josm ;
l'idéal est une "télé-commande
" qui
envoie le nœud et les tags ad hoc vers JOSM.



Comme dit ce matin, ça se veut avant tout une page d'analyse. Pas de 
souci pour la transformer en passerelle d'édition, mais il faudrait 
quelques pré-requis :
- prendre population et nom dans le COG, le GeoFLA ne connaît que les 
majuscules sans accents

- coder la chose (tant mieux, jamais fait, ça m'apprendra)
- et idéalement dégager un peu de consensus sur le bien fondé de la 
démarche. Mais bon, qui ne dit mot consent, si personne ne s'y oppose, 
j'essaie de faire ça dans la semaine.


vincent

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

Re: [OSM-talk-fr] FranceTopo: Message à destination du pirate breton qui se reconnaîtra

[DH]

Le 24/03/2012 21:27, Pierre-André Le Ny a écrit :

Bonsoir,
"parfois peuplée de gens de votre espèce"

C'est quoi cet amalgame entre l'origine de l'IP et le peuple breton ?
Je comprends l'avertissement mais je le trouve personnellement super 
limite.

Et je suis également perplexe sur la méthode menaçante.


"Le coeur a ses raisons, que la raison ne connaît point. On le sent en 
mille choses."


/Pensées/, Blaise Pascal, éd. Gallimard (édition de Michel Le Guern), 
coll. Folio classique, 1977 (ISBN 2070316254 
), 
fragment 397, p. 251 (texte intégral sur Wikisource 
)


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

Re: [OSM-talk-fr] Position du noeud "Marseille"

[Yves]

Mais, il devrait etre sur la ligne du ferry-boat!
Tu vas pas betement le mettre sur le quai, si ?
Yves


Sylvain Maillard  a écrit :

Bonjour à tous,

en faisant quelques tests de routage, je me suis rendu compte d'un problème 
avec un noeud un peu particulier: le noeud "Marseille" qui est admin_centre de 
plusieurs relations (http://www.openstreetmap.org/browse/node/26761400)

Ce noeud se trouve en plein sur le centre historique de la ville: le vieux 
port. Le problème c'est qu'un port, c'est de l'eau, et les outils de routages 
n'aime pas du tout ça ! La majorité d'entre eux sortent un message d'erreur 
lorsqu'on demande une route qui a pour origine "Marseille" => normal puisque 
jusqu'à preuve du contraire les voitures ne flottent pas bien ...
Je voudrais donc déplacer le noeud pour le ramener sur terre (ce qui me semble 
cartographiquement plus réel), par exemple sur le quai du vieux port au bout de 
la Canebière. Étant donné que je n'ai jamais vraiment touché de noeud faisant 
partie de grosses relations, je préfère poser la question avant de faire une 
modification d'importance ... est-ce que je peux bouger le noeud simplement 
comme ça sans conséquences, ou est-ce qu'il y a des choses à prendre en 
considération avant ?

je sais qu'on ne cartographie ni pour le rendu ni pour le routage, mais là il 
semblerait que la position initiale soit justement faite pour le rendu :D


Sylvain
aka Eologeek

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

[OSM-talk-fr] spatialite et osm -> EPSG:900913 alias du EPSG:3857

[Cyrille Giquello]

Bonjour,

Dans spatialite il n'y a pas le SRID 3857 pour le Mercator Sphérique,
qui est la projection utilisée par OSM. J'en ai besoin pour convertir
des points dans la projection utilisée par OSM.
Je pose la question car je trouve ça étrange et je me dis que j'ai dû
rater quelque chose.

Merci
-- 
Cyrille.

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

Re: [OSM-talk-fr] spatialite et osm -> EPSG:900913 alias du EPSG:3857

[Philippe Verdy]

Mercator « sphérique », kesako ? Mercator c'est uniquement **cylindrique**.

Tu dois confondre avec les projections corrigeant la latitude linéaire
pour rétablir les rapports de surface (comme si on avait un jeu très
fin de projections coniques successives). Pour la géodésie en France,
on n'utilise pas ce genre de projection, mais uniquement un jeu limité
de projections coniques pour corriger en partie les déformations de la
projection cylindrique de Mercator (donc aussi WGS84 qui n'utilise
qu'un seul cylindre et non plusieurs cônes selon les latitudes).

La base OSM utilise une projection WGS84, basée sur une projection
cylindrique, mais **sans** correction non linéaire de la latitude, une
correction qui serait pourtant nécessaire pour conserver au moins les
surfaces (mais qui ne corrigerait pas pour autant les angles fortement
déformés près des pôles).

L'interface cartographique d'OSM, en fait celel de son rendu (telle
que Mapnik), ne corrige pas cette projection de représentation, alors
qu'elle devrait être transformée en projection conique pour rétablir
les proportions et les angles: c'est bien pour ça que cette interface
ne permet pas d'afficher les latitudes de plus de 85 degrés (Nord ou
Sud), et que même au delà de 80 degrés, les distortions sont trop
beaucoup trop importantes (pas question de modéliser par exemple un
bâtiment rectangulaire dans cette projection WGS84, car le bâtiment
rectangulaire devient nécessairement un trapézoïde, affiché alors
nettement plus étroit dans la direction du pôle de l'hémisphère où ce
rectangle est situé).

Il y a une raison à cela: c'est que le rendu se fait actuellement en
images bitmap, et que les navigateurs web ne savent pas encore prendre
en charge les déformations non linéaires de telles images qui seraient
pourtant nécessaires pour rétablie les proportions, les angles et les
surfaces, par triangulation selon le vecteur normal central de
visualisation de la carte: ce vecteur normal devant alors bouger
chaque fois qu'on se déplace en glissant la carte, il faudrait aussi
réajuster toutes les images (donc les redessiner). Les serveurs de
tuiles ne savent pas générer des tuiles bitmap réajustées pour des
projections arbitraires selon le vecteur normal d'observation.

La solution serait d'avoir des tuiles en format vectoriel, le
navigateur s'occupant lui-même de recalculer les projections et donc
de redessiner aussi les POI et les routes.

== NOTES ==

WGS84 a le défaut (mineur actuellement) de perdre sa précision selon
les coordonnées quand on s'éloigne du zéro degré (de longitude ou de
latitude), si on utilise une représentation en virgule flottante. Je
m'explique :

Dans la base OSM la précision est limitée par l'utilisation de
flottants sur 32 bits, on n'a donc que 23 bits de précision. Chaque
fois qu'un angle est multiplié par 2, on perd 1 bit de précision :

- de >=0° à < 1°, la précision représentable passe de la quasi
exactitude (précision infinitésimale ne dépendant que du plus petit
exposant de 2 représentable par le flottant) à la précision de 0,66 cm
(on stocke donc dans la base des bits de précision inutiles pour cet
intervalle angulaire).

- de >=1° à <2°, la précision chute brutalement à  4,3 millièmes de
seconde d'arc, soit 1,32 cm  (très bien, mais on n'est limité qu'à une
toute petite zone de 2 degrés de large de part et d'autre du méridien
de Greenwich et de part et d'autre de l'équateur, une zone de
l'Atlantique dans le golfe de Guinée)

- de >=2° à <4°, elle est réduite à 2,65 cm
- de >=4° à <8°, elle est réduite à 5,30 cm
...
- de >=64° à <128° (y compris les 90° de latitude pour les pôles),
elle n'est plus que 84,77 cm (2,75 centièmes de seconde d'arc)
- de >=128° à <256° (en fait seulement 180°, et seulement pour les
longitudes), la précision est seulement de 1,70 m  (5,49 centièmes de
seconde d'arc) !!

Autrement dit on est encore trop loin de la précision décimétrique
voulue qui n'est atteinte que sur une partie de la Terre proche de
l'équateur et proche du méridien de Greenwich. La base OSM a donc
seulement une précision à peine métrique. L'anomalie d'OSM (non liée à
la projection WGS84 elle-même) c'est d'avoir choisi la représentation
sous forme de flottants 32 bits, avec donc une précision **non
uniforme** pour sa projection WGS84.

Si la base OSM (ainsi que son API exposant les valeurs stockées, et
les outils de modification comme JOSM) utilisait plutôt des entiers 32
bits (dans toute leur étendue: les 32 bits couvrant exactement
l'étendue des longitudes ou des latitudes permises) plutôt que des
flottants 32 bits, on aurait offert une précision **uniforme** pour :

- **toutes** les latitudes (de 0,931 milliardième de degré partout,
soit 9,31 cm partout dans la direction d'un méridien, toujours
meilleure que la représentation actuelle hormis un minuscule rectangle
de 9,31 cm de largeur centré sur le méridien de Greenwich), et

- **toutes** les longitudes (une précision uniforme seulement deux
fois moindre, de 1,863 millliardièmes de d

Re: [OSM-talk-fr] spatialite et osm -> EPSG:900913 alias du EPSG:3857

[Philippe Verdy]

Pour résumer tout ça, la précision nécessaire pour une précision
décimtrique nécessite que toutes les coordonnées soient exprimables et
calculables avec 10 chiffres significatifs (les mêmes 10 chiffres
qu'on trouve dans un entier 32 bits, mais qu'on ne trouve pas dans un
flottant 32 bits qui n'a QUE 7 chiffres significatifs)...

Le 25 mars 2012 03:34, Philippe Verdy  a écrit :
> Mercator « sphérique », kesako ? Mercator c'est uniquement **cylindrique**.
>
> Tu dois confondre avec les projections corrigeant la latitude linéaire
> pour rétablir les rapports de surface (comme si on avait un jeu très
> fin de projections coniques successives). Pour la géodésie en France,
> on n'utilise pas ce genre de projection, mais uniquement un jeu limité
> de projections coniques pour corriger en partie les déformations de la
> projection cylindrique de Mercator (donc aussi WGS84 qui n'utilise
> qu'un seul cylindre et non plusieurs cônes selon les latitudes).
>
> La base OSM utilise une projection WGS84, basée sur une projection
> cylindrique, mais **sans** correction non linéaire de la latitude, une
> correction qui serait pourtant nécessaire pour conserver au moins les
> surfaces (mais qui ne corrigerait pas pour autant les angles fortement
> déformés près des pôles).
>
> L'interface cartographique d'OSM, en fait celel de son rendu (telle
> que Mapnik), ne corrige pas cette projection de représentation, alors
> qu'elle devrait être transformée en projection conique pour rétablir
> les proportions et les angles: c'est bien pour ça que cette interface
> ne permet pas d'afficher les latitudes de plus de 85 degrés (Nord ou
> Sud), et que même au delà de 80 degrés, les distortions sont trop
> beaucoup trop importantes (pas question de modéliser par exemple un
> bâtiment rectangulaire dans cette projection WGS84, car le bâtiment
> rectangulaire devient nécessairement un trapézoïde, affiché alors
> nettement plus étroit dans la direction du pôle de l'hémisphère où ce
> rectangle est situé).
>
> Il y a une raison à cela: c'est que le rendu se fait actuellement en
> images bitmap, et que les navigateurs web ne savent pas encore prendre
> en charge les déformations non linéaires de telles images qui seraient
> pourtant nécessaires pour rétablie les proportions, les angles et les
> surfaces, par triangulation selon le vecteur normal central de
> visualisation de la carte: ce vecteur normal devant alors bouger
> chaque fois qu'on se déplace en glissant la carte, il faudrait aussi
> réajuster toutes les images (donc les redessiner). Les serveurs de
> tuiles ne savent pas générer des tuiles bitmap réajustées pour des
> projections arbitraires selon le vecteur normal d'observation.
>
> La solution serait d'avoir des tuiles en format vectoriel, le
> navigateur s'occupant lui-même de recalculer les projections et donc
> de redessiner aussi les POI et les routes.
>
> == NOTES ==
>
> WGS84 a le défaut (mineur actuellement) de perdre sa précision selon
> les coordonnées quand on s'éloigne du zéro degré (de longitude ou de
> latitude), si on utilise une représentation en virgule flottante. Je
> m'explique :
>
> Dans la base OSM la précision est limitée par l'utilisation de
> flottants sur 32 bits, on n'a donc que 23 bits de précision. Chaque
> fois qu'un angle est multiplié par 2, on perd 1 bit de précision :
>
> - de >=0° à < 1°, la précision représentable passe de la quasi
> exactitude (précision infinitésimale ne dépendant que du plus petit
> exposant de 2 représentable par le flottant) à la précision de 0,66 cm
> (on stocke donc dans la base des bits de précision inutiles pour cet
> intervalle angulaire).
>
> - de >=1° à <2°, la précision chute brutalement à  4,3 millièmes de
> seconde d'arc, soit 1,32 cm  (très bien, mais on n'est limité qu'à une
> toute petite zone de 2 degrés de large de part et d'autre du méridien
> de Greenwich et de part et d'autre de l'équateur, une zone de
> l'Atlantique dans le golfe de Guinée)
>
> - de >=2° à <4°, elle est réduite à 2,65 cm
> - de >=4° à <8°, elle est réduite à 5,30 cm
> ...
> - de >=64° à <128° (y compris les 90° de latitude pour les pôles),
> elle n'est plus que 84,77 cm (2,75 centièmes de seconde d'arc)
> - de >=128° à <256° (en fait seulement 180°, et seulement pour les
> longitudes), la précision est seulement de 1,70 m  (5,49 centièmes de
> seconde d'arc) !!
>
> Autrement dit on est encore trop loin de la précision décimétrique
> voulue qui n'est atteinte que sur une partie de la Terre proche de
> l'équateur et proche du méridien de Greenwich. La base OSM a donc
> seulement une précision à peine métrique. L'anomalie d'OSM (non liée à
> la projection WGS84 elle-même) c'est d'avoir choisi la représentation
> sous forme de flottants 32 bits, avec donc une précision **non
> uniforme** pour sa projection WGS84.
>
> Si la base OSM (ainsi que son API exposant les valeurs stockées, et
> les outils de modification comme JOSM) utilisait plutôt des entiers 32
> bits (dans toute leur étendue: les 32

Re: [OSM-talk-fr] Position du noeud "Marseille"

[Philippe Verdy]

Le 24 mars 2012 19:56, Sylvain Maillard  a écrit :
> je sais qu'on ne cartographie ni pour le rendu ni pour le routage, mais là
> il semblerait que la position initiale soit justement faite pour le rendu :D

Je pense seulement qu'elle est basée sur un centroïde géométrique. Le
routage n'est qu'une utilisation particulière, on ne tague pas non
plus spécifiquement pour le routage, c'est au moteur de routage de
trouver une position proche du lieu à atteindre. D'ailleurs concernant
les panneaux indicateurs, ils utilisent pas toujours un point de
routage multimodal comme point zéro de calcul des distances.

Le nœud n'est pas forcément non plus sur la route et pourrait être au
milieu d'une place piétonne qu'on ne peut pas atteindre non plus en
voiture ou en bateau: ce noeud est positionné en fonction d'un piéton
seulement, pas nécessairement une voiture et certainement pas non plus
un bateau (sauf pour les distances indiquées sur les cartes de
navigation maritime ou fluviales qui prennent en référence un quai),
ni un train (la référence sera le point central d'une gare).

Je ne vois rien de mal à la position du nœud désigné comme Marseille
au milieu de l'eau (sauf que ce n'est pas non plus un centre
"administratif", mais il n'a pas non plus à être contraint par le
routage !)

Bref c'est plutôt une anomalie du moteur de routage qui ne trouve pas
un nœud à atteindre, alors qu'il devrait trouver tout seul la relation
de surface de la commune, et y trouver un point atteignable qui n'a
aucune raison non plus d'être celui indiqué comme "admin_centre".

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

Re: [OSM-talk-fr] Position du noeud "Marseille"

[Philippe Verdy]

Note: pourquoi ce point devrait être sur le quai ? Pourquoi pas non
plus à la gare Saint-Charles, ou à l'aéroport (hors de Marseille...),
ou à la gare routière, ou à la position du principal point d'échange
multimodal (bus, métro, taxis) le plus proche de la mairie, ou à la
mairie elle-même ?

Le centroïde est finalement le point qui permet de se centrer le mieux
autour de ces nœuds. Rien à voir avec le rendu, mais un point désigné
central dans une commune doit seulement être assez proche des points
habituellement recherchés, mais ne peut pas correspondre à tous les
usages.

Dans un moteur de routage vers une ville assez grande, de toute façon
il est impossible de déterminer un point précis : ce point ne sert
qu'à centrer la carte où l'utilisateur précisera une adresse à
atteindre. C'est au moteur de routage de se débrouiller pour trouver
d'autres points de passage : il est impossible de satisfaire tous les
usages avec un seul nœud, donc pour le reste il faut que ces usages
différents admettent un rayon de recherche d'un point à atteindre et
pas seulement la position du seul nœud indiqué.

Le 25 mars 2012 03:54, Philippe Verdy  a écrit :
> Le 24 mars 2012 19:56, Sylvain Maillard  a écrit :
>> je sais qu'on ne cartographie ni pour le rendu ni pour le routage, mais là
>> il semblerait que la position initiale soit justement faite pour le rendu :D
>
> Je pense seulement qu'elle est basée sur un centroïde géométrique. Le
> routage n'est qu'une utilisation particulière, on ne tague pas non
> plus spécifiquement pour le routage, c'est au moteur de routage de
> trouver une position proche du lieu à atteindre. D'ailleurs concernant
> les panneaux indicateurs, ils utilisent pas toujours un point de
> routage multimodal comme point zéro de calcul des distances.
>
> Le nœud n'est pas forcément non plus sur la route et pourrait être au
> milieu d'une place piétonne qu'on ne peut pas atteindre non plus en
> voiture ou en bateau: ce noeud est positionné en fonction d'un piéton
> seulement, pas nécessairement une voiture et certainement pas non plus
> un bateau (sauf pour les distances indiquées sur les cartes de
> navigation maritime ou fluviales qui prennent en référence un quai),
> ni un train (la référence sera le point central d'une gare).
>
> Je ne vois rien de mal à la position du nœud désigné comme Marseille
> au milieu de l'eau (sauf que ce n'est pas non plus un centre
> "administratif", mais il n'a pas non plus à être contraint par le
> routage !)
>
> Bref c'est plutôt une anomalie du moteur de routage qui ne trouve pas
> un nœud à atteindre, alors qu'il devrait trouver tout seul la relation
> de surface de la commune, et y trouver un point atteignable qui n'a
> aucune raison non plus d'être celui indiqué comme "admin_centre".

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

Re: [OSM-talk-fr] FranceTopo: Message à destination du pirate breton qui se reconnaîtra

[Philippe Verdy]

Oui, et je ne comprends pas pourquoi je me prends ce message dès
l'entrée sur ce site, agrémenté en plus de menace de plainte
judiciaire quand on ne fait que venir sur ce site.

En revanche le rendu de de site est magnifique, avec en sus la
topographie, les lignes de niveau, et une vue rapprochée montrant une
vue en pseudo-relief des bâtiments du plus bel effet.

On mesure combien le Géoportail de l'IGN (mais aussi l'imagerie
cadastrale sur le serveur national du ministère de l'Économie et des
finances) a des progrès à faire pour produire un résultat aussi
magnifique, et aussi facilement utilisable et navigable !

C'est la plus belle carte de France actuellement (loin devant celle de
Google Maps qui sert surtout à agrémenter des données de POIs, liens
et publicités photos et interactions vers d'autres sites Google, et
dont Google vend maintenant très cher le référencement, comme
maintenant aussi l'usage de sa carte pour faire d'autres services...)

Il ne manque plus que le zoom progressif, et la transition vers des
tuiles vectorielles pour avoir une échelle continue.

Et qui sait plus tard une carte réellement 3D (mais OSM avec son
modèle 2D actuel n'est pas prêt pour ça, car il n'a pour gérer cela
que l'attribut "alt", utilisé pour l'altitude de certains points
géodésiques, et n'a pas inclus l'altitude comme une donnée géométrique
de base pour les nœuds)... En conséquence, la topographie n'a pas
encore sa place dans OSM, ne serait-ce que pour la seule altitude du
sol (au dessus et en dessous du niveau du sol, il n'y a que les
attributs "layer", qui ne sont pas des altitudes utilisables mais
juste des relations d'ordre relatif entre les objets, avec seulement
un index relatif local qui ne permet non plus aucune transition).

Le 24 mars 2012 21:27, Pierre-André Le Ny  a écrit :
> Bonsoir,
> "parfois peuplée de gens de votre espèce"
>
> C'est quoi cet amalgame entre l'origine de l'IP et le peuple breton ?
> Je comprends l'avertissement mais je le trouve personnellement super limite.
> Et je suis également perplexe sur la méthode menaçante.

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