Re: [OSM-dev-fr] Réflexion autour des fichiers diff OSM
+1: les diffs actuels ne sont pas à supprimer, mais à compléter d'où l'idée de parle d'updates et plus de diff. Oui, pardon, j'avais bien compris que tu ne parlais pas de leur suppression, je me suis mal exprimé. La question que je me posais était plutôt qui devrait être en charge de cette génération et tu semblais (?) suggérer que la fondation OSM s'en charge. Bien que s'ils le proposaient, j'en serais ravis, je me demande s'ils n'ont pas déjà assez de boulot et que c'est quelque chose que quelqu'un d'autre (asso osm-fr par exemple) puisse prendre en charge. Pour ce qui est de la suite, je pense que c'est la réalisation qu'il faudrait entamer, et plutôt que dans le vent, appliqué à un besoin réél. Mais là, j'entrevois pas mal de boulot... -- 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
Re: [OSM-dev-fr] Réflexion autour des fichiers diff OSM
Le 8 août 2012 15:44, sly (sylvain letuffe) li...@letuffe.org a écrit : +1: les diffs actuels ne sont pas à supprimer, mais à compléter d'où l'idée de parle d'updates et plus de diff. Oui, pardon, j'avais bien compris que tu ne parlais pas de leur suppression, je me suis mal exprimé. La question que je me posais était plutôt qui devrait être en charge de cette génération et tu semblais (?) suggérer que la fondation OSM s'en charge. Bien que s'ils le proposaient, j'en serais ravis, je me demande s'ils n'ont pas déjà assez de boulot et que c'est quelque chose que quelqu'un d'autre (asso osm-fr par exemple) puisse prendre en charge. La frontière entre fondation ou pas est pour moi relativement artificielle. Prends l'exemple des extraits par pays de geofabrik. Ils sont très utilisés bien que ça ne soit pas des machines de la fondation qui les génèrent. Si ces fichiers d'updates sont très utilisés, la fondation pourra pérenniser si besoin leur génération. Pour ce qui est de la suite, je pense que c'est la réalisation qu'il faudrait entamer, et plutôt que dans le vent, appliqué à un besoin réél. Mais là, j'entrevois pas mal de boulot... Je n'ai pas encore tellement réfléchit à l'implémentation, mais je pense qu'il doit s'appuyer sur un schéma osmosis modifié. Pour avoir du grain à moudre et d'autres visions sur ce qui se fait, la dernière version de l'overpass API intègre un mécanisme proche de ce dont on parle, mais pas pour les diffs (uniquement pour l'import initial) : http://wiki.openstreetmap.org/wiki/Overpass_API/versions Son idée, pas idiote, est que toute instance de l'overpass API peut être clonée afin de re-construire une base à jour à l'identique. Je ne connais pas les entrailles précisément, mais le résultat annoncé est de ~4/8 heures pour un import de la base monde, là où, en partant d'un fichier planet.osm il faut ~20 heures Cela permet donc une topologie en multi-pyramide où chaque nouvelle instance peut se greffer sur une existante et gagner du temps pour la construction initiale. En revanche, ce mécanisme n'existe pas (encore) pour les diffs Et à mon avis, c'est du super spécifique à ce format, je doute qu'il est voulu à la base un format générique J'ai vu cette possibilité en voulant installer une overpass API. Il me semble que cela consiste essentiellement à copier un snapshot des fichiers d'une overpass à une autre, non ? Il y a un mécanisme plus perfectionné que ça ? -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Réflexion autour des fichiers diff OSM
J'ai vu cette possibilité en voulant installer une overpass API. Il me semble que cela consiste essentiellement à copier un snapshot des fichiers d'une overpass à une autre, non ? Il y a un mécanisme plus perfectionné que ça ? Je viens de vérifier et en fait, ça consiste juste à ça en effet, toutefois, il y'a un appel prévu pour demander à l'overpass source de préparer ces fichiers (ce n'est pas fonctionnel par défaut sur une instance neuve, juste celle de http://overpass-api.de/) qui s'occupe alors d'en faire une copie, de les compresser et de les rendre disponible à un téléchargement. C'est un peu brut de script comme on pourrait par exemple récupérer un dump SQL d'une base osm2pgsql pour la dupliquer plus rapidement. Mais l'idée reste celle-ci : ne pas toujours repartir du fichier planet.osm (et ça à aussi l'avantage d'exister) -- 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
Re: [OSM-dev] [GSoC] Improvements to Vespucci
Am 2012-08-01 09:41, schrieb Peter Wendorff: I assume it's possible to apply several presets to the same object, each adding it's tags Yes. You can apply any number of presets. Combining this with what you describe about Vespucci, I wonder, if Vespucci supports this, too in the autocomplete feature - that more than one preset is used for the autocomplete menus. Currently, no - only the last preset is used, and only immediately after it was applied. Once you close the tag editor, it forgets. However, you can add one preset, add all tags you want, then add the next preset and repeat. I am afraid making it more complex would make it confusing for the user (When/why do tags show on top of autocomplete?) Second question in the same direction: If I add addr:street, and that's part of an address preset - wouldn't it be nice even if I don't use prefix to get the common tag combination as suggested by the prefix description in the autocomplete feature? I consider using the best matching preset if none was manually applied. However, this could again be more confusing than helpful. Kind regards, Jan ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] Broken style file table
Hi, I seem to have broken the JOSM wiki and need the help of an admin to fix it. I made a new JOSM mapcss style file called 'Surface - Data Entry' which is a paint style designed to aid in entering surface tags on roads from aerial imagery. I created a subpage of the 'Styles' page on the wiki as per the directions for getting it included in the JOSM preferences window. The entry shows up now, however when you try to enable the paint style you end up getting a different style which is just called 'Surface'. This happens because of the spaces in the URL which end up truncating the URL so that it ends at Surfaces, instead of continuing on to Surfaces - Data Entry. I tried changing the URL in the actual mapcss stylesheet at the following link, but that doesn't seem to have fixed the problem: http://josm.openstreetmap.de/wiki/Styles/Surface%20-%20Data%20Entry When you look at the corresponding row in the table on http://josm.openstreetmap.de/wiki/Styles you will see that the row for my stylesheet is all garbled up, breaking the table formatting. It looks like this table is being autogenerated by a python macro called 'Styles' which prevents me from manually just fixing the url in that table. I would appreciate help getting this issue resolved as quickly as possible as anyone who currently tries to use my stylesheet will instead end up getting the other user's stylesheet of a similar name, causing much confusion. I have tried my best to fix this issue myself but cannot, due to not having any admin privileges on the wiki or the trac server. I think in order to fix the problem, either the python macro will need to be tweaked to properly expand spaces in URL's into %20 symbols, or the page where my stylesheet is should be moved to a new name, without the spaces (probably just replace the spaces with underscores). As far as I know either of these fixes will require a JOSM admin to do. Manually changing the URL in the JOSM preferences window to include the %20 symbols does fix the issue, so as long as the python macro properly puts these in the problem should be solved, both for me, and for anyone who uses spaces in their pagename in the future. In a related issue, this stylesheet seems to have uncovered a bug in the mapcss parser that I documented in a ticket here: http://josm.openstreetmap.de/ticket/7935 -AndrewBuck P.S. I sent a version of this message a few minutes ago and it bounced. I think this was because I was not yet subscribed to the mailing list. I subscribed and re-sent the message. Sorry if this double posts as a result of this issue. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Broken style file table
Hey I did rename the page (used underscores instead of whitespaces) but the script still needs to be fixed. Cheers Colliar ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Broken style file table
Am 09.08.2012 00:27, schrieb colliar: Hey I did rename the page (used underscores instead of whitespaces) but the script still needs to be fixed. Sorry, underscores did not work that well but without whitespaces it works for now. ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Broken style file table
Thanks for doing the rename. The name isn't the prettiest, but it will work fine. It is far more important that it actually functions than what the name looks like (which users will never really see anyway). -AndrewBuck On Wed, Aug 8, 2012 at 5:41 PM, colliar colliar4e...@aol.com wrote: Am 09.08.2012 00:27, schrieb colliar: Hey I did rename the page (used underscores instead of whitespaces) but the script still needs to be fixed. Sorry, underscores did not work that well but without whitespaces it works for now. __**_ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.**org/listinfo/josm-devhttp://lists.openstreetmap.org/listinfo/josm-dev ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
