Re: [OSM-dev-fr] Test de dev.osmose.openstreetmap.fr
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
Le 7 octobre 2012 19:18, Ab_fab gamma@gmail.com a écrit : J'ai créé deux relations : une dans le sens Nantes-Renneshttp://www.openstreetmap.org/browse/relation/2455384, l'autre dans le sens Rennes-Nanteshttp://www.openstreetmap.org/browse/relation/2455383 Je tente ma toute première suggestion d'organisation de la base de données OSM ! Vu que, dans Alert-C il n'y a qu'une seule voie (la 10301 si je comprends bien), ne serait-il pas correct de rassembler ces deux relations dans une relation composition, les deux relations ayant chacune un rôle dans la composition : l'aller (ou le + ? ) et le retour (ou le - évidemment). Je fais référence aux rôles de relation tels qu'ils sont présentés dans le wiki anglais à http://wiki.openstreetmap.org/wiki/Relation#Roles ; le wiki français n'en parle pas, je ne sais pas pourquoi. Voilà :-) ___ 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
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. Le cas se complique toutefois pour les routages (comme certaines lignes de bus) qui ont un décrochement en Y et dont une branche est prise en aller et retour après demi-tour mais dans un seul sens, tandis que dans l'autre sens la même branche du Y n'est pas parcourue. Les rôles ne suffisent pas alors car il faudrait pouvoir ajouter le même chemin deux fois dans la relation (interdit), ou bien laisser l'ordre de parcours des chemins ambigu. Pour ça on est amené à distinguer un trajet aller et un trajet retour dans des relations distinctes. Pourquoi parler de cas qui ne doivent pas se présenter ? Le routage des lignes de bus est clairement défini [1] : A route is a relation that describes the physical path taken by the vehicles through the infrastructure by a transit service which is known to the public with a particular reference or name. A route should contain an ordered list of all ways used by the service from the starting station to the terminal station. The route also includes details of actual stop_positions (with role 'stop') and platforms (with role 'platform'). Each direction and each variant of the service is represented in an own route relation. Une relation par sens pour la ligne donc il ne peut pas y avoir de problème de chevauchement de branches. On finit la ligne en englobant celle-ci dans une route_master [2] et c'est bon. [1] http://wiki.openstreetmap.org/wiki/Public_Transport#Service_routes [2] http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport#Route_master ___ 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
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 http://www.openstreetmap.org/user/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] Contrôle qualité des axes routiers
J'ai fait ce qui m'a semblé le plus simple, pour aboutir à une relation qui montre la continuité d'un bout à l'autre, pour un sens de circulation. En vue d'une application pour le contrôle qualité, ça me semble plus robuste. Il y a le cas des routes à 2 x 1 voies, qui peuvent être ponctuellement séparées en deux chaussées distinctes, surtout en agglomérations. La problématique risque d'être assez similaire aux relations des lignes de bus. Pour les tags, on peut tout imaginer. Mais là mon objectif c'était d'utiliser les mêmes principes que ce que l'on voit dans la proposition pour un nouveau schéma. J'ai déjà indiqué des rôles (TMC:Point TMC:Segment). S'il faut ajouter backward et forward dans tout ça, ça va devenir compliqué. Je trouve que les + et les - c'est pas si mal, en pratique. 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 http://www.openstreetmap.org/user/ab_fab a mis en place pour rennes - nantes ? ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr -- ab_fab http://wiki.openstreetmap.org/wiki/User: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
Re: [OSM-dev-fr] Contrôle qualité des axes routiers
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] API sur http://analyser.openstreetmap.fr/ ?
Le 6 octobre 2012, didier2020 a écrit : Le samedi 06 octobre 2012 à 13:15 +0200, didier2020 a écrit : Le samedi 06 octobre 2012 à 13:06 +0200, Christian Quest a écrit : Y-a-til une API pour interroger http://analyser.openstreetmap.fr/ sur la validité d'une relation ? http://osm3.crans.org/osmbin/analyse-relation?283030 ca marche plus ... Effectivement, parce qu'il n'y a plus de base adéquate sur osm3. Du coup, j'ai déplacé le script sur osm8: http://osm8.openstreetmap.fr//~osmbin/analyse-relation-open.py?283030 -- Jocelyn ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
[OSM-dev-fr] Re : Re: API sur http://analyser.openstreetmap.fr/ ?
cool ! - Mail d'origine - De: Jocelyn Jaubert jocelyn.jaub...@gmail.com À: dev-fr@openstreetmap.org Envoyé: Tue, 09 Oct 2012 22:08:20 +0200 (CEST) Objet: Re: [OSM-dev-fr] API sur http://analyser.openstreetmap.fr/ ? Le 6 octobre 2012, didier2020 a écrit : Le samedi 06 octobre 2012 à 13:15 +0200, didier2020 a écrit : Le samedi 06 octobre 2012 à 13:06 +0200, Christian Quest a écrit : Y-a-til une API pour interroger http://analyser.openstreetmap.fr/ sur la validité d'une relation ? http://osm3.crans.org/osmbin/analyse-relation?283030 ca marche plus ... Effectivement, parce qu'il n'y a plus de base adéquate sur osm3. Du coup, j'ai déplacé le script sur osm8: http://osm8.openstreetmap.fr//~osmbin/analyse-relation-open.py?283030 -- Jocelyn ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr -- didier --mapeur amateur-- ___ dev-fr mailing list dev-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev-fr
Re: [Potlatch-dev] [OpenStreetMap] #4599: Icon for medical doctor in potlatch2
#4599: Icon for medical doctor in potlatch2 --+ Reporter: Hno-Zentrum | Owner: potlatch-dev@… Type: defect | Status: new Priority: minor| Milestone: Component: potlatch2|Version: Resolution: | Keywords: --+ Comment (by Porfino): I would highly appreciate this too. You can add a battlefield but no doctors. There should also be a symbol for psychotherapist/psychiatrist i think. But one symbol would be fine for me too. -- Ticket URL: https://trac.openstreetmap.org/ticket/4599#comment:1 OpenStreetMap http://www.openstreetmap.org/ OpenStreetMap is a free editable map of the whole world ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OpenStreetMap] #4599: Icon for medical doctor in potlatch2
#4599: Icon for medical doctor in potlatch2 --+ Reporter: Hno-Zentrum | Owner: potlatch-dev@… Type: defect | Status: new Priority: minor| Milestone: Component: potlatch2|Version: Resolution: | Keywords: --+ Comment (by andy.hofstedt@…): I think that this would be a useful option to inculde location of surgeries and clinics on the map. -- Ticket URL: https://trac.openstreetmap.org/ticket/4599#comment:2 OpenStreetMap http://www.openstreetmap.org/ OpenStreetMap is a free editable map of the whole world ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [Potlatch-dev] [OpenStreetMap] #4599: Icon for medical doctor in potlatch2
#4599: Icon for medical doctor in potlatch2 --+ Reporter: Hno-Zentrum | Owner: potlatch-dev@… Type: defect | Status: new Priority: minor| Milestone: Component: potlatch2|Version: Resolution: | Keywords: --+ Changes (by andy.hofstedt@…): * cc: andy.hofstedt@… (added) -- Ticket URL: https://trac.openstreetmap.org/ticket/4599#comment:3 OpenStreetMap http://www.openstreetmap.org/ OpenStreetMap is a free editable map of the whole world ___ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
Re: [OSM-dev] Blank Tiles at z23 and Deeper
Hi, On Tue, 9 Oct 2012 00:21:25 -0400 jpk _...@jpk.is wrote: In any case, I set up my tile server for this purpose. I changed the #define MAX_ZOOM to 30 in mod_tile's render_config.h, and set MAXZOOM in renderd.conf to 30. That's enough to get the tile server to serve tiles down to z30 instead of 404'ing. But the directory structure used to store the metatiles supports only 20 bits for x and y, so i would expect that on z21 and above you'll not be able to retrieve tiles from your server (or maybe see the same tile not matter what coordinates you use)... or are you using someting other than mod_tile? Bye Frederik ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [Potlatch-dev] [OpenStreetMap] #4615: Grammar pedantry: show less should arguably be show fewer in the toolbox
#4615: Grammar pedantry: show less should arguably be show fewer in the toolbox --+ Reporter: SomeoneElse | Owner: potlatch-dev@… Type: defect | Status: new Priority: trivial | Milestone: Component: potlatch2|Version: Resolution: | Keywords: --+ Comment (by sdoerr): -1: unless you include the word 'tools', I think 'less' is better. -- Ticket URL: https://trac.openstreetmap.org/ticket/4615#comment:1 OpenStreetMap http://www.openstreetmap.org/ OpenStreetMap is a free editable map of the whole world ___ Potlatch-dev mailing list potlatch-...@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
[OSM-dev] Will the real OpenStreetBugs stand up?
I'm trying to understand the status of OpenStreetBugs and where development is happening. I was trying to follow along at the EWG meeting yesterday. Parsing through the wiki [1] now I remain confused. Here are my questions: - Why are there two sites: osmbugs.org and http://openstreetbugs.schokokeks.org/? The Wiki says there are but not why [1]. - What is the canonical repository right now? Or is the project essentially forked? I find three repositories [2, 3, 4]. - What issue tracker should I look like? - What's the right site to link point people to? schokokes or osmbugs.org? The message on http://osmbugs.org/ is really confusing: This page is no longer a redirect; the original OpenStreetBugs web page is still available [here](http://openstreetbugs.schokokeks.org/). I know TomH is working on updating the status on http://wiki.openstreetmap.org/wiki/Top_Ten_Tasks - apologies if I'm jumping the gun, I hope my questions are helpful to clarify the situation for anyone who wants to get involved in OSMBugs. [1] http://wiki.openstreetmap.org/wiki/OpenStreetBugs [2] Linked from osmbugs.org https://github.com/emka/openstreetbugs [3] Linked from wiki ([1]): http://git.openstreetmap.org/?p=rails.git;a=shortlog;h=refs/heads/openstreetbugs [4] Mercurial repository ([1]) on http://openstreetbugs.org Alex Barth http://twitter.com/lxbarth tel (+1) 202 250 3633 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Will the real OpenStreetBugs stand up?
On 09/10/12 21:01, Alex Barth wrote: I'm trying to understand the status of OpenStreetBugs and where development is happening. I think you are confusing two (or more) completely different things. I was trying to follow along at the EWG meeting yesterday. Parsing through the wiki [1] now I remain confused. Here are my questions: - Why are there two sites: osmbugs.org and http://openstreetbugs.schokokeks.org/? The Wiki says there are but not why [1]. - What is the canonical repository right now? Or is the project essentially forked? I find three repositories [2, 3, 4]. - What issue tracker should I look like? - What's the right site to link point people to? schokokes or osmbugs.org? The message on http://osmbugs.org/ is really confusing: This page is no longer a redirect; the original OpenStreetBugs web page is still available [here](http://openstreetbugs.schokokeks.org/). All those are independent third party sites created by individuals and are not directly related to core site. I know TomH is working on updating the status on http://wiki.openstreetmap.org/wiki/Top_Ten_Tasks - apologies if I'm jumping the gun, I hope my questions are helpful to clarify the situation for anyone who wants to get involved in OSMBugs. What we were talking about in the EWG meeting was adding a bug reporting system to the main site that records things in the main database and is integrated with the API etc. It is not directly related to any of the sites you mention. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Will the real OpenStreetBugs stand up?
All those are independent third party sites created by individuals and are not directly related to core site. Aren't they using the same database somehow? What we were talking about in the EWG meeting was adding a bug reporting system to the main site that records things in the main database and is integrated with the API etc. It is not directly related to any of the sites you mention. Okay, then what is it? :) Is it not open-source at all? I thought that you were working on a branch of the 'official' OSB project and just needed to merge/publish that? So afaik, there is no public core site (even an old development version), and no public source for OSB (even an old branch). ^ If that's wrong, please correct with URLs and information. On Tue, Oct 9, 2012 at 4:15 PM, Tom Hughes t...@compton.nu wrote: On 09/10/12 21:01, Alex Barth wrote: I'm trying to understand the status of OpenStreetBugs and where development is happening. I think you are confusing two (or more) completely different things. I was trying to follow along at the EWG meeting yesterday. Parsing through the wiki [1] now I remain confused. Here are my questions: - Why are there two sites: osmbugs.org and http://openstreetbugs.** schokokeks.org/ http://openstreetbugs.schokokeks.org/? The Wiki says there are but not why [1]. - What is the canonical repository right now? Or is the project essentially forked? I find three repositories [2, 3, 4]. - What issue tracker should I look like? - What's the right site to link point people to? schokokes or osmbugs.org? The message on http://osmbugs.org/ is really confusing: This page is no longer a redirect; the original OpenStreetBugs web page is still available [here](http://openstreetbugs.**schokokeks.org/)http://openstreetbugs.schokokeks.org/) . All those are independent third party sites created by individuals and are not directly related to core site. I know TomH is working on updating the status on http://wiki.openstreetmap.org/**wiki/Top_Ten_Taskshttp://wiki.openstreetmap.org/wiki/Top_Ten_Tasks- apologies if I'm jumping the gun, I hope my questions are helpful to clarify the situation for anyone who wants to get involved in OSMBugs. What we were talking about in the EWG meeting was adding a bug reporting system to the main site that records things in the main database and is integrated with the API etc. It is not directly related to any of the sites you mention. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ __**_ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.**org/listinfo/devhttp://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Will the real OpenStreetBugs stand up?
On 09/10/12 21:24, Tom MacWright wrote: All those are independent third party sites created by individuals and are not directly related to core site. Aren't they using the same database somehow? No idea. What we were talking about in the EWG meeting was adding a bug reporting system to the main site that records things in the main database and is integrated with the API etc. It is not directly related to any of the sites you mention. Okay, then what is it? :) Is it not open-source at all? I thought that you were working on a branch of the 'official' OSB project and just needed to merge/publish that? What part of I will take an action to get something pushed out before the next meeting did you fail to understand yesterday? The story is that Kai created something that was literally based on taking one of the existing OSB systems and bolting that javascript onto the rails code but it didn't produce a something that was very coherent with the rest of the site and API so I have been reworking it. There is a branch out there that you may stumble across but it bears no resemblence to the current code. Now if you want me to get what I have cleaned up and published I should probably stop writing emails about it and actually work on it instead... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Will the real OpenStreetBugs stand up?
What part of I will take an action to get something pushed out before the next meeting did you fail to understand yesterday? This sounds promising, but I fail to understand it fully. Is there someone else from the EWG meeting (not TomH, who I don't want to bother) who would like to fill us in on these developments with integrating bug tracking into OSM.org? -Mikel * Mikel Maron * +14152835207 @mikel s:mikelmaron From: Tom Hughes t...@compton.nu To: Tom MacWright t...@developmentseed.org Cc: dev@openstreetmap.org Sent: Tuesday, October 9, 2012 4:31 PM Subject: Re: [OSM-dev] Will the real OpenStreetBugs stand up? On 09/10/12 21:24, Tom MacWright wrote: All those are independent third party sites created by individuals and are not directly related to core site. Aren't they using the same database somehow? No idea. What we were talking about in the EWG meeting was adding a bug reporting system to the main site that records things in the main database and is integrated with the API etc. It is not directly related to any of the sites you mention. Okay, then what is it? :) Is it not open-source at all? I thought that you were working on a branch of the 'official' OSB project and just needed to merge/publish that? What part of I will take an action to get something pushed out before the next meeting did you fail to understand yesterday? The story is that Kai created something that was literally based on taking one of the existing OSB systems and bolting that javascript onto the rails code but it didn't produce a something that was very coherent with the rest of the site and API so I have been reworking it. There is a branch out there that you may stumble across but it bears no resemblence to the current code. Now if you want me to get what I have cleaned up and published I should probably stop writing emails about it and actually work on it instead... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Will the real OpenStreetBugs stand up?
On Tue, Oct 9, 2012 at 9:48 PM, Mikel Maron mikel_ma...@yahoo.com wrote: What part of I will take an action to get something pushed out before the next meeting did you fail to understand yesterday? This sounds promising, but I fail to understand it fully. Is there someone else from the EWG meeting (not TomH, who I don't want to bother) who would like to fill us in on these developments with integrating bug tracking into OSM.org? i've just finished putting the minutes up [1] and the relevant extract is: * ACTION: TomH to push current OSB/notes branch public (which he has been improving on a local branch) * (OSB/notes) there are concerns about the UI implementation of the current branch, but it may be possible to merge the API separately so that UI development can proceed independently cheers, matt [1] http://www.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2012-10-08 -Mikel * Mikel Maron * +14152835207 @mikel s:mikelmaron From: Tom Hughes t...@compton.nu To: Tom MacWright t...@developmentseed.org Cc: dev@openstreetmap.org Sent: Tuesday, October 9, 2012 4:31 PM Subject: Re: [OSM-dev] Will the real OpenStreetBugs stand up? On 09/10/12 21:24, Tom MacWright wrote: All those are independent third party sites created by individuals and are not directly related to core site. Aren't they using the same database somehow? No idea. What we were talking about in the EWG meeting was adding a bug reporting system to the main site that records things in the main database and is integrated with the API etc. It is not directly related to any of the sites you mention. Okay, then what is it? :) Is it not open-source at all? I thought that you were working on a branch of the 'official' OSB project and just needed to merge/publish that? What part of I will take an action to get something pushed out before the next meeting did you fail to understand yesterday? The story is that Kai created something that was literally based on taking one of the existing OSB systems and bolting that javascript onto the rails code but it didn't produce a something that was very coherent with the rest of the site and API so I have been reworking it. There is a branch out there that you may stumble across but it bears no resemblence to the current code. Now if you want me to get what I have cleaned up and published I should probably stop writing emails about it and actually work on it instead... Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Will the real OpenStreetBugs stand up?
On 10/09/2012 02:31 PM, Tom Hughes wrote: On 09/10/12 21:24, Tom MacWright wrote: All those are independent third party sites created by individuals and are not directly related to core site. Aren't they using the same database somehow? No idea. What we were talking about in the EWG meeting was adding a bug reporting system to the main site that records things in the main database and is integrated with the API etc. It is not directly related to any of the sites you mention. Okay, then what is it? :) Is it not open-source at all? I thought that you were working on a branch of the 'official' OSB project and just needed to merge/publish that? What part of I will take an action to get something pushed out before the next meeting did you fail to understand yesterday? The story is that Kai created something that was literally based on taking one of the existing OSB systems and bolting that javascript onto the rails code but it didn't produce a something that was very coherent with the rest of the site and API so I have been reworking it. Yes that is more or less correct. OpenStreetBugs in one form or another has existed for a long time now already and has been a great resource to OSM. Imho one of its biggest shortcomings however is visability. I.e. too few people people know about and use OpenStreetBugs for it to fullfill its full potential. So people have been talking about integrating it into the openstreetmap.org project for nearly as long as OSB exists. However, as too often in OSM, despite everyone seemingly agreeing that this should be a priority for some reason no one actually wrote any code for it. I noticed at some point that the original author of OSB actually wrote a nicely encapsulated OpenLayers extension [1] to make it really easy for people to integrate the client side OSB functionality into new sites without having to reinvent the wheel. Given how easy it was to integrate OSB into a new page, how much people talked about the need for integrating this functionality into osm.org and that no one else had coded something up, I hacked together a proof of concept version in a few days in February 2010 and committed it to a branch of the rails port [2]. The javascript part was a thin glue layer around the existing OpenStreetBugs OpenLayers extension, while the backend was a re-implementation of the OSB database in rails. Since then the backend side has been improved to be more in line with the API layout of the rails_port (although the original API remained to be compatible with the external OSB), but apart from a few tweeks, the javascript code remained the original OpenLayers extension. The later part is (afaik) what Tom is objecting to and wants to rewrite it to be more in line with the rest of the javascript on osm.org and meet the maintainability standards of the code in rails_port. Also the currently publicly committed code on the OpenStreetBugs branch is still in rails 2 rather than rails 3. It is the clean up and improvement of this branch that TomH has currently only locally as he hasn't gotten around to finishing it off in order to push it back to the public branch. Although quite a bit of the cleanup and review he has done on the branch (before the switch to rails3) has also already been committed. So both the rails_port re-implementation and the original OSB code is available in public repositories, just that there are some as yet unpublished improvements that Tom has said we will try and get around to publishing till the next EWG meeting. With respect to the relation to http://openstreetbugs.schokokeks.org/ and http://osmbugs.org/ it is meant to be a replacement for the two (which I do think are just two separate front-ends to the same bug database). It is supposed to replace them. Back in 2010/2011 when I last talked to the author of OSB, he was fine with the idea. There were also thoughts of migrating/ importing the existing OSB database into the rails_port database and pointing the front-end on http://openstreetbugs.schokokeks.org/ to use the then new official osm.org rails_port database to make sure there wasn't any fragmentation of the bugs database. I presume the authors of OSB would still be fine with this, although I don't know if or what plans Tom has for a transition period. It at least partly depends on if the backend remains compatible with the original OSB API making it feasible to migrate the old db and use the frontend at http://openstreetbugs.schokokeks.org/ as a proxy. Should e.g. the decision be made that one needs to login to ones OSM account in order to submit a bug / note then such a transition would obviously not be possible. I hope this makes it slightly clearer on the relation between the to be re-implemented rails_port notes (OSB) branch and the original sites and at what stage of development it currently is at. Kai [1]
Re: [OSM-dev] Blank Tiles at z23 and Deeper
On Tue, Oct 9, 2012 at 12:21 PM, jpk _...@jpk.is wrote: All tiles at z23 and greater are solid green-ish (#b5d0d0, to be exact). Poking through the mapnik style, I see this color is used as the background color for the Map element (osm.xml, line 6). Changing that color changes the color I see for these solid tiles. I'm not yet knowledgeable when it comes to mapnik but in trying to digest the style files, nothing struck me as explicitly causing this behavior at z22. Additionally, I tried MapQuest's style (found here: https://github.com/MapQuest/MapQuest-Mapnik-Style) and found the same thing (except instead of solid #b5d0d0, you get their wavy light-blue water texture). Is this a style issue? A mapnik issue? renderd or mod_tile? Don't the styles for Mapnik have a scale (zoom) range? This makes it possible to render objects differently depending on the zoom level. I'm not familiar with the Mapnik styles for the main OSM style or MapQuest's but it's possible that the style rules defined to work at z18 may not render any object beyond some higher zoom level leading to the default background that you're seeing. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] how to debug rendering issue
Hi, I have a strange rendering issue on my server. This highway is not rendered: http://www.openstreetmap.org/browse/way/177905977 The other oneway highway next to it is rendered: http://tile.osm-tools.org/osm_then/18/203537/124374.png On osm.org both ways are rendered: http://tile.openstreetmap.org/18/203537/124374.png I checked the database and the way is included in planet_osm_line (as well as in _roads) select * from planet_osm_line where osm_id=177905977 177905977;;secondary;;yes;;;401;;paved;;;6;;ref=401, oneway=yes, highway=secondary, surface=paved, dual_carriage=yes;01022031BF0D006A0048E17AEC461A65413D0AD7A376362F41CD54491A6541AE47E17A76362F41E17A140E711A6541713D0AD781362F410088D31A6541F6285C0FBC352F41D7A37025081B6541FE342F41C3F528C4171B6541A4703D0AF9342F41D7A370F5921B65411F85EB5120362F4114AE4739A21B6541C3F5285C7B362F415C8FC28DAD1B65415C8FC2752C372F41AE47E18AB31B654148E17A946B382F4185EB5128BF1B654114AE47619F3B2F415C8FC275C51B6541A4703D8A283C2F4114AE4779D21B6541A4703D8A8B3C2F418FC2F578E91B6541B81E85EBCF3C2F41F6285C97181C65413D0AD7231B3D2F419A99521C65417B14AEC7DC3D2F4152B81EF56B1C6541713D0AD7D53D2F4152B81EF5851C654114AE4761EC3D2F418FC2F5E8BE1C654152B81E05603E2F41EC51B82E1B1D65410AD7A3F0AA3E2F4148E17AD44D1D654185EB51B8C53E2F41E17A145E651D65411F85EBD1413F2F413363B91D65419A99A3412F41A4703DDAD91D6541A4703D8A36422F4166C62E1E654185EB51B87D432F417B14AE27781E6541E17A14AE19442F41F6285C078D1E654114442F411F85EB79321F65418FC2F528C8422F417B14AE87EF206541D7A3703D7D3F2F4148E17AF43B21654152 B81E85EC3E2F41E17A14DE56216541A4703D8AB93E2F4185EB511097216541295C8FC2413E2F4148E17AECFB216541A4703D8A853D2F411F85EB6192236541D7A3703DDE372F41F6285CCFD12365411F85EBD19E372F41295C8F5A4F246541C3F5285C4F382F4100886F256541713D0AD70F3A2F41E17A14BE922565417B14AEC7183A2F4152B81E5DC8256541C3F5285CB6392F419A414027654152B81E05A1352F4152B81E453F296541AE47E1FAE7312F4114AE47495829654185EB51B880312F419AA97C29654152B81E0575302F41EC51B89EDC296541A4703D8A172D2F410AD7A3E0FB2965419A192B2B2F4148E17AFC172A6541F6285C8F22292F411F85EBA1762A6541295C8F428E222F41EC51B83E8E2A6541B81E85EB1D212F4152B81EF5A82A6541D7A3703D38202F41295C8F92D92A65411F85EB510D1F2F41E17A1486F62A6541E17A142EC71D2F41A4703D7A3E2B654166E6211A2F41AE47E14AB52B654133B323142F4148E17A84F22B6541F6285C8F30112F413D0AD76B0A2C654114AE47E1A0102F415C8FC2DD242C654152B81E0576102F419AC1642C6541713D0AD770112F411F85EB29072D65413D0AD7A3E0132F4114AE4711262D65415C8FC2F5F3132F4166AE592D65413D0AD723C2132F41D7A37025F42D6541A4703D0A EC122F413D0AD793122E6541E17A14AEBD122F41EC51B86E222E65411F85EBD155122F41A4703D02552E65417B14AEC7580F2F41B81E854B762E65415C8FC275660D2F413D0AD7B3972E6541AE47E17A120C2F41CDA4B52E654100806C0B2F41B81E85BBFB2E654148E17A14930A2F41713D0AB75B2F6541E17A14AE50092F413D0AD72BBE2F65410AD7A3F00D092F41333B04306541713D0AD7E9082F41713D0A5F18306541EC51B89E54092F41B81E85032B306541C3F528DC480A2F41663E3C306541F6285C8F880B2F415230654133B38C0C2F41AE47E1CA66306541B81E85EBFD0D2F419AB17C3065419A19AF0E2F413D0AD703A2306541AE47E1FA240F2F4100E8C1306541295C8F42510F2F41E17A142EF4306541EC51B81E3E0F2F4114AE47210C31654114AE47E1380F2F4166E60E3165417B14AE47380F2F419A99173165411F85EBD1F90E2F41F6285C77343165418FC2F5285C0E2F41C3F528EC49316541295C8F42B20D2F4166AE6131654152B81E85AB0C2F417B14AE077831654148E17A94910B2F419AC9993165410AD7A370EA092F416686AB316541713D0A570E092F4100E0BF3165415C8FC2F5E8072F41AE47E112CD316541D7A3703D0B072F416646DE3165417B14AEC7A3052F 413D0AD7EBE6316541F6285C0FB5042F418FC2F5B0ED316541CD4C0B042F41A4703DCAF7316541EC51B81E83022F4152B81EF505326541D7A3703D7F002F41295C8F02173265415C8FC2F503FE2E41295C8F721F326541E17A142EB7FC2E4148E17A9435326541EC51B81E8DF92E411F85EB094C32654166E636F62E41295C8FE25932654133B335F42E41AE47E1BA73326541A4703D8A90F02E419A0974326541A4703D0A81F02E41295C8FC27632654148E17A14F8EF2E411F85EB6984326541F8ED2E417B14AEB79D32654100804DEA2E41 In the log files I see nothing unusual. My rendering is done using tirex. Setting debug=1 in mapnik.conf only returns this in the log which sounds ok: sending: id=1349812110_147016472#012map=osmthen#012metatile=/var/lib/tirex/tiles/osmthen/18/49/30/181/29/0.meta#012render_time=598#012result=ok#012type=metatile_render_request#012x=203536#012y=124368#012z=18 Data is imported using 64 bit ID mode osm2pgsql. Postgresql is 9.2.1 with postgis 2.0.1. Mapnik is 2.1.0. Tirex and the osm mapnik style are both up to rev 28793. Style was only modified for a different font, but as both highways in the given tile are a secondary, I see no reason why only one should render. What possibilities do I have for debugging into this issue? Can I enable more verbosity? What could cause a symptom like this? Stephan ___ dev mailing list dev@openstreetmap.org
[OSM-dev] Blank Tiles at z23 and Deeper
On Tue, Oct 9, 2012 at 6:31 PM, Eugene Alvin Villar sea...@gmail.com wrote: On Tue, Oct 9, 2012 at 12:21 PM, jpk _...@jpk.is wrote: All tiles at z23 and greater are solid green-ish (#b5d0d0, to be exact). Poking through the mapnik style, I see this color is used as the background color for the Map element (osm.xml, line 6). Changing that color changes the color I see for these solid tiles. I'm not yet knowledgeable when it comes to mapnik but in trying to digest the style files, nothing struck me as explicitly causing this behavior at z22. Additionally, I tried MapQuest's style (found here: https://github.com/MapQuest/MapQuest-Mapnik-Style) and found the same thing (except instead of solid #b5d0d0, you get their wavy light-blue water texture). Is this a style issue? A mapnik issue? renderd or mod_tile? Don't the styles for Mapnik have a scale (zoom) range? This makes it possible to render objects differently depending on the zoom level. I'm not familiar with the Mapnik styles for the main OSM style or MapQuest's but it's possible that the style rules defined to work at z18 may not render any object beyond some higher zoom level leading to the default background that you're seeing. (Oops, didn't reply to the list.) Yep, they do. That was my first thought, but there's no min/maxscale things defined for z18. From what I gather, everything that renders at z18 doesn't set a minscale to 18, so tiles for z19 to z22 render the same stuff as z18 just scaled up (which is fine by me). I'm not sure why z23 is the magic number where it breaks. -- john p. kiffmeyer ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[josm-dev] Uploading Presets to the JOSM wiki
Hi All, Sorry if this isn't really a dev question. We have a preset we want to add here: http://josm.openstreetmap.de/wiki/Presets/ The issue is the preset we made has a lot of items and URL links. Basically each item links to the appropriate wikipage with a description. This is getting caught in the spam filter. Is there a way to add the page? Do we just need an account? I tried to create an account, but the captcha didn't appear and my attempt to make an account also go stopped as spam. Thanks, -Kate ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Uploading Presets to the JOSM wiki
Hello, Sorry if this isn't really a dev question. We have a preset we want to add here: http://josm.openstreetmap.de/wiki/Presets/ The issue is the preset we made has a lot of items and URL links. Basically each item links to the appropriate wikipage with a description. This is getting caught in the spam filter. Files attached to Presets page get deleted anyway. Please read the instructions http://josm.openstreetmap.de/wiki/Presets#Createnewpresets more carefully. Either you add a link to a remote hosted file or you create a subpage of Presets and host the preset there. When making a wiki page, there are some ways to circumvent the spam check, the two most important: a) login and fill captcha (gains 30 points) b) Split the edit into multiple (reduced the impact of external links) Is there a way to add the page? Do we just need an account? I tried to create an account, but the captcha didn't appear and my attempt to make an account also go stopped as spam. You created an account named wonderchook! There is currently no indication of successful account except the enter password now. Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ josm-dev mailing list josm-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/josm-dev
