[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) <liste at 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 at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/dev-fr