[OSM-talk-fr] JOSM en touche "enter"

[Philippe Verdy]

Le 8 juin 2012 10:44, Vincent de Chateau-Thierry <vdct at laposte.net> a écrit :
> Bonjour,
>
>> De : "Philippe Verdy"
>>
>> Toutefois on pourrait aussi imaginer pour cette dernière utilisation
>> un plugin capable de traiter une source CSV ou tabulée
>>
>
> Sur ce point, voir :
> http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData
>
> qui fait déjà ça.

Pas vraiment encore... Les éléments nécessaires aux recherches et
permettant de croiser les fichiers de données pour les associer aux
éléments de géométrie stockés dans OSM ne marchent pas du tout. Faute
de cohérence des données (davantage d'ailleurs qu'à cause des tracés
encore absents, pour lequelq je ne comprend toujours pas pourquoi on
n'a pas au minimum créé une relation contenant un nœud, même si on n'a
pas toutes les frontières, ce qui permet cependant des fusions
ultérieures, tout en assurant la complétude des données importées).

Ce projet devrait s'assurer :
- de rechercher les relations manquantes, celles en doublon (noeuds à
fusionner quand ils représentent en fait la même entité, mais n'ont
pas été trouvés par un import précédent car il manquait certains
attributs permettant de les trouver facilement même en cas de
géométrie incomplète ou cassée), et d'assurer une couverture à 100 %
ave toutes les relations nécessaires.

- de permettre ensuite les rapprochements faciles par des clés de
recherche qui donnent exactement 100% de couverture (sans trou et sans
doublon)

- de rationnaliser les tags utilisés, y compris des tags ajoutés par
soucis de compatibilité entre divers outils de vérification, même si
dans un premier survol cela peut paraître redondant (il y a encore
trop de façon de voir la modélisation).

- de simplifier et accélérer les recherches dans la base OSM, avec des
requêtes moins volumineuses et moins complexes à traiter
qu'actuellement (voir mon dernier message sur les subareas que TOUS
les pays ont adopté — sauf pour la France où vous souhaitez encore
faire cavaliers seuls —, ce qui a pourtant énormément stabilisé par la
suite leur géométrie et facilité la maintenance en évitant des tas
d'oublis et consolidé leur schéma pour toutes sortes d'usages avec
beaucoup moins d'erreurs et même beaucoup moins de réparations
nécessaires, car la situation actuelle demande de charger trop de
données que le serveur ne permet même pas de toujours obtenir: erreurs
500 du serveur, requêtes simples qui nécessitent de charger sans arrêt
des centaines de milliers de points là où il n'y a eu que des modifs
très locales, conflits d'édition augmentés et mal réparés...)

- d'automatiser les mises à jour de certaines données datées (par
exemple : données démographiques).

- de faciliter des changements au schéma initial par des
reclassifications automatisables

- finalement même de réduire nombre de redondances qui ne sont plus
nécessaires (par exemple les traductions, les noms des rues et villes
rapportés aux relations, les classements de types de routes : aller
davantage vers un mode relationnel, là où il marche déjà très bien
dans tous les outils de base (Nominatim, Mapnik, Mapquest, outils de
vérification, outils produisant des cartes imprimés, rapports
statistiques et d'avancement des projets ; en ne gardant les coûteuses
requêtes géométriques que pour les recherches globales des éléments
selon leur distance quand ils sont au départ non corrélés ensemble par
un lien relationnel fort : tous les systèmes GIS le font, pas encore
OSM et surtout pas en France !).

Avoir une intégration de données sans autoriser les liens relationnels
est une aberration. Très coûteuse en plus en temps homme comme en
ressources machine/réseau ! C'est même totalement anticollaboratif,
car les volumes à traiter empêchent trop de monde de pouvoir
participer sans faire trop d'erreurs ; la moindre modif locale mineure
représente un travail titanesque pour ***trop*** de monde, qui n'a pas
forcément la bande passante réseau ni la puissance nécessaire sur son
PC (oui avec le système actuel, machnie puissante nécessaire : OS 64
bits obligatoire, au moins 8 Go de RAM, plutôt 12..., au moins 4
coeurs CPU, processeur rapide pour gérer des centaines de milliers ou
des millions de points dans un même fichier OSM et encore pouvoir
faire glisser les cartes dans un édteur comme JOSM.

Rationnalisez !