Re: [OSM-dev-fr] Beta Osmose Leaflet
+1 pour la possibilité de recherche de lieu +1 pour le truc qui s'anime pour faire patienter + pour la sélection des calques, je préfère une action clic sur le bouton layer qui ouvre et ferme plutôt que le survol ( c'est juste une préférence) Test sous linux/chromium (version libre de chrome): - l'animation ne fonctionne pas et les Osmose error n'apparaissent pas Test sous seven/firefox+ie7+chrome: - pour la sélection des erreurs (tout-rien-inverser) : inverser agit sur les calques (pas les layers de base, mais les autres) - l'animation pour patienter ne se voit pas si on sélectionne uniquement le layer 'Osmose error heatmap - permalink : je clique sur permalink = ok dans la barre d'adresse + si je clic sur une catégorie (structurel, tags manquants ...) = clic sur permalink ne fait rien apparaitre dans la barre d'adresse + si je clic sur une catégorie (structurel, tags manquants ...) ET modification d'item = clic sur permalink ne fait pas apparaitre la localisation (lat,lon,zoom) dans la barre d'adresse en tout cas : bravos (oui avec un s) Le dimanche 23 février 2014 à 22:29 +0100, Frédéric Rodrigo a écrit : Bonjour, Nous finalisons une réécriture de l'interface d'Osmose en Leaflet. L'aspect de l'interface reste le même. Juste quelques petites sucreries en plus (géolocalisation navigateur et recherche d'adresses). L'interface doit aussi fonctionner sur mobile. On est preneur de tests et des remontés de problèmes : http://beta.osmose.openstreetmap.fr/fr/map/ Pour l'instant le seul problème connu et sans solution est le select de la gravité qui marche mal sous osx et mobile. Cette beta interagit avec les mêmes données que la version normale, c'est juste l'interface web qui change. Merci d'avance, Frédéric. Note : également merci à Yohan pour ces conseils en javascript. ___ 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
[OSM-dev-fr] Overpass API et Talend
Bonjour, Quelqu'un a déjà testé le traitement d'une requête overpass API dans l'ETL Talend ? Deux composant OsmWayInput / OsmNodesInput le permettent mais sur l'api, non sur overpass. Quelle est la différence entre les deux ? Et existe-t-il un moyen de faire correspondre les sorties (ou trouver une autre solution...) Bonne journée. Eric ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
Le 23 février 2014 21:54, Vincent de Château-Thierry v...@laposte.net a écrit : Le 23/02/2014 10:28, Christian Quest a écrit : Il manque à mon avis un fichier mix entre les points isolés et les points sur façade. En effet, ma façon manuelle de positionner les adresses est la suivante: - si la façade du bâtiment donne sur la rue, je met le point adresse en façade du bâtiment sur un noeud du polygone - si le bâtiment principal ne donne pas sur la rue, je met le point adresse en limite de parcelle J'ai l'impression que je ne suis pas le seul à procéder comme ça et là je suis obligé de passer d'un fichier à l'autre ce qui bien sûr ne fait pas vraiment gagner de temps au final. Cela correspond aussi à ma façon de mapper, je vais essayer de faire quelque chose dans ce sens (mais il me faut un peu de temps, je voudrais essayer d'utiliser l'angle que fait le numéro dessiné sur le cadastre pour déterminer la direction ou projeter le numéro). Le parti pris implicite dans les fichiers, c'est une modélisation homogène au sein d'un même fichier (1 fichier = 1 rue) sachant qu'il y a déjà une combinatoire entre 3 implantations et 2 modélisations. Le risque d'usine à gaz n'est jamais loin... Pour ce qui est de mon code, je crois que j'ai déjà atteint le niveau usine à gaz vu que j'ai du mal à me relire... Si ce fichier mix intermédiaire correspond mieux à ceux que certains attendent peut-être que l'on pourra supprimer la version points tous isolés découpés par rue. Par contre il a un fichier points tous isolés non découpé par rue, un seul gros fichier, qui est actuellement caché, et je me pose la question de le rendre publique. Je m'en sert souvent, non pas pour intégrer, mais pour vérifier une zone déjà mappée, ou quand je ne comprends pas pourquoi le découpage par rue a exclus certains numéros de tel ou telle rue. Je trouve qu'il a une vrais utilité. Je le génère dorénavant avec l'option upload=false pour que JOSM dissuade son envoie directe dans OSM. Que pensez vous de rendre ce fichier accessible à tous ? Ou alors sous condition, comme pour les fichiers eau ? Tyndare. ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
Le 24 février 2014 11:26, Tyndare tynd...@wanadoo.fr a écrit : Le 23 février 2014 21:54, Vincent de Château-Thierry v...@laposte.net a écrit : Le 23/02/2014 10:28, Christian Quest a écrit : Il manque à mon avis un fichier mix entre les points isolés et les points sur façade. En effet, ma façon manuelle de positionner les adresses est la suivante: - si la façade du bâtiment donne sur la rue, je met le point adresse en façade du bâtiment sur un noeud du polygone - si le bâtiment principal ne donne pas sur la rue, je met le point adresse en limite de parcelle J'ai l'impression que je ne suis pas le seul à procéder comme ça et là je suis obligé de passer d'un fichier à l'autre ce qui bien sûr ne fait pas vraiment gagner de temps au final. Cela correspond aussi à ma façon de mapper, je vais essayer de faire quelque chose dans ce sens (mais il me faut un peu de temps, je voudrais essayer d'utiliser l'angle que fait le numéro dessiné sur le cadastre pour déterminer la direction ou projeter le numéro). Ah oui, c'est une info qui peut aider, mais il faut faire attention car il y aura forcément des numéros non orientés vu la disparité dans les données vectorielles du cadastre. Le parti pris implicite dans les fichiers, c'est une modélisation homogène au sein d'un même fichier (1 fichier = 1 rue) sachant qu'il y a déjà une combinatoire entre 3 implantations et 2 modélisations. Le risque d'usine à gaz n'est jamais loin... Pour ce qui est de mon code, je crois que j'ai déjà atteint le niveau usine à gaz vu que j'ai du mal à me relire... Si ce fichier mix intermédiaire correspond mieux à ceux que certains attendent peut-être que l'on pourra supprimer la version points tous isolés découpés par rue. L'idéal serait d'arriver à trouver un consensus sur la modélisation et de ne proposer que des fichiers correspondant à ce consensus histoire d'avoir au final des données homogènes sur toute la France (à défaut de pouvoir homogénéiser sur le monde entier). Par contre il a un fichier points tous isolés non découpé par rue, un seul gros fichier, qui est actuellement caché, et je me pose la question de le rendre publique. Je m'en sert souvent, non pas pour intégrer, mais pour vérifier une zone déjà mappée, ou quand je ne comprends pas pourquoi le découpage par rue a exclus certains numéros de tel ou telle rue. Je trouve qu'il a une vrais utilité. Je le génère dorénavant avec l'option upload=false pour que JOSM dissuade son envoie directe dans OSM. Que pensez vous de rendre ce fichier accessible à tous ? Ou alors sous condition, comme pour les fichiers eau ? Il faut éviter que l'outil d'extraction soit utilisé hors OSM et un tel fichier risquerai d'être trop facilement exploité hors OSM. Il n'en reste pas moins très utile... justement pour créer par exemple une base adresses brute pouvant servir à faire du géocodage (pour des besoins internes OSM). Il ne faut pas oublier les conditions de notre autorisation d'exploiter les données du cadastre: - mention de la source et du millésime, - intégration dans une base composite (donc pas que des données du cadastre) - pas de reproduction intégrale -- Christian Quest - OpenStreetMap France Conférence State Of The Map France du 4 au 6 avril à Parishttp://openstreetmap.fr/sotmfr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
Bonjour, De : Christian Quest L'idéal serait d'arriver à trouver un consensus sur la modélisation et de ne proposer que des fichiers correspondant à ce consensus histoire d'avoir au final des données homogènes sur toute la France (à défaut de pouvoir homogénéiser sur le monde entier). Tout à fait d'accord avec ça. Mais comment parvenir à ce consensus ? Est-ce que, dans un premier temps, on met à dispo tous les parfums de fichiers ( 6 actuellement, bientôt 8 si on attaque la version mixte limites de parcelles / façades) et au bout de 6 mois, avec du recul, on lance un sondage ? Ou bien on constate quel modèle est devenu prépondérant en base ? Ce sont des idées en vrac, je n'ai pas d'avis sur la méthode, mais je partage vraiment la cible, à savoir qu'on définisse sur la France un modèle accepté comme celui qu'on recommande à tout nouveau contributeur sur le sujet. vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
Le lundi 24 février 2014 13:47:31 V de Chateau-Thierry a écrit : Bonjour, De : Christian Quest L'idéal serait d'arriver à trouver un consensus sur la modélisation et de ne proposer que des fichiers correspondant à ce consensus histoire d'avoir au final des données homogènes sur toute la France (à défaut de pouvoir homogénéiser sur le monde entier). Tout à fait d'accord avec ça. Mais comment parvenir à ce consensus ? Est-ce que, dans un premier temps, on met à dispo tous les parfums de fichiers ( 6 actuellement, bientôt 8 si on attaque la version mixte limites de parcelles / façades) et au bout de 6 mois, avec du recul, on lance un sondage ? +1 Je trouve que c'est en se confrontant à la saisie qu'on mesure la diversité des situations, et en testant les différents schémas qu'on évalue leur pertinence. Perso, je n'ai pas encore vraiment saisi beaucoup d'adresses, mais testé les différents schémas, et j'ai beaucoup appris ! :-) Il serait peut-être temps (l'outil me semble prêt) de diffuser sur talk-fr pour avoir d'autres opinions et pouvoir ensuite trouver ce consensus. Bonne baignade -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
Après ma rencontre chez médipost où on a beaucoup parlé d'adresses, je suis arrivé à la conclusion que lorsqu'on parle d'adresse, on ne parle pas tous de la même chose... d'où le problème pour avoir un consensus. Un seul modèle ne peut donc répondre à toutes les facettes de ce que peut être une adresse ou alors il faut que ce soit un modèle extensible. Justement... OSM fonctionne sur ce principe d'extensions. Il faudra sûrement aller plus loin que le modèle actuel pour que tout le monde y trouve son compte. Alors de quoi parle-t-on ? - de parcelles - de bâtiments - de plaques adresse - d'accès depuis la voirie la plus proche - de point plus métier: position de la boite aux lettres, du compteur EDF/eau, des entrées, de la livraison... autre ? Les parcelles ne sont pas dans OSM et on n'a pas de projet à moyen terme pour les intégrer. Les bâtiments... ils peuvent être liés à une ou plusieurs adresses ou l'inverse (plusieurs adresses pour un même bâtiment) Les plaques adresses: c'est un truc un peu virtuel... qui correspond plus ou moins à une entrée (mais j'ai de beaux contre exemple en photo... plaque adresse, mais aucune entrée, juste un poteau de parking !) Les accès: en gros ça donne une position en bord de voirie, c'est peut être le plus universel Les points métiers sont modélisables mais en étendant le modèle actuel. Qu'en dites-vous ? Le 24 février 2014 13:47, V de Chateau-Thierry v...@laposte.net a écrit : Bonjour, De : Christian Quest L'idéal serait d'arriver à trouver un consensus sur la modélisation et de ne proposer que des fichiers correspondant à ce consensus histoire d'avoir au final des données homogènes sur toute la France (à défaut de pouvoir homogénéiser sur le monde entier). Tout à fait d'accord avec ça. Mais comment parvenir à ce consensus ? Est-ce que, dans un premier temps, on met à dispo tous les parfums de fichiers ( 6 actuellement, bientôt 8 si on attaque la version mixte limites de parcelles / façades) et au bout de 6 mois, avec du recul, on lance un sondage ? Ou bien on constate quel modèle est devenu prépondérant en base ? Ce sont des idées en vrac, je n'ai pas d'avis sur la méthode, mais je partage vraiment la cible, à savoir qu'on définisse sur la France un modèle accepté comme celui qu'on recommande à tout nouveau contributeur sur le sujet. vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- Christian Quest - OpenStreetMap France Conférence State Of The Map France du 4 au 6 avril à Parishttp://openstreetmap.fr/sotmfr ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
De : Christian Quest Après ma rencontre chez médipost où on a beaucoup parlé d'adresses, je suis arrivé à la conclusion que lorsqu'on parle d'adresse, on ne parle pas tous de la même chose... d'où le problème pour avoir un consensus. Un seul modèle ne peut donc répondre à toutes les facettes de ce que peut être une adresse ou alors il faut que ce soit un modèle extensible. Justement... OSM fonctionne sur ce principe d'extensions. Il faudra sûrement aller plus loin que le modèle actuel pour que tout le monde y trouve son compte. Alors de quoi parle-t-on ? - de parcelles - de bâtiments - de plaques adresse - d'accès depuis la voirie la plus proche - de point plus métier: position de la boite aux lettres, du compteur EDF/eau, des entrées, de la livraison... autre ? D'accord avec cette pluralité. Dans la liste que tu dresses, un seul élément nous est systématiquement fourni par des sources simples d'accès (cadastre, bing), c'est le bâtiment. D'où ma conviction, déjà exprimée ici dans un fil précédent, que c'est le(s) bâtiment(s) qui doit se faire l'étendard de l'info d'adresse. Une précision cependant : en discutant sur la manière de modéliser, je ne pense quasi pas à ce que chacun voudra faire sur un terrain qu'il peut arpenter en piéton, qu'il peut scruter, affiner, détailler. Chacun chez soi saura mapper les adresses aux petits oignons, par justement la possibilité de positionner les accès piéton et voiture, les portes d'entrée, les boîtes aux lettres, etc. Je discute ici plutôt d'un modèle minimal que chacun serait à même d'appliquer sur des territoires où il contribue sans les connaître, un peu comme il arrive qu'on fasse un import de bâti sur un patelin où on n'a jamais mis les pieds. C'est un mal nécessaire si on veut que l'adresse devienne un matériau utilisable dans OSM car suffisamment répandu. vincent ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Service de pré-intégration d'adresses
2014-02-24 14:14 GMT+01:00 Christian Quest cqu...@openstreetmap.fr: Les parcelles ne sont pas dans OSM et on n'a pas de projet à moyen terme pour les intégrer. Selon moi, adresses postales et parcelles sont deux choses totalement séparées. On fait le mélange lorsqu'on voit les données au travers du prisme DGFiP. Qu'en dites-vous ? Qu'il faut en discuter ailleurs que sur la liste dev-fr... Pieren ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Overpass API et Talend
On lundi 24 février 2014, Eric Pommereau wrote: Bonjour, Hello, Quelqu'un a déjà testé le traitement d'une requête overpass API dans l'ETL Talend ? Deux composant OsmWayInput / OsmNodesInput le permettent Je préfère le dire tout de suite, j'ai rien compris à ces trois phrases, je connais pourtant assez bien l'API 0.6 et l'Overpass API, mais le fait d'introduire des éléments sur un logiciel dont on a jamais entendu parlé sur cette liste n'aide pas à la compréhension de ta question et donc augmente encore la difficulté à y répondre. Habituellement, dans un cas comme ça, je ne répond pas (vu que je ne sais pas/ne comprends pas) mais comme je n'avais rien compris non plus à ton précédent message sur les Contours de communes et arrondissements PLM alors que c'est aussi un sujet que je comprend bien dans osm, je me dis que peut- être tu devrais simplifier la formulation de ton problème, sachant que la thématique à l'air intéressante. Revenons à ce cas concret, je ne sais pas non plus ce qu'est ETL talend, mais si c'est un truc qui appel des données osm par une API il faut voir à quel point il peut être paramétré et customisé (as-tu accès au code ? es-tu développeur de l'outil ? quelles options peuvent être touchées ?) Si tu ne peux pas toucher le code, pas choisir le end point de l'api appelé, alors c'est vite vu, tu ne pourra pas faire grand chose... mais sur l'api, Sais-tu quelle est l'api appelée ? est-ce l'api 0.6 de http://api.openstreetmap.org/api/0.6/ ? une xapi ? non sur overpass. Quelle est la différence entre les deux ? Elles peuvent sortir exactement le même type de contenu (des noeuds, ways et relation en provenance d'osm au format .osm) mais n'ont pas du tout les mêmes méthodes d'appel : http://wiki.openstreetmap.org/wiki/Api06 http://wiki.openstreetmap.org/wiki/Overpass_API En outre, l'api 0.6 fourni sur http://api.openstreetmap.org a pour objectif d'être utilisé principalement pour l'édition des données et non pour la consommation des données. Une utilisation importante pourrait amener à un bannissement. Et existe-t-il un moyen de faire correspondre les sorties ça veut dire quoi ? si c'est pour avoir le même format en sortie, voir la réponse de frédéric et l'option meta -- sly qui suis-je : http://sly.letuffe.org ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
[OSM-dev-fr] Beta Osmose Leaflet
piste? : il n'y a pas de notion de parent coté menu ou coté layer ?
// Invert item check
_invertAllItem: function () {
$(input[type='checkbox']).each(function () {
___
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr
Re: [OSM-dev-fr] Beta Osmose Leaflet
Super merci, c'est bien ça. Tout et rien avait été corrigé mais pas
inverser.
Le 24/02/2014 15:33, didier2...@free.fr a écrit :
piste? : il n'y a pas de notion de parent coté menu ou coté layer ?
// Invert item check
_invertAllItem: function () {
$(input[type='checkbox']).each(function () {
___
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] Beta Osmose Leaflet
Normalement on a tout pris en compte, tu peux nous confirmer que c'est bon. Le select sur mobile est également corrigé. Frédéric. Le 24/02/2014 12:18, didier2020 a écrit : Le lundi 24 février 2014 à 11:36 +0100, Frédéric Rodrigo a écrit : Le 24/02/2014 09:07, didier2020 a écrit : +1 pour la possibilité de recherche de lieu +1 pour le truc qui s'anime pour faire patienter + pour la sélection des calques, je préfère une action clic sur le bouton layer qui ouvre et ferme plutôt que le survol ( c'est juste une préférence) Test sous linux/chromium (version libre de chrome): - l'animation ne fonctionne pas et les Osmose error n'apparaissent pas Je ne constate pas ce problème avec le dernier linux/chromium. Tu peux confirmer que ce n'était pas juste temporaire ? On a des doutes sur la capacité du serveur a répondre tout le temps en temps raisonnable pour une utilisation interactive de Osmose. autant pour moi, mon premier essai était sur debian 6. Avec debian 7 / Chromium et Iceweasel (FF libre) fonctionnent comme sous windows. Avec debian 6 / Firefox 64 fonctionne comme sous windows. Test sous seven/firefox+ie7+chrome: - pour la sélection des erreurs (tout-rien-inverser) : inverser agit sur les calques (pas les layers de base, mais les autres) On avait ce problème au début partout, mais je ne vois plus d'où ça peut venir, et en plus spécifique à une plateforme. cf ci-dessus, ce n'est pas spécifique a une plateforme. Tu peux cibler un peu plus s'il te plait ? clic sur inverser : - cela ajoute un # dans la barre d'adresse. - la selection des layers secondaire s'inverse - la selection de la gravité ne fonctionne plus correctement tant qu'on laisse le # dans la barre d'adresse clic sur tout ou rien n'a pas d'influence sur ces memes layers. - l'animation pour patienter ne se voit pas si on sélectionne uniquement le layer 'Osmose error heatmap Ça c'est normal, elle n'est là que pour les marqueurs. - permalink : je clique sur permalink = ok dans la barre d'adresse + si je clic sur une catégorie (structurel, tags manquants ...) = clic sur permalink ne fait rien apparaitre dans la barre d'adresse + si je clic sur une catégorie (structurel, tags manquants ...) ET modification d'item = clic sur permalink ne fait pas apparaitre la localisation (lat,lon,zoom) dans la barre d'adresse ok, vu. Merci de ton retour ___ 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] Full History Extracts
Hi Am 14.02.2014 05:56, schrieb amrit karmacharya: Can you make a extract for Nepal? As of now, I need to download the whole asia and extract nepal which covers only 0.3% of asia. There are no other options available. Here you go: http://osm.personalwerk.de/full-history-extracts/latest/asia/southern-asia/ I'll try to update them weekly. Regards, Peter ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Strange map div layout problem with OL 2.13 and Chrome only
El Sábado, 22 de febrero de 2014 10:44:18 Armin escribió: I'm in the process of upgrading to OL 2.13. Everything seems to be fine with Firefox, but in Chrome, [...] Any idea what could be going on there? This. https://github.com/openlayers/openlayers/issues/1181 Cheers, -- Iván Sánchez Ortega i...@sanchezortega.es ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New OSM Test Data Repository
Jochen Topf joc...@remote.org wrote: It also depends on what you are testing. If you are testing the OSM XML parser, those cases are valid data that the OSM parser must understand. If you are testing the renderer, it might be different. For the renderer it would be nice to have a model village featuring all objects in the standard mapnik style. Apart from this I once set up a testfile for verification of correct rendering of riverwidths. Background: I learnt from a cartographer, that waterbodies should always be rendered in their real width on the ground. Probably also of interest to this database. Regards Sven -- Trotz der zunehmenden Verbreitung von Linux erfreut sich der Bär, und - dank Knut - insbesondere der Eisbär, deutlich größerer Beliebtheit als der Pinguin. (Gefunden bei http://telepolis.de/) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New OSM Test Data Repository
Jochen Topf joc...@remote.org wrote: I have started to work on a common OSM test data repository that can be used to test all sorts of software that works with OSM data. Hm, you seem to user real osm id-numbers. Don't you think we should define a private id-range for this purpose? 900 and above might be a reasonable range. I think about importing such data into postgis for rendering tests and it might be bad in some cases if this would kill existing data. Sven -- Those who do not understand Unix are condemned to reinvent it, poorly (Henry Spencer) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New OSM Test Data Repository
On Mo, Feb 24, 2014 at 04:08:09 +, Sven Geggus wrote: Jochen Topf joc...@remote.org wrote: I have started to work on a common OSM test data repository that can be used to test all sorts of software that works with OSM data. Hm, you seem to user real osm id-numbers. Don't you think we should define a private id-range for this purpose? 900 and above might be a reasonable range. I think about importing such data into postgis for rendering tests and it might be bad in some cases if this would kill existing data. Creating test cases etc. is bad enough without having to count zeros in huge numbers. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] New OSM Test Data Repository
On Mo, Feb 24, 2014 at 03:55:37 +, Sven Geggus wrote: Jochen Topf joc...@remote.org wrote: It also depends on what you are testing. If you are testing the OSM XML parser, those cases are valid data that the OSM parser must understand. If you are testing the renderer, it might be different. For the renderer it would be nice to have a model village featuring all objects in the standard mapnik style. Apart from this I once set up a testfile for verification of correct rendering of riverwidths. Background: I learnt from a cartographer, that waterbodies should always be rendered in their real width on the ground. Probably also of interest to this database. For me that's out of scope. I am trying to test software not rendering style files. But if somebody else wants to tackle this, we can talk about whether it makes sense to put all of this in the same repository or how we can organize it best. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Wiki :: Proposition/Support Implementing Dynamic Lists
Hi everybody, I'm contributing to the H.O.T. project ( http://wiki.openstreetmap.org/wiki/Hot ). Under projects there is a list of current projects, which is difficult to maintain, especially because there are different versions in languages of this page. My proposition to simplify the handling of this list is to use a dynamic list using the mediawiki extension DynamicPageList ( https://www.mediawiki.org/wiki/Extension:Intersection ). In the future we could run one page on the wiki, containing all the projects of H.O.T. Tagging it with Category:HOTProjects or similar we could use the dynamic page to get a bullet list of latest projects on the wiki site. Questions: 1) What do you think about the idea implementing this? 2) Who could support with installing the mediawiki extension? Thank you! Chris ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Full History Extracts
Thank you very much, this is a big help to developers here. On Mon, Feb 24, 2014 at 5:03 PM, Peter Körner osm-li...@mazdermind.dewrote: Hi Am 14.02.2014 05:56, schrieb amrit karmacharya: Can you make a extract for Nepal? As of now, I need to download the whole asia and extract nepal which covers only 0.3% of asia. There are no other options available. Here you go: http://osm.personalwerk.de/full-history-extracts/latest/asia/southern-asia/ I'll try to update them weekly. Regards, Peter ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [josm-dev] Git sync stuck
Hi Toby! On 24/02/14 08:28, Toby Murray wrote: The GitHub mirror of the JOSM SVN repo appears to not have gotten any updates in over a month. I'm not sure who runs it but could it please be kicked? We also have a Trac ticket for this issue: http://josm.openstreetmap.de/ticket/6887 @Ævar: Would you please check the mirror again. Please also check my pull request https://github.com/openstreetmap/openstreetmap-mirror/pull/2 – the Evil revision hack is no longer needed due to adaption of the build file. @JOSM team: Since the mirror is apparently used frequently, we might want to to turn this unofficial mirror into an official mirror? Cheers, Simon ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
