Re: [OSM-dev-fr] [OSM-talk] landuse=farm bientôt retiré du rendu standard

[Philippe Verdy]

Cela concerne aussi place=farm qui est une alternative à
place=isolated_dwelling pour les lieux-dits ?
Sachant qu'on peut mettre un place=* sur une surface, cette surface
pourrait aussi être un landuse=farmyard, mais qui n'a pas nécessairement un
nom de lieu-dit, alors qu'un place=* a nécessairement un name=* pour
indiquer un toponyme.

Alternative alors: la surface en landuse=farmyard, le noeud toponymique en
place=isolate_dwelling.

(Il y a encore des fermes aujourd'hui inhabitées, landuse=farmyard reste
approprié tant que ce n'est pas reconverti en batiments résidentiels ou
industriels ou services (autre valeur de landuse=*, mais son noeud
place=isolated_dwelling doit être changé en place=locality si c'est
maintenant inhabité et devenir place=isolated_dwelling, voire hamlet si
c'est reconverti en logements).

2017-03-28 17:10 GMT+02:00 althio :

> Le tag landuse=farm sera bientôt retiré du rendu standard de
> openstreetmap.org
> [openstreetmap-carto sur GitHub
> https://github.com/gravitystorm/openstreetmap-carto]
>
> Il est maintenant suggéré de choisir un des tags plus explicites,
> typiquement landuse=farmland ou landuse=farmyard ou autre landuse=*
> ...
> Pas d'éditions automatiques bien sûr ! Vous pouvez tomber sur des
> reliquats de CLC - Corine Land Cover.
>
> Dans quelques jours les éléments landuse=farm ne seront plus visibles,
> les trous dans la carte rendue seront des bonnes indications des zones
> à travailler.
>
> Bonnes balades cartographiques à la campagne !
>
> -- althio
>
>
>
> -- Forwarded message --
> From: nebulon42 
> Date: 22 March 2017 at 13:56
> Subject: [OSM-talk] Upcoming removal of landuse=farm in the standard style
> To: osm-talk , tagg...@openstreetmap.org
>
>
> Dear all,
>
> at openstreetmap-carto - the standard style on osm.org - a change has
> been merged
> (https://github.com/gravitystorm/openstreetmap-carto/pull/2554) to drop
> rendering of landuse=farm. There was overall consensus that this tag is
> deprecated and its usage steadily declined over the last years, but
> there are still around 340 000 uses. See
> https://taginfo.openstreetmap.org/tags/landuse=farm and
> http://taghistory.raifer.tech/ for details.
>
> This change will make it into the next release, but there is no release
> date yet. You might want to change cases of landuse=farm in your area to
> either landuse=farmland or landuse=farmyard before that. Please don't do
> any automatic re-tagging though. After the release empty spots will make
> it easier to clean up the remaining uses of this tag.
>
> Michael
>
>
> ___
> talk mailing list
> t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Open Earth View - tuiles 3D

[Philippe Verdy]

Apparemment le clic gauche ne fait pas le drag, mais change l'orientation
de la caméra pour viser un même point fixe à la surface de laterre
initialement centré en LAT0/LON0 autour d'une sphère de rayon fixe
(indépendant du zoom). c'est le clic droit qui fait le drag du point fixe,
mais de façon très étrange (la direction n'est pas celle de la vue mais
relative à l'angle du vrai nord qui n'est pas en haut de la carte une fois
qu'on a changé l'orientation de la caméra. Le zoom est avec la molette ou
CTRL+clic gauche.
Il y a un autre pan avec CTRL+clic droit mais il est beaucoup trop rapide
en vue rapprochée (il semble que la distance de déplacement la souris est
proportionnelle avec l'angle de déplacement sur la carte mais ce taux est
malheureusement pas dépendant du niveau de zoom).

Ca demande pour être plus intuitif de ne pas controler la vue en fonction
des longitudes/latitudes cartographiques mais en fonction des coordonnées
de la projection (donc effectuer les projections inverses pour ajuster les
paramètres de projection/zoom/orientation.

Intuitivement au lieu de controler un nioveau de zoom, iol faudrait
controler la hauteur de la caméra par rapport au point central de la vue au
sol, au centre de l'écran.

Il y a du travail à faire sur les formules mathématiques des projections et
projections inverses nécessaires, et aussi pour déterminer quels niveaux de
zoom sont les plus adaptés pour afficher (selon la distance réelle des
objets vus à leur échelle) le niveau de zoom à demander pour les tuiles des
TMS utilisés (je ne vois d'ailleurs que des tuiles bitmap, y-a-t-il un
niveau où apparaissent des données vectorielles?).

Pour l'instant ça ne marche pas du tout. Tout cela est donc très difficile
à utiliser: les formules utilisées ne sont pas bonnes du tout. C'est
quasiment impossible de naviguer : la souris devrait contrôler un
déplacement relatif au niveau de zoom sur la carte représentée, et dans le
même angle que cette vue (au moins l'angle calculé sur le point central de
la vue et non un point hors de la vue).


Le 14 janvier 2016 à 20:57, Frédéric Rodrigo  a
écrit :

> Petit retour rapide. J'ai juste testé la démo.
> Je trouve la navigation à la sourie complètement contre intuitive.
> click gauche devrait faire du drag, le zoom molette est à l'inverse de ce
> qu'il se fait habituellement.
> bref pour la première démo je ne suis pas arrivé a visualiser quelque
> chose en navigant.
>
>
>
> Le 14/01/2016 12:32, Clement IGONET a écrit :
>
>> Bonjour tout le monde,
>>
>> Je travaille depuis plus d'un an sur un projet de génération de
>> tuiles 3D à partir des données d'OSM. Le projet se concentre surtout
>> sur la modélisation de bâtiments.
>>
>> Le projet était en C++, mais j'ai tout refait en NodeJS pour
>> beaucoup plus de souplesse en dev (adoption, facilités du langage avec
>> modèle de données JSON, concision du code, évolutions, maintenance,
>> etc...).
>>
>> Actuellement, les tuiles 3D générées peuvent être au formats suivants:
>> - GeoJSON
>> - X3D (JSON)
>> - X3D (XML)
>> Et à venir:
>> - JSON pour la lib three.js
>> - JSON pour la lib js babylon.js
>>
>> J'ai une quantité assez importante de projet à développer autour de
>> ça:
>> - viewer 3D web avec globe terrestre (x3dom, three.js, babylon.js)
>> - vue cubemap/skybox pour la navigation là où les camionettes google
>> ne vont pas (intérieur de bâtiment, chemins en montagne, etc...)
>> - gestion d'évènemetns temps réel dans les bâtiments (surveillance
>> ascenseurs, clims, incendie, intrusions, etc...)
>>
>> Le projet a vocation à être libre (le moins de contraintes
>> d'exploitation possibles).
>>
>> Certains d'entre vous serez-t-il intéressé par rejoindre le projet?
>>
>> Tout type de participation serait bievenu (demandes de
>> fonctionnalités, communications, développement, intégration, tests,
>> etc...).
>>
>> Présentaiton du projet:
>> http://wiki.openstreetmap.org/wiki/Open_Earth_View
>> Projet nodejs: https://www.npmjs.com/package/osm2x3d
>> Projet entier:
>> https://git.framasoft.org/pizaninja/OpenEarthView/tree/master/
>> Démos:
>> - http://www.openearthview.net/ (hébergement OVH payé par framasoft)
>> - http://www.openearthview.net/demo/cubemap_forest/forest.html
>> (attention, 10 MO à télécharger dans la scène)
>>
>> Clément Igonet.
>>
>> ___
>> dev-fr mailing list
>> dev-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/dev-fr
>>
>
>
> ___
> dev-fr mailing list
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Way splitté en base

[Philippe Verdy]

mapnik peut toujours trouver un way très long dans une requête qui déborde
un peu de son rectangle de travail,  a condition qu'il y ait au moins un
nœud du way pas trop loin afin d'assurer trouver les segments qui
traversent le carré.
Pour cela seul les nœuds suffisent : pas besoin de découper le way
arbitrairement tant qu'on reste bien dessous des 2000 nœuds par way, et
tant qu'on n'a pas de tag spécifique a une partie,  ni d'inclusion
partielle dans des relations voisines.
Le 22 août 2015 10:46, Vincent de Château-Thierry v...@laposte.net a
écrit :


 Le 22/08/2015 10:06, sly (sylvain letuffe) a écrit :


 Est-ce que ça dit quelquechose à quelqu'un ?


 Oui. C'est dans pg-output.c (si ça existe toujours) que le code du split
 est.

 Mon soupçon est

 qu'osm2pgsql

 splitte les longs ways, plus ou moins arbitrairement


 C'est pile poil ça. La valeur est en dur dans le code.


 Le code a bougé depuis, mais j'ai retrouvé ça :

 https://github.com/openstreetmap/osm2pgsql/blob/aaddc60fb61bdce80b67145951ec0511ac55886e/ChangeLog#L523
 qui dit la raison du pourquoi : limiter la bbox de chaque way, au moins
 pour éviter de la part de Mapnik des requêtes avec emprise délirante.

 Merci Sly !

 vincent

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

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

Re: [OSM-dev-fr] Way splitté en base

[Philippe Verdy]

1 degré c'est une distance considérable et compte tenu des projections on
est loin des conditions de linéarité,  et l'ajout des points intermédiaires
est nécessaire.  ceci dit est en mer et une approximation avec un demi
degra d'ecart donne des ecarts maximums entre l'orthodomie et un arc d'une
projection quelconque vont pas excéder quelques 100 mètres. la précision en
revanche ser a plus nevessaire si on est pres des cotes dans kes eaux
territoriales et devrait do ner des erreurs de moins de 50 metres.

en revanche il n'y a normalement oas lieu de decouper les chemins quand l
il n'y a qu'yne poignee de points par degre, tout pouvant tenir sous les
2000 noeuds par chemin.  au dela il est conseille de couper en plusieurs
chemins et les lier a une relation commune.
Le 21 août 2015 23:04, Vincent de Château-Thierry v...@laposte.net a
écrit :

 Bonsoir,
 je suis tombé sur une bizarrerie en regardant ce way :
 http://www.openstreetmap.org/way/150388021
 dans une base PostGIS chargée via Osm2pgsql.

 On trouve 22 enregistrements correspondant à ce way, chacun avec une
 partie de sa géométrie. Les morceaux bout à bout recomposent bien le way
 complet.

 Est-ce que ça dit quelquechose à quelqu'un ? Mon soupçon est qu'osm2pgsql
 splitte les longs ways, plus ou moins arbitrairement pour que chaque
 portion rentre à peu près dans un carré de 1 degré de côté. Mais je n'ai
 jamais constaté ça auparavant, d'où la question.

 merci pour vos lumières,
 vincent

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

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

Re: [OSM-dev-fr] requete pour trouver un way qui intersecte plusieurs communes

[Philippe Verdy]

Le 19 mai 2015 18:16, Jérôme Amagat jerome.ama...@gmail.com a écrit :

 liste des types de  highway dans routes.csv avec leur occurance :

 unclassified 20923
 residential 20637
 tertiary 16783
 track 11960
 secondary 10341
 primary 5270
 path 2762
 service 1325
 trunk 726
 footway 697
 cycleway 629
 road 139
 living_street 109
 motorway_link 70
 bridleway 68
 trunk_link 55
 pedestrian 55
 primary_link 46
 construction 26
 proposed 21
 raceway 19
 tertiary_link 19
 steps 16
 bus_guideway 15
 platform 14
 secondary_link 13
 corridor 3
 bus_stop 3
 via_ferrata 3
 unclassified;residential 1
 unclassified;tertiary 1

 Il faut se limiter à certains. Moi je dirais, ceux là :
 primary, secondary, tertiary, unclassified, residential, track,
 living_street
 plus surement ceux la :
 primary_link, secondary_link, tertiary_link, service, road


Pas road, ou alors juste comme un alias, synoryme de unclassified
(certains ont d'autres avis justement parce qu'ils inclus des voies non
routières dans les highways (par exemple les vias ferratas sont des voies
nécessitant un équipement sportif particulier et un entrainement
spécifique, sinon elles sont très dangereuses; et elles ne sont pas à
pratiquer seul).


 peut être :
 trunk, trunk_link, footway, cycleway, bridleway, pedestrian, path, steps.


OK pour steps, mais les bridleways sont davantage des restrictions d'accès
que des équipements très spécifiques. Sinon ce sont des allées piétonnes
comme les autres (et parfois aussi ouvert à certains véhicules privés
autorisés). On en trouve rarement dans les espaces publics, ce sont surtout
des chemins de service internes à des propriétés privées, clubs hippiques,
ou hippodromes. Partout ailleurs il n'y a pas d'espace réservé aux seuls
chevaux. D'ailleurs la plupart des bridleways (bon nombre en fait des
chemins de ferme) sont maintenant des chemins piétons classiques, et
ouverts aussi aux cyclistes, il n'y en a plus du tout dans les villes
actuelles.

D'ailleurs les voisins des fermiers se plaignent dans des animaux ou
troupeaux utilisent les rues et routes normales (alors qu'ils ne peuvent
plus faire autrement) et les bergers doivent demander des autorisations
spéciales pour fermer les routes le temps de déplacer les troupeaux sur la
voie publique. Et la gendarmerie fait vite dégager les cavaliers des routes
du réseau principal ou secondaire (les cavaliers ne sont admis que sur le
réseau tertiaire et dans des espaces limités des campagnes et forêts, et
dont les routes sont balisées pour avertir la présence de chevaux)



Mais pas ceux là :
 motorway, motorway_link, construction, proposed , raceway, corridor,
 bus_stop, via_ferrata, bus_guideway, platform


- proposed: OK, car on utilise plutôt le tag proposed:highway=*

- motorway: pas du tout d'accord (je ne vais pas être le seul, les
autoroutes ne sont pas que des voies rapides du réseau primaire, alors que
tu mets au donditionnel aussi les trunk !)

- raceway: on peut envisager que c'est en fait une route de service (accès
réservé à certains véhicules ayant une autorisation spéciale, interdit à
tous les autres; cependant on est en plus dans des terrains privés, bref la
législation devient floue à leur sujet, gormis les obligations relatives à
l'accueil du public et la protection du voisinage; sinon ces lieux
n'existent que temporairement le temps d'une course et rouverts ensuite à
la circulation normale); à voir donc plutôt ave la façon plus générale de
taguer les espaces sportifs (stades, etc... y compris pelouses, terrains
marqués pour certains sports, gradins/tribunes, batiments, et pistes de
toutes sortes: le circuit raceway est très secondaire dans tout ça et
soit c'est un highwya normal réservé le temps d'une course, soit c'est une
voie de service à suage sportif donc highway=service; service=raceway et
sport=car_racing ou autres sports motorisés)


 Apres, il y a aussi le problème des routes nommés qui dépassent
 seulement de quelques mètres ou dizaines de mètre sur la commune d'à coté
 ou celles qui longent plus ou moins la frontière en empiétant des 2 cotés.


Plus que la route seule, ce sont les propriétés longées et accessibles par
cette route qui posent le problème des adresses qui font déborder beaucoup
plus qu'on ne s'imagine le nom des voies, en incluant non seulement les
façades mais une large surface derrière, et ce n'est pas parce que les
occupants ont leur appartement du côté opposé à cette rue qu'il ne sont pas
à la même adresse, il peut même arriver que le bâtiment soit à cheval sur
la frontière communale et on peut se demander alors à quelle commune
revient tel appartement dans le même immeuble quand tous ses accès se font
uniquement d'un seul côté depuis la voirie publique qui est entièrement sur
une seule commune).

Le cas est plus fréquent dans les périphéries de villes assez grandes pour
avoir une banlieue, dans les zones commerciales et industrielles, où tel ou
tel entrepôt ou magasin peut se retrouver à cheval sur plusieurs communes.
Mais des 

Re: [OSM-dev-fr] Synchronisation d'une DB tierce avec OSM : diff vs Overpass

[Philippe Verdy]

Le 14 août 2014 18:54, Christian Quest cqu...@openstreetmap.fr a écrit :

 Nous utilisons des SSD standards et pas des modèles entreprise beaucoup
 plus cher.
 Sur layers c'est un Samsung 840 Pro, sur tile (plus ancien) c'est un OCZ
 Revodrive.


J'utilise des Samsung 840 Pro aussi, et un Crucial M550 (environ 300 euros
le 512Go, prix en baisse continue, meilleure performance que le Samsung, et
chauffe moins que le Samsung epndant des opération intensives) dans mon
portable comme disque système (le second SSD est resté Samsung 840,
légèrement moins performant mais est moins sollicité). Les deux séries
suivent sensiblement les mêmes évolutions de prix, à un ou deux euros près
selon les stocks des vendeurs.

Sur le PC desktop, les tests de performance ont donné des résultats
contraires (Samsung un peu meilleur que Crucial) je ne sais pas trop
pourquoi mais cela semble lié à la gestion de l'énergie apparemment
meilleure sur le Crucial (il préserve aussi ma batterie plus longtemps
qu'avec Samsung, la veille est mieux réglée, réveil et mise en veille
semblent un peu plus rapide chez Crucial, mais c'est sans doute lié aussi à
la conso du controleur Samsung à triple coeur ARM). Mais en gros, so les
deux se valent; le Crucial n'a pas les pauses qu'on voit de temps en
temps chez Samsung qui met parfois quelques secondes à se réveiller alors
qu'il est très actif.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] glonflement des tables osm2pgsql...

[Philippe Verdy]

Il faudrait tout de même distinguer les trous libres laissés dans les
pages (dépendants du fill factor) des trous laissés par les pages
totalement libres au sein du pool de pages occupé par une table ou un index
dans la base.

Le mode de stockage aussi de la base globale intervient (trous dans un même
tablespace), de même que la fragmentation ou la rapartition des pages
alloues entre plusieurs tablespaces alloués sur des disques ou clusters de
disques différents, sachant qu'un même tablespace peut mélanger des pages
allouées pour des tables ou index différents. Le concept de tablespace
intervient pour passer outre certaines limitations du système de fichiers
utilisé pour y allouer physiquement les tablespaces (ces systèmes de
fichiers étant eux aussi plus ou moins locaux avec des performances d'accès
très différentes selon leur localisation et leur support physique, y
compris sur un emplacement réseau).

Une table de base de données n'est pas nécessairement associée
bijectivement à un fichier physique du système de fichiers. et un
tablespace peut aussi être monté directement dans une partition sans
système de fichiers géré par l'OS (la base de données est déjà en elle-même
un système de fichiers autonome avec son propre catalogue), mais la
situation inverse existe aussi où un système de fichier possède tous les
attributs d'une base de données.



Le 12 août 2014 23:28, Christian Quest cqu...@openstreetmap.fr a écrit :

 Le 12 août 2014 22:09, Christophe Merlet red...@redfoxcenter.org a
 écrit :

 Le 12/08/2014 21:38, Christian Quest a écrit :
  Le 12 août 2014 21:07, Christophe Merlet red...@redfoxcenter.org
  mailto:red...@redfoxcenter.org a écrit :
 
  Le 12/08/2014 20:44, Christian Quest a écrit :
   Ah bon, postgres n'essaye pas de faire un update sur place quand
  c'est
   possible ?
 
  Non. UPDATE étant une opération de type DELETE/INSERT (
  http://postgresql.todaysummary.com/q_postgresql_32709.html )
 
 
  Marrant je n'ai pas la même lecture que toi... je ne vois pas de
  référence au DELETE dans ces explications, juste une proposition pour
  faire l'équivalent du REPLACE de mysql qui fait soit un INSERT soit un
  UPDATE si la ligne existe déjà.


 Ho zut, je me suis trompé de lien oO rien à voir !!
 C'est celui là

 http://www.postgresql.org/message-id/482e80323a35a54498b8b70ff2b879800458c31...@azsmsx504.amr.corp.intel.com


 Mouais... un peu courte l'explication.

 UPDATE est équivalent à DELETE+INSERT vu d'en haut, mais vu d'en bas ça
 m'étonnerai beaucoup que ça soit géré comme ça... show me the code ;)


 C'est comme ça que je comprend la doc
  http://www.postgresql.org/docs/current/static/sql-vacuum.html

 VACUUM reclaims storage occupied by dead tuples. In normal PostgreSQL
 operation, tuples that are deleted or obsoleted by an update are not
 physically removed from their table; they remain present until a VACUUM
 is done. Therefore it's necessary to do VACUUM periodically, especially
 on frequently-updated tables.


 Ok, un DELETE ou UPDATE peuvent laisser des trous, VACCUM les élimine.
 Pour ça VACUUM va prendre des data en fin de fichier et les déplacer dans
 les trous au fur et à mesure de son scan en remettant à jour les index vu
 le déplacement des données. C'est ce que j'ai lu je ne sais plus où :(
 VACUUM FULL procède autrement, il crée une copie de la table en recopiant
 les tuples un à un sans recopier les trous.

 --
 Christian Quest - OpenStreetMap France

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


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

Re: [OSM-dev-fr] glonflement des tables osm2pgsql...

[Philippe Verdy]

Le fill factor (taux de remplissage) est lié à l'orgnisation interne des
tables d'une base de données: les tables stockent les lignes par pages de
taille fixe dans lesquelles on agrège une ou plusieurs lignes; chaque page
est l'élement de base d'une organisation d'une des diverses variantes de
B-arbres. Dans chaque page il reste elors un espace inoccupé, et le fill
factor est le critère qui permet de savoir en dessous de quel taux
d'occupation il faut fusionner deux pages ou plus (lors des suppressions ou
mises à jour réduisant la taille d'une ligne), ou si on doit les éclater en
plusieurs parties (lors des insertions ou mises à jour augmentant la taille
d'une ligne).

Avec un fill factor élevé, les réorganisations agiront sur plus de pages
pour maintenir le taux remplissage souhaité dans toutes les pages. Pour des
tables ne subissant pas trop de mises à jour locales, un fill factor voir
de 85% est généralement bon, une réorganisation nécessitant de traiter
environ 5 ou 6 pages; le but du fill fator est donc d'établir un compromis
en terme de nombre de pages à réorganiser (les écritures sont plus longues:
si le taux est élevé, les réorgnisations seront plus fréquentes mais le
résultat sera une table plus compacte) et en nombre de pages d'I/O
nécessaires poru les accès en lecture (un taux élevé favorise une lecture
séquentielle plus rapide puisqu'il y aura plus de lignes par page lue dans
une seule I/O et puisque le cache en mémoire des pages sera plus efficace).

Si on fait un compactage complet, on obtient les lectures les plus rapides,
mais rapidement cela se dégrade puis ça se stabilise, car les insertions de
lignes dans la table ne tiendront pas dans les pages.

L'effet est moins critique si la table n'est pas elle-même un index
(autrement dit elle n'est pas triée, quelque soit l'organisation de tri
interne, même si c'est généralement un B-arbre dans les bases de données)
Mais la plupart des tables d'une base sont indexées (soit la table est
elle-même stockée comme index primaire, soit c'est un index secondaire
contenant seulement les clés). Si c'est un B-arbre, un fill-factor trop
faible diminue le degré, c'est-à- dire augmente sa profondeur de la page
racine aux pages feuilles et donc augmente les temps d'accès en recherche
indexée.

Un fill factor ne devrait en principe jamais être inférieur à 50%, sauf
sans les tables très souvent mises à jour mais où il est acceptable
d'augmenter un peu le temps d'accès en lecture lors des accès indexés. Une
base de données a un paramétrage par défaut de ce fill factor pour les
index qu'elle gère. Ce fill factor est modifiable, mais une modification
entrainera une réroganisation de tout son contenu pour réapprocher au mieux
ce taux. souvent la valeur par défaut est voisine de 85%, mais en regardant
les statistiques d'I/O sur une table on peu voir si l'essentiel des accès
est passé à la maintenir pour réorgansier des pages (le moteur doit fournir
des stats sur les pages supplémentaires à lire/écrire lors des
fusion/scission de pages) ou si les accès indexés prenent trop de temps.

Selon l'usage constaté, on peut ajuster ce taux (par palier de 5% pour un
taux en dessous de 85%, ou par palier de 1%); plus on s'approche du taux
100% (taux impossible à égaler sauf dans les tables dont les lignes sont
toutes de taille fixe et sous-multiple de la taille de page), et plus les
réorganisations seront fréquentes : à 99% une réorganisation peut
nécessiter de traiter près de 200 pages à la fois (c'est donc coûteux en
I/O)...



Le 12 août 2014 13:47, Francescu GAROBY f.gar...@gmail.com a écrit :

 Et ça ne vaudrait pas le coup de modifier la fonction pgsql_modify_node
 que tu pointes pour lui faire faire un UPDATE, plutôt qu'un INSERT/DELETE ?
 La modification ne me paraît pas compliquée et si ça peut faciliter votre
 histoire de fillfactor (j'avoue ne pas comprendre de quoi il s'agit)...

 Francescu


 Le 12 août 2014 12:47, Christian Quest cqu...@openstreetmap.fr a écrit :

 Par défaut le fillfactor sur les data est de 100%, d'où l'idée de le
 baisser un peu... mais l'efficacité dépendra aussi de comment osm2pgsql met
 à jour les données et vu le code ça semble malheureusement se faire à coup
 de DELETE/INSERT et pas d'UPDATE...
 https://github.com/openstreetmap/osm2pgsql/blob/master/output-pgsql.c#L1432

 Je ne suis pas sûr dans ces conditions que ça serve à grand chose.


 Le 12 août 2014 11:37, Christophe Merlet red...@redfoxcenter.org a
 écrit :

 Le 12/08/2014 10:10, Christian Quest a écrit :
  Vu qu'on a 2 bases osm2pgsql monde à la structure identique sur les
  serveurs tile et layers, j'ai comparé l'espace occupé par les tables
 car
  celui-ci est compté actuellement sur nos SSD de 480 (tile) et 512Go
  (layers).
 
  Il y a des différentes plus ou moins importantes. La plus étonnante
  concerne planet_osm_line qui pour les seules data fait 55Go sur tile et
  39Go sur layers, soit une différence de 40%.
 
  Je m'explique difficilement ces différences.
 
  Je viens de 

Re: [OSM-dev-fr] glonflement des tables osm2pgsql...

[Philippe Verdy]

En terme d'I/O cela ne changera pas grand chose.

Même faire un UPDATE à la place d'un DELETE/INSERT n'aura pas grande
incidence tout bonnement car le premier DELETE aura déjà chargé les pages
qui seront les mêmes que celles affectées par l'INSERT qui suit pour mettre
à jour les index: elles sont encore en cache meˆme s'il y a un petit délai
entre les deux opérations et s'il y a beaucoup d'opérations concurrentes.

Même un UPDATE pourrait avoir poru effet de réorganiser des pages pour
maintenir le fill factor, car l'UPDATE peut changer la taille d'une ligne
de table (en plus ou en moins).

Si on veut être optimal toutefois, un simple SELECT n'a pour effet QUE de
charger les pages nécessaires dans le cache, ce qui rend ensuite l''INSERT
ou l'UPDATE qui suit quasi instantané (au moins pour les pages des index
qui sont utilisés pour faire le SELECT initial). Cependant le SELECT
initial peut se contenter souvent de ne lire qu'un seul index sans avoir à
mettre à jour toutes les tables et index liés, c'est donc plus rapide
puisque le volume de pages concerné est plus faible au cas où la clé n'est
pas trouvée et qu'on va finalement faire un INSERT. En revanche si le
SELECT initial trouve la clé, il est fort probable alors que toutes les
pages de toutes les tables et index liés seront affectées (mais là comme on
a trouvé la clé, et qu'on va faire un UPDATE en utilisant cette clé, les
pages de l'index utilisé pour fait le SELECT initial sont déjà en mémoire
et resteront lues uniquement, alors que les autres tables/index seront mis
à jour pendant l'UPDATE de la ligne trouvée).

Mais le problème de la méthode SELECT suivi de INSERT ou UDATE c'est la
concurrence d'accès: on doit utiliser le mode transactionnel et donc
locker les pages de l'index utilisé pour le SELECT initial. Et là ce sont
ces locks qui risquent d'entraver les performances.

Tout dépend donc de la granularité des transactions: qu'est-ce qui est
atomique dans l'opération INSERT ou UPDATE poru que cela ne provoque pas de
requêtes incohérentes dans les accès concurrents? Pour certaines opérations
de mises à jour comme celles-là où les accès concurrents sont majoritaires
on pourrait croire que DELETE+INSERT inconditionnel serait toujours
préférable, surtout s'il n'y a qu'un seul accès effectuant des mises à jour
des tables (et que tous les autres accès concurrents sont en lecture
seule). On ne peut pas réellement le garantir.

L'atomicité (transactionnelle) de l'opération DELETE+INSERT sera donc la
même que pour l'opération SELECT+(INSERT ou UPDATE) si on veut éviter des
requêtes incohérentes (et donc se retrouver plus tard avec des données
manquantes ou en trop qui restent oubliées dans la base ou éviter de se
retrouver avec des clés doubles (qui provoquent des erreurs
transactionnelels lors de l'INSERT dans une table à index unique).

Les bases utilisées ont de très nombreux accès concurrents; on ne peut pas
se passer réellement du mode transactionnel. De fait on a intérêt donc à
faire un lock tout au début des transactions avant de commencer les
modifs de la transaction, et donc cela milite effectivement pour des mises
à jour utilisant un SELECT initial pour ensuite faire selon qu'on a trouvé
on on la clé, un INSERT ou un UPDATE dans la même transaction (l'intérêt du
lock initial étant que l'opération de rollback ne fait que libérer les
locks et n'aura rien à modifier, il n'y aura eu donc en cas de conflit
nécessitant un rollback, aucun autre accès que des accès en lecture seule.

De plus les locks peuvent être obtenus tous ensembles de façon atomique, et
on eput utiliser alors le mode transactionnel optimiste (où les
rollbacks sont très peu probables, il n'y a qu'à libérer les locks en
cours pour éviter les deadlocks des accès concurrents, et le moteur peut
reprogrammer la transaction sans même avoir besoin de l'annuler ou la
signaler en erreur d'accès concurrent).

Dans tous les cas, le fill factor n'entre pas en jeu pour déterminer le
mode transactionnel. Ce qui compte ce sont uniquement les ratios entre I/O
en lecture seule et I/O en écriture pour les réorganisations de pages
d'index.

En revanche, le modèle de stockage des tables (le type de B-arbre utilisé)
joue un plus grand rôle: dans un B-arbre simple, on stocke les lignes de
table directement dans les pages de n'importe quel niveau (y compris poru
la page racine).

Cependant des modèles de stockage plus performants peuvent utiliser un
stockage différent pour les pages feuilles de l'arbre (stockant toutes les
colonnes de toutes les lignes) et pour les pages de branche ou de la racine
(ne stockant que les clés, lesquelles peuvent aussi être compressées en
utilisant le fait que leur tri cohérent induit une forte redondance entre
les clés voisines dans l'ordre de tri de l'index). Avec un tel modèle de
table, on peut stocker beaucoup de clés dans la même page, les
réorganisations sont très peu fréquentes par rapport aux pages feuilles
plus volumineuses.

Dans un tel modèle d'arbre ayant deux 

Re: [OSM-dev-fr] glonflement des tables osm2pgsql...

[Philippe Verdy]

DELETE/INSERT la plupart du temps va réutiliser la page dans laquelle il
vient de créer un trou, mais au passage il peut aussi utiliser n'importe
quelle autre page déjà en mémoire si cette autre page permet un meilleur
équilbrage de l'arbre que de réutiliser l'ancienne page: le but est
d'équilibrer les trous dans les pages pour éviter de se retrouver dans le
cas au pire (le pire cas c'est une insertion au milieu d'une page déjà
pleine, quand toutes les pages racines sont déjà pleines, ce qui arrive
justement après une compression maximale de la table: c'est là qu'on a le
plus d'I/O puisqu'il faut non seulement scinder la page en deux, lire les
pages voisines avant et après, et restructurer aussi les pages parentes
dans l'arbre de la même façon).

Je n'ai pas eu souvent à mettre dans une base SQL un fill factor supérieur
à 85% (au moins pour les pages feuilles). pour les tables de données, ni
supérieur à 95% pour les index secondaires à clé courte. 97% est un taux
exceptionnel et au delà ça rame dès qu'il y a plus de 3 ou 4 accès
concurrents (même en lecture, à cause des nombreux locks de pages causés
sur une grande partie des pages y compris les pages mères, et à cause des
volumes d'I/O).

Si on veut une base rapide, on doit accepter qu'il y ait des trous à un
taux raisonnable dans les tables volumineuses ayant de nombreux accès
concurrents (surtout que pour ce type de base on à toutes sortes de types
d'accès: séquentiels comme aléatoires, par une grande diversité de requêtes
utilisant des filtres très différents, et des sélectivités de clés
imprévisibles dans les données OSM).



Le 12 août 2014 18:36, Christophe Merlet red...@redfoxcenter.org a écrit :

 Le 12/08/2014 17:30, Francescu GAROBY a écrit :
  Je pensais plutôt à tester la présence (via un SELECT sur l'osm_id, qui
  doit être un champ indexé, je suppose...) et, selon la réponse, à faire
  un INSERT ou un UPDATE.
  Si un SELECT est sensiblement aussi rapide qu'un DELETE, et un INSERT
  aussi rapide qu'un UPDATE, tu ne verras pas de différence notable sur le
  temps de traitement, mais tu auras résolu ton problème de trous de
 partout.
 
  Francescu,
  (qui est développeur, pas DBA)

 Généralement DELETE/INSERT est plus rapide que UPDATE. Et de ce que j'ai
 pu lire sur pgsql,  UPDATE execute en interne un DELETE/INSERT avec donc
 la création de trou dans la base.


 Librement,
 --
 Christophe Merlet (RedFox)

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

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

Re: [OSM-dev-fr] glonflement des tables osm2pgsql...

[Philippe Verdy]

Le 12 août 2014 19:06, Christophe Merlet red...@redfoxcenter.org a écrit :

 Le 12/08/2014 18:47, Philippe Verdy a écrit :
  DELETE/INSERT la plupart du temps va réutiliser la page dans laquelle il
  vient de créer un trou, mais au passage il peut aussi utiliser n'importe
  quelle autre page déjà en mémoire si cette autre page permet un meilleur
  équilbrage de l'arbre que de réutiliser l'ancienne page: le but est
  d'équilibrer les trous dans les pages pour éviter de se retrouver dans
  le cas au pire (le pire cas c'est une insertion au milieu d'une page
  déjà pleine, quand toutes les pages racines sont déjà pleines, ce qui
  arrive justement après une compression maximale de la table: c'est là
  qu'on a le plus d'I/O puisqu'il faut non seulement scinder la page en
  deux, lire les pages voisines avant et après, et restructurer aussi les
  pages parentes dans l'arbre de la même façon).
 
  Je n'ai pas eu souvent à mettre dans une base SQL un fill factor
  supérieur à 85% (au moins pour les pages feuilles). pour les tables de
  données, ni supérieur à 95% pour les index secondaires à clé courte. 97%
  est un taux exceptionnel et au delà ça rame dès qu'il y a plus de 3 ou 4
  accès concurrents (même en lecture, à cause des nombreux locks de pages
  causés sur une grande partie des pages y compris les pages mères, et à
  cause des volumes d'I/O).

 Je te signale quand même que PostgreSQL a un fillfactor par defaut de
 100 pour les data et de 90 pour les index B-tree. J'imagine que les dev
 auraient choisi d'autres valeurs si cela était si impactant sur les
 performances.


Ce n'est pas vrai cela dépend du type de table employé. un fill factor 100
pour les data n'a pas de sens. cela voudrait dire une table totalement sans
aucun index primaire, qui ne sert qu'à cumuler des données (tables de log)
sans aucun critère de tri ou d'unicité. Dès que tu as une clé primaire,
cela ne sert plus à rien.

Si le fill factor pour les B-tree par défaut est 90% c'est un peu trop
optimiste et suppose une base majoritairement utilisé en lecture seule avec
très peu de mises à jour concurrente.

Et MySQL (ou son fork plus récent), comme PostgreSQL, Oracle et d'autres
moteurs SQL proposent aussi différents modèles de tables indexées (et même
si globalement se sont des B-arbres, il y a de nombreuses options dans les
B-arbres, notamment en faisant la différence entre les pages feuille et les
pages racines, et dans la compression des clés, ou encore dans le maintien
(de façon synchrone ou non) de données statistiques de sélectivité.

Un modèle unique pour toutes les tables ou index n'est pas optimal, car
cela est largement dépendant du rapport entre taille moyenne des clés et
taille des pages: idéalement on a intérêt à maintenir un degré élevé des
arbres pour en réduire la profondeur et réduire le nombre de
réorganisations coûteuses en I/O.

Je ne suis pas un grand spécialiste de PostgreSQL, je connais mieux
d'autres moteurs, mais 90% me semble trop élevé (à voir selon justement le
rapport entre taille des clés et tailles des pages, et selon la structure
de B-arbre employé (si elle est différente entre les pages feuilles et les
branches; ou si la compression des clés s'applique aussi aux pages
feuilles) qui n'est peut-être alors pas optimale avec le modèle par défaut
(rappel: il y a au moins une bonne douzaine de B-arbres documentés dans la
littérature mais chaque moteur SQL a inventé les siens et parfois les a
révisé entre leurs versions; certains moteurs SQL disposent d'un optimiseur
dynamique capable de modifier le modèle d'une table au cours de sa vie; en
fournissant des analyses statistiques synchrones ou asynchrones : si les
analyses asynchrones ne sont pas lancées régulièrement sur les tables les
plus vivantes les performances se dégradent, c'est bien plus important de
les lancer que de tenter de recompacter les tables, ce qui ne sert à rien
sur une base très vivante!).

On peut donner des pistes mais sans analyser les statistiques et les
volumétries typiques des requêtes et leur sélectivité, il n'est pas
possible de donner une réponse unique (d'autant plus que la solution
optimale sera à adapter table par table, index par index).

Au début on peut même ne pas avoir de statistiques significatives pour
décider, mais maintenant on atteint un rythme de croisière avec des volumes
typiques importants et des requêtes récurrentes.

Mais il me semble même qu'une optimisation du stockage pour un moteur de
rendu type Mapnik (qui cherchent des cas les plus typiques) sera
nécessairement différent de celle d'une appli de QA, type Osmose (qui
cherche plutôt des cas atypiques par des requêtes que Mapnik ne fera
jamais).

De même les données mises à jour en continu par le rendu Mapnik sont très
peu nombreuses (uniquement indexer des tuiles et leur état) alors qu'il
effectue des recherhes sur des tables de Features prémachées par un
script osm2gis (dont le résultat est très différent de ce qui est
prémâché pour Osmose puisqu'il ne recherche

Re: [OSM-dev-fr] glonflement des tables osm2pgsql...

[Philippe Verdy]

Le 12 août 2014 21:17, Christian Quest cqu...@openstreetmap.fr a écrit :

 Même un UPDATE pourrait avoir poru effet de réorganiser des pages pour
 maintenir le fill factor, car l'UPDATE peut changer la taille d'une ligne
 de table (en plus ou en moins).


 Tout dépend comment le fillfactor est utilisé justement. Sur la partie
 données (et je n'ai parlé que de ça), j'imagine que c'est un peu d'espace
 libre conservé lors des INSERT, mais justement pour être disponible lors
 des UPDATE... sinon quel peut bien être son intérêt ? Si on réserve
 toujours un ratio fixe d'espace vide ça revient à ne jamais l'utiliser...
 et ça n'a aucun intérêt.


Non: le fill factor est un taux de remplissage *minimum* à conserver autant
que possible. On peut toujours remplir au delà. et c'est bien ce que dit la
doc que tu cites qui indiques que justement une update ultérieur peut
toujours réutiliser cet espace laissé libre en cas d'augmentation de taille
d'une ligne.

Cependant je suis plutôt surpris par ton interprétation libre de ce qu'est
un index clustered, dont le but est justement de préserver l'ordre des
lignes de données dans la table: et c'est là alors que pour le préserver,
on peut être amené à scinder une page en deux en déplaçant des lignes dans
une autre page. Alors interient le fill factor qui va chercher à remplir
les deux pages issues de la scission en y ramenant de lignes trouvées dans
les pages suivantes ou précédentes tant qu'elles préservent un taux de
remplissage minimum. C'est là qu'il y aura des I/O pour amener ces autres
pages et vérifier si leurs lignes peuvent être déplacées. Mais cette
recherche reste limitée.

Dans les faits, le fill factor servira lors des mises à jour ou suppression
quand une page n'est plus assez remplie: on récupère alors là aussi des
lignes dans les pages précédentes ou suivantes, et dans certains cas, on se
retrouve avec des pages vides car il y aura fusion de page, et donc on
aboutit à une libération de certaines pages qui deviennent libres (elles
sont ajoutées à un pool de pages libres pour la table, mais si le pool de
pages est déjà trop plein, les groupes de pages libres dans le pool peuvent
être remis à disposition pour d'autres tables.

Autrement dit, une table organisée en clustered index reste triée, ce qui
veut dire que la lecture séquentielle de la table (fulll table scan)
ramènera des lignes déjà triées dans l'ordre de l'index clustered; la table
et l'index ne font qu'un, la table est elle-même un index. Toutefois elle
ne stocke pas que des clés et donc serait inefficace pour des accès rapides
si toutes les pages d'index contenaient toutes les colonnes hors clés
d'index. C'est là qu'on a un format utilisant deux types de pages par un
table en clustered index : des pages racine/branches ne contenant QUE les
clés (ce qui donne un plus grand nombre de clés par page, donc un plus haut
degré de l'arbre et donc aussi une moins grande profondeur), et les pages
feuilles contenant les données hors des colonnes clé des branches (mais les
colonnes des clés absentes des pages de branches/racine mères, seront
stockées dans la page feuille; seule la première ligne dans la page feuille
n'a pas besoin de stocker sa clé puisqu'elle est dans la page
branche/racine mère. Cette première ligne d'une page feuille a une clé
nulle, les autres lignes stockent leur clé (ou une partie différentielle de
la clé en cas de compression des clés).

Il y a divers formats de tables index disponibles selon les moteurs SQL sur
l'emplacement de stockage des clés! Les B-arbres les plus simples
n'emploient qu'un seul type de page et ne distinguent pas les pages
feuilles des pages racines/branches, ne ne compressent pas non plus les
clés qui sont stockées dans toutes les lignes de toutes les pages.




 Si on veut être optimal toutefois, un simple SELECT n'a pour effet QUE de
 charger les pages nécessaires dans le cache, ce qui rend ensuite l''INSERT
 ou l'UPDATE qui suit quasi instantané (au moins pour les pages des index
 qui sont utilisés pour faire le SELECT initial). Cependant le SELECT
 initial peut se contenter souvent de ne lire qu'un seul index sans avoir à
 mettre à jour toutes les tables et index liés, c'est donc plus rapide
 puisque le volume de pages concerné est plus faible au cas où la clé n'est
 pas trouvée et qu'on va finalement faire un INSERT. En revanche si le
 SELECT initial trouve la clé, il est fort probable alors que toutes les
 pages de toutes les tables et index liés seront affectées (mais là comme on
 a trouvé la clé, et qu'on va faire un UPDATE en utilisant cette clé, les
 pages de l'index utilisé pour fait le SELECT initial sont déjà en mémoire
 et resteront lues uniquement, alors que les autres tables/index seront mis
 à jour pendant l'UPDATE de la ligne trouvée).


 J'imagine plus le SELECT chargeant uniquement ce dont il a besoin.
 Quelques pages de l'index qui permet de trouver les données, puis les
 données... et aucune page d'autre index éventuel pointant sur le données.

Re: [OSM-dev-fr] Aide html/javascript

[Philippe Verdy]

Ce ne serait pas une limite de sécurité des XmlHttpRequest imposée par IE8
pour une requête inter-domaine qui empêche la requête de s'exécuter ?

Deux lignes bizarres (dans ton main.js):

xhr.setRequestHeader( Content-length, params.length );
xhr.setRequestHeader( Connection, close );

Pour la première ce n'est pas la bonne valeur, car tu compte le nombre de
caractères UTF-16 de la chaîne Javascript et non son encodage dans la
requête (UTF-8) et aussi il manque le réencodage HTTP des sauts de ligne.
Tout dépend de ce qui est dans params.
De plus tu utilises à la fois des param_tres POST et des paramètres GET
dans une requête POST:
xhr.open(POST, getDepartement.php?ville= + ville, true );
Pour pas simplement dans ce cas ne pas tout mettre dans la query string et
utiliser une requête GET?

Pour la seconde, Connection:close est suspect. A priori on ne précise que
la condition keep-alive (si la requête se fait en HTTP/1.0 et sinon rien en
HTTP/1.1).

Les deux entêtes Connection:close et Content-length:* sont marqués unsafe
par la console de Chrome mais je soupçonne que le vieux XmlHTTPRequest
d'IE8 soit plus radical et rejette ta requête. A priori c'est au composant
XMLHttpRequest de s'en charger.

Enfin XMLHttpRequest dans IE a été un activeX nécessitant une autorisation
spéciale et qui peut sinon t'empêcher de faire une requête interdomaine.
Mais ici l'URL que tu utilises dans xhr.open() ne précise pas le domaine et
si XmlHTTPRequest est un composant externe, il n'aura pas accès tout seul à
l'URL de base de ton document. Il faut alors préciser l'URL complète et pas
une URL relative;

Cela concerne aussi:

xmlhttp.open(GET, getCenter.php?dep= + dep + ville= + ville);

où cette fois tu n'utilises que des paramètres GET (dans la query-string),
requête qui a l'avantage d'être cachable par défaut au contraire des
requêtes POST.



Le 28 avril 2014 13:00, Tyndare tynd...@wanadoo.fr a écrit :

 Le 28 avril 2014 06:15,  didier2...@free.fr a écrit :
  je viens juste d'essayer sur windows xp
  + avec ie8:
 
  - en bas a droite de la page web, le lien de l'image openstreetmap.fr
 est brisé : http://www.cleo-carto.com/images/cartouche_osm-fr.png
  mais il y a une redirection de cleo ...

 Effectivement. Je ne connais pas trop l'historique du site web.
 Quelqu'un sais où trouver une image cartouche osm fr pour remplacer ?

  - la selection du departement fonctionne mais la liste des communes est
 vide

 La je sèche...
 La liste est normalement remplie en modifiant la valleur innerHTML
 avec le résultat d'une XmlHttpRequest. Je ne sais pas trop ce qui pose
 problème avec IE8.

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

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

Re: [OSM-dev-fr] Aide html/javascript

[Philippe Verdy]

Le 28 avril 2014 16:16, Tyndare tynd...@wanadoo.fr a écrit :

 Le composant axtiveX c'était je crois pour ie6, pas ie8.


Je ne suis pas certain qu'il soit disparu même si IE donne une interface
native pour l'instancier. Utiliser directement les XHR pose des problèmes
de compatibilité. Cela fait longtemps que je n'utilise plus les XHR de
cette façon, mais j'utilise un framework.
Il y a même une intégration plus poussée avec le framework Leaflet pour ses
mixins.

Sinon j'en ai soupé de suivre les versions d'IE qui changent leurs API sans
arrêt ou la façon de les utiliser en préservant la compatibilité de ce qui
se faisait dans les versions d'avant (et pas toujours des moyens simples
pour détecter la bonne façon de faire).

Tu peux déjà essayer en utilisant une URL absolue et non une URL relative
(la question qui se pose est bien  relative à quoi ? Il est possible que
cette requête ne s'exécute pas du tout en fait (rien envoyé au serveur, ou
erreur HTTP 404, j'ai déjà eu des trucs bizarres avec les XHR utilisant des
URL relatives mal résolues, parfois liées à des threads concurrents qui
interrogent d'autres serveurs XHR)

Sinon, les XHR sont un peu obsolètes, les requêtes JSON ont une intégration
native et plus sécurisée (et moins de contraintes et plus de performance,
même si ici les requêtes ne sont pas énormes et fréquentes). Même si au
final tes requêtes XHR ne servent pas à charger du XML nécessitant un
parseur lourd côté client.

Enfin sur Chrome la première requête effectuée (si on n'a encore rien saisi
dans la commune) en sélectionnant un département est
.http://cadastre.openstreetmap.fr/getDepartement.php?ville=undefined

Tu noteras la présence de undefined qui signale une variable non
initialisée (le nom de la ville cherchée). Je ne sais pas ce qui est
transmis en valeur sous IE et comment cela affecte ensuite la recherche des
communes...
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Disparition de balises (seamark) - exploiter les diff

[Philippe Verdy]

Apparemment il a importé massivement en créant des doublons pour retracer,
puis nettoyé tous les doublons sans prendre garde à la présence de tags
qu'il n'a pas importés dans les nouveaux objets de remplacement.

C'est en ça qu'un bot d'import mal utilisé peut être nuisible si
l'utilisateur ne prépare pas correctement ses imports.

Ca devrait être marqué dans les notices pour bots : si un dédoublonnage est
compliqué, au lieu de supprimer il vaut mieux ajouter un tag fixme ou une
relation collectant dans une zone donnée ce qui est à corriger, afin
ensuite de pouvoir créer une tâche collaborative dont l'avancement qui peut
être suivie.

Mais l'idéal c'est de créer ces collections sur une base dédiée (du type
Osmose) où on peut marquer ce qui est à vérifier.




Le 25 avril 2014 16:00, THEVENON Julien julien_theve...@yahoo.fr a écrit :

 Re,

 Pour l instant je suis aux alentours du 17 Mars ( la connection du boulot
 n a pas l air tres rapide ) et je commence a voir apparaitre beaucoup de
 suppressions d objets contenant des tags seamarks par l utilisateur
 IENC-import  ( http://www.openstreetmap.org/user/IENC-Import  )
 Par exemple ces 3 changesets :
 http://www.openstreetmap.org/changeset/21081303
 http://www.openstreetmap.org/changeset/21081560
 http://www.openstreetmap.org/changeset/21081255


 Je t envoie le log complet quand il aura fini

 Julien

   --
  *De :* Bruno Cortial bruno.cort...@laposte.net

 *À :* Discussions développeur OSM en français dev-fr@openstreetmap.org
 *Envoyé le :* Vendredi 25 avril 2014 14h46
 *Objet :* Re: [OSM-dev-fr] Disparition de balises (seamark) - exploiter
 les diff




 Le 25 avril 2014 14:41, Frédéric Rodrigo fred.rodr...@gmail.com a écrit
 :

 C'est tout simplement le tag seamark:fixme


 Mais ce n'est pas ce tag spécifiquement qui a été supprimé, mais sans
 doute l'objet, car les objets avec des tag seamark* ont diminué dans les
 mêmes proportions.


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



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


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

Re: [OSM-dev-fr] Un utilisateur fantome

[Philippe Verdy]

Le 12 janvier 2014 21:33, Pierre Béland pierz...@yahoo.fr a écrit :

 Ce peut être un problème de communication entre ID et l'API. Mais de toute
 façon, il y a un problème d'enregistrement des informations par l'API. On
 ne devrait pas y enregister un  changeset sans transaction de données. Et
 encore moins avec un usager inexistant.


Tous les changeset sont créés initialement vides avant qu'on y injecte des
transactions dans des requêtes séparées.

Cependant les changesets sont ensuite autmatiquement fermés par le s'il n'y
a plus d'autres transaction pendant un certain temps.

A ce moment-là (ou lorsque le changeset est fermé explicitement par une
transaction close), s'il n'y a aucune transaction dedans, le serveur
pourrait le supprimer aussitôt de la base (et aussi de l'historique de
l'utilisateur, même s'il y a d'autres attributs comme un commentaire).
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Un utilisateur fantome

[Philippe Verdy]

Différentes raisons peuvent expliquer un changeset vide, même sans aucune
erreur réseau.

Par exemple un utilisateur modifie ou supprime un chemin ou une relation et
veut l'envoyer, ce sera la première transaction du changeset: il ouvre un
changeset (qui est alors vide), puis envoie l'objet à modifier ou supprimer.

Et là le serveur détecte un conflit d'édition. L'utilisateur peut mettre
des heures à gérer le conflit et réparer son envoi. Pendant ce temps-là, le
changet n'aura toujours aucune transaction valide, et le serveur pourra
même le fermer prématurément.

L'utilisateur peut aussi décider d'abandonner sa modif et ne rien faire
d'autre que fermer le changeset (CTRL+ALT+Q dans JOSM), et jeter ses modifs
en cours. Le changeset est là aussi fermé et reste vide.

Dans les deux cas, ce changeset vide reste dans le journal de l'utilisateur
mais ne sert à personne, même pas à son auteur. Car même si l'auteur n'a
pas abandonné ses données locales, s'il veut les envoyer après avoir résolu
le conflit d'édition, il devra ouvrir un nouveau changeset (l'ancien a été
fermé).

Un changeset peut rester vide et ouvert pendant assez longtemps avant que
le serveur le ferme automatiquement (plusieurs heures ?). Ce n'est pas une
anomalie donc d'avoir un changeset vide visible tant qu'il est ouvert, mais
ça l'est si le changeset est fermé.

Le changeset étant lié à un utilisateur, si cet utilisateur est supprimé,
cela ne peut pas se faire avec un changeset associé encore ouvert : ce
changeset doit d'abord être fermé. Ce changeset peut alors être purgé
(puisqu'il est vide), et l'utilisateur supprimé quand les autres changesets
non vides de cet utilisateur ont été modifiés pour aller dans un compte
utilisateur poubelle (là il faut lancer un processus de nettoyage comme
pour le changement de licence, selon la validité des données associées qui
restent dans la base, si leur licence était valide et si les données
n'étaient pas abusives ou des déchets).

Le cas pourrait concerner des comptes utilisateurs bannis par le DWG, ou
supprimés à la demande de l'utilisateur, quand les données bien que valides
au plan de la licence pourraient être nuisibles à l'utilisateur sur sa vie
privée ou celle des autres (imaginez qu'on trouve dans OSM des
localisations précises des points de rassemblements LGBT en Russie ou en
Iran, avec les dates et heures, ou listes de personnes attendues, ou leur
numéros de téléphone, adresses mail, pages Facebook ou Twitter, ou des
liens vers des documents compromettants, y compris des photos publiées par
erreur ou mal anonymisées, etc. Imaginez aussi les liens nuisibles de type
spam vers des sites redirecteurs, généralement on ne veut pas des
shortURL anonymisées chez des fournisseurs qui n'ont aucun système de
filtrage des abus).




Le 14 janvier 2014 06:49, Philippe Verdy verd...@wanadoo.fr a écrit :

 Le 12 janvier 2014 21:33, Pierre Béland pierz...@yahoo.fr a écrit :

 Ce peut être un problème de communication entre ID et l'API. Mais de toute
 façon, il y a un problème d'enregistrement des informations par l'API. On
 ne devrait pas y enregister un  changeset sans transaction de données. Et
 encore moins avec un usager inexistant.


 Tous les changeset sont créés initialement vides avant qu'on y injecte des
 transactions dans des requêtes séparées.

 Cependant les changesets sont ensuite autmatiquement fermés par le s'il
 n'y a plus d'autres transaction pendant un certain temps.

 A ce moment-là (ou lorsque le changeset est fermé explicitement par une
 transaction close), s'il n'y a aucune transaction dedans, le serveur
 pourrait le supprimer aussitôt de la base (et aussi de l'historique de
 l'utilisateur, même s'il y a d'autres attributs comme un commentaire).


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

Re: [OSM-dev-fr] Précisions à propos du format XML OSMChange

[Philippe Verdy]

En gros les données d'un changeset ne sont pas traitées dans n'importe quel
ordre:
- d'abord tous les create sont traités (dans l'ordre: [1]tous les noeuds
créés, puis [2]tous les chemins créés, puis [3]toutes les relations créées)
- puis tous les modify ([4]ordre indifférent)
- puis tous les delete (dans l'ordre: [5]toutes les relations supprimées,
puis [6]tous les chemins supprimés, puis [7]tous les noeuds supprimés)

Il y a une difficulté aux étapes [3] et [5] concernant les dépendances
mutuelles entre les relations. En cas de référence cyclique entre deux
relations à supprimer, il fait d'abord briser la référence cyclique en
modifiant une d'elles à l'étape [4] pour commencer en supprimans ses
membres référents dont un d'eux est à effacer, ce qui permet de supprimer
alors l'autre relation qui n'a plus de référence, puis ensuite de supprimer
la première relation qui na déjà plus de membre.

De même cette difficuté existe en cas de création de références cycliques
entre deux relations nouvelles : on commence par créer chaque relation mais
sans le membre de la première qui référence la seconde relation pas encore
créée.

Les listes de noeuds, ou de chemins aux étapes 1, 2 , 6 et 7 n'ont pas
d'ordre interne.

Le plugin Reverter de JOSM ne sait toujours pas cependant traiter
correctement l'ordre d'envoi (nécessitant plusieurs versions dans le même
changeset pour la même relation) pour les listes de relations des étapes 3
et 5 : l'ordre topologique est partiel et ne sait pas traiter les
références cycliques.

D'une façon générale les références cycliques entre relations sont à éviter
dans la base, mais la base OSM ne l'interdit pas du tout, et on a vu de
gros plantages dans JOSM ou dans les outils de rendus à cause de ça
 (boucles infinies, débordement mémoire de la pile, explosion de quota en
temps CPU ou mémoire). processus figé, voire même OS planté si ça survient
dans une procédure critique d'affichage (bogue que j'ai signalé dans JOSM
et pour lequel il y a une correction depuis des mois) !

On trouve ces références cycliques dans la base pour certaines relations
ayant des membres de rôles applies_to et defaults.



Le 22 décembre 2013 20:41, François Lacombe 
francois.laco...@telecom-bretagne.eu a écrit :

 Merci Pierre pour cette réponse.

 Le 22 décembre 2013 20:26, Pierre Béland pierz...@yahoo.fr a écrit :

 François,

 Voici une partie des réponses. Je vais laisser à d'autres traiter des
 relations.

 À partir de l'historique de openstreetmap.org, si nous regardons
 l'historique d'un changeset particulier, il nous est offert de voir
 l'historique au format osmchange. Et effectivement, il est donc possible de
 voir toutes les transactions effectuées dans la base OSM avec ce changeset.

 Voir par exemple
 http://www.openstreetmap.org/api/0.6/changeset/19585655/download, où on
 voit clairement des objets

 - créés  create  le id n'est pas négatif, mais correspond plutôt à
 celui attribué lors de la sauvegarde
 - modifiés modify et effectivement avec un no. de version plus grand
 que 1, correspondant à celui attribué lors de la sauvegarde
 - effacés delete


 Je n'ai pas pensé à faire un appel download pour me rendre compte, c'est
 très instructif.

 Je n'avais pas pris au sérieux la mention in fact, *all* *id* attributes
 in create elements are treated as placeholders whether negative or not.
 mais il y a bien plusieurs create, modify ou delete.



 Un noeud déplacé ne change pas d'id. C'est la géométrie qui change (ie.
 lat et lon).


 Ah oui ça c'est une chose qui m'avait échappé, on a des identifiants
 logiques plus que des numéros d'enregistrement.
 Ça résout une bonne partie des cas auxquels j'avais pensé.

 Néanmoins, qu'est-ce qui m'assure que si plusieurs nœuds et une voies sont
 créés, la voie sera après la liste de tous les nœuds ? Pour ne pas la
 digérer avec des références vers les nœuds négatives.

 Dans les autres cas, create sera traité avant modify. Si la voie existe et
 qu'on lui ajoute un nœud, elle sera forcément traitée après le nœud donc
 avec la bonne référence.



 *François Lacombe*

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

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


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

Re: [OSM-dev-fr] Précisions à propos du format XML OSMChange

[Philippe Verdy]

Note: les listes de relations à créer ou celles à supprimer peuvent se
faire dans n'importe quel ordre si la création ou la suppression des
relations se fait d'abord avec des listes de membres vides.

Les références cycliques ne peuvent exister que dans les listes de membres
des relations. C'est là qu'il faut faire attention. Une solution c'est:
* ne pas créer les relations avec les membres. On se contente de créer des
relations entièrement vides (et même sans aucun tag) pour gagner du temps
(ou juste un tag signalant que c'est une version intermédiaire, ce qui peut
faciliter la récupération en cas d'échec d'un upload), puis on met à jour
toutes les relations avec tous les tags et listes de membres complètes.
* ne pas supprimer directement les relations ayant des membres. Commencer
par les modifier en vidant tous les tags et membres (ou en gardant juste un
tag indiquant que l'objet vide de sens va être supprimé), puis envoyer les
demandes de suppression des relations vides.

On ne peut dans les deux cas combiner ces étapes (en une seule version et
non deux par relation à créer ou à supprimer) que si on n'est sûr qu'il n'y
a pas de références cycliques entre les relations à créer ou entre les
relations à supprimer. Et c'est là qu'un tri topologique permet déviter de
doubler le nombre de versions à envoyer.
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Précisions à propos du format XML OSMChange

[Philippe Verdy]

Un autre truc que ne fait toujours pas correctement JOSM c'est minimiser
l'impact de ce qu'on doit faire en cas de conflits détectés lors des envois
d'objets à modifier ou à supprimer:
Comme OSM accepte des envois par lots, il peut y avoit de nombreux lots
intermédiaires entre les objets vides à créer et leur utilisation dans
d'autres objets.
De fait on commence souvent par envoyer de gros lots de noeud vierges de
tout tag qui ne seront utilisés que lors de l'envoi bien plus tard des
chemins ou relations qui les utilisent.

Idéalement, on devrait tenter de réduire cet écart dans les lots envoyés en
assurant de compléter intégralement et le plus vite possible (avant les
autres) les objets qui utilisent les objets déjà envoyés.

C'est d'autant plus critique que les créations d'objets (noeuds chemin ou
relations) se font de façon très éloignée, et que ce n'est ensuite que lors
des étapes d'envois d'objets créés plus tard ou pire ceux qui sont
modifiés, que ces nouveaux objets vont être utilisés dans la base, et que
ce n'est que lors des envois d'objets à modifier qu'on va détecter des
conflits d'édition.

Les premiers conflits d'éditions se produisent donc souvent très tard,
alors qu'on a déjà envoyé beaucoup de nouveaux objets, et que cela
complique sévèrement la récupération en cas de problème (conflit d'édition,
ou même problème réseau interrompant la session en cours).

Un tri topologique devrait donc toujours être réalisé afin que les envois
de données vers la base OSM soient terminés le plus tôt possible dans un
état cohérent. Sinon on se retrouve facilement avec la base laissant des
tas d'objets inutilisés (et souvent même sans aucune balise quand il s'agit
des noeuds qui se retrouvent orphelins).

La gestion des erreurs et la facilitation des situations de récupération
d'erreurs de dessions ou de conflits d'édition doit être pensé assez tôt,
sinon la tâche qui incombe à l'utilisateur pour nettoyer ça prend un temps
fou et est particulièrement complexe (même les outils poru faire un revert
ont du mal à gérer les dépendances pour faire ça proprement).

Pour des grosses modifs (contenant nécessairement plein de travaux de
préparation, de fusion et d'intégration), les conflits d'édition sont
inévitables, surtout dans des zones denses ou étendues.

Là dessus les outils (pas seulement JOSM) peuvent encore et devraient
s'améliorer sur la façon dont ils ordonnent les envois au serveur. Car on
passe énormément plus de temps souvent à gérer les conflits d'édition (aevc
un gros risque de commettre des erreurs pour les résoudre manuellement)

Et ce n'est même pas plus facile non plus d'abandonner en cours et vouloir
faire un revert complet (les reverts sont encore une affaire de
spécialistes qui savent jongler avec les dépendances d'objets, sélectionner
manuellement des sous-listes d'objets à envoyer d'abord avant les autres...
alors qu'une machine ferait les choses bien plus facilement et plus
proprement en procédant dans le bon ordre)
.


Le 22 décembre 2013 22:14, François Lacombe 
francois.laco...@telecom-bretagne.eu a écrit :

 Pas de soucis Christian.

 Le format OsmChange concerne l'appel changeset/#id/upload de l'API v0.6
 Normalement je vais essentiellement traiter des input JOSM mais je ne sais
 pas ce qu'il utilise de l'API, je me contente d'implémenter le protocole en
 entier.

 J'ai pas la même structure qu'OSM mais j'ai les mêmes primitives.
 Du coup pas de soucis, seuls les nœuds sont porteurs des coordonnées chez
 moi aussi. Nul besoin d'avoir la voie dans le fichier OsmChange si la liste
 de ses membres n'est pas modifiée.

 Tout le travail consistait à traduire mes objets au format OSM et à bien
 interpréter les documents en retour.
 Après c'est du gâteau.



 *François Lacombe*

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


 Le 22 décembre 2013 22:07, Christian Quest cqu...@openstreetmap.fr a
 écrit :

  Je ne sais pas quels fichiers osmChange tu vas traiter, mais pour les
 changeset issus des diff des serveurs OSM, il faut prendre en compte un
 truc important: tu peux avoir un changement sur un noeud qui impactera des
 ways sans que les ways ne figurent dans le changeset. Leur géométrie est
 modifiée, mais pas leur définition.
 Pareil pour les relations...

 C'est compréhensible sur le plan base de données relationnelle, ça l'est
 beaucoup moins pour une base de données géographiques.
 C'est ce qui fait toute la complexité d'osm2pgsql (et autres) sur la
 gestion des diffs...

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



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


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

Re: [OSM-dev-fr] Simplifier nos limites admin...

[Philippe Verdy]

Le 18 décembre 2013 00:34, Christian Quest cqu...@openstreetmap.fr a
écrit :

 Il va falloir trouver une astuce... j'ai testé département par département
 et là c'est jouable.

... sauf si les limites côtières entre deux départements traversent
justement par un estuaire (ex. 35 et 44), mais ça dépend jusqu'où on fait
remonter l'estuaire maritime pour les limites des communes littorales.

En revanche pour les limites de régions et départements (i.e. les limites
préfectorales, pas celles des collectivités locales de la région et du
département, qui n'ont pas compétence du domaine maritime et même pas la
compétence totale sur le littoral terrestre protégé) et les limites
nationales, on n'a pas de mal à définir leur domaine maritime en utilisant
les limites dans les eaux territoriales.

C'est bien pour ça qu'on devrait supporter en France aussi ce que font les
Allemands depuis longtemps (et d'autres pays aussi) : les land_areas
définis sur les lignes de côtes et non les limites des eaux territoriales
nationales.

Peut-être que ces land_areas ne sont pas documentés sur le wiki en anglais
mais ça l'est parfaitement en allemand et il y a assez d'explication et de
notes d'alertes dans les données OSM pour expliquer la différence avec les
boundary=*, et ils en ont aussi discuté depuis longtemps de la nécessité
d'avoir ces land_areas (qui ne sont pas seulement un besoin administratif,
mais aussi un clair besoin au plan géographique/cartographique, même si en
théorie on nos lignes de côtes devraient être celles de la ligne de base
légale, qui traverse aussi les estuaires et inclut les ports presque fermés
par une digue de protection et toute zone d'eau de moins de 50 mètres de
large environ, soit l'ordre de grandeur des marées le long des plages
atlantiques et de la Manche ou la Mer du Nord, cette distance étant plus
réduite en Méditerranée, mais variant dans les estuaires selon les régimes
des fleuves pour ce qui concerne les limites des estuaires)..

Mais c'est vrai qu'un land_area pour la France demanderait un multipolygone
très complexe avec de nombreux membres, tellement nos cotes sont découpées
(surtout en Bretagne).

Actuellement on ne sait toujours pas si en France les limites de nos
régions doivent être celles des collectivités territoriales (excluant les
eaux territoriales), ce qui semble être le cas, ou les limites
(sous-)préfectorales (en fait de la compétence exclusive de l'Etat, lequel
inclut le domaine maritime). Selon les cas on aurait besoin d'avoir les
deux aussi en France, les limites administratives (de l'Etat) incluant les
eaux territoriales, et une autre relation pour les land_areas (dans la
compétence réelle des régions, départements et communes en tant que
collectivités locales mais qui ne sont pas réellement un découpage complet
du pays).
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Maintenance serveurs free (osm11/12/13) le lundi 2 décembre

[Philippe Verdy]

Sur la page wiki que tu cites, osm11 et osm12 ne correspondent à rien du
tout. Les numéros sont différents (au dessus de 100 à Bezons).
Page wiki pas à jour ?


Le 26 novembre 2013 15:35, Christian Quest cqu...@openstreetmap.fr a
écrit :

 Je planifie un petit passage chez free à Bezons lundi prochain (le 2/12)

 Au programme:
 - ajout d'un SSD sur osm12, donc reboot de celui-ci
 - reboot éventuel d'osm11 et osm13 après quelques mises à jour (de kernel
 entre autre)

 Pour voir ce qui peut être impacté, consulter la page Fr:Servers sur le
 wiki: http://wiki.openstreetmap.org/wiki/FR:Servers


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

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


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

Re: [OSM-dev-fr] Drole d'user dans les diffs

[Philippe Verdy]

Le 20 novembre 2013 11:08, Pieren pier...@gmail.com a écrit :

 Tu ne peux pas trop te fier au champs user pour suivre quelqu'un
 mais plutôt à son uid. Par contre, il me semble que quelqu'un avait
 développer un service qui retournait tous les pseudo utilisés par un
 même uid mais je ne le retrouve pas.

L'ennui c'est qu'on peut faire un browse des changesets d'un utilisateur
uniquement avec son username actuel, mais pas avec son uid. Ainsi :
  http://www.openstreetmap.org/user/Ivolino
fonctionne (actuellement, jusqu'au moment où il changera à nouveau son
username) mais pas :
  http://www.openstreetmap.org/user/1514664
et pas plus non plus:
  http://www.openstreetmap.org/uid/1514664
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Drole d'user dans les diffs

[Philippe Verdy]

Le 20 novembre 2013 11:30, Ista Pouss ista...@gmail.com a écrit :Merci,
et apparemment il y a aussi un appel à l'api de possible :


 http://api.openstreetmap.org/api/0.6/user/1514664 - renvoie... Ivolino !
 yep ! yep !

 ... et donc ça veut dire que je dois aborder les appels directs à l'API
 OSM... un univers sans fin s'ouvre à moi, ai-je le sentiment de
 l'impression.


OK mais résultat en XML, ce n'est pas navigable. Mais au moins cela répond
correctement à la question (pas comme whosthat.osmz.ru qui se trompe)

Pourquoi alors on n'a pas une version HTML de cette API OSM officielle,
permettant de préciser l'uid et non un user name peut-être obsolète ? Il
faut ouvrir un ticket pour demander d'avoir:

  http://www.openstreetmap.org/uid/1514664

et pas seulement

  http://www.openstreetmap.org/user/Ihttp://www.openstreetmap.org/uid/1514664
volino

(un lien qui n'est pas stable avec le temps) ?
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Récupération de données d'un fichier .osm

[Philippe Verdy]

Le 25 juillet 2013 22:23, Frédéric Rodrigo fred.rodr...@gmail.com a écrit
:

 Le 25/07/2013 22:03, Pierre Béland a écrit :

  Je voulais vous montrer le nouveau parametre area avec la variante où on
 spécifie le nom plutôt que le no de relation. Plus simple à première vue
 que l'id de la relation + 36.

 Mais je n'obtiens pas le même résultat que Christian en utilisant le
 parametre area[name=Bordeaux];

 De fait, il y a deux limites administratives qui portent le même nom
 Bordeaux. Il serait sans doute mieux dans de tels cas de donner des noms
 légèrement différents pour représenter ces deux entités. Mais je risque
 sans doute de lancer encore un long débat sur le sujet des limites
 administratives.

 Bordeaux, admin_level=7 relation 1667452
 Bordeaux, admin_level=8 relation 105270


 Oui, ça fait un moment que c'est comme ça et ça pose problème.

Même avec admin_level cela ne suffira pas. Des homonymes il y en a partout
dans la base pour des endrois qui n'ont rien à voir entre eux. changer un
name ne changerait de toute façon pas le problème, une requête sur name=*
ne changera rien à l'existence des homonymes très nombreux, et n'améliorera
pas plus la carte (sans compter qu'un name=* peut avoir des utilisations
autres que des limites administratives, rappelez-vous du noms des petites
îles de l'archipel artificiel Monde aux Emirats arabes unis, ajoutez les
localités non adminsitratives, lieux-dits, quartiers non administratifs,
noms de commerces...)

Dans TOUTE requête avec juste name=*, on peut s'attendre à des homonymies
et trouver plusieurs résultats. Nominatim affiche une liste de résultats,
et c'est à l'utilisateur de préciser sa requête en sélectionnant un d'eux
(ce qui ramène alors l'identifiant précis).
OSM n'est pas fait pour privilégier une utilisation ou un rendu particulier
plutôt qu'un autre. Donc ce n'est absolument pas un problème pour OSM, mais
VOTRE problème selon votre point de vue à un instant T, que de croire
qu'OSM devinera pour vous ce que vous cherchez.

Maintenant on devrait pouvoir indiquer au lieu du paramètre:
area[name=Bordeaux] un paramètre plus précis:
- area[admin_level=8][name=Bordeaux] (problème possible avec les
paroisses)
- area[boundary=administrative][admin_level=8][name=Bordeaux]
- area[boundary=local_authority][name=*Bordeaux] (pour la communauté
urbaine)
- etc.

Et améliorer aussi en indiquant une bbox ou un point de référence (lon/lat
ou x/y pour faire court) sur la carte du monde (sélection selon la distance
la plus courte), comme dans le site web OSM.org avec son outil de recherche
Nominatim, ce qui modifie le classement par pertinence (et alors pas besoin
d'inventer de nouveaux pseudo-identifiants).
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Des IDs a votre bon coeur COMPLET J'ESPERE.

[Philippe Verdy]

Je suis aussi d'avis que ces IDs générés en interne par une base privée
sont du même type que ceux généras par un des nombreux services de type
TinyURL. Ils sont tous privés, pas homogènes, pas garantis d'être stables
ni même librement utilisables (et sans suivi de leur utilisation par un
tiers, qui peut aussi décider de renvoyer vers autre chose ou d'insérer des
données modifiées de son choix dans le trafic).

Si des IDs stables doivent exister pour référencer des objets OSM, ils
doivent être définis dans cette base OSM elle-même, ou bien s'appuyer sur
des bases tierces ouvertes ne demandant pas un tel suivi (c'est le cas des
identifiants INSEE par exemple, librement vérifiables).

La stabilité des IDs est très relative : elle n'est garantie que si ils
sont datés avec leur date de validité, les objets référencés pouvant à tout
moment changer de statut. Si un ID stable devait être utilisé, il devrait
au minimum inclure l'année de leur création
- soit dans leur valeur (exemple ref:INSEE=35238:2000 au lieu de
ref:INSEE=35238),
- soit dans la clé (exemple ref:INSEE:2000=35238, ce qui permettrait
d'avoir une autre clé pour d'autres années après un changement de l'objet
référencé, ici une commune si celle-ci est divisée ou fusionnée avec une
autre voisine).
Ensuite à charge pour les outils de recherche et de mise en relation avec
d'autres bases de faire les correspondances avec ces IDs stables, en tenant
compte de l'année s'il y a des IDs différents pour la même base de
référence (ici celle de l'lNSEE).

Combien d'IDs garder ensuite dans la base OSM ? On peut faire le ménage en
fonction des dates indiquées justement, qui permettent de procéder à des
vérifications ultérieures ou des remises à jour (même si cela consiste
seulement à garder l'identifiant en ne changeant que l'année), et en
fonction de l'universalité de ces identifiants (les identifiants INSEE sont
assez largement universels pour être gardés à demeure pour longtemps
partout en France, tant que l'INSEE les maintiendra; mais l'INSEE peut
aussi décider une année de revoir son propre système de codification et ces
dates indiquées dans des références supplémentaires historiques seront
utiles pendant une période de transition assez longue). Ces identifiants
sont plus universels que bien d'autres d'origine privée (mais d'usage
limité au seul domaine de leur concepteur).

Les IDs externes ne sont utiles que si la base externe est bien la source
de référence principale et fiable de vérification des données (cette
fiabilité pouvant être garanti par la loi quand elle oblige une entité à
s'inscrire dans un registre officiel reconnu, dont le nombre est
relativement limité). S'il s'agit par exemple d'un point géodésique en
France, la base de référence française est bien connue et c'est d'elle
qu'on tire l'identifiant externe. S'il s'agit d'un identifiant de société
ou d'un établissement de cette société, il n'y a que les identifiants au
RCS et SIREN+SIRET qui sont stables et fiables (mais eux aussi devrait être
datés), mais on peut ajouter le numéro fiscal européen.





Le 28 juin 2013 14:38, Pieren pier...@gmail.com a écrit :

 2013/6/28 Ista Pouss ista...@gmail.com:

  Quelqu'un avait rouspété que l'id se formait de façon obsure. Pas du
 tout !
  À chaque id je suis capable de faire correspondre l'ID Overpass (car
  j'utilise overpass).

 C'est quoi l'ID Overpass ? Comment fais-tu pour convertir la requête
 Overpass:

 http://overpass.osm.rambler.ru/cgi/interpreter?data=node%2845.38591285563495%2C4.306640625%2C45.48228066163947%2C4.51263427734375%29%5B%22shop%22%3D%22bakery%22%5D%5B%22name%22%3D%22La+baguette+magique%22%5D%3Bout%3B

 en un numéro magique 71435 ou (stephboulange/71435) ?

 Est-ce que, comme le suggère Frederic, c'est juste un short-link, un
 hash-map stocké sur ton serveur ou celui d'overpass ? Cela veut-il
 dire qu'une autre instance d'overpass donnera un autre chiffre ?
 Est-ce que ça fonctionne encore si la requête retourne plusieurs
 objets ? Comment garanties-tu l'unicité si un autre objet contenant
 les mêmes caractéristiques apparait plus-tard dans le même
 bounding-box, ça marchera encore ?

 Pieren

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

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

Re: [OSM-dev-fr] Des IDs a votre bon coeur COMPLET J'ESPERE.

[Philippe Verdy]

Sinon en dehors des identifiants, on a en France aussi les codes APE qui
permettent de classer les activités (cela permettrait de dégrossir les
types de commerce par exemple, même si les APE peuvent eux aussi changer et
devraient aussi être datés). Cela permettrait aussi des vérifications sur
les autres classifications OSM génériques (comme shop=*) pour détecter des
anomalies ou des oublis dans les tags génériques.


Le 28 juin 2013 16:18, Philippe Verdy verd...@wanadoo.fr a écrit :

 Je suis aussi d'avis que ces IDs générés en interne par une base privée
 sont du même type que ceux généras par un des nombreux services de type
 TinyURL. Ils sont tous privés, pas homogènes, pas garantis d'être stables
 ni même librement utilisables (et sans suivi de leur utilisation par un
 tiers, qui peut aussi décider de renvoyer vers autre chose ou d'insérer des
 données modifiées de son choix dans le trafic).

 Si des IDs stables doivent exister pour référencer des objets OSM, ils
 doivent être définis dans cette base OSM elle-même, ou bien s'appuyer sur
 des bases tierces ouvertes ne demandant pas un tel suivi (c'est le cas des
 identifiants INSEE par exemple, librement vérifiables).

 La stabilité des IDs est très relative : elle n'est garantie que si ils
 sont datés avec leur date de validité, les objets référencés pouvant à tout
 moment changer de statut. Si un ID stable devait être utilisé, il devrait
 au minimum inclure l'année de leur création
 - soit dans leur valeur (exemple ref:INSEE=35238:2000 au lieu de
 ref:INSEE=35238),
 - soit dans la clé (exemple ref:INSEE:2000=35238, ce qui permettrait
 d'avoir une autre clé pour d'autres années après un changement de l'objet
 référencé, ici une commune si celle-ci est divisée ou fusionnée avec une
 autre voisine).
 Ensuite à charge pour les outils de recherche et de mise en relation avec
 d'autres bases de faire les correspondances avec ces IDs stables, en tenant
 compte de l'année s'il y a des IDs différents pour la même base de
 référence (ici celle de l'lNSEE).

 Combien d'IDs garder ensuite dans la base OSM ? On peut faire le ménage en
 fonction des dates indiquées justement, qui permettent de procéder à des
 vérifications ultérieures ou des remises à jour (même si cela consiste
 seulement à garder l'identifiant en ne changeant que l'année), et en
 fonction de l'universalité de ces identifiants (les identifiants INSEE sont
 assez largement universels pour être gardés à demeure pour longtemps
 partout en France, tant que l'INSEE les maintiendra; mais l'INSEE peut
 aussi décider une année de revoir son propre système de codification et ces
 dates indiquées dans des références supplémentaires historiques seront
 utiles pendant une période de transition assez longue). Ces identifiants
 sont plus universels que bien d'autres d'origine privée (mais d'usage
 limité au seul domaine de leur concepteur).

 Les IDs externes ne sont utiles que si la base externe est bien la source
 de référence principale et fiable de vérification des données (cette
 fiabilité pouvant être garanti par la loi quand elle oblige une entité à
 s'inscrire dans un registre officiel reconnu, dont le nombre est
 relativement limité). S'il s'agit par exemple d'un point géodésique en
 France, la base de référence française est bien connue et c'est d'elle
 qu'on tire l'identifiant externe. S'il s'agit d'un identifiant de société
 ou d'un établissement de cette société, il n'y a que les identifiants au
 RCS et SIREN+SIRET qui sont stables et fiables (mais eux aussi devrait être
 datés), mais on peut ajouter le numéro fiscal européen.





 Le 28 juin 2013 14:38, Pieren pier...@gmail.com a écrit :

 2013/6/28 Ista Pouss ista...@gmail.com:

  Quelqu'un avait rouspété que l'id se formait de façon obsure. Pas du
 tout !
  À chaque id je suis capable de faire correspondre l'ID Overpass (car
  j'utilise overpass).

 C'est quoi l'ID Overpass ? Comment fais-tu pour convertir la requête
 Overpass:

 http://overpass.osm.rambler.ru/cgi/interpreter?data=node%2845.38591285563495%2C4.306640625%2C45.48228066163947%2C4.51263427734375%29%5B%22shop%22%3D%22bakery%22%5D%5B%22name%22%3D%22La+baguette+magique%22%5D%3Bout%3B

 en un numéro magique 71435 ou (stephboulange/71435) ?

 Est-ce que, comme le suggère Frederic, c'est juste un short-link, un
 hash-map stocké sur ton serveur ou celui d'overpass ? Cela veut-il
 dire qu'une autre instance d'overpass donnera un autre chiffre ?
 Est-ce que ça fonctionne encore si la requête retourne plusieurs
 objets ? Comment garanties-tu l'unicité si un autre objet contenant
 les mêmes caractéristiques apparait plus-tard dans le même
 bounding-box, ça marchera encore ?

 Pieren

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



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

Re: [OSM-dev-fr] Des IDs a votre bon coeur COMPLET J'ESPERE.

[Philippe Verdy]

En quoi ton ID est meilleur ou constitue une référence stable ? Alors que
tu en es le seul auteur (même si tu utilises un algorithme, il va générer
un ID dans une base qui n'est pas réputée stable, ni utilisable à aussi
grande échelle que les IDs des instituts nationaux officiels (qui ont
démontré les employer et les maintenir depuis des années).

Le seul vrai problème des ID officiels est qu'ils omettent souvent de
mentionner leur année de référence. Mais quand ils l'indiquent, on omet
encore de mentionner cette date.

Et c'est là qu'il suffirait de compléter ces IDs avec la date (au moins
l'année) où on les a obtenus pour savoir s'ils correspondent encore à
quelquechose, et vers quel(s) autre(s) objets avec d'autres IDs ils ont
évolués  (pour peu que la source maintienne des infos sur les
transformations survenues, et qu'on puisse consulter ces historiques pour
trouver  des correspondances (de 1 vers 1 l'ID est conservé, mais de N vers
1, ou de 1 vers N, ou de N vers M c'est plus compliqué, mais on a tout de
même réduit l'espace de recherche pour se resynchroniser entre deux dates
de référence : l'indication de l'année permet de savoir où des ambiguités
sont apparues, et facilitera tout de même les rapprochements en réduisant
le nombre de vérifications à faire sur le terrain).

C'est là que:
- ref=ID peut devenir ref:2000=ID, ou bien ref=ID:2000 (plus
ambigu à interpréter selon les formats d'ID des sources) indiquées.
- ref:source=ID devient aussi ref:source:2000=ID, ou
ref:source=ID:2000 (même remarque)

La stabilité est ici apportée par l'année indiquée (si elle suffit à
déterminer une version). C'est ce qui permet de suivre les évolutions. Peu
importe l'année indiquée d'ailleurs tant qu'elle tombe dans la tranche de
date où l'identifiant à été constaté comme valide, mais si on veut
contrôler plus tard, on peut toujours vouloir mettre à jour cette date en
indiquant la date de dernière vérification.

Certaines bases de référence sont versionnées non pas par année mais par
numéro de version majeure (un changement de version majeure peut entraîner
parfois un changement de format de l'identifiant):
- ref=ID peut devenir ref:v:version=ID, ou bien
ref=ID:version (plus ambigu à interpréter selon les formats d'ID
des sources) indiquées.
- ref:source=ID devient aussi ref:source:v:version=ID, ou
ref:source=ID:version (même remarque)

(La remarque s'applique aussi aux tags similaires mentionnant des
identifiants, par exemple les codes ISO 3166 qui ont actuellement des tags
non préfixés par ref:)



Le 28 juin 2013 16:49, Ista Pouss ista...@gmail.com a écrit :

 Le 28 juin 2013 16:18, Philippe Verdy verd...@wanadoo.fr a écrit :

 Je suis aussi d'avis que ces IDs générés en interne par une base privée
 sont du même type que ceux généras par un des nombreux services de type
 TinyURL. Ils sont tous privés, pas homogènes, pas garantis d'être stables
 ni même librement utilisables (et sans suivi de leur utilisation par un
 tiers, qui peut aussi décider de renvoyer vers autre chose ou d'insérer des
 données modifiées de son choix dans le trafic).


 Oui, bien sûr, ok, mais le mien ?? Moi c'est vachement mieux :-)



 Si des IDs stables doivent exister pour référencer des objets OSM, ils
 doivent être définis dans cette base OSM elle-même, ou bien s'appuyer sur
 des bases tierces ouvertes ne demandant pas un tel suivi (c'est le cas des
 identifiants INSEE par exemple, librement vérifiables).


 Je n'empêche personne de procéder ainsi.

 Il me semble, toutefois, que la création de tels identifiants, nécéssite
 de poser le même genre de questions que celles que j'essaie de proposer :
 qu'est-ce qui caractérise un objet ? Qu'est ce qui permet de le reconnaître
 ? Qu'est ce qui définit leur égalité ? Comment les hasher ?

 Mais enfin, on verra.


 La stabilité des IDs est très relative : elle n'est garantie que si ils
 sont datés avec leur date de validité, les objets référencés pouvant à tout
 moment changer de statut. Si un ID stable devait être utilisé, il devrait
 au minimum inclure l'année de leur création
 - soit dans leur valeur (exemple ref:INSEE=35238:2000 au lieu de
 ref:INSEE=35238),
 - soit dans la clé (exemple ref:INSEE:2000=35238, ce qui permettrait
 d'avoir une autre clé pour d'autres années après un changement de l'objet
 référencé, ici une commune si celle-ci est divisée ou fusionnée avec une
 autre voisine).
 Ensuite à charge pour les outils de recherche et de mise en relation avec
 d'autres bases de faire les correspondances avec ces IDs stables, en tenant
 compte de l'année s'il y a des IDs différents pour la même base de
 référence (ici celle de l'lNSEE).


 Oui, enfin bon, OK. La stabilité comme tu dis des ID est effectvement un
 problème, puisque l'objet peut se modifier de toutes formes.

 Mais, à l'inverse, on peut dire que les risques de modifications
 permanentes rendent plus intéressantes encore l'existence d'un ID :-)




 Les IDs externes ne sont utiles que si la base externe est bien la source

Re: [OSM-dev-fr] Proposition d'amélioration de la gestion du cache

[Philippe Verdy]

Là aussi on peut penser à une autre piste: l'adaptation de la taille des
tuiles servies en fonction de la densité: rien n'oblige les métatuiles à
avoir la même taille, et le protocole pourrait mentionner la taille des
métatuiles touchées, pour réduire le nombre de requête ou optimiser les
requêtes en terme de compression et d'échanges : quand une tuile est
retournée, une métadonnée peut indiquer quelles autres tuiles font partie
de la même métatuile générée, et retourner alors non pas la tuiles mais
l'indication d'une autre tuile plus grande ou de plusieurs autres plus
petites.

Mais le protocole WMS ne semble pas avoir prévu ce type d'adaptation
(dynamique en fonction des contenus).

Le protocole cependant supporte de remplacer une tuile par une autre
(fonctionalité offerte par HTTP via des redirections : cela permettrait par
exemple de retourner la même tuile une seule fois quand elles sont
identifiques entre elles pour des zones assez grandes : une signature MD5
ou SHA1 des données de la tuile générée suffirait à identifier les tuiles
identiques dans leur contenu (mais pas forcément dans leurs métadonnées de
géolocalisation notamment).

Au pire cela gagnerait de l'espace de stockage côté serveur (il créait des
liens symboliques ou physiques en stockant ses tuiles sous un nom issu de
la signature de contenu), mais pas de temps pour générer ces tuiles
(générer une signature SHA1 est aujourd'hui une opération très rapide, avec
des accélérations matérielles dans les processeurs ou des optimisation
importantes, disponibles dans les bibliothèques de sécurisation, on obtient
facilement aujourd'hui le gigaoctet par seconde pour SHA1, dont le calcul
aurait alors un temps négligeable en comparaison du temps gagné sur les
accès disques épargnés par le stockage partagé des tuiles identiques).

Pour le reste, la vraie charge côté serveur c'est le temps de génération de
ces tuiles et la complexité des requêtes SQL à effectuer, et des
traitements géométriques, plus le traitement graphique plus ou moins
complexe pour le rendu lui-même, et enfin les I/O pour stocker les tuiles
générées. La piste d'optimisation c'est alors de voir si les métatuiles ne
sont pas trop grandes par rapport à la demande réelle, et savoir gérer côté
serveur des métadonnées sur leur fraicheur et leur fréquence de mise à jour
(ou durée minimale avant l'obsolescence).

Coté serveur on n'est pas non plus obligé de faire patienter le client même
si on a marqué une métatuile comme obsolète: on peut lui servir
immédiatement une tuile qu'on sait obsolète, mais qui sera mise à jour plus
tard : si on le fait on ne change rien aux métadonnées retournées au client
et on peut lui indiquer une date de péremption actualisée légèrement dans
le futur (jusqu'à une date estimée où cette tuile aura bien été régénérée
du côté du serveur). Le serveur peut estimer cette date du futur en pistant
le délai entre les dernières mises en file d'attente de tuiles à régénérer
et le moment où elles sortent de cette file d'attente.

Dernière problème : les tuiles demandées et que le serveur ne stocke pas
(cela concerne les niveaux de zoom élevés) : là seul un proxy Squid frontal
permet d'éviter de surcharger le serveur de génération des tuiles, mais il
vaut mieux que pour ces tuiles il y ait un serveur de génération séparé de
clui des tuiles que le serveur veut stocker et garder à jour (pour les
niveaux de zoom faibles) :

- on touche alors au tuning des serveurs Squid (programmation des durées
minimales de conservation en cache), et

- on doit se demander aussi comment les clients gèrent eux-mêmes leurs
propres caches HTTP (les navigateurs web font ça très bien, mais pas les
éditeurs hors navigateurs, comme JOSM). Cependant même pour les navigateurs
Web, on est lié aussi à la façon dont les frameworks javascripts exécutent
leurs requêtes HTTP : ces requêtes sont-elles correctement cachables du
côté client et du côté serveur pour que jamais l'utilisateur n'ait à
s'occuper de vider son cache local ?





Le 6 mai 2013 08:20, Christian Quest cqu...@openstreetmap.fr a écrit :

 Bonjour Matthieu,

 Ne transmettre qu'un diff de ce qui a changé sur une tuile impliquerai
 de conserver côté serveur, la dernière version d'une tuile ainsi qu'un
 certain nombre de diff des versions précédents.

 Ce mécanisme ne fonctionnerai correctement que si le client a déjà une
 ancienne tuile dans son cache. Est-ce si souvent le cas ?

 Je pense surtout que le problème de ressources n'est pas dans le
 transfert des tuiles, mais plus dans leur génération.

 L'avenir se situe sûrement dans un domaine tout autre: les tuiles
 vectorielles... et le rendu au niveau du client.


 Le 5 mai 2013 12:07, Matthieu Rakotojaona
 matthieu.rakotoja...@gmail.com a écrit :
  Bonjour,
 
  Je lurke depuis quelque temps sur le projet OSM que je trouve
  incroyable, et j'ai cru comprendre que les requêtes de tuiles sont un
  véritable problème parce qu'elles consomment un max de ressources,
  ressources qui ne coulent 

Re: [OSM-dev-fr] (sans objet)

[Philippe Verdy]

Le 5 avril 2013 15:24, Ab_fab gamma@gmail.com a écrit :
 J'ai l'impression que Simon Poole ne fait pas beaucoup d'efforts pour
 admettre qu'il n'y a pas QUE des bâtiments du cadastre en France.
 Surtout il aime bien dire qu'on n'a pas beaucoup d'adresses.

Je crois que le serpent de mer des adresses est un prétexte chez lui.
tenter de justifeir l'inutilité des buildings dans la base en se
basant sur des données fausses, et sur un modèle des données pour les
adresses qui est encore largement défaillant, et sur des outils comme
Nominatim qui ne savent même pâs correctement gérer les adresses dans
de nombreux cas (y compris les codes postaux que je viens d'évoquer
concernant Nominatim qui a des très sérieux problèmes à leur sujet).
Ne devrait justement pas avoir pour effet de bloquer la saisir des
bâtiments.

D'autant plus que le fait de taguer renseigner les bâtiments ne peut
conduire qu'à une amélioration sensible de la qualité et la précisions
des noeuds d'adresses saisis (même si pour cette saisie, on ne peut
pas s'appuer sur Nominatim pour fournir une géolocalisation
suffisante).

Simon Poole devrait donc voir qu'on est encore dans une phase
transitionnelle (à peine commencée), où pour pouvoir monter une base
d'adresses fiable, il va fallori encore beaucoup de travail sur les
outils et aussi sur la précision des autres données connexes comme le
bâti qui va servir à renseigner la base adresses avec précision.

Bref il veut placer l'oeuf avant la poule, ou l'inverse. Comme si on
ne pouvait pas, et ne devait pas faire évoluer en fait en parallèle à
la fois l'oeuf et la poule... et aussi la poêle antiadhésive pour
faire l'omelette sans la crâmer, et le four pour faire rôtir la
volaille dodue, et les couteaux et la planche à découper pour préparer
les morceaux à servir dans l'assiette.

Il est temps de faire comprendre que bâtiments et adresses ne sont pas
modélisés de la même façon, et que ce sont plutôt les outils de
consultation utilisés pour l'évaluation faire par Simon Poole qui sont
défaillants, mais pas les données du bâti elles-mêmes qui servent
**déjà** à justement aider à enrichir la base d'adresses avec plus de
précision.

Les deux types d'informations petit à petit trouvent leur cohérence et
s'harmonisent, même si nos outils actuels pour les utiliser sont
encore défaillants (mais ils feront d'autant moins d'erreurs que
justement on aura augmenté la précision des deux types de données, ce
qui permettra justement à ces outils d'évoluer pour faire moins
d'erreurs).

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

Re: [OSM-dev-fr] (sans objet)

[Philippe Verdy]

Si on juge son travail, sa méthode fournit trop de faux positifs sur
l'absence d'adresses. Il suffit de voir comment il surcharge en rouge
tellement de bâtiments à Paris dans n'importe quelle rue, pour se
rendre compte que pour lui il faut absolument que chaque bâtiment
porte un point d'adresse et que ce point doit absolument être dans le
polygone du bâtiments ou sur sa limite (et encore cela ne suffit même
pas, il trouve des faux-positifs même là où il y a un point
d'adresses).

Pour lui no devrait répéter le point d'adresses pour chaque
construction, chaque barraque au fond du jardin. Dans certains lieux
où une école et un temple protestant forment un ensemble de batiments
modélisés par des polygones différents mais associés strictment à la
même adresse (même numéo, même rue), il va mettre en rouge un des deux
batiments, alors que la base d'adresses est absolument complète, tous
les numéros éant correcement positionnés.

Certes si on est en face du bâtiment dans la rue, ou peut se demander
si c'est le 19 bis ou le 21. Mais OSM n'est pas là pour inventer des
points d'adresses plus précis que la réalité. Si on veut savoir on va
éventuelelment regarder les boites aux lettres mais elles peuvent
parfois être regroupées sur plusieurs numéros. Ou regarder le nom sur
la sonnette (qui rarement indique le numéro utilisé par son résident).

En faisant les choses le mieux possible, il est clair qu'il y a un
découplage total entre les bâtiments d'une part et les noeuds
d'adresse d'autre part, qui même complets ne peuvent pas suffire à
déterminer le numéro d'un bâtiment. Et d'ailleurs ce n'est me^me pas
nécessaire puisque pour se géolocaliser en ville, on indique un numéro
dans la voie et une fois sur place on n'est plus à 10 mètres près et
ce qu'on cherche ce n'est plus le numéro mais le résident parmi les
portes autour, qu'il va fallloir chercher par son nom, par son numéro
d'étage, et parfois en pénétrant dans une propriété et traversant un
hall commun pour trouver le logement dans une cour privée derrière, un
bâtiment qui n'est pas directement sur la rue, alors que le même
logement aura sa boite à lettre souvent groupée avec ceux du premier
bâtiment traversé.

Sa méthode qui aboutit à tellement de faux positifs peut aboutir
certains à surcharger la base de points d'adresses totalement
identiques dans leur contenu, mais à des positions multiples. Ou à
tracer des polygones englobants plusieurs bâtiments (on va se
retrouver à cartographier les limites exactes de propriétés
privées...)

Btef c'est la méthode qui est criticable bien plus que la supposée
'absence d'adresses alors que celles-ci sont largement suffisantes
(et déjà complètes).

On se demande ce qu'il va vouloir faire dans les zones où il n'y a
strictement aucun numéro dans les rues, mais juste des noms de
secteurs. Dans certains pays on n'a même pas le choix, les numéros
n'existent pas (par exemple presque partout dans les métropoles
japonaises), où même les rues n'ont pas de nom ou numéro unique, les
numéros d'axe pouvant se superposer car ils renseignent sur des
itinéraires et non la voie...).

Bref il cherche des poux là où il n'y en a pas, et est sans doute trop
orienté par ce qu'il a observé chez lui, dans son pays ou sa ville, en
voulant absolument calquer cela ailleurs.

Le 5 avril 2013 19:33, yvecai yve...@gmail.com a écrit :
 Il me semble que le travail de Simon concerne surtout sur le manque
 d'adresses, pas sur la présence des batiments.

 paranoia ? :)
 Yves


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

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

Re: [OSM-dev-fr] Conversion en batch de fichier OGR vers OSM...

[Philippe Verdy]

Le 28 mars 2013 17:36, Sylvain Maillard sylvain.maill...@gmail.com a écrit :
 Salut,

 oui, ce problème est clairement lié à l'encodage des caractère !
 En interne Python 2 utilise par défaut l'ascii

Faux, Python en interne n'utitile que des chaines d'octets sans savoir
rien de plus sur le codage, ni me^me si cela contient effectivement du
texte. Ce support des encagages est apporté par les librairies Python
selon leur propre API et l'usage qu'elle font de ces chaines d'octets.

Pytonh gère aussi des chaines dites Unicode sauf que ces chaines
n'ont aucune obligation à être réellement codées selon Unicode, mais
juste fr pouvoir coder un caractère Unicode dans une position unique.
Dans les faits Pythin utilise alors pour cela en interne des chaines
de mots 32-bits. Il peut aussi gérer des chaines de mots 16 bits.

Il faut aussi distinguer ce que fait Python en interne dans le moteur
de sa VM, de sa syntaxe de programmation qui elle ne dépend pas de
Python lui-même mais d'une API aussi, celle de son analyseur
lexico-syntaxique qui soumet ses analyses à son compilateur. Là encore
ne pas confondre le langage de programmation avec ce pourquoi il est
utilisé dans une application.

Ces remarques ne sont pas spécifiques à Python, on les retrouve aussi
dans d'autres langages (compilés ou non) : C/C++, Java, C#, PHP,
JavaScript/ECMAScript (ne pas confondre Javascript avec HTML qui a ses
propres spécifications en terme de codage, ce que n'a pas Javascript
lui-même qui en est séparé)...

Bref ne pas tout mélanger

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

Re: [OSM-dev-fr] Conversion en batch de fichier OGR vers OSM...

[Philippe Verdy]

Cette page ne parle que de l'encoding, tel que défini dans une
bibliothèque de base Python. Elle ne parle pas des objets chaines de
caractères qui sont triatés en interne par Python. Ma remarque était
juste car tu disais Python utilise en interne ce qui est faux
justement car en interne il est totalement neutre au regard des
encodages et ne vot ces chaines QUE comme des chaines d'octets sans
rien imposer de plus.

Ce qui fait alors que justement Pythin peut travailler avec des tas de
codages différents, y compris incompatibles avec Unicode, et même
manipuler des fichiers binaires comme des images bitmap au sein même
de ses chaines, ou via ses API I/O. En cela Python n'est pas différent
non plus de C/C++, Java, PHP, Javascrript, etc

Et ce n'est donc pas un problème comme tu le dis, mais plutôt une
fonctionnalité qui le rend très versatile (mais alors il faut faire
attention aux APIs utilisées qui peuvent ou non imposer un encodage
particulier si on doit les utiliser pour traiter du texte). Quand àç
son langage de programmation, il offre quelques facilités syntaxiques
pour Unicode mais c'est lié au compilateur, pas au traitement interne
à l'exécution.

(Notes: Javascript est un peu particulier car il n'a pas d'objet
chaine d'octets mais juste chaine de mots 16-bits ; Java n'a pas
directement de chaines d'octets mais sait gérer des ByteBuffers
dans des tableaux d'octets signés, alors que son type String est à la
base un tableau de mots 16-bits non signés, eux aussi non restreints à
l'Unicode seul ; un problème de Java est cependant que son type
String est malheureusement déclaré final donc non dérivable en une
sous-classe pour éviter d'avoir à suivre l'encodage utilisé dans les
APIs dans une variable séparée, avec poir conséquence que toutes les
conversions d'encodage doivent être explicités à chaque fois).

Le 28 mars 2013 23:13, Sylvain Maillard sylvain.maill...@gmail.com a écrit :
 http://docs.python.org/2/howto/unicode.html

 Encodings don’t have to handle every possible Unicode character, and most
 encodings don’t. For example, Python’s default encoding is the ‘ascii’
 encoding. The rules for converting a Unicode string into the ASCII encoding
 are simple; for each code point:

 If the code point is  128, each byte is the same as the value of the code
 point.
 If the code point is 128 or greater, the Unicode string can’t be represented
 in this encoding. (Python raises a UnicodeEncodeError exception in this
 case.)

 = ça ressemble quand même vachement au problème initial ...

 Il s'agit peut-être d'un problème d'api au sein de python, je n'ai pas été
 regarder, mais le résultat est le même : tout appel à un module qui n'est
 pas explicitement écrit de manière à gérer l'unicode, utilisera l'encodage
 par défaut qui est l'ascii et générera ce genre d'erreurs !

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

Re: [OSM-dev-fr] osm2psql, problème de fichier.

[Philippe Verdy]

Je ne vois pas comment un memory mapping en 32-bits peut mapper la
totalité d'un fichier qui ne tient pas dans un seul segment mémoire
virtuel 32 bits.

A mon avis il faut recompiler une version 64 bits de l'application (et
utiliser un OS installé en 64 bits pour le supporter). Sinon tu auras
beau faire mies les pointeurs mémoire 32 bits ne pourront pas accéder
à tout le fichier.

Autre solution : que le logiciel ne fasse plus un mémory mapping aussi
grand mais fasse des I/O classiques à la demande avec un buffer
classique assez grand pour éviter de multiplier les I/O.

D'autant plus que les accès à ce fichier pendant le décodage sont
essentiellement séquentiels (par un parseur, même si le format du
fichier PBF est binaire et contient des offsets 64 bits pour indexer
ses différentes sections), et demandent assez peu d'accès aléatoires
pendant le traitement.

Ca complique un peu le programme qui doit gérer des caches pour les
index mais ce n'est pas infaisable et cela améliorerait même les
performances en évitant justement de solliciter le gestionnaire
mémoire plus que nécessaire (au delà de 4 Mo environ, il n'y a plus
beaucoup d'intérêt réel à utiliser le memory mapping, les I/O seront
plus performantes en mettant moins de charge sur le système). On peut
garer un memory mapping sur les segments importants d'index du fichier
PBF si cela peut aider, mais pas pour le plus gros de ses données.

2013/3/21 Lucas Nussbaum lucas.nussb...@loria.fr:
 On 21/03/13 at 13:55 +0100, Vincent Pottier wrote:
 Le 21/03/2013 11:57, Lucas Nussbaum a écrit :
 Que dit:
 strace -f /home/vincent/Documents/cartographie/sh/france.osm2sql.sh
 ?
 
 Lucas
 Good guess !
 Je ne comprends pas tout mais voici un extrait vers la fin :

 [pid 25569] write(2, \nReading in file: /home/vincent/..., 58
 Reading in file: /home/vincent/tmp/france-latest.osm.pbf
 ) = 58
 [pid 25569] time(NULL)  = 1363869357
 [pid 25569] brk(0xa51e000)  = 0xa51e000
 [pid 25569] mmap2(NULL, 33558528, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x643df000
 [pid 25569] mmap2(NULL, 33558528, PROT_READ|PROT_WRITE,
 MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x623de000
 *[pid 25569] open(/home/vincent/tmp/france-latest.osm.pbf,
 O_RDONLY) = -1 EOVERFLOW (Value too large for defined data type)*

 D'après open(2):

 EOVERFLOW
pathname refers to a regular file that is too large to be opened.
The  usual  scenario  here  is that  an application compiled on a
32-bit platform without -D_FILE_OFFSET_BITS=64 tried to open a
file whose size exceeds (231)-1 bits; see also O_LARGEFILE
above.  This is the error  specified by POSIX.1-2001; in kernels
before 2.6.24, Linux gave the error EFBIG for this case.

 Donc recompiler l'appli avec -D_FILE_OFFSET_BITS=64 devrait aider. (ou
 passer sur un système 64 bits)

 J'ai mis en gras ce qui me semble être un indice de ce qui ne va pas.
 D'après ce que je viens de voir[1] mmap2 effectue une projection en
 mémoire d'un fichier. Peut-être que ma machine manque de mémoire
 pour traiter ce fichier de 2.4 Go (3.4 Go de RAM).

 non, au pire ça swappera.
 --
 | Lucas Nussbaum  Assistant professor @ Univ. de Lorraine |
 | lucas.nussb...@loria.fr   LORIA / AlGorille |
 | http://www.loria.fr/~lnussbau/+33 3 54 95 86 19 |

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

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

Re: [OSM-dev-fr] Direct wikipedia

[Philippe Verdy]

Je plussoie. Une très belle organisation des données affichée qui ne
se contente pas de Wikipédia (dont il n'est extrait qu'une toute
petite partie du contenu juste avec ce qu'il faut pour trouver une
photo et un lien dans l'édition de la langue utilisateur ou par défaut
l'édition lingusitique indiquée dans OSM).
J'aime bien pouvoir trouver des tas d'autres infos, par exemple sur un
restaurant le, l'adresse exacte, le téléphone, les heures d'ouverture,
une page web éventuelle, le type de cuisine, l'accessibilité et les
stations de métro, bus, et gares proches...

J'aime bien aussi pour certains points très proches ou confondus que
ceux(ci affichent un cercle un peu plus grand affichant une liste
d'objets permettant de choisir celui qu'on veut afficher en détail (ça
évite de surcharger la carte avec des tas de petits cercles à moitié
superposés ou d'en avori certains qui ne sont pas sélectionnables car
en dessous des autres dans un ordre à priori arbitraire).

Maintenant que ce soient des cercles ou des bulles, c'est un détail
mineur, et ce site ne génèrent ps lui-même le rendu du fond de carte.
Le rendu FR est maintenant bien meilleur sur bien des aspect par
rapport au Mapnik par défaut d'OSM qui est trop technique (orienté
vers les contributeurs et beaucoup moins pour les utilisateurs qui ont
du mal à s'y retrouver).

Je pense qu'à terme de toute façon bien des rendus actuels Mapnilk
deviendront multicouches (avec des tuiles semi-transparentes)
permettant d'afficher ou masquer certaines catégories de données (par
exemple la numérotation des routes ou les limites de vitesse, ou la
position des radars seront moins importantes que leur nom local de la
rue et les enseignes de commerces pour une utilisation à pied). Comme
sur les navigateurs GPS, les listes de POI à afficher seront
sélectionnables.

Et sans doute il faudra bien un jour se mettre au rendu SVG pour
pouvoir gérer des quantités importantes de couches avec aussi plus de
niveaux de zooms (le rendu des données vectorielles en bitmaps se fera
alors côté client, comme cela se fait déjà dans les navigateurs GPS,
même si pour cela ils utilisent souvent des formats vectoriels
binaires mais propriétaires et plus ou moins bien documentés). L'autre
intérêt du format vectoriel est aussi de pouvoir changer de projection
et d'orientation de la carte (ce qu'on ne fait pas facilement avec un
rendu bitmap sans distortions disgracieuses et sans rendre les
libellés presque illisibles).

2013/3/17 Christian Quest cqu...@openstreetmap.fr:
 Regarde 
 http://www.openlinkmap.org/?zoom=16lat=48.80503lon=2.11511layers=BFT

 Liens wikipédia et URL y sont visibles et il y a pas mal de bonnes idées.

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

Re: [OSM-dev-fr] OSMOSE - Problème de rafraîchissement des données ?

[Philippe Verdy]

Il y a peut-être eu un plantage et une restauration ne tenant pas
compte des corrections enregistrées entre temps. Bref cela me semble
anecdotique, il suffit de cliquer faux positif (après avoir contrôlé
rapidement l'objet dans rawedit, dans lequel bon nombre de modifs
simples peuvent se faire immédiatement, comme celles-là qui ne portent
que sur les tags simples d'un seul objet, et non pas la géométrie ou
les membres de relations ou noeuds d'un chemin pour lesquels il vaut
mieux passer à un autre éditeur plus complet), il n'y a rien de
spécial à faire d'autre pour nettoyer.

2013/1/17 Christian Quest cqu...@openstreetmap.fr:
 Ah... si y'a des erreurs dans les erreurs, on va-t-on ma bonne dame ! ;)

 C'est étrange en effet.


 Le 17 janvier 2013 00:28, Black Myst black.m...@free.fr a écrit :

 Hello,

 D'après Osmose, il y a erreur sur le tag wikipedia détecté le 2013-01-16 :

 http://osmose.openstreetmap.fr/map/?zoom=13lat=49.24074lon=4.05204layers=BFFTitem=3031level=1,2,3

 Mais en base, cette erreur a été corrigé le 29 juillet 2012:
 http://www.openstreetmap.org/browse/node/1020954966

 Cdt

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




 --
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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


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

Re: [OSM-dev-fr] OSMOSE - Problème de rafraîchissement des données ?

[Philippe Verdy]

A noter dans la même catégorie d'erreurs osmose:
wikipedia:image=(URL sur commons)
est signalé comme : mauvais suffixe image car il ne le connait pas
(et ce n'est pas non plus au foramt d'un code langue valide).
Mais ce tag semble erroné de toute façon d'une part si on y met une
URL, d'autre part ce n'est pas une image sur Wikipedia.

Ce tag devrait être plutôt : image:url=*
ou si on veut mentionner une resource de Wikimedia commons:
image:commons=(nom du fichier en clair, sans souligné mais avec
espace, et sans préfixe File:)

Par exemple (voir http://www.openstreetmap.org/browse/way/162643501)
osmose signale ceci:

wikipedia:image=http://image.wikipedia.org/wiki///upload.wikimedia.org/wikipedia/commons/e/e8/Charteves_saint-caprais.jpg

ce devrait être:
image:url=http://image.wikipedia.org/wiki///upload.wikimedia.org/wikipedia/commons/e/e8/Charteves_saint-caprais.jpg

ou sans doûte mieux:
image:commons=Charteves saint-caprais.jpg


Le 17 janvier 2013 00:50, Philippe Verdy verd...@wanadoo.fr a écrit :
 Il y a peut-être eu un plantage et une restauration ne tenant pas
 compte des corrections enregistrées entre temps. Bref cela me semble
 anecdotique, il suffit de cliquer faux positif (après avoir contrôlé
 rapidement l'objet dans rawedit, dans lequel bon nombre de modifs
 simples peuvent se faire immédiatement, comme celles-là qui ne portent
 que sur les tags simples d'un seul objet, et non pas la géométrie ou
 les membres de relations ou noeuds d'un chemin pour lesquels il vaut
 mieux passer à un autre éditeur plus complet), il n'y a rien de
 spécial à faire d'autre pour nettoyer.

 2013/1/17 Christian Quest cqu...@openstreetmap.fr:
 Ah... si y'a des erreurs dans les erreurs, on va-t-on ma bonne dame ! ;)

 C'est étrange en effet.


 Le 17 janvier 2013 00:28, Black Myst black.m...@free.fr a écrit :

 Hello,

 D'après Osmose, il y a erreur sur le tag wikipedia détecté le 2013-01-16 :

 http://osmose.openstreetmap.fr/map/?zoom=13lat=49.24074lon=4.05204layers=BFFTitem=3031level=1,2,3

 Mais en base, cette erreur a été corrigé le 29 juillet 2012:
 http://www.openstreetmap.org/browse/node/1020954966

 Cdt

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




 --
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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


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

Re: [OSM-dev-fr] OSMOSE - Problème de rafraîchissement des données ?

[Philippe Verdy]

Le 17 janvier 2013 00:57, Philippe Verdy verd...@wanadoo.fr a écrit :
 ou sans doûte mieux:
 image:commons=Charteves saint-caprais.jpg

Autre alternative aussi (à discuter ici):
image:wikimedia=commons:Charteves saint-caprais.jpg
qui permet aussi:
image:wikimedia=fr:Charteves saint-caprais.jpg
(par exemple ici si l'image n'est pas partagée sur Commons mais
hébergée localement sur une édition spécifique de Wikipedia, la
française dans cette syntaxe).

Si les images peuvent être hébergées localement ailleurs que sur
Commons ou Wikipedia, on peut aussi utiliser les autres préfixes
interwiki :
- image:wikimedia=wikt:fr:Charteves saint-caprais.jpg
(ici c'est le Wiktionnaire français : les préfixes donnés en valeurs
de image:wikimedia devraient être résolus comme sur Commons: les
préfixes de code langue interwiki pointant par défaut vers Wikipedia
et non le Wiktionnaire ou Wikinews)
- image:wikimedia=n:Charteves saint-caprais.jpg
(ici on pointe sur l'édition anglaise de Wikinews)
- image:wikimedia=n:fr:Charteves saint-caprais.jpg
(ici on pointe sur l'édition française de Wikinews)

Si on adopte cette règle pour résoudre les valeurs données à
image:wikimedia (selon Wikimedia Commons comme wiki de départ), alors
on peut même se passer du préfixe commons: et indiquer directement
et le plus simplement du monde:
image:wikimedia=Charteves saint-caprais.jpg
(Wikimedia Commons est alors implicite)

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

Re: [OSM-dev-fr] OSMOSE - Problème de rafraîchissement des données ?

[Philippe Verdy]

Toujours dans le sujet des tags wikipedia:

http://www.openstreetmap.org/browse/node/329206041
Osomose dit Invalid wikipedia sufix 'sco' 
car il ne reconnait pas le code langue interwiki valide sur Wikipedia :
wikipedia:en = Golf_Disneyland
wikipedia:nl = Golf_Disneyland
wikipedia:fr = Golf_Disneyland
wikipedia:sco = Gowf_Disneyland

A remarquer: il oublie de signaler les soulignés, ce devrait être:
wikipedia:en = Golf Disneyland
wikipedia:nl = Golf Disneyland
wikipedia:fr = Golf Disneyland
wikipedia:sco = Gowf Disneyland

que je viens de corriger en ajoutant aussi la clé dans la langue par
défaut en français (puisque ce golf est en France) en:
wikipedia = fr:Golf Disneyland
wikipedia:en = Golf Disneyland
wikipedia:nl = Golf Disneyland
wikipedia:sco = Gowf Disneyland

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

Re: [OSM-dev-fr] [OSM-talk-fr] Osmose et les tags wikipedia

[Philippe Verdy]

Déjà un tag comme wikipedia:name ne devrait pas pouvoir être
interprété comme contenant un code langue valide (name n'est pas un
code langue ISO 639 ou même BCP47 valide).
Pour tous tags traduits comme tag:lang=* une chose à faire avant
est de vérifier qu'il s'agit bien d'un code langue valide.

Note : pour Wikipedia, les codes langue ne sont pas tout à fait
conformes à BCP 47, puisque ce sont en fait des labels de
sous-domaines dans le domaine wikipedia.org. Normalement maintenant
tous les codes langues Wikipedia devraient être conformes à BCP 47
(préférablement un code ISO 639-1, sinon ISO 639-2T, sinon ISO 639-3;
mais on a parfois des extensions à ces codes, qui devraient être
conformes à BCP 47 pour indiquer une écriture ISO 15924, une région
ISO 3166-1 ou UN-M.49, ou un code variante enregistré dans la base
IANA pour BCP47). Cependant il persiste encore quelques codes langues
utilisés sur Wikipédia qui ne sont pas conformes à BCP47
- par exemple nrm pour le normand, qui n'a pas de code dans BCP 47
ni dans ISO 639, mais est utilisé pourtant pour coder le jériais ou le
guernésiais qui sont considérés comme des langues avec un statut
officiel à Jersey et Guernesey ; ces langues sont en fait des variétés
dialectales du normand, lequel est encore considéré comme une variante
du français, ce qui ferais du jériais ou du guernésiais des variantes
du français, ce que réfute les Etats de ces îles ; malheureusement au
lieu d'utiliser un code privé sur Wikipédia, le normand a été codé
nrm et est en conflit avec une autre langue codée dans ISO 639-3 et
dans BCP 47.
- autres exemples avec le serbo-croate, qui a été déprécié dans ISO
639, persiste encore n'est plus recommandé dans BCP47, mais y est
conservé et encore utilisé pour Wikipédia. Techniquement ce n'est pas
incompatible et ne crée pas de conflit.

Bref le code langue à mettre dans wikipedia:lang=* doit être un
label de sous-domaine existant dans Wikipedia. Il serait bon qu'Osmose
en maintienne une liste exhaustive (ce n'est pas une longue liste).

Mais tous les autres codes langue des autres tags (par exemple
name:lang=*) doivent être conformes à BCP 47, si possible non
dépréciés (utiliser le code recommandé dans la base IANA, qu'Osmose
devrait apprendre à lire et décoder correctement), mais on accepte les
aussi les codes de macrolangues (comme zh pour le chinois, sans
préciser la langue individuelle), et les extensions pour mentionner
d'autres écritures (par exemple zh-Bpmf pour une translitération en
alphabet Bopomofo, ou zh-Latn utilisé pour une romanisation à priori
en pinyin en Rép. Pop. de Chine, ou ja-Kana pour mentionner une
translitération dans les syllabaires Hiragana/Katakana, de noms
préférablement écrits en sinogrammes Kanji, ou ja-Hani pour
mentionner une orthographe traditionnelle en sinogrammes Kanjis de
noms aujourd'hui plutôt écrit en Hiragan/Katakana voir romanisés).

Mais pour qu'Osmose vérifie les codes langues de ces derniers tags
(sauf wikipedia:lang=*) il lui télécharger et utiliser la base IANA
pour BCP 47, afin que d'une part il les décode correctement (selon RFC
5446) pour en vérifier d'abord la syntaxe (sinon ce n'est pas un code
langue valide), puis pour vérifier dans la base IANA les codes
inexistants (à signaler), et les codes dépréciés à remplacer par ceux
indiqués dans la base IANA (attention tous les codes langues
dépréciés, y compris les anciens codes n'ont pas toujours un code de
remplacement comme jw-jv ou iw-'he, car le remplacement est
ambigu entre plusieurs codes candidats). Osmose devrait aussi signaler
les codes langues d'usage spécial (comme mul ou und) ou privés
(x-*) dont on n'a pas défini de règle d'usage sur OSM. Il devrait
aussi signaler les codes de familles/collections de langues (dans ISO
639-2 la plupart, plus un seul dans ISO 639-1) qui ne sont PAS des
macro-langues (par exemple le code pour apache n'est pas assez
précis).

Les codes qui n'ont pas de traduction claire dans BCP 47, bien que
partiellement conformes, mais qui ont un usage défini dans Wikipédia
(tels que roa-rup pour le francique ripuaire) devraient aussi être
remplacés par le code préféré et standard dans BCP 47 pour tous les
tags AUTRES que wikipedia:lang=*.

Petit à petit, Wikipédia met à jour ses codes pour les mettre en
conformité avec BCP 47 (pour ne pas casser les liens externes, il
transforme ces anciens codes en alias CNAME sur ses noms de domaines,
et il met à jour sa liste de préfixes interwikis pour traduire les
alias ; cela fonctionne pendant un certain temps, jusqu'à ce qu'il n'y
ait pratiquement plus d'accès visible de l'ancien domaine sur ses
serveurs Squid, et jusqu'à ce que les bots aient traduits tous les
codes langue qui trainent encore dans les articles et modèles ; la
transition peut être assez longue avant que le support de l'ancien
usage non conforme soit supprimé, mais cela va plus vite sur les codes
langues peu utilisés).

Osmose pourrait apprendre ces règles et donc faire un meilleur
travail. J'ai bien peut que le 

Re: [OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle

[Philippe Verdy]

Le 21 décembre 2012 12:52, sly (sylvain letuffe) li...@letuffe.org a
écrit :

 Son petit nom :
 2u : acronyme de Ugly and Usefull
 (J'aurais aimé l'appelé 4u, mais je n'ai pas trouvé les 2 u qui me manque)


Ugly, Unneeded, Ubiquitous and Useful

On a encore: Universal si Unneeded ne plait pas, mais c'est un peu
redondant avec Ubiquitous.
Et: Ultrasonic si Ugly est trop négatif, voire Underground si tu veux
insister sur l'aspect mystérieux...

Suggestions assez complètes sur:
http://fr.wiktionary.org/w/index.php?title=Cat%C3%A9gorie:Adjectifs_en_anglaisfrom=u#mw-pages
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] Styles Mapnik gérés par CartoCSS - question existentielle

[Philippe Verdy]

Le 21 décembre 2012 14:15, Pieren pier...@gmail.com a écrit :


 Mouais. Je crois avoir lu la même chose à chaque fois qu'un nouveau
 format est sorti (xml, json, etc). Difficile de dire à l'avance si ça
 marchera ou pas.
 Il y a aussi, c'est sûr, des effets de mode. (...)


Le succès croissant de JSON par rapport à XML est indéniable. Et ce n'est
pas juste un « effet de mode », car il y a de sérieux appuis dans les
standards du web. Même Unicode s'y met en proposant (depuis peu) sa base
CLDR aussi en format JSON au lieu de seulement XML/LDML.

En particulier, il y a une une meilleure intégration dans les navigateurs,
avec une implémentation native et plus sécurisée que le XML (qui est un peu
trop ouvert avec son support des DTD et des références externes et à cause
de son extensibilité très permissive par les namespaces), et une syntaxe
nettement plus verbeuse et plus compliquée à parser que le JSON, qui
offre pratiquement les mêmes possibilités ontologiques même si le schéma
de données doit être adapté par une convention de traduction
supplémentaire).

De plus en plus les sites utilisent les JSONRequests au lieu des classiques
XMLHttpRequests : c'est plus rapide et plus facile à programmer et utiliser
en Javascript/ECMAScript et même dans d'autres langages. Il n'y a plus de
dépendance avec les anciennes XMLHttpRequests (très peu sécurisées
d'Internet Explorer, utilisant dans le passé un composant ActiveX pour
s'interfacer). Même sur un vieux navigateur qui n'aurait pas de parser JSON
intégré, on peut encore en monter un en Javascript (en utilisant soit les
anciennes XMLHttpRequest pour l'interrogation du serveur, soit les
nouvelles WebSockets), et sécuriser ce Javascript adaptateur facilement
(contre les attaques de type injection de code Javascript), sans
dégradation notable de performance (car un parser JSON est très simple à
écrire, même en Javascript).
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[Philippe Verdy]

Le 19 décembre 2012 18:54, sly (sylvain letuffe) li...@letuffe.org a
écrit :


 ça oui, tout à fait, mais je parlais des cas où, je crois, mais des stats
 pourraient le confirmer, en moyenne les tuiles de zoom 12/13 et + sont
 demandées en moyenne 1,2 fois (ou dans ce goût là) !  donc gain du cache
 médiocre et donc double peine pour le premier à les télécharger alors que
 ça
 ne servira que peu ensuite.


Tout à fait d'accord sur ce point : c'est beaucoup d'effort et de
ressources gaspillées pour un  bénéfice quasi nul, qui en plus dégrade la
fraicheur des données (et la qualité perçue par les utilisateurs).

Là où ça vaut le coup d'investir c'est dans une ferme globale de moteurs de
rendus, avec une distribution des requêtes clientes en utilisant un service
DNS répartissant la charge entre ces serveurs, et s'assurer que chacun de
ces serveurs dispose de la bande passante adéquate, et de la capacité de
calcul suffisante à générer les tuiles demandées.

Déployer des Squid ne sert pas à grand chose et sera plutôt nuisible au
projet.
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[Philippe Verdy]

En gros tu proposes un proxy plus intelligent que Squid (qui ne différencie
pas les zones à afficher ni la géolocalisation des clients).

Je pense que la différenciation des zones à afficher sur des serveurs
dédiés serait utile à l'échelle continentale au mieux, mais qu'ici le but
est de réduire les coûts en bande passante et donc d'utiliser en priorité
la géolocalisation des clients.

Et pour ce dernier objectif (géolocalisation des clients, ou plutôt
détermination de la route IP par laquelle ils arrivent), il vaut mieux
s'appuyer sur un serveur DNS dynamique (qui retournera l'adresse du bon
serveur à utiliser selon la géolocalisation du client, en retournant un nom
de domaine alternatif par une entrée CNAME).

Ce sera beaucoup plus efficace qu'un proxy intelligent qui aura son lien
amont (accès par les clients) surchargé et pas réparti en bande passante,
même si son lien aval (du côté des serveurs de rendu) il va faire faire des
économies aux serveurs de rendu : là on gagnera réellement de la bande
passante au niveau des routeurs d'entrée (et notamment sur les liaisons de
peering, entre lesquelles on pourra gérer la répartition des bandes
passantes).

Ensuite ce qu'on met au bout des adresses redirigées par le proxy peut être
un gros serveur de rendu avec un petit cache Squid frontal, ou un petit
serveur de rendu et un gros cache Squid frontal (mais dans les deux cas une
date de péremption bien plus rapide, pour les réponses HTTP émises du
serveur de rendu vers Squid, puisque entre les deux, le frontal Squid et
le(s) serveurs de tuiles et de rendus cela peut se faire sur une boucle
locale à coût voisin de zéro en terme de bande passante utilisée).




Le 19 décembre 2012 19:56, sly (sylvain letuffe) li...@letuffe.org a
écrit :

 On mercredi 19 décembre 2012, Jocelyn Jaubert wrote:
  Je me demandais: est-ce que avoir un serveur de rendu dédié à une région
  spéciale (genre la France) serait une solution envisageable ?

 Jocelyn, tu penses à tout ;-)

 Je pense que ça peut se creuser, y'a de l'idée et j'ai même commencé à
 mettre
 sur papier quelques idées, mais j'ai peur que ça soit un peu délicat et pas
 super robuste (en tout cas avec mes bidouilles à deux balles que j'ai en
 tête), il faut que je chercher voir si squid, ou apache peut nous faire ça
 en
 mode proxy.

 De prim abord, je pense que la puissance nécessaire à faire un rendu sur la
 terre, bien que pas vraiment possible avec mon smartphone, n'est pas non
 plus
 impossible. Je prouverais (dès que cquest c'est occupé de ma VM au lieu de
 jouer avec des kernels :-p ) , que c'est possible avec les serveurs que la
 fondation free a eu le bon goût de nous fournir.
 (j'ai peur de découvrir toutefois qu'un SSD aurait vraiment été bien,
 auquel
 cas je ferais mon malin à dire J'l'avais dis :-p)

 Et cette croyance actuelle que j'ai m'incite à ne pas m'éparpiller à coller
 des bouts des ficelles entre eux mais partir sur une vrai solution, avec
 une babasse qui dépotte

  En gros, l'idée serait d'avoir un serveur de rendu par région, qui ne
  contiendrait qu'un petit terrain, et sur les zoom élevés. Ça devrait
  permettre
  de diminuer grandement la taille de la machine nécessaire, en la mettant
 là
  où
  c'est le plus nécessaire. Avec les diffs locaux, ça pourrait être
 possible.

 Oui, je le crois tout à fait réaliste en terme de puissance, moins en
 terme de
 réalisation.
 Pour info, je continue à faire un rendu europe à jour real time avec des
 vieux
 style mal optimisés sur un 4-coeur + 8GO de RAM sans SSD, donc oui, j'y
 crois
 et ce, en grande partie grâce à ce que tu as développé pour les europe
 diffs)

 En quoi j'ai peur de la réalisation ?
 le protocole utilisé est TMS, on l'appel comme ça :
 http://duchmol/zoom/x/y.png

 Et, hélas pas, ainsi : http://zone-[bbox max].duchmol/zoom/x/y.png
 Ou il aurait été bien plus facile de préparer un cluster géographique
 réparti
 ou chaque serveur annonce quelle bbox il peut couvrir et le client
 openlayers
 supportant ce faux TMS se charge d'interroger le bon serveur de la bonne
 zone

 En clair avec le vrai TMS, on tombe sur un seul serveur, et lui ne sait pas
 encore s'il peut ou non servir la requête, l'idée que j'ai est donc un
 proxy
 (non cache) intelligent que je préfère nommer le dispatcher

 Son rôle et de transmettre la demande au bon serveur qui gère la bonne
 zone,
 il doit :
 - maintenir une liste des serveurs ordonnés de zone et la zone qu'ils
 couvrent
 - faire le calcul, à partir d'une URL TMS afin de déterminer dans quelle
 zone
 elle se trouve
 - Proxier/ou rediriger par un HTTP 301 la demande de l'internaute vers le
 serveur le plus adapté

 Bigre, rien qu'a l'écrire, je me dis que ça n'est pas si compliqué que ça
 et
 que ça pourrait largement trop bien le faire.
 (cadeaux bonux, mise en cache des zoom 0 à 9 les plus souvent demandés)


 --
 sly, DWG member since 11/2012
 Coordinateur du groupe [ga]
 http://wiki.openstreetmap.org/wiki/User:Sletuffe

 

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[Philippe Verdy]

Le 19 décembre 2012 21:10, Jocelyn Jaubert jocelyn.jaub...@gmail.com a
écrit :

 Il reste le souci soulevé par Philippe V., que ca ne permet pas de réduire
 la
 bande passante, qui est le vrai problème actuellement. La solution d'un
 proxy
 n'est pas vraiment envisageable, à moins qu'il ne fasse des 301 HTTP
 Redirect
 sur les bons serveurs. (je ne sais pas si c'est possible)


Si c'est possible mais en terme de temps de réponse (avec les doubles
allers-retours pour les requêtes HTTP) je ne pense pas que ce soit
souhaitable (et tous les clients HTTP ne gèrent pas les redirections HTTP
301).

Personnellement je vois d'un meilleur œil une solution avec des
redirections DNS. (Oui là je parle bien d'un serveur DNS tenant compte de
la géolocalisation des clients, ou plutôt tenant compte de l'interface
d'entrée sur les routeurs de peering vers les serveurs de tuiles selon
l'adresse IP du client, ce qui nécessite une connaissance de la topologie
amont du réseau, au moins jusqu'au point où des différences de coûts sont
connues et mesurables).
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[Philippe Verdy]

Le 19 décembre 2012 21:21, Christophe Merlet red...@redfoxcenter.org a
écrit :

 Ce sont des stats de rendu de tuiles du zoom 0 à 15...
 On est loin du temps réel pour un paquet de tuiles... Manque de chance
 ce sont les plus denses et curieusement, les plus sollicités


Et c'est justement pour ces tuiles (en fait niveau 0 à 12, voire un peu
moins) qu'il est payant de mettre en place des proxy-caches. Au delà les
caches n'ont plus beaucoup d'intérêt car les tuiles mises en cache
serviront presque tout le temps à un seul client qui ne les demandera le
plus souvent qu'une seule fois, sauf intérêt particulier soulevé par une
discussion publique.

Pour les niveaux plus élevés, les données sont beaucoup plus petites mais
il y a beaucoup plus de tuiles et s'il y a du monde, le travail pour
récupérer les données de la base sera presque aussi important que pour
mettre à jours les tuiles des premiers niveaux. Mais il peut se faire sans
cache de tuiles (juste un cache pour les données) à la demande, même si le
temps de réponse est un peu plus long (au pire on définit une date de
péremption plus précoce de ces tuiles pour pouvoir les purger plus vite du
cache que les tuiles des premiers niveaux.
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[Philippe Verdy]

Ton option de dipatcher (avec un proxy intelligent qui répartit les
requêtes des clients vers plusieurs serveurs) il y a aussi les 50 ms pour
CHAQUE tuile.

Et à cela tu dois ajouter une consommation de bande passante quasiment
doublée (ton dispatcher consommera à la fois de la bande passante amont ET
aval, presque en même quantité pour les niveaux de zoom élevés. Si ton
dispatcher est installé sur une connexion Internet asymétrique, c'est le
débits des deux qui s'effondre vers le plus petit des deux, et le temps de
réponse avec.

On n'a pas ce problème avec une répartition au niveau DNS (bande passante
négligeable pour les requêtes sur le serveur DNS, et aucune obligation de
faire ce ping-pong pour CHAQUE tuile demandée par le même client, qui ne
fera sa requête DNS qu'une seule fois pour arriver ensuite directement sur
le bon serveur sans aucun ping-ping supplémentaire, sans délai, et sans
doubler la bande passante quelque part pour livrer le contenu des tuiles).


Le 19 décembre 2012 21:25, sly (sylvain letuffe) li...@letuffe.org a
écrit :

  La solution d'un proxy n'est pas vraiment envisageable, à moins qu'il ne
  fasse des 301 HTTP Redirect

 Voilà ;-)

  sur les bons serveurs. (je ne sais pas si c'est possible)

 si si, seul défaut, par rapport à ton option DNS level c'est qu'on se
 tape
 un aller retour pour rien vers le dispatcher, mais m'est avis que 50ms
 c'est
 pas ça qui posera tant de problème.


 --
 sly, DWG member since 11/2012
 Coordinateur du groupe [ga]
 http://wiki.openstreetmap.org/wiki/User:Sletuffe

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

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

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[Philippe Verdy]

Le 19 décembre 2012 21:10, Jocelyn Jaubert jocelyn.jaub...@gmail.com a
écrit :


 Il reste le souci soulevé par Philippe V., que ca ne permet pas de réduire
 la
 bande passante, qui est le vrai problème actuellement. La solution d'un
 proxy
 n'est pas vraiment envisageable, à moins qu'il ne fasse des 301 HTTP
 Redirect
 sur les bons serveurs. (je ne sais pas si c'est possible)


Je les ai lu au moment où je les ai reçus sans retard, et je sais même
avant de poster s'il y a eu une réponse entre temps (Gmail m'avertit tout
de suite pratiquement à la seconde : je le sais lorsque je suis en
discussion au téléphone et que j'envoie un mail à la même personne, le
délai pour que la personne au bout du fil ait le mail n'excède pas quelques
secondes ; même chose quand c'est elle qui m'envoie un mail, et c'est
pratiquement la seconde dans les deux sens, si on est tous les deux sur
Gmail).

Maintenant il est possible que tu ne reçoives pas les messages dans le même
ordre et que des réponses des uns et des autres se croisent. Donc
n'interprète pas un désordre apparent entre des messages des uns et des
autres qui se succèdent en quelques minutes (selon la vitesse que met
chaque FAI à livrer ses mails dans les boites aux lettres).
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[Philippe Verdy]

Le 19 décembre 2012 21:46, Christophe Merlet red...@redfoxcenter.org a
écrit :


 Je te propose de me faire un script d'analyse des logs de Squid capable
 de m'afficher la fréquentation de chaque tuile avec un style mapnik...
 bref, une sorte de hotmap


Je n'ai pas la bande passante et la connectivité pour faire tourner un
serveur Squid à l'échelle de ce qu'on cherche.

Et je n'ai pas accès non plus à ce genre de logs (qui sont des données
privatives pour l'essentiel, donc non publiées).

Ensuite pas les ressources (en bande passante, même si j'ai ce qu'il faut
en matériel) pour monter un serveur de tuiles (sauf pour un usage par une
ou deux personnes).

J'ai bien de l'hébergement dispo mais pas avec les capacités nécessaires
(c'est juste du PHP/MySQL de base pour la partie libre que je peux
utiliser, sinon le reste n'est pas pour ça et pas réellement à ma
disposition, mais pas de quoi y mettre une appli comme Mapnik ni même une
base pgSQL), même si pour ça je pourrais utiliser un des serveurs de
projets de rendus de cartes libres, offrant une base pqDSL déjà chargée et
requêtable.

Pour ce genre d'appli de toute façon ce n'est pas une appli du genre Mapnik
qu'il faut puisqu'il suffirait seulement de servir des tuiles monochromes
semi-transparentes, uniquement en protocole WMS sans rien tracer d'autre :
une tuile plus ou moins transparente ou avec une transparence unique de
50%, 100% de luminosité, 100% de saturation et en variant la couleur pour
former un dégradé de couleurs en HSV : pour chaque tuiles WMS de Mapnik on
génère une tuile de même taille et de même coordonnées monochrome (on peut
mettre dans cette tuile uniquement une tâche colorée centrale surface
variable, le tour étant totalement transparent).

Bref aucun calcul de géométrie à faire, ni aucun besoin d'une base SQL
carto, puisque alors on a juste à compter les tuiles numérotées dans un
rectangle tout autour dans un même niveau de zoom et faire une moyenne
horaire pour déterminer la couleur de la tuile à retourner (ces tuiles
pouvant être des images précalculées, 100 images dans un même dossier
suffiront, ces images étant microscopiques en taille).

Je ne peux pas t'en dire plus puisque je n'ai pas les logs pour le faire.
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] [OSM-talk-fr] Tr : [OSM-talk] New OpenStreetMap tile server

[Philippe Verdy]

2012/12/20 Christophe Merlet red...@redfoxcenter.org

 1355960486.937  0 93.31.155.175 TCP_HIT/200 25368 GET
 http://tile.openstreetmap.org/15/16500/11681.png - NONE/- image/png


L'expression régulière ne doit traiter que les URL d'une tuile et pas les
URL d'autres pages qui seront ignorées (s'il y en a aussi dans le log).

En ignorant le reste de la ligne sur les statuts (si on ne veut que mesurer
la charge du serveur) il n'y a que 4 champs à prendre par ligne avec une
unique expression régulière par ligne. Pas besoin de base, un script PHP
peut lire plusieurs milliions de lignes comme ça en moins de 2 secondes
pour obtenir le quadruplet:

(1355960486.937, 15, 16500, 11681)

Autrement dit le timestamp en secondes qui sert juste à déterminer
l'intervalle de date pour le calcul de moyenne, et les numéros de tuile
pour chaque niveau de zoom.

On peut ignorer l'adresse IP du client (ici 93.31.155.175 : c'est une
donnée PRIVÉE, à ne pas publier elle gélolocalise le client et peut
l'identifier précisément avec le timestamp...), et le protocole utilisé
(TCP), le statut du cache (HIT) et de la réponse (200).

A priori on peut ignorer aussi le verbe de requête (GET) et le MediaType
retourné (image/png) même si la réponse du serveur a été une erreur
(requête invalide). Cela dépend des autres requêtes qui passent par ce même
proxy et présentes aussi dans le même log.

Cependant si le serveur a une erreur 5xx, cela peut signifier son anomalie
temporaire, et on peut marquer le timestamp où ça se produit et celui où ça
s'arrête pour soustraire ce temps de l'intervalle de temps (qui sert à
calculer la moyenne horaire des hits). Si l'ntervalle de temps n'a aucune
période sans erreur 5xx, le serveur a un problème et on peut retourner une
couleur par défaut distincte (gris par exemple au lieu d'un dégradé du
blanc au rouge). Sinon on traite cette ligne dans les cumuls :

Il n'y a plus qu'à retourner pour un niveau donné (pour une tuile)
l'image correspondant au nombre de tuiles dans un bucket formé par le
numéro de tuile demandé et autour (si on demande la tuile statistique au
niveau n en x, y, on peut cumuler le nombre de hits trouvés sur:
- (x-16..x+15) et y +/- 14 pour le niveau n+4
- (x-8..x+7) et y +/- 7 pour le niveau n+3
- (x-4..x+3) et y +/- 3 pour le niveau n+2
... (recoller les largeurs d'intervalles x/y en fonction du découpage des
tuiles entre un niveau de zoom n et le niveau n+1, pour qu'elles occupent
la même surface réelle, si ce n'est pas comme ici une division du niveau N
en 4 tuiles du niveau N+1). Pour les valeurs x +/- i faire le calcul modulo
l'intervalle couvrant les 360° de longitude, pour les y (latitudes) borner
avec un min/max sur l'intervalle couvrant les 180° de latitude.

On ignore toutes les lignes qui sortent de ces cadres et celles sortant de
l'intervalle de timestamp, on divise par la durée de l'intervalle de
recherche. Si on veut, on peut cumuler non pas les hits mais la taille en
octets des requêtes (qui est aussi dans chaque ligne, ici 25368 octets).

Le tout se fait en cumulant dans un unique entier pour parser tout le
fichier log. Aucune base de données nécessaire, il faut juste pouvoir
accéder au fichier log pour le lire.

Ceci fait on a un seul nombre qu'on normalise dans un intervalle de 0 à 100
pour retourner une image statique selon la note obtenue. 2 pages de code
PHP suffiront largement pour ça. Autour on met une autre page PHP statique
pour déclarer la ressource WMS et c'est tout. Il reste à créer le dossier
contenant les 100 images de tuiles (on peut aussi générer le PNG par le
même script, c'est juste inutilement compliqué à coder quand un nombre fini
d'images statiques suffit).

Le test à faire ensuite c'est pour les constantes de normalisation (pour
éviter d'avoir une carte toute blanche ou toute rouge), le nombre de
sous-tuiles à moyenner autour d'une coordonnée zoom/x/y, et pour régler la
longueur de l'intervalle de temps (à voir avec un log complet sur le cas
pratique, bien qu'on puisse aussi normaliser en gardant trace de la
statistique maximale obtenue sur des logs plus longs).
___
dev-fr mailing list
dev-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev-fr

Re: [OSM-dev-fr] python shapely - c geos

[Philippe Verdy]

Que ce soit en Python ou Java ou C++ les différences de performances sont
extrèmement minimes (à algorithme équivalent). Tout bonnement car le code
est de toute façon exécuté en code natif compilé (même si en Python ou
Java, la compilation est faite à la demande au tout début de l'utilisation
d'une classe).
Je dirais même l'ayant constaté souvent, que le code est plus rapide en
Python ou Java qu'en C++, tout bonnement car la compilation a lieu sur la
machine cible elle-même en tenant compte au mieux de ses capacités
physiques et de tout un tas de critères liées aux mesures de performance
(le code s'autooptimise) : ce n'est pas le cas du code C++ qui est compilé
sur une machine donnée pour être déployé sur une autre dont on ne connait
pas grand chose.

Bref le problème n'est pas là : le choix de l'algorithme (et surtout des
structures de données utilisées), et divers détails (surtout liés à la
localité des données, et à certaines autres choses comme la minimisation
des appels à l'allocateur mémoire), c'est ce qui fait réellement la
différence. L'autre différence c'est lié aux traitements qu'on fait en trop
(par exemple analyser une structure en entier, pour n'en utiliser en fin de
compte qu'une toute petite partie : les APIs ou bblilothèques utilisées
doivent être bien choisies).

Sinon en C++ on a tendance à en faire trop (et dans ce trop, ne pas tout
vérifier et introduire des anomalies qui se répercutent sur ce dont on a
réellement besoin).

Bref une appli avant d'être du code dans un langage donné, c'est avant tout
une bonne architecture, un bon design (ça passe même avant toute
optimisation locale du code, surtout en C++, car Java ou Python et tout
langage fonctionnant sur une base de machine virtuelle savent éliminer
plein de choses automatiquement si on ne les utilise pas).

Une solution hybride, c'est le C++ compilé en code managé pour une machine
virtuelle (par exemple .Net) qui offre le meilleur des deux mondes (mais
pas tout car C++ permet encore trop de choses : il faut se restreindre à
employer du code managé clean sans manipulations de pointeurs supposant
un modèle mémoire unique). Mais il n'y a strictement aucune différence de
performance alors entre du C++ managé (ou C#), du Java (ou du J#) hormi les
performances de la machine virtuelle elle-même (et les VM Java sont
aujourd'hui excellentes, du moins celles fournies par Sun/Oracle, car du
côté des VM Java de Google, Dalvik VM, ou de GNU c'est pas encore le top au
niveau de leur gestionnaire mémoire ; on peut aussi le dire aussi de la VM
pour CLI (.Net) de Microsoft est bien meilleure que les autres VM CLI
portées actuellement.

Si on veut le top des VM, Intel fournit une VM managée vraiment au poil
(mais elle est chère et sert surtout pour des serveurs pro commerciaux);
Intel sait aussi faire des compilateurs C++ très performants (y compris C++
pour CLI/.Net où il fournit des optimiseurs dynamiques pour les VM a
compilation de type JIT, autrement dit compilation à l'exécution, sur la
machine cible et pouvant même adapter le code compilé en fonction de la
charge à effectuer ou de la charge en cours, et la possibilité de
distribuer le code automatiquement sur un réseau de processeurs distants
fournisseurs de puissance, ou vers des processeurs massivement parallèles,
tels que les GPU).

C++ n'est cependant pas le code idéal pour programmer du parallélisme
massif, il n'est pas assez précis pour décrire les conditions de
rendez-vous, de synchronisation, ou de dépendance entre les flux de
données ou leur conditions de validité (ou alors il s'avère
particulièrement verbeux et les oublis et erreurs de programmation sont
alors nombreuses). De fait un compilateur C++ s'interdit plein
d'optimisations possibles car il n'a pas les moyens de décider tout seul.

J'ai programmé beaucoup en C et C++ dans le passé; maintenant je suis accro
à Java (même si le langage est encore un peu verbeux pour certaines choses,
mais il existe des moyens automatiques de réduire cette verbosité, y
compris avec les générateurs de code et les frameworks), et de temps en
temps Eiffel pour des modélisations plus complexes, surtout en phase de
prototypage et évaluation de la faisabilité ou l'étude fonctionnelle
préalable.

D'autres langages plus pratiques (mais compatibles) apparaissent qui
compilent pour une VM Java, .Net, ou Python ; même pour PHP qui inclue lui
aussi une VM qui s'améliore de plus en plus mais n'a pas encore le même
niveau de qualité et devrait plutôt songer à utiliser une compilation vers
une VM Java, .Net, ou Python, ce qui est parfaitement possible et
permettrait des intégrations et déploiement plus faciles. Javascript aussi
est devenu extrèmemement performant dans ses VM.

On reproche souvent aux programmeurs Java ou .Net (et surtout Javascript)
d'utiliser trop la Réflexion, c'est vrai, ça ralentit énormément beaucoup
et ça brise le moule solide de l'analyse et la modélisation. Pourtant on a
des outils dans les deux cas qui permettent au code à l'exécution

Re: [OSM-dev-fr] Liste des changesets d'un utilisateur

[Philippe Verdy]

Ce qu'il dit c'est que le paramètre uid est ignoré et qu'on obtient
les 100 derniers changesets de tout le monde (peu importe le nombre
d'ailleurs pour ce cas). Cela se passe avec une requête de type:
http://api.openstreetmap.org/api/0.6/changesets?uid=

Mais pas avec:
http://api.openstreetmap.org/api/0.6/changesets?display_name=X
qui utilise bien ce paramètre (et affiche objet non trouvé si l'objet
indiqué n'existe pas)

Ceci suggère que le paramètre uid n'existe pas ou a un autre nom que
celui qui est documenté, ou qu'il n'est pas pris en compte à cause
d'un bogue ou une impasse d'implémentation.

Le 18 octobre 2012 18:27, THEVENON Julien julien_theve...@yahoo.fr a écrit :
 c est normal c est explique dans l API
 http://wiki.openstreetmap.org/wiki/API_0.6#Query:_GET_.2Fapi.2F0.6.2Fchangesets
 si tu veux aller plus loin il faut rajouter des parametres de temps pour
 deplacer la fenetre des 100 changesets affiches

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

Re: [OSM-dev-fr] Test de dev.osmose.openstreetmap.fr

[Philippe Verdy]

La sévérité donnée l'orthographe (par exemple me parait plus limitée
quand ce nom n'est pas réellement mauvais mais ne diffère que par un
accent ou la capitalisation).

Certes on doit donner priorité à la graphie officielle dans la langue
officielle du lieu (mais il peut y en avoir plusieurs selon la langue
dans les zones multilingues admettant les langues régionales ; mais
dans ce cas, ne nom officiel contient souvent les deux noms, et ce
n'est pas une erreur pour name=*, juste pour name:lang=*).

Certaines graphies ne sont pas fausses mais juste alternatives (on
pourrait changer un name=* en alt_name=* pour garder cette autre
graphie non officielle mais fréquente, y compris une dénomination
d'usage locale parfois abrégée).

Les espaces en excès au début ou à la fin d'un champ de nom ne sont
pas des fautes graves (ils viennent généralement d'un copier-coller
depuis une page web), ils pourraient être même corrigés par un bot,
donc leur gravité n'est pas si haute que ça.


La haute sévérité en revanche doit revenir à toutes les erreurs de
géométrie (polygones non fermés ou possédant des intersections avec
leurs enclaves).

Les confusions de rôle entre inner et outer pour les enclaves sont
moins graves (les moteurs d'analyse s'en sortent très bien). De même
les rôles manquants pour les enclaves (pas pour les exclaves). Donc
sévérité moyenne pour ça.

Enfin les autres rôles manquants qui devraient être plutôt outer
sont très peu graves. La correction c'est juste pour unifier le schéma
et permettre ensuite des résolutions de problèmes lorsque le polygone
sera ultérieurement modifié incorrectement (ouverture,
auto-intersection, segments en trop) par quelqu'un d'autre. Donc
sévérité faible pour ça, car dans l'immédiat c'est encore tout à fait
correct et n'empêche pas une bonne interprétation par n'importe quel
outil d'analyse ou de rendu (même chose si le polygone emploie encore
les rôles enclave au lieu de inner aujourd'hui préféré, et
exclave au lieu de outer aujourd'hui préféré).

Priorité faible aussi si la liste des membres d'un polygone n'est pas
ordonnée dans un sens de fermeture des anneaux (il semble que Potlatch
ne fasse pas ce tri quand on scinde un segment en deux ou quand on
fusionne deux segments successif, il ajoute le nouveau segment à la
fin de la liste des membres sans regarder à quel segment précédent ou
suivant il se connecte pour savoir où mettre le nouveau segment dans
la liste ; je trouve que c'est gênant cela ne permet pas de comparer
facilement les diffs d'une version à l'autre pour voir ce qui a été
ajouté ou retiré d'une relation, même si du côté de JOSM on a des
indications par des couleurs dans l'éditeur de conflits).

Le 8 octobre 2012 11:28, Pieren pier...@gmail.com a écrit :
 Interface plus claire puisque la liste des erreurs dépend de la
 sévérité choisie. Mais je suis assez d'accord sur la remarque
 contestant les erreurs appartenant à plusieurs niveaux de sévérité.
 Est-ce un moyen d'admettre que le classement dans tel ou tel niveau de
 sévérité est subjectif ? Il suffirait de l'écrire en intro sur la doc.
 Sinon, petite remarque, il faudrait écrire soit all severities (ou
 1+2+3) au lieu de all severity.

 Pieren

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

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

Re: [OSM-dev-fr] Contrôle qualité des axes routiers

[Philippe Verdy]

Je voulais surtout dire section car ça peut être une suite de point
formant un seul et même way sur lequel on met des attributs
spécifiques à cette section, mais pas toute la route (donc pas toute
la relation avec ses propres attributs).

Le 9 octobre 2012 12:19, Ista Pouss ista...@gmail.com a écrit :
 Le 9 octobre 2012 11:55, Philippe Verdy verd...@wanadoo.fr a écrit :

 Pas besoin de deux relations, on a les rôles forward et backward

 pour mentionner le sens pris sur un segment unidirectionnel.


 Je ne les vois pas mentionné dans les relations  rennes nantes et inverse ?
 Ils semblent équivalent au + et - de FR:10301+ et FR:10301- je pense ?

 Quand tu dis segment, est-ce que ce terme est équivalent à l'ensemble de
 la relation que ab_fab a mis en place pour rennes - nantes ?

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

Re: [OSM-dev-fr] Test de dev.osmose.openstreetmap.fr

[Philippe Verdy]

Les pastilles de couleur à mon avis n'apporte pas grand chose (en plus
du fait qu'elles sont peu accessibles, pensez à ceux qui ont du mal à
distinguer les couleurs, surtout sur des objets de petite taille, car
il n'y a pas non plus d'indication de placement comme sur les vrais
feux). Si au moins dans la pastille il restait quand même un chiffre.
Mais c'est vrai qu'il n'y a pas d'utilité non plus à les décaler, si
le but est l'accessibilité justement.

Tant qu'à faire au lieu des pastilles (sensées coder la priorité de
correction selon la gravité), on pourrait même avoir des panneaux plus
parlants car ce que ça signifie c'est surtout :
* erreur: danger/faux, les sélections d'objets ou le rendu risquent de
mal fonctionner (exemple géométrie brisée, intersection entre les
anneaux d'une relation inner/outer, valeur très ambiguë, numéro de
référence erroné) : priorité 1
* erreur: pas grave mais l'objet ou la valeur est ignoré ou ne sera
pas visible, ou pas très joli (exemple : capitalisation des noms,
abréviations) : priorité 2
* avertissement: donnée pas fausse mais devenue inutile ou redondante,
ou qui n'est plus recommandée (il y a une meilleure façon de faire) :
priorité 3

Le premier niveau pourrait être un panneau STOP, le second un panneau
de danger (ex: route glissante), le dernier un panneau d'information
(ex; point d'information tourisme)

Le 8 octobre 2012 01:22, Black Myst black.m...@free.fr a écrit :


 Le 7 octobre 2012 10:40, Frédéric Rodrigo fred.rodr...@gmail.com a écrit :

 Bonjour,

 Pouvez vous nous faire part de vos commentaires sur la mise à jour de la
 présentation du frondend d'Osmose :

 http://dev.osmose.openstreetmap.fr



 Le but est de valider que ce soit bien utilisable et qu'il n'y ai pas de
 bugs d'affichage.


 J'aime beaucoup le nouveau menu avec la sévérité exprimé sous forme de rond
 de couleur et le fait qu'il soit masquable pour optimiser la surface de la
 carte.
 En revanche, je ne sais pas si pas si elle est très intuitive pour un nouvel
 utilisateur (comme je connaissait la version précédente, j'ai tout de suite
 compris).
 Pourrait-on ajouter un tooltip sur les icônes ?

 Sinon, je ne comprends pas pourquoi certain items ont plusieurs niveaux de
 gravité ?
 Après tout, si on laisse à l'utilisateur le choix des niveaux qu'il souhaite
 afficher, pas besoin de multi-classer les items.
 Ca me semblerait plus simple qu'il n'y en ait qu'une, et du coup, on aurait
 une seule colonne avec la pastille de la bonne couleur.

 Bravo pour ces changements
 Black Myst


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


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

Re: [OSM-dev-fr] Contrôle qualité des axes routiers

[Philippe Verdy]

Le 9 octobre 2012 00:02, Marc Sibert m...@sibert.fr a écrit :
 HS (aussi) : ce n'est pas un *sport* de dépasser les limites légales, c'est
 stupide. Respecte-les et pas de flash. Bon j'arrête là.

Je n'ai pas dit ça. Tu ne comprends pas.

Ce qui est sport ce sont les entrées et sorties sur la rocade de
Nantes avec ses voies de droite ultracourtes qui servent à la fois
d'entrée et de sortie, et où tout le monde pousse et personne ne met
de clignotant pour savoir s'il sort ou s'il rentre, et quand on se
fait aussi pousser par derrière.

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

Re: [OSM-dev-fr] Test de dev.osmose.openstreetmap.fr

[Philippe Verdy]

Pour moi :

* un faux positif concerne une anomalie qui n'en est pas une et
qu'il ne faut pas corriger, telle que pare exemple la suggestion d'une
autre orthographe ou un autre nom que ce qui est présent dans la base
: bref détecté mais qui ne doit pas être corrigé) : cela ne devrait
plus être resignalé lors des exécutions et raffraichissement de la
base. Toutefois un faux positif devrait être revu par un humain, ou
être signalé comme faux positif à au moins 2 utilisateurs distincts
pour confirmer qu'il n'y a rien à corriger.

* sinon c'est corrigé si l'anomalie n'est plus là après
vérification, soit parce que quelqu'un l'a déjà corrigée ou qu'on
vient de le faire en modifiant la base. Ce type de clic n'implique
aucun enregistrement dans la base : lors du rafraîchissement, si
l'erreur est redétectée, elle sera à nouveau signalée. Le clic sur
corrigé ne fait donc disparaitre la bulle que temporairement, cela
va être revérifié automatiquement et resignalé si la correction n'a
pas eu lieu (ou si elle a été annulée).

Cette nouvelle interface ne change pas la signification par rapport à
l'ancienne où on avait déjà les deux mêmes liens d'action pour retirer
une bulle.

Le 7 octobre 2012 13:01, Ista Pouss ista...@gmail.com a écrit :
 Au niveau de l'utilisisabilité, je ne sais pas quels sont les principes
 généraux. Et je ne comprends pas toujours ce que je clique que ce que je
 fais.

 Au niveau de ce qui me semble de catégorie bug, avec mon firefox 15.0.1 /
 Ubuntu :

 - Les coordonnées de la souris en bas à droite ne sont correctes qu'à partir
 du moment où je bouge la souris. Sinon, elles sont à 0.
 - Si je clique sur rawedit dans un petit phylactère, ça me met dans une
 situation inextricable si je ne veux pas me connecter. Je vois apparaître
 une grosse fenêtre et je ne peux plus m'en sortir.
 - L'espèce de panneau de liste de catégories d'erreur est un peu déroutant
 quand il est replié : déjà il n'a pas de titre, et on n'est pas censé savoir
 ce que c'est (quand il est déplié c'est plus facile de deviner), et l'action
 sur les liens tous rien inversé ne provoque rien de visible (puisque
 le panneau est replié). De plus, même quand il est déplié, si je vois bien
 les cases se cocher ou se décocher en fonction, j'ai du mal à comprendre ce
 que ça déclenche au niveau de la carte. De plus, ce panneau replié ne suit
 pas le langage que j'ai choisi : chez moi il reste en anglais.
 Bref, la version repliée est assez perturbante :-)
 - Dans les phylactères, la notion de faux positif est très déroutante pour
 un utilisateur lambda concernant une erreur : c'est quoi une erreur positive
 ? une erreur en faux positif ?
 - un clic sur Permalink retourne exactement la même chose. Je comprends
 bien le but de la manoeuvre de la cause de la chose, mais peut être
 faudrait-il donner quelques explications ?... (et le mettre en français si
 j'ai choisi le français comme langue ? )

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

Re: [OSM-dev-fr] Test de dev.osmose.openstreetmap.fr

[Philippe Verdy]

Le 7 octobre 2012 14:05, Ista Pouss ista...@gmail.com a écrit :
 Bonjour Philippe,

 Je connais les explications, je voulais juste dire que, pour l'utilisateur x
 y ou z, faux positif et permalink n'ont pas des fonctionnement
 intuitifs, et peuvent être considérés comme des bugs. Après, avec les
 considérations, tout se discute, bien sûr.

On a pourtant un lien vers une page d'aide sur chaque bulle. Ceci dit
il manque un lien général sur la page d'aide pour utiliser l'outil et
savoir quoi en faire.

De plus je ne suis pas certains que cliquer sur faux positif empêche
la bulle d'anomalie de revenir. On dirait que ça tient uniquement tant
que l'objet OSM référencé n'a pas eu une modification de sa version,
mais qu'elle revient après, tandisque que les vrais positifs sur
lesquels on a cliqué corrigé par erreur, vont revenir dès la mise à
jour suivante (dans les heures qui suivent, parfois quelques jours
quand la base est en pause et ne charge pas les mises à jour venant
d'OSM pour recalculer les analyses).

Je me demande quand même où sont listés les faux positifs signalés,
car pendant assez longtemps il pourraient rester non signalés alors
qu'on les a déclarés faux positif par erreur (d'autant plus que les
utilisateurs ne sont pas identifiés, pas même apparemment par un
cookie de session résident).

L'outil sort-il quelquepart une liste des faux-positifs déclarés, afin
de permettre une maintenance en cas de signalement par erreur ou pour
réactiver une analyse alors que l'anomalie est toujours détectée
automatiquement mais masquée ?

Les modifications de l'algo de détection tiennent-elles compte des
faux-positifs les plus fréquemment signalés ? Que se passe-t-il quand
l'algo d'une analyse est modifiée, et que de nouvelles analyses
devraient tenir compte des nouvelles règles même si celle-ci dans sa
version antérieure détectait une anomalie déclarée auparavant comme un
faux positif mais qui ne le serait plus selon les nouvelles règles de
détection qui peuvent ajouter d'autres conditions de signaler à
nouveau l'erreur de façon plus précise ?

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

Re: [OSM-dev-fr] Test de dev.osmose.openstreetmap.fr

[Philippe Verdy]

Le 7 octobre 2012 16:56, Etienne Trimaille
etienne.trimai...@gmail.com a écrit :
 Le 7 octobre 2012 16:30, Philippe Verdy verd...@wanadoo.fr a écrit :

 L'outil sort-il quelquepart une liste des faux-positifs déclarés ?


 Oui, dans l'onglet statistiques d'osmose dans la barre supérieur.
 Pour chaque erreurs, tu peux avoir la liste des faux positifs, le graph, les
 erreurs.
 Tu peux aussi avoir la liste par région :
 http://osmose.openstreetmap.fr/utils/false-positive.py

Heureusement, je découvre cette liste de faux-positifs... qui étaient
de vrais positifs.

Comme par exemple l'erreur 3032 relevée sur le nom Église de
Saint-Arnoult (qui indique sa localisation, c'est-à-dire le nom de la
commune où elle est située, et non le nom de l'église, d'autant plus
qu'il y a plusieurs églises à Saint-Arnoult, et qu'en plus il y a
encore un noeud juste à côté de l'église plaçant la même église mais
sans les contours du bâtiments). – Osmose avait raison de signaler
l'erreur que quelqu'un a déclaré à tord comme faux positif. Les noms
des églises consacrés à des saints ne prennent déjà pas de traits
d'union comme les toponymes des communes, et ne prennent pas de
majuscule sur saint, un nom d'église correct étant Église saint
Arnoult ou Église saints Paul et Jacques. Ce type d'aide devrait
être mentionné dans le wiki pour expliquer mieux la nature de
l'erreur. Si on ne connait pas le nom de l'église dans la commune,
autant ne pas l'indiquer du tout, on laissera en revanche les autres
tags indiquant que c'est bien une église, et le culte pratiqué.

Certaines erreurs comme celles-ci devraient être plus explicites dans
leurs formulation, afin d'éviter que certains signalent cela à tord
comme un faux positif, sans même regarder la carte en plus, sinon le
second emplacement indiqué par un nœud juste à côté aurait été éliminé
aussi pour éviter le doublon de localisation qui est resté depuis !

Cela me suggère une autre analyse à développer pour Osmose : certains
bâtiments de même nature (ici des églises, ce pourrait être aussi des
temples ou mosquées) sont très rarement aussi proches l'un de l'autre
sur la carte ! Les écoles aussi (quand elles ont des noms identiques
ou très similaires, et sont de même catégorie et non partie d'un
groupe scolaire), ou encore les cinémas, théâtres, ou les parcs et
jardins, ou les point d'information touristique (généralement pas plus
d'un seul par commune).. **et cela pourrait aider à localiser
automatiquement les doubles imports du cadastre**

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

Re: [OSM-dev-fr] Test de dev.osmose.openstreetmap.fr

[Philippe Verdy]

Le 7 octobre 2012 18:43, Philippe Verdy verd...@wanadoo.fr a écrit :
 Comme par exemple l'erreur 3032 relevée sur le nom Église de
 Saint-Arnoult (qui indique sa localisation, c'est-à-dire le nom de la
 commune où elle est située, et non le nom de l'église, d'autant plus
 qu'il y a plusieurs églises à Saint-Arnoult, et qu'en plus il y a
 encore un noeud juste à côté de l'église plaçant la même église mais
 sans les contours du bâtiments). – Osmose avait raison de signaler
 l'erreur que quelqu'un a déclaré à tord comme faux positif. Les noms
 des églises consacrés à des saints ne prennent déjà pas de traits
 d'union comme les toponymes des communes, et ne prennent pas de
 majuscule sur saint, un nom d'église correct étant Église saint
 Arnoult ou Église saints Paul et Jacques. Ce type d'aide devrait
 être mentionné dans le wiki pour expliquer mieux la nature de
 l'erreur. Si on ne connait pas le nom de l'église dans la commune,
 autant ne pas l'indiquer du tout, on laissera en revanche les autres
 tags indiquant que c'est bien une église, et le culte pratiqué.

D'ailleurs je note que plein de faux positifs listés proviennent des
erreurs faites par un utilisateur comme s_frantz lorsqu'il fait des
imports : une fois qu'il a fait le travail, il marque visiblement
faux positif alors qu'il a oublié d'enlever des doublons bien réels.
Je soupçonne que ce soit lui qui clique sans arrêt sur faux positif
sans même regarder la carte en zoomant dessus, juste parce qu'il n'a
pas envie de voir l'erreur et s'intéresse à autre chose.

A mon avis le clic sur le lien faux positif ne devrait être autorisé
QUE pour les utilisateurs authentifié (donc avec un compte perso sur
le site Omose qui devrait donc gérer des comptes personnels). Pour
tous les autres, ce lien faux positif ne devrait pas être là. Ils ne
devraient pouvoir faire QUE cliquer sur corrigé afin de permettre
une réanalyse ultérieure. Ceci permettrait d'évaluer la qualité de ces
faux positifs, et de les enlever en masse par un bot (en filtrant par
utilisateur et type d'erreur, ou juste par utilisateur qui n'a pas
compris à quoi servait le lien faux positif) s'il y a trop de faux
positifs signalés à tord, afin qu'Osmose réactive l'analyse dessus et
resignale l'erreur.

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

Re: [OSM-dev-fr] Test de dev.osmose.openstreetmap.fr

[Philippe Verdy]

En continuant sur la même idée : si on est identifié sur Osmose, un
clic sur corrigé masque la bulle d'erreur mais uniquement pour soi :
la marque corrigée est alors enregistrée dans la liste des
corrections marquées par l'utilisateur et qu'il ne veut pas voir.

Cette liste des trucs corrigés pour chaque utilisateur peut être
automatiquement purgée lors de l'analyse suivante du même objet : le
masquage reste temporaire. Mais en attendant, l'utilisateur peut à
nouveau consulter dans son compte perso sur Osmose la liste de ses
propres erreurs corrigées pour en faire réapparaître certaines plus
rapidement (parce que le masquage de la bulle a été faite par erreur,
par exemple en cliquant sur corrigé dans la mauvaise bulle ouverte.
Cette réactivation dans sa propre liste d'erreurs corrigées sera
faite pour tout le monde à priori.

L'outil permettrait aussi de tenir des statistiques sur la qualité des
signalements et des corrections, utilisateur par utilisateur, afin que
ceux-ci progressent dans leur compréhension des problèmes signalés et
apprennent à mieux utiliser l'outil.

Je suggère même que les clics sur corrigé effectués par les
utilisateurs non identifiés sur Osmose, ne fassent QUE masquer
l'erreur pour eux-même et pas les autres utilisateur, en gérant des
comptes perso temporaires (identification par un cookie de session
uniquement, qui peut avoir une durée de vie de un mois maxi, ce compte
temporaire était purgé de la base au moment de l'analyse suivante ou
lorsque le cookie expire et n'a pas été renouvelé par une nouvelle
visite de l'utilisateur sur le même navigateur).

Si l'idée d'avoir des comptes perso identifiés ne plait pas, on
pourrait avoir pour tout le monde des comptes perso anonymes
identifiés par le cookie de session à durée de validité limitée, et
dans ce cas, pour tout le monde avoir encore accès au lien faux
positif (nombreux sont ceux qui ne purgent pas les cookies de leur
navigateur). Mais ceux qui ont un navigateur réglé pour ne pas
accepter les cookies de session ne verront aucun effet sur le bouton
corrigé ou faux positif, car à chaque fois ils seront dans une
nouvelle session puisqu'ils ne transmettent pas avec leur clic le
cookie envoyés par Osmose lorsqu'il affiche sa page ou n'importe
quelle bulle d'erreur.

Mais je serais favorable à avoir des comptes perso permanents sur
Osmose, non dépendants des cookies temporaires. Afin de permettre
d'avoir des listes perso de suivi et pour chacun conserver une trace
statistique de son propre travail de signalement des erreurs corrigées
ou déclarations de faux positifs.

Cela répondrait mieux à la question posée récemment par les
anglophones sur Qui est un bon mappeur ? qui se base sur une
évaluation subjective par les autres et sans critère réellement
objectif.

Le 7 octobre 2012 19:08, Philippe Verdy verd...@wanadoo.fr a écrit :
 Autre idée qui va avec la gestion de comptes personnels sur Osmose :

 Disposer pour chacun la possibilité de consulter la liste des propres
 faux positifs qu'on a déclaré soi-même, pour pouvoir les réviser à
 nouveau, et pouvoir annuler cette déclaration, par exemple parce qu'on
 a cliqué au mauvais endroit (l'erreur est humaine, mais si on peut se
 corriger soi-même et revenir dessus, c'est aussi bien, cela améliorera
 aussi l'outil en permettant à chacun d'évaluer la qualité de son
 travail en regardant un peu plus tard avec un oeil neuf ou plus
 éclairé et mieux informé).

 Pour tous les autres ou si on n'est pas identifié, ne mettre QUE le
 lien corrigé (qui masque temporairement la bulle pendant quelques
 heures jusqu'à la prochaine passe d'analyse).

 Résultat : moins de maintenance, et une liste de faux positifs qui
 sera plus utile, y compris pour améliorer la qualité de l'analyse
 automatique d'Osmose (sur lequel des règles de détection peuvent alors
 être améliorées sur des bases plus objectives fondée sur une vraie
 expérience basée sur des faux positifs vérifiés).

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

Re: [OSM-dev-fr] Test de dev.osmose.openstreetmap.fr

[Philippe Verdy]

J'ai perdu le lien, c'était à Saint-Arnoult en Normandie, déclaré en
faux positif après un import de bâti (qui a laissé un doublon avec le
noeud mentionnant la position d'une église mais sans la nommer), alors
qu'Osmose avait bel et bien raison.

Et pas mal d'autres faux positifs sont incorrectement déclarés alors
qu'ils concernent le même utilisateur z_Frank d'après lhistorique
de ses derniers imports.

Je ne veux pas polémiquer. Mais si Osmose offrait à chacun la
possibilité de suivre ses erreurs, et de les comprendre, on aurait
aussi un outil formateur. Je crois à la vertu de l'autoformation et de
la possibilité de se corriger, ou sinon de demander de l'aide sur ce
qu'on ne comprend pas, ou de savoir que certaines modifs on ne sait
décidément pas les faire et qu'il vaut mieux s'abstenir de les faire,
tant qu'on n'aura pas expérimenté un peu plus sur des cas au départ
plus simples.

L'autoévaluation de ses propres erreurs, et la possibilité de savoir
se corriger rapidement en corrigeant soi-même, serait positif pour la
communauté et la qualité générale des données. Au delà de ça c'est
aussi quelque chose qui limiterait le vandalisme (en évitant par
exemple qu'un vandale clique systématiquement sur faux positif pour
éviter que les autres voient les erreurs qu'il provoque
volontairement).

Je trouve ça bien mieux que de demander aux autres : que pensez-vous
de cet utilisateur, et d'entrer dans les polémiques de dénonciation
publique ou des polémiques inutiles suite à une seule erreur commise
que un grand nombre de modifs et ajouts corrects et bien faits.

Plus j'y réfléchis et plus je pense qu'avoir des comptes perso
identifiés dans Osmose serait une bonne idée pour permettre à chacun
de s'autoévaluer et s'améliorer ou apprendre à demander de l'aide aux
autres sur ce qu'on n'arrive pas à faire correctement tout seul.

Le 7 octobre 2012 20:55, Frédéric Rodrigo fred.rodr...@gmail.com a écrit :
 Le 07/10/2012 18:43, Philippe Verdy a écrit :

 Les noms
 des églises consacrés à des saints ne prennent déjà pas de traits
 d'union comme les toponymes des communes, et ne prennent pas de
 majuscule sur saint, un nom d'église correct étant Église saint
 Arnoult ou Église saints Paul et Jacques. Ce type d'aide devrait
 être mentionné dans le wiki pour expliquer mieux la nature de
 l'erreur.


 Peux tu me citer une source pour justifier ça, stp ?

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

Re: [OSM-dev-fr] Test de dev.osmose.openstreetmap.fr

[Philippe Verdy]

Osmose me rend responsable de certaines erreurs tels que des routes
chevauchant des bâtiments. Chaque fois c'était une route que j'ai
tracée (ou corrigée un minimum pour assurer la continuité en me basant
sur Bing) avant même que le bâtiment soit importé des mois après par
quelqu'un d'autre, qui n'a pas soit réaligné la route, soit vérifié la
cohérence de l'alignement de ses bâtiments importés ou ajoutés.

Osmose visiblement ne regarde pas les dates des modifications, il
suppose que c'est le dernier qui a tracé ou modifié la route qui a
fait l'erreur. Il n'y a pas moyen de contrôler ça ?

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

Re: [OSM-dev-fr] Test de dev.osmose.openstreetmap.fr

[Philippe Verdy]

Nonn le problème est surtout que cela mentionne le lieu (le nom de la
commune) et non le nom de l'église. Comme si on avait marqué Église
de Quimper, sauf qu'ici la ville porte le nom d'un Saint.

Surtout en regardant de plus près il y a d'une part le polygone du
bâtiment importé (qui justement mentionne le nom de la commune, qui a
plusieurs églises), mais aussi 30 mètres à côté (hors du polygone,
dans l'espace autour de l'église) un noeud mentionnant une église sans
lui donner de nom (ce qui est correct tant qu'on ne connait pas le nom
de l'église) mais qui est resté après l'import.

Je ne vois pas en quoi on peut dire faux positif quand Osmose a
raison sur le fait que ce n'est pas le nom de l'église, mais que celui
qui a importé le bâteiment a laissé le doublon (qu'Osmose ne signle
pas pourtant), très visible pourtant sur la carte (on voit les deux
croix du symbole de l'église, le noeud anonyme étant marqué dans le
rendu simplment avec le nom par défaut Église.

Le 7 octobre 2012 21:51, Pierre-Alain Dorange pdora...@mac.com a écrit :
 Frédéric Rodrigo fred.rodr...@gmail.com
 wrote:

  Les noms
  des églises consacrés à des saints ne prennent déjà pas de traits
  d'union comme les toponymes des communes, et ne prennent pas de
  majuscule sur saint, un nom d'église correct étant Église saint
  Arnoult ou Église saints Paul et Jacques. Ce type d'aide devrait
  être mentionné dans le wiki pour expliquer mieux la nature de
  l'erreur.

 Peux tu me citer une source pour justifier ça, stp ?

 A priori les noms d'église respectent les conventions de toponymie
 française, donc avec des majuscules et un trait d'union.

 La page toponymie du wiki français OSM qui reprend l'essentiel des
 recommandations de la CNIG et de l'IGN et de l'INSEE semble s'accorder
 la dessus. Bien que rien de spécifique ne soit préciser au sujet des
 lieux de cultes, cela concerne les noms de lieux.
 Surtout il est bien précisé que les noms de saint prennent majuscule et
 trait d'union : Saint-Paul.

 http://wiki.openstreetmap.org/wiki/FR:Toponymes,_odonymes

 On notera toutefois que le CNIG que l'omission des majuscules et trait
 d'union en cartographie (contraire aux recommandations) peut être
 acceptée pour minimser la longueur des textes, si ces conventions sont
 expliqués en légende... ;-)

 La charte de topymie de l'IGN (1) ne cite qu'un seul exemple de nom
 d'église et celle-cine concerne pas un saint, mais il y a des des
 majuscules : Église des Ulis.

 Les recommandations du CNIG (2) ne cite pas d'églises...

 (1) http://www.ign.fr/sites/all/files/charte_toponymie_ign.pdf
 (2)
 http://www.cnig.gouv.fr/Front/docs/cms/cnt-grammaire-recommandation_1269
 24688421947500.pdf

 --
 Pierre-Alain Dorange
 OSM experiences : http://www.leretourdelautruche.com/map/


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

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

Re: [OSM-dev-fr] live.openstreetmap.fr besoin de test et retours avant annonce...

[Philippe Verdy]

Je ne comprend pas alors pourquoi cela figure dans le javascript
chargé avec la page, où il y a un plugin social intégré (supportés:
Tweeter/Retweet, Google+/+1, Facebook/J'aime, et un bout de code en
commentaire pour d'autres sites sociaux comme DiggIt).
Mais bizarrement rien de GoogleAdwords/Doubleclick qu'on trouve un peu
partout sur le web maintenant (et qu'on ne peut pas désactiver sans
planter le site ou emôécher toute interaction autre que la simple
consultation).

C'est bien un plantage de Flash qui fait planter cette appli au bout
d'une demi-heure. Note: j'ai un bloquer de réseaux sociaux, il ne
signale rien sur ton site, pourtant il y a bien du code pour ça. Je me
demande si ce n'est pas justement le bloqueur de trackers
publicitaires et sites sociaux qui injecte du code destiné à bloquer
ces sites mais provoque alors l'anomalie. (Ce bloqueur c'est Do Not
Track Plus, mais je ne constate aucune anomalie avec d'autres sites
qui n'utilisent pas directement les modules sociaux et trackers
publicitaires/comportementaux; ni même sur des stes très dynamiques
comme Youtube malgré le bloquage du +1 de Google pour mon bloqueur. En
moyenne ce bloqueur évite un peu plus plus de 30  000 liens tiers par
mois ! Preuve de l'étendue gigantesque et clairement abusive du
pistage comportemental sur Internet)

Le 31 août 2012 18:58, Christian Quest cqu...@openstreetmap.fr a écrit :
 Parle-t-on bien de la même URL ?

 http://osm7.openstreetmap.fr/~cquest/live/
 ou
 http://osm7.openstreetmap.fr/~zorglub/livechanges/frontend/ (dernière version)


 Le 31 août 2012 18:40, Philippe Verdy verd...@wanadoo.fr a écrit :
 Note: j'ai trouvé aussi dans la page le support du bouton +1 pour
 Google+. Comme le bouton J'aime de Facebook. Pour Google+ je suis
 confiant qu'il n'y a pas de Flash dedans, mais avec Facebook j'en suis
 moins sûr (et pas question qu'on s'interface avec Facebook sans passer
 par leur API officielle qu'il est interdit de modifier et dont le
 contenu change sans arrêt pour contourner chaque fois des
 restrictions). La seule façon d'éviter un accès Facebook caché c'est
 d'ôter toute référence à son API de m***e !


 Sont utilisés:
 - jquery
 - highcharts
 - leaflet

 rien d'autre, pas de Facebook ou autre +1 et toujours pas de flash.

 J'ai fait tourner le live pendant plus de 4h sur mon Chrome sous
 OSX... aucun problème.

 --
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

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

Re: [OSM-dev-fr] live.openstreetmap.fr besoin de test et retours avant annonce...

[Philippe Verdy]

Ca marche sur Chrome, mais pas longtemps (guère plus d'une
demi-heure). A la fin on a une erreur Flash, sans doute un débordement
mémoire d'une liste d'objets qui ne cesse de s'allonger et n'est
jamais purgée, ou parce qu'il y a trop de sessions ouvertes sur les
différents serveurs et il se produit une erreur.

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

Re: [OSM-dev-fr] live.openstreetmap.fr besoin de test et retours avant annonce...

[Philippe Verdy]

Le 31 août 2012 12:03, Christian Quest cqu...@openstreetmap.fr a écrit :
 Une erreur flash... y'a effectivement un gros problème... flash n'est
 pas du tout utilisé ou alors à l'insu de notre plein gré ;)

Y-a pas un plugin ou un tracker publicitaire dedans, qui poserait
problème en surchargeant les requêtes (vu qu'elles sont exécutées en
boucle) ?

Déjà que je trouve bizarre de trouver dans le javascript de tous les
sites OSM du code pour tester le format et la validité d'un numéro de
carte de crédit (test de Luhn)...

Je n'ai pas fouillé la série de javascripts qui s'exécutent et ce
qu'ils chargent en plus. Mais comem il y a du SVG, je me demande si
c'est l'install de Flash intégrée au navigateur qui ne le prendrait
pas en charge (ça fait longtemps que le SVG est supporté sur les
navigateurs par un plugin Adobe, au départ séparé mais maintenant
intégré dans Flash.

Mais là je pense que c'est lintégration des plugins sociaux dans
Leaflet qui doit activer un bout de code Flash, via l'aPI officielle
Tweeter ou Facebook qui doit s'initialiser ici pour rien sans qu'on le
demande réellement. On n'a pas une version de Leaflet SANS support de
ces plugins sociaux indésirables ?

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

Re: [OSM-dev-fr] Base de données encodage

[Philippe Verdy]

Déjà il serait temps que les distribs Linux arrêtent de s'installer
dans une locale C et n'installer que l'anglais. Même pour l'anglais
UTF-8 devrait être la valeur par défaut partout, installé
systématiquement. Jusque même dans les outils de création de compte
utilisateur qui devraient être dans ce codage par défaut. La locale C
c'est juste pour des comptes annexes destinés à installer munellement
des anciennes configurations.
Idem pour les serveurs de base de données, les shells, les consoles
X11 et terminaux dans les paramètres de connexion et de session, les
outils d'exportation de données...
JE suis même convaincu que la locale fr_FR (et même en_US) devrait
être maintenant des alias vers leur version UTF-8 par défaut et non
ISO 8859-1 ou 15, ou une vieille page de code 437 ou 850.
Les outils qui ne supportent pas l'UTF-8 devraient ne plus être
installés du tout par défaut mais seulement à la demande pour ceux qui
en veulent encore. Le web tout entier passe à l'UTF-8 (qui dépasse en
volume largement maintenant la somme de tous les autres encodages,
hormi l'US-ASCII pur qui reste compatible sans aucun changement en le
comptant comme UTF-8).

Le 19 juillet 2012 16:16, Mikaël Cordon mikael.cor...@gmail.com a écrit :
 Les problèmes de codage caractère sont casse-bonbons, je confirme :)

 Ceci dit, ce n’est pas parce que l’affichage foire que les données en base
 sont foireuses… Tu peux faire des opérations sur tes données via la base ;
 elle respectera le codage caractère.

 Bon courage !

 Le 19 juillet 2012 15:01, Arnaud Vandecasteele arnaud@gmail.com a
 écrit :

 Bon je crois que je vais arrêter là, car mon mal de crâne avec ce problème
 d'encodage ne fait qu'empirer.
 Quand j'aurais un peu plus de temps j'essayerai de revenir dessus à tête
 reposée.

 Merci en tout cas pour le coup de main !

 Arnaud


 2012/7/19 Gilles Bassière gbassi...@gmail.com

 On jeu., 2012-07-19 at 13:02 +0200, Arnaud Vandecasteele wrote:
  Donc cela proviendrait de mes locales qui ne sont pas bien
  configurées ?

 D'après le résultat de la commande ``locale``, ton système utilise
 l'encodage C. Ce n'est ni bien ni mal, c'est juste un choix avec des
 avantages et des inconvénients.

 D'après la page déjà citée, C correspond grosso-modo au ASCII
 standard. C'est donc normal que tu ne puisses pas voir correctement des
 caractères UTF-8.

 Sauf cas particuliers, les logiciels qui tournent sur ton système vont
 donc travailler dans l'encodage C. Ça concerne ta console et plein
 d'autres logiciels.

 Je ne sais pas si tu peux te permettre de changer l'encodage au niveau
 système. C'est une solution un peu radicale (c'est-à-dire simple mais
 avec de possibles effets indésirables).

 Sinon, chaque application a sa façon de gérer l'encodage. ogr2ogr
 utilise PGCLIENTENCODING (pour les connexions PostGIS en tout cas),
 pgsql2shp a une option -W, etc...

 Note que pour utiliser un encodage, il faut que le système le
 reconnaisse. La commande ``locale -a`` t'indique les encodages
 actuellement supportés. Tu dois normalement pouvoir en ajouter d'autres,
 la page citée précédemment explique comment. C'est de la doc Ubuntu mais
 ça doit pouvoir s'appliquer à des systèmes similaires. Pour le reste, le
 mieux serait que tu en parles avec des spécialiste de Solaris.

 Cordialement
 --
 Gilles Bassière - Web/GIS software engineer
 http://gbassiere.free.fr/



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




 --
 
 Arnaud Van De Casteele
 Mines Paris Tech - CRC
 Sophia-Antipolis
 0698 24 25 29
 SIG - WebMapping - Spatial Ontology - GeoCollaboration

 Web Site
 http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/
 http://geotribu.net/
 http://www.i2c.eu/

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



 Cordialement,
 --
 Mikaël Cordon

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


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

Re: [OSM-dev-fr] Base de données encodage

[Philippe Verdy]

Le 19 juillet 2012 16:53, Mikaël Cordon mikael.cor...@gmail.com a écrit :
 Et d’ailleurs les distributions GNU/Linux les plus populaires s’installent
 avec l’UTF-8 activée par défaut depuis quelques années déjà… :)

Pas dans tous les outils installés par défaut ou ceux qui sont
directement supportés par la distrib (je ne parle pas des outils
optionnels qui sont dans une catégorie à part, même chez Ubuntu ou
RedHat). Il y a encore un nombre considérable d'outils configurés dans
la locale C (et qui ne veulent pas autre chose en plus)?

De ce point de vue-là on en est encore à la situation qu'il y avait en
1995-2000 avec DOS/Windows... Un mix d'encodages avec des passerelles
de conversion un peu partout juste pour tenter de présenter ça en
Unicode dans une session utilisateur. Il n'y a guère que les
navigateurs qui soient encore à peu près au point (mais pas les
navigateurs en mode texte qui utilisent iconv un peu partout, avec des
pertes et résultats étranges quand ils remplacent par exemple å par aa
ou pire encore par ä...

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

Re: [OSM-dev-fr] Notion des routes payantes dans un flux JSON

[Philippe Verdy]

Le 4 juillet 2012 17:32, sly (sylvain letuffe) li...@letuffe.org a écrit :
 On mercredi 4 juillet 2012, Philippe Verdy wrote:
 pasaccordés non lus de
 façon cohérente pour servire de guide

 Merci philippe, de me faire autant rire


 , et en mélangeant aussi des
 affirmations (non délimitées), jusqu'au point où on ne savait pas ce
 qu'il voulait faire et où était sa question. C'était un gros mélange
 de mots où on ne savait pas ce qu'il demandait.

 En remplaçant dans ta phrase demandait par disait

Non c'était bien demandait. Pour le reste désolé pour les fautes de
frappe sur un smartphone qui remplace sans arrêt les mots et ne
facilite pas du tout les corrections qu'il annule dès le caractère
suivant (la correction caractère par caractère est extrêmement
pénible).

Mais si je fais rire, au moins je n'insulte personne. Et je n'inonde
pas cette liste comme le font 20 fois par jour ou plus ceux qui me
l'ont reproché (pour faire des stats il faut aussi savoir déjà compter
sur ses doigts, ce n'est pas à la porté de tout le monde).

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

Re: [OSM-dev-fr] Travailler sur des imports partiels

[Philippe Verdy]

Attendre que Geofabrik actualise son fichier. Sinon compléter toi même
en aller chercher les polygones manquants dans la base OSM (JOSM peut
t'aider à exporter un fichier OSM ou un shapefile).

Le 4 juillet 2012 17:44, Philippe DAVID philippe.da...@allgoob.com a écrit :
 Bonjour,
 ma question fait suite à la discussion Polygones Aquitaine et Gironde sur
 talk-fr.

 J'ai fait un import de aquitaine.osm (from geofabrik) dans un nominatim, et
 quand je vais sur la page détails.php, les polygones n'apparaissent pas pour
 la Gironde et l'Aquitaine.

 Est-ce que c'est un genre de problème connu, ou ça vaut la peine que je
 creuse ?

 Vous faites comment sur openstreetmap.fr pour importer uniquement des
 données relatives à la France ?

 --
 Philippe
 Allgoob SA


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


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

Re: [OSM-dev-fr] Travailler sur des imports partiels

[Philippe Verdy]

Note: le bogue des deux régions date s'il y a près de 3 semaines, je
l'ai corrigé à ce moment-là car une frontière avait été brisée par une
opération de résolution de conflits d'édition qui a mal tourné. On
voyait le bogue dans Layers, il n'y est plus maintenant, Layers ayant
reçu les modifs.

Le 4 juillet 2012 17:58, Philippe Verdy verd...@wanadoo.fr a écrit :
 Attendre que Geofabrik actualise son fichier. Sinon compléter toi même
 en aller chercher les polygones manquants dans la base OSM (JOSM peut
 t'aider à exporter un fichier OSM ou un shapefile).

 Le 4 juillet 2012 17:44, Philippe DAVID philippe.da...@allgoob.com a écrit :
 Bonjour,
 ma question fait suite à la discussion Polygones Aquitaine et Gironde sur
 talk-fr.

 J'ai fait un import de aquitaine.osm (from geofabrik) dans un nominatim, et
 quand je vais sur la page détails.php, les polygones n'apparaissent pas pour
 la Gironde et l'Aquitaine.

 Est-ce que c'est un genre de problème connu, ou ça vaut la peine que je
 creuse ?

 Vous faites comment sur openstreetmap.fr pour importer uniquement des
 données relatives à la France ?

 --
 Philippe
 Allgoob SA


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


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

Re: [OSM-dev-fr] Travailler sur des imports partiels

[Philippe Verdy]

Le 4 juillet 2012 18:10, Philippe DAVID philippe.da...@allgoob.com a écrit :
 Euh ce n'est pas le même problème que celui dont je parlais sur l'autre
 liste.
 Là les polygones n'apparaissent pas du tout.

Parce que dans la conversion des ways, ils étaient rompus. Si la
boucle n'est pas bouclée, plus rien de la zone n'apparait, elle n'est
pas remplie.

 Je me disais que suivant comment leur export est fait, ça peut bugger un peu
 pour tout ce qui se trouve pile à la frontière. Donc je voulais savoir si
 qqun a déjà travaillé sur des imports partiels et si il a rencontré ce type
 de pb.

l'outil que tu utilise devrait être capable de combiner plusieurs
fichiers OSM. Cela ne devrait poser aucune problème puisque tous les
objets OSM ont un numéro de version, il suffit de garder le numéro le
plus élevé. Donc si dans le gros fichier OSM (dans lequel n'a été
extrait que les zones fermées), il manque des objets, et que tu
importe des petits fichiers OSM supplémentaires pour les zones
manquantes et tu les combine, cela fera une mise à jour des trous en
attendant que tu puisses importer une nouvelle version du gros fichier
(là encore par combinaison, en allant vérifier ensuite si des objets
de l'ancienne version du gros fichier qui ne sont plus dans la
nouvelle version n'ont pas été supprimés dans la base).

Il devrait y avoir des outils pour faciliter cette combinaison, mais
JOSM permet de faire de telles fusions entre des calques OSM chargés
séparément, afin de créer un nouveau calque fusionné : il signalera
les conflits éventuels et te permettra aussi pour les résoudre d'aller
charger dans un calque supplémentaire la dernière version à jour de
cet objet dans la base OSM. afin de savoir si un trou dans la nouvelle
version n'est que temporaire.

Souvent ce qu'on voir c'est que le trou a été créé par un way qui a
été coupé en deux : on voit alors encore la plupart des anciens noeuds
mais dont une partie qui ne semblent reliés à aucun way, parce que
dans le jeu de données il manque encore le nouveau way qui a été
ajouté pour lier ces noeuds.
Il reste alors à vérifier les relations qui utilisent encore la partie
qui a été gardée pour savoir quelles relations sont nécessaires aussi
pour le nouveau way qui manquait.

Etant donné que quand on coupe un way en deux, il y a assez souvent
aussi des conflits d'édition pendant la sauvegarde, la partie
manquante du nouveau way peut ne pas être pendant une durée parfois
assez longue dans la base, simplement parce qu'elle n'a pas encore été
envoyée mais la partie conservée a été elle conservée.

Certains conflits demandent beaucoup de temps pour les résoudre, avec
des téléchargements et mises à jour assez longues à faire et
volumineuses en données. C'est le cas pour les relations des régions
car on ne peut pas les charger en totalité par une requête de tous les
objets dans un rectangle. On procède par chargements successifs dans
les zones où il apparait des trous pour savoir où est passé le way qui
manque et qui se connecte encore au noeud voulu pour fermer la boucle.

De temps en temps on verra que cela aboutit à deux ways : le way
complet (encore présent) et un nouveau way partiel qui se superpose,
tandisque le way complet n'a pas encore été mise à jour dans la base
car l'utilisateur qui a créé le nouveau way partiel est en train de
résoudre un conflit d'édition et n'a pas encore pu transmettre la
totalité des données.

Quand les outils automatiques de Geofabrik.de tournent, ils
n'attendent pas la fin de résolution de ces conflits. Ils prennent la
base à un instant T. Il reste donc des éléments manquants avec
lesquels il faut aller à la pêche aux informations.

Comme Geofabrik dans son fichier généré élimine les relations
incomplètes, tu ne trouves rien et c'est à toi d'aller chercher les
éléments qui manquent. On aimerait bien que Geofabrik non seulement
exporte des fichiers OSM mais aussi exporte une analyse des relations
brisées afin qu'on sache où aller chercher les infos manquantes (et
qui sont certainement encore dans la base, au moins dans une version
antérieure).

Ce travail de fermeture des relations est ce qui est fait de temps en
temps pour les gros shapefiles disponibles en téléchargement séparé
sur le site OSM (comme les lignes de côtes). Ces shapefiles sont
fermés mais alors pas nécessairement à la dernière version, il y a des
éléments ajoutés provenant de la fusion avec des versions antérieures.
Ils sont tous produits avec une supervision manuelle, c'est un gros
travail à faire qui prend pas mal de temps.

Si les trous sont petits (ou des points distincts se superposent, les
shapefiles tentent aussi la fusion des points pour fermer les
relations, ou de les relier par un segment suppélementaire si leur
distance est inférieure à un certain seuil (en dessous de 50 mètres,
il n'y a guère d'ambiguité sur la façon de fermer une ligne de côte
par exempl, même si ça veut dire que ce trou fermé arbitrairement
pourrait correspondre à l'embouchure d'une petite rivière, ou 

Re: [OSM-dev-fr] Travailler sur des imports partiels

[Philippe Verdy]

Grosse bécane ? Mon PC portable charge sans problème toutes les
régions et département de France dans un seul fichier OSM), et même de
plusieurs pays frontaliers. La VM java est configurée pour pouvoir
monter sans problème à 16 Go de RAM (mon portable en a 32 Go avec 8
coeurs, il n'a pas couté une fortune non plus, acheté en déstockage il
y a un an et demi à moins de 1000 euros, bien moins cher que mon gros
PC de bureau en config RAID 5, et pourtant avec une carte graphique
décente, une excellente ventilation, deux disques durs en stripe, avec
un cache frontal SSD 64 Go sur la carte mère).

Mais dans JOSM il vaut mieux utiliser une version 64 bits de Java (et
s'assurer qu'une mise à jour de Java ne remette pas seulement une
nouvelle version 32 bits qui sera inutilisable pour charger plus d'1
million de noeuds dans une VM dépassant à peine les 2 Go), tandis que
la version 64 bits encore présente ne sera plus utilisable pour un
lancement par JavaWebStart.

Quand on utilise Java avec un navigateur web, celui-ci ne prend en
charge dans son plugin que la version 32 bits. Pourtant c'est la
version 64 bits qu'on devrait utiliser pour JOSM. Mais on a parfois
beauc faire, meˆme en mettant à jour les deux versions, JavaWebStart
persiste à ne vouloir lancer que la version 32 bits du JRE (et le
panneau de configuration Java ne voit même pas la version 64 bits
encore installée et même mise à jour...)

Ce qui fait que parfois il faut désinstaller Java complètement et le
réinstaller directement en 64 bits, pour ensuite ne charger la version
JRE 32 bits que pour l'intégration dans le navigateur web. L'autre
solution c'est de se passer de JavaWebStart, et télécharger et
installer le JAR de JOSM séparément, pour le lancer par une ligne de
commande où on indique la version de Java à utiliser.

Je pense sincèrement que le système de mise à jour automatique de Java
ne gère pas encore bien la coexistence des versions 32 bits et 64
bits, et qu'il manque dans le lanceur Java un système pour déterminer
la version 32 bits ou 64 bits à lancer (à mon avis sur une machine 64
bits, la version 32 bits ne devrait être qu'une surcouche
d'adaptation, de type thunking, de la version 64 bits, uniquement
destinée aux plugins d'intégration des navigateurs web qui ne veulent
encore qu'une version 32 bits des plugins On aurait moins de
problèmes avec les mises à jour.

De même on attends que les navigateurs web supportent tous une version
native 64 bits (quitte pour eux à intégrer une interface de
compatibilité pour intégrer les plugins 32 bits qui devraient vite
être remplaçables eux aussi en version 64 bits).

Le 4 juillet 2012 22:06, sly (sylvain letuffe) li...@letuffe.org a écrit :
 Ce dont j'avais peur c'est que le
 problème que j'ai rencontré sur le dump d'une région puisse aussi arriver
 à l'échelle d'un pays. D'après ce que dit le readme de geofabrik dans
 clipbounds, c'est la même méthode utilisée donc ça pourrait aussi arriver.
 Et d'ailleurs c'est arrivé comme disait Frédéric.

 Le mieux serait peut-être de re-vérifier, beaucoup ont fait remonter
 l'information à geofabrik et je sais que le polygone utilisé pour découper la
 france a pas mal été changé ces dernières années et peut-être que maintenant,
 si tu télécharges le fichier france.osm tu aura toute la france 
 (métropolitaine
 en tout cas)


 Pour résumer, si je souhaite:
 - avoir un nominatim de plusieurs pays
 - avoir toutes les données, quitte à déborder
 - appliquer des diff updates

 Est-ce que je peux faire ça pour les pays en questions seulement ?
 ou c'est
 trop compliqué et il vaut mieux travailler direct sur le monde entier ?

 Si tu veux appliquer les diff updates, ça change pas mal de chose car c'est
 l'opération qui nécessite le plus de ressources serveur (i/o principalement).

 En clair, si tu as besoin des diffs, il te faut une grosse bécanne, et parti 
 de
 là, importer le monde ne te prendra que 2 jours au max, donc j'ai envie de
 dire, importe le monde directement.

 Seul cas : tu utilises des disques de trop petite taille pour contenir une
 base monde et là il va falloir ruser. (Si ton projet et professionnel, essayes
 plutôt de convaincre de te faire payer des gros disques, tu y gagnera
 plusieurs journées qui auraient couté plus que les disques ;-) )



 --
 sly (sylvain letuffe)

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

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

Re: [OSM-dev-fr] Travailler sur des imports partiels

[Philippe Verdy]

Tu parles des perfs du RAID 5 : franchement j'ai de meilleure perfs
sur mon RAID 5 à 6 disques en SATA 3 (trois contrôleurs) que sur un
SSD unique. Sans doute une limitation de l'unique interface SATA
(supposée SATA 3 mais qui visiblement sature bien avant d'atteindre le
débit maximum supposé).

Visiblement nos SSD actuels ont un dispositif qui limite leurs
performance (sans doute dans la table d'index des secteurs), je ne
sais pas trop où mais ça me laisse dubitatif sur même la cohérence des
données qu'ils stockent. D'ailleurs à débit élevé on voit très
nettement des pauses assez longues entre des séquences de burst. Ces
pauses ont des conséquences car l'OS met le thread en attente et ne le
réactive aussi qu'après un certain délai quand il pense pouvoir faire
quelquechose d'autre comme des processus de maintenance automatique.

Je ne vois, lors de débits I/O massifs, pas de réel gain du SSD par
rapport au RAID, pire je vois des pauses bien plus longues où les
threads sont mis en sommeil bien plus longtemps, et les cores de CPU
passent en mode basse énergie et basse fréquence et sont assez longs à
réveiller : trop de cores en fait restent en sommeil et ne font rien
du tout sur la config SSD, et le nombre et la fréquence de pages qui
sont mises en swap out de façon anticipée explose (ces swaps sont
d'ailleurs prioritaires sur toutes les autres I/O et peuvent être
responsables de ces délais).

L'OS y est aussi certainement pour quelquechose. Mais je n'ai pas
envie de fouiller pour savoir pourquoi, la solution de contournement
sera trop spécifique à une seule instance de l'OS et ne résistera pas
à la mise à jour d'un pilote ou d'un service annexe (y compris une
solution logicielle de sécurité mise à jour tous les jours).

De toute façon, un SSD ne permet pas de stocker à pris raisonnable
tout ce dont on a besoin pour l'OS, la base de données, les services,
et les outils qu'on utilise autour. Je garde le SSD uniquement pour le
logiciel, pas pour les données ni pour la partition de swap en stripe
sur un petit volume RAID distinct, et ça suffit. Question coût aussi.
Si on veut plus de performance, c'est plus rentable de meetre à jour
son serveur SQL pour qu'il puisse utiliser de nouvelles méthodes
d'indexation et formats de stockage, et de faire un peu de tuning SQL
(surtout aussi pour optimiser les requêtes en fouillant les plans
d'exécution pour trouver les goulots d'étranglement)

Le 4 juillet 2012 22:45, Vincent de Chateau-Thierry v...@laposte.net a écrit :
 http://lists.openstreetmap.org/pipermail/dev-fr/2012-June/000974.html

 Philippe, si tu as des éléments probants, c'est le moment. Du concret, du
 factuel, bref, du constructif...

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

Re: [OSM-dev-fr] Travailler sur des imports partiels

[Philippe Verdy]

Ok je viens de comprendre : pour votre usage c'est moins de débit que
la fréquence des requêtes qui vous limite. Je n'ai pas encore atteint
en pratique la limite de mon système RAID 6 (d'autant plus que tous
les disques RAID ont un frontal SSD qui absorbe bon nombre d'I/Os). La
réelle limite que j'ai c'est plutôt le débit par interface de
contrôleur, ce que j'ai résolu en multipliant les interfaces, ce qui
reste de toute façon moins cher que les gros SSD qui sont absolument
hors de prix (à plus de 5 euros le Go, c'est la mort, alors que les
SSD classiques de 128Gb sont facturés autour de 1,50 euros / Go).

Pour une base de données de 1 To cela donne un prix de 5000 euros par
SSD (sans compter que pour la maintenance, il va falloir le doubler au
minimum en mirroir RAID 1, plus prévoir de toute façon une sauvegarde
externe sur des volumes à disque dur, et qu'en plus il faudra héberger
le logiciel sur un autre SSD encore, car il y a de grande chance pour
que, lorsqu'un des deux gros SSD plante pour des raisons matérielle,
le second soit aussi planté en même temps par corruption des données
même s'il n'a pas lui-même de panne physique, problème classique des
solutions en RAID 1 et RAID 0 qui suffisent pourtant pour le
logiciel, dont on a une sauvegarde stable facilement restaurable en
cas d'accident ou de corruption).

L'autre problème des SSD c'est qu'en pleine charge, leur montée de
température est plus élevée et plus brutale que celle des disques
durs. Leur refroidissement est moins bien conçu et moins facile à
faire. Mal refroidi, leur taux d'erreur est plus élevé que pour les
disques durs qui ont intégré divers systèmes de sécurité et de
stabilisation, qui manquent encore aux SSD qui ne réagissent pas aussi
bien.

Maintenant je n'ais jamais fait d'essai avec une config pour OSM ou
les bases pgSQL/OpenGIS. Mes applications ne sont pas bridées par les
I/O mais davantage par les TPM logiciels au niveau du moteur (lequel
dépend surtout des performances de la mémoire et des coeurs CPU).
Peut-être que vos configs ont trop investi sur les SSD et pas assez
sur la RAM tout simplement, alors que c'est pourtant bien moins
cher/plus rentable, ou sur le choix de l'OS et sa configuration. Enfin
le logiciel bien écrit doit savoir faire une usage intelligent de ses
caches en mémoire pour réduire considérablement les I/O sur les
volumes disques (RAID ou SSD), ou encore le choix des architectures de
bus, ou encore sur le tuning de la base de données basé sur un
monitoring en situation réelle. Cela peut montrer des choix logiciels
pas efficaces (les algorithmes d'indexation notamment, ou les modèles
de données).

J'admet qu'OSM a un modèle beaucoup trop simple (trop plat dans trop
peu de tables avec un stockage quasiment en vrac) qui laisse peu de
place aux optimisations possibles.

Le 4 juillet 2012 23:28, Philippe DAVID philippe.da...@allgoob.com a écrit :
 Tu as fait un vrai tests pour affirmer cela ?
 Je peux t'affirmer qu'en terme d'IO/s c'est faux.
 Je parle bien d'IO/s, car c'est cela qui importe pour des bases des données,
 et pas des débits séquentiels.

 Personnellement j'ai utilisé des SSD dans l'industrie, des Intel X25-M, donc
 assez vieux maintenant.
 Dans la pratique (j'insiste), 1 disque montait à 10 000 IO/s.
 Un SAS même à 15k tours ne peux pas physiquement dépasser 300 IO/s (15 000
 tours/min = 250 tours/seconde)

 En théorie donc, 10 SAS15k  ne peuvent pas dépasser 3000 IO/s, et on l'a
 vérifié concrètement avec ce setup.

 Est-ce que tu peux argumenter tes propos avec de vrais chiffres s'il te
 plait ?

 2012/7/4 Philippe Verdy verd...@wanadoo.fr

 Tu parles des perfs du RAID 5 : franchement j'ai de meilleure perfs
 sur mon RAID 5 à 6 disques en SATA 3 (trois contrôleurs) que sur un
 SSD unique. Sans doute une limitation de l'unique interface SATA
 (supposée SATA 3 mais qui visiblement sature bien avant d'atteindre le
 débit maximum supposé).

 Visiblement nos SSD actuels ont un dispositif qui limite leurs
 performance (sans doute dans la table d'index des secteurs), je ne
 sais pas trop où mais ça me laisse dubitatif sur même la cohérence des
 données qu'ils stockent. D'ailleurs à débit élevé on voit très
 nettement des pauses assez longues entre des séquences de burst. Ces
 pauses ont des conséquences car l'OS met le thread en attente et ne le
 réactive aussi qu'après un certain délai quand il pense pouvoir faire
 quelquechose d'autre comme des processus de maintenance automatique.

 Je ne vois, lors de débits I/O massifs, pas de réel gain du SSD par
 rapport au RAID, pire je vois des pauses bien plus longues où les
 threads sont mis en sommeil bien plus longtemps, et les cores de CPU
 passent en mode basse énergie et basse fréquence et sont assez longs à
 réveiller : trop de cores en fait restent en sommeil et ne font rien
 du tout sur la config SSD, et le nombre et la fréquence de pages qui
 sont mises en swap out de façon anticipée explose (ces swaps sont
 d'ailleurs prioritaires sur toutes les

Re: [OSM-dev-fr] 10 bonnes raisons de passer sous Postgresql 9.1 ?

[Philippe Verdy]

C'est une question de volume. LEs bases OSM de toute façon sont trop
volumineuses pour tenir avec leurs index dans un SSD de taille
raisonnable et à prix non prohibitf. Le taux de panne étant important
plus le volume croit plus la fréquence des pannes augmente.
Les solutions de RAID et de serveurs de fichiers en miroir fonctionne
bien, augmentent la fiabilité, facilitent la maintenance (y compris
les sauvegardes qui ne sont plus prohibitives en temps d'accès pendant
qu'elles tournent quasiment en continu).

Il n'y a pas que la fiabilité des supports SSD en jeu. Les problèmes
sont encore plus fréquents dans leurs interfaces et dans les complexes
algorithmes de placement. Un SSD a aussi une zone très critique qui
contient le mapping des secteurs : trop sollicitée c'est cette zone
qui lâche la première et on se retrouve alors avec un méli-mélo de
secteurs et de couteuses et longues tentatives de récupération.


Le SSD reste très bien pour installer un kernel et les logiciels
(partitions /, /bin, /usr et même /home, mais pas /tmp qui en revanche
ira très bien dans un ramdisk). Ou alors on peut avoir un RAID dont
chacun des disques est monté avec un frontal SSD transparent,
détachable.
Attention à la régulation de température des SSD: c'est souvent très
mal fait. Le SSD est alors plus faible pour les interruptions de
courant ou plantages système. Et marche mieux dans ce cas que la
mémoire cache intégrée aux disques (souvent de l'ordre de 32Mo à 64
Mo).

Mais le critère de coût/remplacement est encore prohibitif. C'est
tellement plus simple d'ajouter des disques en stripe. On peut même
utiliser des interfaces réseau pour connecter des disques en
FiberChannel et paralléliser des serveurs.
Je sais que les RAID en SSD seul ça existe, mais un projet
OpenStreetMap quelconque n'a pas les moyens de se payer ça.

Autant acheter plutôt un autre serveur pour répartir les services y
compris ceux de maintenance, ou pour tester de nouvelles versions et
faciliter des migrations. Ou sinon pour ajouter un autre générateur de
tuiles pour les plus hauts niveaux de zoom et avec assez d'espace pour
garder du cache sans trop le soliciter et permettre des
rafraichissements de tuiles plus rapides entre versions.

Ou acheter une carte contrôleur de plus pour éviter des goulots de
bande passante sur un bus. Et privilégier l'optimisation du noyau et
des logiciels pour le parallélisme en multhithread partout où c'est
possible (pas la peine sinon d'avoir des cœurs en plus si on ne s'en
sert pas). Enfin bien mettre au point les accès de monitoring et
apprendre à gérer son serveur et vérifier que le déploiement est
encore conforme aux attentes et usages (qui varient largement au cours
du temps).

Le 25 juin 2012 14:13, sly (sylvain letuffe) li...@letuffe.org a écrit :
 pourrais-tu publier ta
 configuration sur la page sus-citée afin que toute la communauté en
 bénéficie ?

 Je serais moi aussi très intéressé par une publication de la part de philippe
 d'un protocol experimental précis et des résultats d'une importation avec
 osm2pgsql afin de donner un peu de concret à ses dirs (comparaison RAID/SSD)
 qui semblent pour l'instant juste sortis du chapeau de la légende urbaine et
 du bruit de couloir...

 Si cela confirme que les SSD n'apportent rien quand on y met les données de la
 base postgresql crée par osm2pgsql, je re-considérerais certains choix que
 j'ai fais, mais pour l'instant, je vais m'en tenir à mes propres benchmarks
 que j'ai publié sur le wiki, faute de concret dans ce qu'annonce philippe.

 --
 sly
 qui suis-je : http://sly.letuffe.org
 email perso : sylvain chez letuffe un point org

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

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

Re: [OSM-dev-fr] Java et Osm

[Philippe Verdy]

Le 28 mai 2012 17:24, jo jonath59...@hotmail.fr a écrit :
 J'ai également une autre question:
 J'ai utilisé un peu la libraire de Travelingsaleman, et ma carte s'affiche 
 bien mais le problème c'est que la carte ne s'affiche pas comme un plan à 
 90 degrés mais comme une sorte de projection de la carte à 120 degrés. 
 Y-a-t-il une solution pour résoudre ce problème ?
 Car de base, les tuiles utilisé sont ceux de OpenStreetMap donc elles sont à 
 90 degrés.

Pour changer l'orientation des tuiles (celles qui sont issues d'un
systèmes WMS-C), pas d'autre moyen que d'utiliser ton propre moteur de
rendu, ou sinon de faire une rotation de bitmap réduisant la précision
des pixels et rendant illisibles nombre de libellés !

Pour que les libellés restent lisibles, par une rotation de tuiles
WMS-C, il faudrait qu'elles soient générées avec une résolution plus
grande permettant aux glyphes du texte de rester lisible, donc que
ceux-ci soient tracés tous avec une graisse suffisante d'au moins 2
pixels de largeur de trait : cela nécessite alors des polices plus
grandes et donc de filtrer davantage les libellés que ce qu'on fait
sur les tuiles WMS-C calculées pour un niveau de zoom avant plus
élevé.

A mon avis, il ne serait pas inutile de générer des tuiles WMS-C
toujours à 90 degrés, mais cette fois avec des polices plus grandes
(tracées donc avec des traits plus épais), permettant ensuite de
réduire dynamiquement cette résolution par ajustement linéaire, mais
aussi de pouvoir les faire pivoter avant dans un angle arbitraire tout
en conservant les libellés lisibles.

Bref monter un serveur de tuiles avec un nouveau style de rendu
utilisant des polices plus grandes que ce qu'on a actuellement à
niveau de zoom équivalent. Cela ne générerait pas forcément plus de
requêtes au serveur de tuiles, ni des tuiles plus grandes (en nombre
de pixels comme en kilooctets par tuile), cela serait équivalent en
terme de volume téléchargé ou en volume généré sur le serveur à celui
d'un niveau de zoom supplémentaire.

(On sait maintenant facilement faire une transformation linéaire
lissée correctement de n'importe quelle image pixellisée, pour des
zooms et rotations arbitraires, et même afficher ces images en 3D en
lui appliquant une couche d'élévation, ce qui est démontré par des
applications comme Google Earth qui utilise la projection sphérique de
Mercator et qui permet aussi d'appliquer une transformation non
linéaire sur la surface : explorez les zones montagneuses: ce que
Google Earth réalise est déjà en démo avec les images produites depuis
OSM, et ça marche bien au moins en Flash, ou en HTML5 avec Javascript
dans un canvas : les cartes graphiques savent toutes maintenant
prendre en charge ces transformations et aussi la plupart des
smartphones vendus maintenant qui ont tous un GPU capable de rendu 3D
accéléré parfaitement accessible en Javascript sans même utiliser la
technologie propriétaire Flash/ActiveScript, qu'Adobe d'ailleurs a
déjà mentionné qu'il sera bientôt abandonné au profit du Canvas
HTML5/Javascript).

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

Re: [OSM-dev-fr] Java et Osm développement

[Philippe Verdy]

Ca ne répond pas à la question, sa question porte sur une  **appli**
en Java. Java a tout ce qu'il faut pour se connecter à une base de
données et son développement ne dépend pas réellement de la plateforme
hôte.

Que je sache JOSM est aussi écrit en Java et n'a pas besoin qu'on
déploie ou développe une base de données pour fonctionner. Sa question
est du même ordre.

Je suggère donc plutôt de voir comment réutiliser une partie de JOSM
pour créer une interface dérivée adaptée à son appli. JOSM sait très
bien colorer une sélection, même si c'est un bâtiment.

Pour le reste, s'il veut utiliser la base de données en ligne, ou une
base locale, c'est un autre problème complètement séparé.

Le 17 mai 2012 10:27, Frédéric Rodrigo fred.rodr...@gmail.com a écrit :
 Bonjour,

 Dans votre cas il va falloir une base de données. Mais attention elle peut
 vite prendre de la place si la zone à couvrir est étendu.
 Les bâtiments dans OSM proviennent du cadastre et le découpage correspond
  aux parcelles s'il n'a pas été corrigé avant l'import. Donc plusieurs
 bâtiments OSM pour un bâtiment dans la réalité.

 Coté technique il va probablement falloir s'orienter vers une base sqlite.
 Il existe déjà plusieurs outil permettant de créer cette base : dont
 osm2sqlite, il y a aussi un patch pour osm2pgsql (à évaluer). Il y a
 sûrement d'autres outils. Mais sqlite avec OSM n'est pas la solution la plus
 rependu.

 Ensuite vient le problème du fond de carte. Il y a deux solutions soit
 stocker des tiles en local, soit faire du rendu vectoriel. Un outil de rendu
 vectoriel peut également être une solution au problème des bâtiments s'ils
 sont dans la base vectorielle pour le rendu. Il y a plusieurs outils, mais
 cela risque de dépendre de l'OS cible :
 http://wiki.openstreetmap.org/wiki/Android voir en particulier MapsForges et
 MapDroyd.

 Bon courage !

 Frédéric.

 Le 16/05/2012 19:45, jonathan coulon a écrit :

 Bonjour,

 Je suis entrain de développer une application immobilière s'appuyant sur
 OpenStreetMap.
 Auriez-vous des conseils à me donner pour l'implémentation d'une carte
 OSM en java en offline.
 Y-a-t-il possibilité de dessiner sur la carte osm en java (ex colorier
 les bâtiments quand on clic dessus.).

 Merci

 COULON Jonathan
 70 rue Emile Zola
 59184 Sainghin en Weppes
 Tél: 0603976045


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

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

Re: [OSM-dev-fr] Key:maxspeed:practical

[Philippe Verdy]

Les temps de parcours moyen sur certains axes fréquents peuvent
effecveiement être calculés et saisis sur des traces GPS. Très utile
en ville pour avoir une idée du temps de parcours ou de traversée, ou
sur les rocades (en tenant compte des temps moyens de parcours
incluant des variations de conditions de circulation), lorsqu'un long
parcours passe à proximité et emprunte ces rocades.

Sur mon GPS, il y a souvent de gros décalages entre le temps estimé
par lui et la réalité. Une fois il m'a donné 1h30 de route là où il en
fallait presque 3, alors que les conditions de circulation étaient
relativement normales, et le trajet comprenait une section d'autoroute
au temps largement prévisible et stable. Du coup en comptant arriver
largement à l'heure à un rendez-vous (en prenant 1 heure ne plus par
sécurité) je suis arrivé en retard d'une demi-heure...

Au moins sur les nationales, voies rapides, et autoroutes, les temps
de parcours moyens seraient très utiles : c'est sur cette base qu'on
peut estimer une vitesse moyenne (qui n'est NI une vitesse conseillée,
ni une limite de vitesse), à laquelle on peut ajouter aussi des temps
moyens correspondant à la traversée d'un péage (peu importe où il
est), ou le passage d'un carrefour avec feux (le temps moyen d'attente
à chaque feu est lui aussi estimable, à condition d'avoir cartographié
les feux, les stops, et les cédez-le-passage pour les priorités.

(Un truc qui manque encore un peu partout dans OSM : quelle voie est
prioritaire ? comment taguer les priorités quand ce n'est pas la
priorité à droite par défaut, et que ce n'est pas non plus
systématiquement la voie classée secondaire par rapport à la voie
tertiaire ou résidentielle ?)

Le 18 avril 2012 14:04,  jul...@krilin.org a écrit :
 On Wed, 18 Apr 2012 13:49:14 +0200, Frédéric Rodrigo wrote:

 Bonjour,

 Le tag maxspeed:practical a déjà fait l'objet d'un vote et rencontré
 une forte opposition. Ça me fait penser à la notion de cyclabilité qui
 est elle aussi subjective et contextuelle.
 C'est pourtant un info très pertinent si on veut faire du calcul
 d'itinéraire de qualité.

 http://taginfo.openstreetmap.org/keys/maxspeed%3Apractical#overview


 oui, mais si Michael Schumacher se met a OSM et qu'il tag tout en
 practical=300Km/h
 qu'est ce qu'on peut en faire ?

 Si une route est limité a 90 mais qu'en fait il vaut mieux rouler a 70, qui
 est juge de ca ?

 dans OSM on note la réalité du terrain, pas le ressenti des gens.





 Si ce tag correspond à un besoin effectif et qu'il y a des moyens réel
 d'obtenir ces informations, il est possibilité des les mettre dans une
 base voisine. Geofabrik à développé une solution à ce problème : le
 SDS (separate data store)

 http://lists.openstreetmap.org/pipermail/josm-dev/2012-March/006099.html

 Je trouve toutefois dommage de séparer cette information de OSM. Tout
 n'est pas déterminable (facilement) depuis la base OSM, comme
 l'encombrement aux heures de pointes...


 Si on avait les trace GPS de tous le monde, on pourrait calculer (comme tom
 tom  co) la vitesse moyenne sur un troncon en fonction du jour et de
 l'heure et affiner les calculs d'itineraire, mais ca doit etre une info mise
 dans une autre base, ca n'a pas sa place dans OSM.


 Le 18 avril 2012 10:59, Mikaël Cordon mikael.cor...@gmail.com a écrit :

 un logiciel pourrait
 se baser sur d'avantages de critères objectifs comme le type de
 surface, l'inclinaison, les courbures de la route...


 +1


 +1




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

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

Re: [OSM-dev-fr] Question bdd Nominatim

[Philippe Verdy]

C'est encore pire: le centroïde ne devrait être utlisé qu'en dernier recours:
- en premier on test l'inclusion dans les frontières (si elles sont fermées)
- en second on regarde si entre deux régions il y a un way qui les
sépare dans au moins une région pour fermer la région non fermée
voisine (de même niveau)
- en trois on utilise l'admin_center quand il est présent (peu importe
alors qu'on puisse ou non vérifier qu'il est dans la zone non fermée)
- en dernier on calcule l'enveloppe convexe des noeuds, pour former un
polygone dont on calcule un centroïde facilement pour ensuite
rechercher la plus petite distance entre le noeud cherché et les
centroïdes des enveloppes convexes des régions candidates (mais si une
des deux régions est fermée, il faut l'exclure du résultat si elle ne
contient pas ce noeud)

Nominatim va donc continuer à se tromper souvent...

Le 3 avril 2012 12:34, Pieren pier...@gmail.com a écrit :
 2012/4/3 Vincent de Chateau-Thierry v...@laposte.net:

 Pour un geocodage à la ville (mais pas à la rue ni au n° de rue), tu as 
 essentiellement
 besoin des nodes place et des relations boundary=administrative. Donc tu 
 peux
 remplacer dans ta syntaxe initiale l'étape --tf accept-ways par celle en 
 --tf accept-
 relations avec (surtout !) les dépendances --used-way et --used-node.
 En revanche il faut la cumuler avec --tf accept-nodes place=* que tu avais 
 déjà, pour
 tenter de ne rien perdre en effet.

 vincent

 Un petit coucou d'un nouvel inscrit sur cette liste et aussi pour
 signaler ce changement récent dans Nominatim:
 https://github.com/twain47/Nominatim/commit/e62e75f1a7e5a94f335e631ee9ce4dc9fedd19e7
 qui tient compte du role admin_centre (uniquement si la recherche avec
 le centroide a échoué). Est-ce juste une coincidence que cela arrive
 en même que cette discussion ?

 Pieren

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

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

Re: [OSM-dev-fr] Générer des fichiers SVG par script...

[Philippe Verdy]

Même sans aller jusqu'à la production d'un SVG complet, on peut se
contenter de générer les chaînes à mettre en valeur de l'attribut d
d'un élément path SVG. Ces chaines peuvent être arbitrairement
longues toutefois, mais la base OSM suggère de limiter ses way à
1000 nœuds, une limite suffisante pour la plupart des moteurs SVG
(même si certains ne sont pas réellement limités et acceptent des
longueurs réellement très longues)

un microformat SVG réduit au strict minimum donc, ne contenant ni
style, juste la déclaration du bounding-box pour régler ses views, et
autant d'éléments path que nécessaires, qui peuvent avoir un id
identique à l'id interne de la base (préfixé de way-), inclus dans
un élément defs, puis des groupes g reprenant les relations (id
identique à la base OSM préfixé de rel-) dont le contenu serait les
path use=way-*/.

A charge ensuite des auteurs de cartes d'ajouter les styles qu'ils
veulent dans les SVG. Les SVG est assez volatile pour permettre de
telles représentations.

Mais certains voudront aussi les libellés (il faudrait un filtre par
langue). D'une façon générale, plus on mettra d'options et plus on se
retrouvera à faire ce que font déjà les moteurs de rendus de tuiles
(même si ici ce seront des tuiles de taille variable, et au format SVG
et non converti en raster PNG ou JPG).

Le 5 mars 2012 16:52, Christian Quest cqu...@openstreetmap.fr a écrit :
 Afin de favoriser la réutilisation, je voudrais mettre en place des
 exports SVG à thème si possible automatiques.

 Par exemple, le découpage des régions ou départements, voire le
 découpage par commune pour chaque département.

 Pourquoi du SVG ? Tout simplement pour que des graphistes, souvent
 demandeurs de fonds de carte puissent s'en servir le plus facilement
 possible.

 J'ai un peu joué avec ST_AsSVG pour sortir des path à la sauce SVG, et
 je me suis bricolé un fichier SVG pour voir leur format.

 Est-ce que vous avez déjà fait ce genre de choses ?
 --
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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

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

Re: [OSM-dev-fr] Générer des fichiers SVG par script...

[Philippe Verdy]

Le 5 mars 2012 18:05, Christian Quest cqu...@openstreetmap.fr a écrit :
 Pour info, tu peux alléger le SVG de 3 façons:
 - faire des arrondis sur les coordonnées

Attention aux arrondis, ils doivent être conformes à la simplification
effectuée qui dépend du niveau de zoom calculé

 - utiliser des déplacements relatifs dans les path

Il peut être plus pratique, dans le cadre d'une réutilisation, de
continuer à utiliser des coordonnées absolues, à condition de déplacer
seulement l'origine. Ca simplifie le travail ultérieur de
réutilisation des cartes au cas où on voudrait les fusionner ou les
rescinder. Car on a rarement besoin des 7 chiffres de précision sur
une même carte qui ne s'affichera en fin de compte que dans un
rectangle d'au mieux 2000x1000 pixels sur les meilleurs écrans. La
précision supplémentaire ne servant que si on zoome le SVG pour voir
certains détails qui autrement n'occupent qu'un seul même pixel.

 - regrouper les path similaire (ça évite de répéter path fill stroke
 stroke-width qui représente pas loin de 50% du SVG généré).

Là tu es optimiste. En fait les SVG que je manipule ont près de 90% de
la taille occupée par la définition des paths, même en cas de
réutilisation par référence (j'utilise une extension SVG permettant de
faire une référence à un même chemin dont on a inverse la direction si
besoin, mais tous les moteurs SVG ne le permettent pas, et si on veut
un SVG compatible TinySVG, il n'y a pas d'autre choix que de
réénumérer les chemins partagés pour des polygones séparés mais
jointifs).

Et je ne me contente pas de ce que produisent les outils, en fin de
compte je me retrouve à éditer les SVG dans un éditeur de texte, où
des tas de simplifications sont possibles aussi (en général sur les
styles, surtout si la carte a été manipulée par un éditeur de SVG
générique comme Sodipodi). Cet édition manuelle réduit la taille
souvent de plus de la moitié, parfois beaucoup plus, sans même rien
faire perdre à leur précision, et cela simplifie aussi énormément leur
réutilisation (par exemple pour produire des séries de cartes dérivées
en modifiant seulement quelques règles de style CSS !

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

Re: [OSM-dev-fr] Générer des fichiers SVG par script...

[Philippe Verdy]

Le 5 mars 2012 21:12, Marc Sibert m...@sibert.fr a écrit :
 Je pense que l'on peut gagner en factorisant les types : il doit bien y
 avoir une sorte de CSS du SVG (pas de souvenirs), sinon le SVG qui est du
 XML qui est du texte est éligible à la compression de répétition de
 séquences (algo LZW) et surement un bon client (50% et au-delà).

Note tout de même la limite de portée de la compression de type LZW :
si les chemins répétés sont assez éloignées, il seront sortis depuis
longtemps du dictionnaire LZW et la répétition ne sera pas détectée.
(les tailles de dictionnaires de recherche de répétitions sont
limitées pour ne pas avoir à assigner trop de bits pour chaque
nouvelle entité représentée par un même code, et il n'est pas
envisageable d'avoir un dictionnaire de compression ou de
décompression qui fasse la taille de n'importe quel fichier dépassant
plus de 64 Ko : on a toujours une fenêtre limitative pour ce type de
recherches faite par le compresseur, pour des raisons de performance,
et pour le stockage du dictionnaire dans le décompresseur, qui lui
aussi ne va pas garder tout le texte décompressé nécessairement en
mémoire pour retrouver la séquence à répéter).

La compression reprendra donc dans l'état du dictionnaire au moment où
chaque chaîne commence, et en gros chaque répétition aura grosso-modo
la même taille compressée.

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

Re: [OSM-dev-fr] Re : Comparaison cours d'eau OSM/Sandre

[Philippe Verdy]

Oui, et il m'arrive aussi de signaler des erreurs de Google Maps, ce
n'est pas pour autant que je vais le citer comme référence (étant
donné que cette source n'est pas libre) même si je n'utilise pas ses
données.

Ce n'est pas de la paranoia, mais la licence OSM porte moins les
obligations et droits relatifs au droit d'auteur et au copyright, que
sur le droit relatif aux bases de données en tant qu'ensemble
recueillant un ensemble de références.

Pour rappel, je citerai le cas de WikiQuotes, qui se contentait de
reproduire de courtes citations, individuellement légales, mais
devenant illégale du fait de leur recensement exhaustif. La
conséquence a été l'effacement intégral de la version française de
Wikiquotes qui n'a pu redémarrer qu'en repartant de zéro. Un cas à ne
pas reproduire ici sans mettre en danger le projet au bout d'un
certain temps.

C'est bien du recensement exhaustif de références à des sources non
libres dont je parle. Un recensement exhaustif qu'OSM cherche à faire
en incluant les références Sandre qui sont couvertes par une licence
CC-BY-NC et d'autres clauses couvertes par le droit français relatif
aux bases de données (et non celles relatives au seul droit d'auteur).

Le 19 février 2012 13:42, Christian Quest cqu...@openstreetmap.fr a écrit :
 Le 19 février 2012 11:40, THEVENON Julien julien_theve...@yahoo.fr a écrit :
 De : Philippe Verdy verd...@wanadoo.fr
 Je me pose la question de la compatibilité de la licence CC-BY-NC
 utilisée par Sandre, avec OSM.

 Il me semble que c est bon parce qu on utilise pas Sandre pour mapper. On
 rajoute juste la ref Sandre sur les donnees OSM

 Julien

 Effectivement, je pense qu'il ne faut pas tomber dans la paranoïa.

 Nous ne reproduisons aucune donnée cartographique venant du Sandre à
 part le numéro de référence qui permet de faire des contrôle et de
 savoir de quel cours d'eau on parle. Le Sandre profite aussi de notre
 travail... je leur ai signalé plusieurs erreurs dans leur base.

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

Re: [OSM-dev-fr] Comparaison cours d'eau OSM/Sandre

[Philippe Verdy]

Concernant la Vilaine (et l'Ille), il y a le cas particulier de sa
section canalisée, qui constitue aussi un cours d'eau navigable
continu mais qui emprunte le même cours d'eau naturel (pour s'en
écarter parfois à l'occasion du franchissement d'une écluse construite
à côté dans ce qui serait un side_stream pour le fleuve, mais pas
pour le canal... tandis que le cours d'eau naturel franchit, lui un
seuil, ou alors son cours principal est dédié dans un bras artificiel
non navigable).

Comment Sandre classe-t-il ces canaux, particulièrement ceux qui
empruntent les cours de plusieurs fleuves ou rivières ? Le but est-il
de cartographier les bassins versants et leur alimentation en eau,
auquel cas c'est le cours naturel qu'il faudrait privilégier. Mais
alors où seront classés les canaux ? Comment vérifier leur continuité
et la cohérence du réseau navigable (ou le réseau de transport d'eau
construit par l'homme) , qui ont leur propre nom qui se superpose par
endroit au nom des cours d'eau naturels empruntés ?

Il me semble que Sandre veut construire des références pour les deux
types de réseaux, et du coup doit casser le modèle de ses propres
références, qui ne forme plus un modèle hiérarchique (celui des cours
d'eaux naturels et leurs affluents), mais contient une modélisation
sur un modèle davantage maillé de façon non hiérarchique (celui des
réseaux navigables qui inclue évidemment les écluses pour fonctionner)

Pourquoi OSM devrait privilégier un des deux modèles plutôt qu'un
autre ? Et dans ce cas, on ne s'en sortira pas sans relation, car le
modèle purement géométrique ne permet absolument pas de résoudre ces
cas (c'est totalement impossible de faire les distinctions nécessaires
si on veut aussi modéliser le réseau maillé navigable, et concernant
les bras, même sur le réseau naturel, il est impossible de déterminer
à priori un bras naturel privilégié par rapport à un autre, comme les
deux bras de a Loire qui traversent Nantes et ont chacun leur nom).

Alors en attendant de trouver quelquechose de solide, les relations
avec les main_stream, side_stream et tributary sont logiquement
corrects et devraient permettre d'avancer, même si Sandre a ses
propres références qui parfois ne suivent pas ce modèle. Et ce système
permet encore de modéliser les deux types de réseaux (naturel, plus ou
moins hiérarchique malgré ses bras, et articifiel des canaux, non
hiérarchique mais maillé).

Le 17 février 2012 17:03, Ab_fab gamma@gmail.com a écrit :
 Tout est en ordre pour les points que j'ai soumis hier.
 Nickel, merci !

 Et sinon, je suis du même avis que Christian dans le message initial de ce
 fil, à savoir écarter les membres avec le rôle side_stream du bilan

 Par contre, à un moment, il faut choisir et désigner un membre main_stream !
 La relation de la Seine est complète, mais au niveau de l'île Saint Louis,
 on a deux membres avec le rôle side_stream
 http://www.openstreetmap.org/browse/way/150372226
 http://www.openstreetmap.org/browse/way/99555151

 Pas JOSM sous la main à l'instant, mais bien l'intention de passer celui
 passant entre l'île Saint-Louis et l'île de la cité en bras principal.
 Est-ce que cela suffisant pour faire grimper le pourcentage près des 100% ?

 hmm, je vois que c'est la stratégie suivie par Christian sur la Garonne, on
 dirait que ça paie pas
 http://www.openstreetmap.org/browse/way/4612199
 http://www.openstreetmap.org/browse/way/4612201

 Deux exemples qui font perdre 734 km :-)

 Ok, ce ne sont que quelques stats, mais ce qui m'embête le plus, c'est de
 ne pas pouvoir identifier plus rapidement où se trouvent les cours d'eau
 vraiment morcelés.

 Le 16 février 2012 15:03, sly (sylvain letuffe) li...@letuffe.org a écrit
 :


 hop, je te laisse regarder le résultat de demain et me dire si tu vois
 toujours un soucis.

 --
 ab_fab
 Il n'y a pas de pas perdus

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


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

Re: [OSM-dev-fr] Comparaison cours d'eau OSM/Sandre

[Philippe Verdy]

L'ennui c'est que ces canaux sont trop courts. Si je prend par exemple
le Canal d'Ille-et-Rance, il va bien jusqu'à Rennes (et même au delà)
en suivant le cours de l'Ille (puis celui de la Vilaine dans sa partie
canalisée) et celui de la Rance.

Les canaux se superposent donc avec les cours naturels, et échappent à
la notion d'affluents (rôle tributary) des cours naturels.

Il arrive même qu'un cours naturel, une fois canalisé, voit ses eaux
circuler dans le sens contraire du cours naturel, de sorte que le sens
du main_stream sur le cours d'eau peut changer de direction sur un
cours naturel, à l'emplacement d'un barrage de séparation alimenté
d'un côté ou l'autre par des petits affluents ou des dérivations,
fossés ou canalisations artificiels.

Cependant je pense que la direction naturelle du cours doit être
conservée pour le cours d'eau naturel, même si ce n'est plus le sens
dans la section canalisée (qui elle changera souvent de direction, ce
qui a un sens si on pense que les différences de hauteur sont
compensées par des écluses ou ascenseurs à bateaux).

Mais dans tous les cas, les relations de rivières ou de canaux (qui
peuvent avoir des sections en commun) doivent former une ligne
ininterrompue, ou alors c'est un canal virtuel (plutôt une route de
navigation) regroupant plusieurs canaux distincts devant avoir chacun
leur nom et leur code, et relié par des sections de rivières ou
fleuves navigables mais non canalisées (parfois seulement avec un
chenal central, pas toujours suffisamment en eau pour faire passer
n'importe quelle péniche ou bateau de plaisance).

Le 18 février 2012 17:36, Ab_fab gamma@gmail.com a écrit :
 Les canaux ont leur propre code SANDRE : le tableau suivant en recense une
 quarantaine (environ)
 http://suivi.openstreetmap.fr/cours-eau/comparaison-sandre.html

 Le code SANDRE appliqué sur la relation est celui représentant tout ce cours
 d'eau et appelé entité géographique.
 Mais les tronçons élémentaires portent égaglement un code qui n'est pas
 (encore) à l'ordre du jour dans OSM
 Les détails se trouvent ici
 http://sandre.eaufrance.fr/Point-sur-le-code-hydrographique


 Le 18 février 2012 14:39, Philippe Verdy verd...@wanadoo.fr a écrit :

 Concernant la Vilaine (et l'Ille), il y a le cas particulier de sa
 section canalisée, qui constitue aussi un cours d'eau navigable
 continu mais qui emprunte le même cours d'eau naturel (pour s'en
 écarter parfois à l'occasion du franchissement d'une écluse construite
 à côté dans ce qui serait un side_stream pour le fleuve, mais pas
 pour le canal... tandis que le cours d'eau naturel franchit, lui un
 seuil, ou alors son cours principal est dédié dans un bras artificiel
 non navigable).

 Comment Sandre classe-t-il ces canaux, particulièrement ceux qui
 empruntent les cours de plusieurs fleuves ou rivières ? Le but est-il
 de cartographier les bassins versants et leur alimentation en eau,
 auquel cas c'est le cours naturel qu'il faudrait privilégier. Mais
 alors où seront classés les canaux ? Comment vérifier leur continuité
 et la cohérence du réseau navigable (ou le réseau de transport d'eau
 construit par l'homme) , qui ont leur propre nom qui se superpose par
 endroit au nom des cours d'eau naturels empruntés ?

 Il me semble que Sandre veut construire des références pour les deux
 types de réseaux, et du coup doit casser le modèle de ses propres
 références, qui ne forme plus un modèle hiérarchique (celui des cours
 d'eaux naturels et leurs affluents), mais contient une modélisation
 sur un modèle davantage maillé de façon non hiérarchique (celui des
 réseaux navigables qui inclue évidemment les écluses pour fonctionner)

 Pourquoi OSM devrait privilégier un des deux modèles plutôt qu'un
 autre ? Et dans ce cas, on ne s'en sortira pas sans relation, car le
 modèle purement géométrique ne permet absolument pas de résoudre ces
 cas (c'est totalement impossible de faire les distinctions nécessaires
 si on veut aussi modéliser le réseau maillé navigable, et concernant
 les bras, même sur le réseau naturel, il est impossible de déterminer
 à priori un bras naturel privilégié par rapport à un autre, comme les
 deux bras de a Loire qui traversent Nantes et ont chacun leur nom).

 Alors en attendant de trouver quelquechose de solide, les relations
 avec les main_stream, side_stream et tributary sont logiquement
 corrects et devraient permettre d'avancer, même si Sandre a ses
 propres références qui parfois ne suivent pas ce modèle. Et ce système
 permet encore de modéliser les deux types de réseaux (naturel, plus ou
 moins hiérarchique malgré ses bras, et articifiel des canaux, non
 hiérarchique mais maillé).

 Le 17 février 2012 17:03, Ab_fab gamma@gmail.com a écrit :
  Tout est en ordre pour les points que j'ai soumis hier.
  Nickel, merci !
 
  Et sinon, je suis du même avis que Christian dans le message initial de
  ce
  fil, à savoir écarter les membres avec le rôle side_stream du bilan
 
  Par contre, à un moment, il faut

Re: [OSM-dev-fr] Comparaison cours d'eau OSM/Sandre

[Philippe Verdy]

Je me pose la question de la compatibilité de la licence CC-BY-NC
utilisée par Sandre, avec OSM.

La restriction non commerciale ne me semble pas libre au sens voulu
par ODdbl dans sa base de données (de même que OSM est en cours
d'abandon de la licence CC-BY qui pourtant n'impose pas la restriction
non commercial).

A quel titre avons-nous alors le droit de mentionner les références
Sandre dans la base OSM ? puisque OSM permet les utilisations
commerciales sans autre forme de licence ?

Si ces licences sont incompatibles, l'association des références OSM
(numéros de relation) et des références Sandre devra se faire dans une
base de comparaison séparée, fournie de façon compatible avec la
licence CC-BY-NC, et pourra être affichée sur un rendu de carte à
condition que ce rendu mentionne les deux licences applicables à
chaque partie (qu'on doit pouvoir isoler en couches visibles et
masquables séparément.

Le 18 février 2012 17:36, Ab_fab gamma@gmail.com a écrit :
 Les canaux ont leur propre code SANDRE : le tableau suivant en recense une
 quarantaine (environ)
 http://suivi.openstreetmap.fr/cours-eau/comparaison-sandre.html

 Le code SANDRE appliqué sur la relation est celui représentant tout ce cours
 d'eau et appelé entité géographique.
 Mais les tronçons élémentaires portent égaglement un code qui n'est pas
 (encore) à l'ordre du jour dans OSM
 Les détails se trouvent ici
 http://sandre.eaufrance.fr/Point-sur-le-code-hydrographique


 Le 18 février 2012 14:39, Philippe Verdy verd...@wanadoo.fr a écrit :

 Concernant la Vilaine (et l'Ille), il y a le cas particulier de sa
 section canalisée, qui constitue aussi un cours d'eau navigable
 continu mais qui emprunte le même cours d'eau naturel (pour s'en
 écarter parfois à l'occasion du franchissement d'une écluse construite
 à côté dans ce qui serait un side_stream pour le fleuve, mais pas
 pour le canal... tandis que le cours d'eau naturel franchit, lui un
 seuil, ou alors son cours principal est dédié dans un bras artificiel
 non navigable).

 Comment Sandre classe-t-il ces canaux, particulièrement ceux qui
 empruntent les cours de plusieurs fleuves ou rivières ? Le but est-il
 de cartographier les bassins versants et leur alimentation en eau,
 auquel cas c'est le cours naturel qu'il faudrait privilégier. Mais
 alors où seront classés les canaux ? Comment vérifier leur continuité
 et la cohérence du réseau navigable (ou le réseau de transport d'eau
 construit par l'homme) , qui ont leur propre nom qui se superpose par
 endroit au nom des cours d'eau naturels empruntés ?

 Il me semble que Sandre veut construire des références pour les deux
 types de réseaux, et du coup doit casser le modèle de ses propres
 références, qui ne forme plus un modèle hiérarchique (celui des cours
 d'eaux naturels et leurs affluents), mais contient une modélisation
 sur un modèle davantage maillé de façon non hiérarchique (celui des
 réseaux navigables qui inclue évidemment les écluses pour fonctionner)

 Pourquoi OSM devrait privilégier un des deux modèles plutôt qu'un
 autre ? Et dans ce cas, on ne s'en sortira pas sans relation, car le
 modèle purement géométrique ne permet absolument pas de résoudre ces
 cas (c'est totalement impossible de faire les distinctions nécessaires
 si on veut aussi modéliser le réseau maillé navigable, et concernant
 les bras, même sur le réseau naturel, il est impossible de déterminer
 à priori un bras naturel privilégié par rapport à un autre, comme les
 deux bras de a Loire qui traversent Nantes et ont chacun leur nom).

 Alors en attendant de trouver quelquechose de solide, les relations
 avec les main_stream, side_stream et tributary sont logiquement
 corrects et devraient permettre d'avancer, même si Sandre a ses
 propres références qui parfois ne suivent pas ce modèle. Et ce système
 permet encore de modéliser les deux types de réseaux (naturel, plus ou
 moins hiérarchique malgré ses bras, et articifiel des canaux, non
 hiérarchique mais maillé).

 Le 17 février 2012 17:03, Ab_fab gamma@gmail.com a écrit :
  Tout est en ordre pour les points que j'ai soumis hier.
  Nickel, merci !
 
  Et sinon, je suis du même avis que Christian dans le message initial de
  ce
  fil, à savoir écarter les membres avec le rôle side_stream du bilan
 
  Par contre, à un moment, il faut choisir et désigner un membre
  main_stream !
  La relation de la Seine est complète, mais au niveau de l'île Saint
  Louis,
  on a deux membres avec le rôle side_stream
  http://www.openstreetmap.org/browse/way/150372226
  http://www.openstreetmap.org/browse/way/99555151
 
  Pas JOSM sous la main à l'instant, mais bien l'intention de passer celui
  passant entre l'île Saint-Louis et l'île de la cité en bras principal.
  Est-ce que cela suffisant pour faire grimper le pourcentage près des
  100% ?
 
  hmm, je vois que c'est la stratégie suivie par Christian sur la Garonne,
  on
  dirait que ça paie pas
  http://www.openstreetmap.org/browse/way/4612199
  http

Re: [OSM-dev-fr] [OSM-talk-fr] Bogue d'Osmose (codage XML invalide provenant du serveur Backend)

[Philippe Verdy]

Le 10 février 2012 12:56, Jocelyn Jaubert jocelyn.jaub...@gmail.com a écrit :
 Bonjour,

 (je redirige sur dev-fr où ça a plus sa place)

 Le 10 février 2012, Philippe Verdy a écrit :

 369               self._write(' %s=%s' % (name, quoteattr(value)))
 378               self._write(' %s=%s' % (name, quoteattr(value)))

 En effet, la fonction Python quoteattr() ne représente pas
 correctement le caractère  qu'il laisse sous cette forme, alors
 qu'il FAUT le réencoder sous la forme amp;

 La fonction quoteattr() est importée depuis le module Python
 sax.saxutils, absent dans les sources GIT d'Osmose. C'est elle qui
 est ici en cause.

 Cette fonction fait parti de la librairie python standard, et sa
 documentation se trouve là:

 http://docs.python.org/library/xml.sax.utils.html

 D'après la doc, quoteattr() échappe bien les   et , donc je ne
 comprends pas le problème.

Tu as une doc à jour, mais pas le module Python à jour qui correspond,
sans doute un module de Python v1. Il y a eu de nombreuses corrections
de sécurité dedans (y compris une correction dans l'ordre de
substitution de , uniquement dans Python 2.1.1, puis ensuite des
tentatives  simplifications du code sans utiliser escape() en
interne... suivi aussitôt d'une anomalie avec une attaque de sécurité
XSS sur un certain nombre de sites.

C'est pour ça que je t'ai fourni des liens vers des versions
correctes. Car je ne sais pas du tout quelle version tu as chargée et
utilisée (depuis quel repository Python ??? Il y en a plein, pas
toujours conformes à l'original ou ne prenant pas en compte les
corrections pourtant approuvées).

 Est-ce que tu pourrais donner un lien sur osmose.openstreetmap.fr qui
 montrerait le problème ?  (avec le permalink en bas à droite)

Oui, mais j'ai corrigé un problème, il n'apparait plus dans Osmose là
où je l'ai vu la première fois.

J'en ai vu ailleurs dans les noms relations de sites géodésiques (dont
les membres sont des noeuds groupés sur une même collection dont la
relation donne une référence commune avec une URL vers le site de
géosésie de l'IGN, ces URL contenant des  puisqu'elles contiennent
des paramètres.

Et j'ai vu ces mêmes URL corrompues par endroit (j'aurais du regarder
l'historique, pour voir que cela venait bien de rawedit).

Si tu n'en voit pas, crée un point avec une erreur de tonomymie dans
JOSM qu'Osmose signalera (par exemple donne un nom comme BOUTIQUE
CA, Osmose ralera sur les majuscules, ouvre le noeud signalé. Tu
verras que même sans rien toucher, il refusera la modification. Mets
une URL en valeur contenant des paramètres de requêtes: dans JOSM il
n'est pas nécessaire et on ne doit rien substituer à l'écran, JOSM
fait correctement les encodages et décodage URL quand il utilise l'API
d'OSM (mais pas Osmose aussi bien dans ses URLs insérées dans le
Frontend HTML/CSS/JS que dans le code Javascript qui communique en XML
avec le Backend d'Osmose, qui vérifie la requête puis renvoie vers
l'API d'OSM).

  Deuxième problème (lié au premier) ===

 Enfin je note que le code Javascript envoyé au client utilise le
 constructeur: new XMLHttpRequest(), mais sans préciser le jeu de
 caractères qui sera utilisé pour dialoguer avec le serveur :

 Le fait que la page html et le fichier .js soient encodées en UTF-8 via
 les headers HTTP ne suffit pas à informer le navigateur ?


 Et est-ce que tu peux donner un exemple d'objet corrompu sur OSM ?

Si tu charges une zones assez grande dans JOSM, il suffit de regarder
les valeurs chargées énumérées dans la liste de valeurs existantes
d'un attribut comme source. Tu y verras des tas de caractères ?
noirs là où auraient du rester des caractères accentués, visiblement
édités sur un navigateur Macintosh; sélectionne cette valeur dans la
liste, uniquement pour la copier dans le presse-papier. Puis recherche
les objets contenant cette valeur incorrecte.

Tu vas en trouver beaucoup.

Ensuite regarde les historiques: tu verras qu'ils proviennent de rawedit.

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