[OSM-talk-fr] possibilité de mixer carte et vues aériennes en dehors d'un éditeur
Bonjour, Dans la région toulousaine, nous disposons d'une orthophoto de belle facture (12cm de résolution) sous licence ODBL Cette image est disponible et utilisable directement dans JOSM. c'est parfait. Maintenant si je me place plus d'un point de vue utilisateur, quand je regarde une carte j'aime bien pouvoir passer de la vue carte à une vue aérienne et même parfois mixer les deux. Mais en dehors d'un éditeur, ou de monter mon serveur, je n'ai pas trouvé la possibilité de faire cela. En cherchant un peu j'ai rencontré des fonctionnalités qui m'ont paru assez proche de ce que je souhaite obtenir : Avec ID (on peut spécifier un overlay spécifique avec l'optio du menu intitulée : custom) http://openstreetmap.us/iD/release/#background=Bingmap=20.00/-77.02271/38.90085 avec en prime la possibilité de régler la transparence de chaque couche. sinon sur : tile.openstreetmap.fr on a bien une rubrique overlay dans le menu à droite mais je ne peux rajouter qu'une vue aérienne dénommée brocas (c'est dans les landes) dans cette vue ne pourrait-on pas agréger les vues aériennes libérées ? Dernière possibilité on peut déjà le faire, mais je n'ai pas trouvé. Laurent Combe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] possibilité de mixer carte et vues aériennes en dehors d'un éditeur
Il y a si peu de vue aérienne sous licence libre, un tel overlay sur une carte globale serait sûrement décevant. Il est par contre facile de mettre en place une carte limitée dans l'espace et proposant ce type d'overlay en utilisant par exemple Leaflet: http://leafletjs.com/ C'est juste une page HTML et un peu de javascript à mettre quelque part sur un serveur. Le 9 juin 2013 08:36, Laurent Combe laurent.co...@free.fr a écrit : Bonjour, Dans la région toulousaine, nous disposons d'une orthophoto de belle facture (12cm de résolution) sous licence ODBL Cette image est disponible et utilisable directement dans JOSM. c'est parfait. Maintenant si je me place plus d'un point de vue utilisateur, quand je regarde une carte j'aime bien pouvoir passer de la vue carte à une vue aérienne et même parfois mixer les deux. Mais en dehors d'un éditeur, ou de monter mon serveur, je n'ai pas trouvé la possibilité de faire cela. En cherchant un peu j'ai rencontré des fonctionnalités qui m'ont paru assez proche de ce que je souhaite obtenir : Avec ID (on peut spécifier un overlay spécifique avec l'optio du menu intitulée : custom) http://openstreetmap.us/iD/release/#background=Bingmap=20.00/-77.02271/38.90085 avec en prime la possibilité de régler la transparence de chaque couche. sinon sur : tile.openstreetmap.fr on a bien une rubrique overlay dans le menu à droite mais je ne peux rajouter qu'une vue aérienne dénommée brocas (c'est dans les landes) dans cette vue ne pourrait-on pas agréger les vues aériennes libérées ? Dernière possibilité on peut déjà le faire, mais je n'ai pas trouvé. Laurent Combe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] possibilité de mixer carte et vues aériennes en dehors d'un éditeur
Bonjour, Pour Toulouse, on peut déjà passer d'une vue à l'autre (des orthophotos 2011 et 2007 aux quatre rendus standard et à celui en occitan de PAULLA) sur : http://wms.openstreetmap.fr/toulouse (comme cela avait déjà été signalé sur cette liste). Pour Tours, Cyrille avait rendu les images visibles dans un navigateur sur : http://blog.libre.cc/orthophoto-toursplus.html Cordialement, Jean-Guilhem Le 09/06/2013 08:57, Christian Quest a écrit : Il y a si peu de vue aérienne sous licence libre, un tel overlay sur une carte globale serait sûrement décevant. Il est par contre facile de mettre en place une carte limitée dans l'espace et proposant ce type d'overlay en utilisant par exemple Leaflet: http://leafletjs.com/ C'est juste une page HTML et un peu de javascript à mettre quelque part sur un serveur. Le 9 juin 2013 08:36, Laurent Combe laurent.co...@free.fr a écrit : Bonjour, Dans la région toulousaine, nous disposons d'une orthophoto de belle facture (12cm de résolution) sous licence ODBL Cette image est disponible et utilisable directement dans JOSM. c'est parfait. Maintenant si je me place plus d'un point de vue utilisateur, quand je regarde une carte j'aime bien pouvoir passer de la vue carte à une vue aérienne et même parfois mixer les deux. Mais en dehors d'un éditeur, ou de monter mon serveur, je n'ai pas trouvé la possibilité de faire cela. En cherchant un peu j'ai rencontré des fonctionnalités qui m'ont paru assez proche de ce que je souhaite obtenir : Avec ID (on peut spécifier un overlay spécifique avec l'optio du menu intitulée : custom) http://openstreetmap.us/iD/release/#background=Bingmap=20.00/-77.02271/38.90085 avec en prime la possibilité de régler la transparence de chaque couche. sinon sur : tile.openstreetmap.fr on a bien une rubrique overlay dans le menu à droite mais je ne peux rajouter qu'une vue aérienne dénommée brocas (c'est dans les landes) dans cette vue ne pourrait-on pas agréger les vues aériennes libérées ? Dernière possibilité on peut déjà le faire, mais je n'ai pas trouvé. Laurent Combe -- gpg 0x5939EAE2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Je crois que tu ne connais pas le sens du mot orthogonal. Car si c'était réellement orthogonal, ce critère de niveau serait utilisable **seul** comme critère de sélection sans avoir jamais à la lier à un autre critère, pour obtenir une liste d'éléments homogène. Ce qui n'est évidemment pas le cas, puisque les niveaux sont toujours liés à autre chose : niveau de quoi ? C'est comme le tag type : type de quoi ? Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net a écrit : Bonjour, Le 08/06/2013 15:28, Christian Quest a écrit : Si on regarde un peu plus loin que le sujet des académies, je pense qu'on va découvrir des découpages scolaires plus ou moins hiérarchiques, peut être pas en France, mais il y a de fortes chances qu'il y en ait dans d'autres pays... pendant un peu plus loin que les bords de notre hexagone ;) De plus mon idée avec boundary:level=* est d'avoir un tag un peu plus générique qui pourrait s'appliquer à tout type de boundary J'approuve complètement cette idée de tag boundary:level, qui deviendrait orthogonal au tag boundary, sans lien particulier avec une des valeurs, comme c'est aujourd'hui le cas avec admin_level. On combinerait boundary=* et boundary:level=* selon le besoin, et sans confusion. Et en toute logique, il faudrait si on l'applique, le propager aussi aux boundary=administrative, à la place d'admin_level. Peut-être pas pour demain matin, mais pour de nouveaux types de limites (telles les académies, s'il y a besoin de hiérarchiser des niveaux) pourquoi pas démarrer directement avec ? vincent __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] SOTM 2013... deadline pour les propositions de présentations
Je viens de proposer une présentation autour de l'accessibilité comprenant intitulée OSM and accessibility: beyond wheelchair=* Le contenu que j'envisage (en vrac): - rappel de l'existant (wheelmap) - les différentes formes de handicap (utilisation de données OSM en rapport avec d'autres sens que la vue par les déficients visuels: l'odeur de la boulangerie, le bruit de la fontaine, etc) - le micromapping indoor: exemples à Orange - les collaborations avec les partenaires: Montpellier, Orange, Transilien - les outils de saisie, de visualisation - un rendu adapté - le thème porteur pour recruter de nouveaux contributeurs La deadline pour proposer des présentations c'est demain... si vous avez des idées, n'hésitez pas à en parler ici. J'en verrai bien une sur le data gardening, c'est à dire comment maintenir à jour les données, un thème qui sera de plus en plus important avec l'ancienneté du projet et le renouvellement des contributeurs actifs. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le pseudo département de L'Epte sur layers a disparu. Le diagnostic était donc bon ;) -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Voilà la dernière évolution du rendu des réserves naturelles (les tuiles sont en cours de régénération car ça impacte à partir du zoom 10): http://tile.openstreetmap.fr/?zoom=13lat=47.29383lon=-2.44937layers=B0F -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le 09/06/2013 10:15, Christian Quest a écrit : Le pseudo département de L'Epte sur layers a disparu. Le diagnostic était donc bon ;) Bien vu :-) Bon dimanche orthogonal, vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Bravo pour avoir retenu mon idée. C'est superbe, très lisible, tous les détails dans la réserve sont enfin visibles. Le 9 juin 2013 10:31, Christian Quest cqu...@openstreetmap.fr a écrit : Voilà la dernière évolution du rendu des réserves naturelles (les tuiles sont en cours de régénération car ça impacte à partir du zoom 10): http://tile.openstreetmap.fr/?zoom=13lat=47.29383lon=-2.44937layers=B0F -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
apparemment cela ne marche qu'à partir du niveau 12, au niveau 10 ou 11 c'est encore l'ancien rendu Le 9 juin 2013 10:31, Christian Quest cqu...@openstreetmap.fr a écrit : Voilà la dernière évolution du rendu des réserves naturelles (les tuiles sont en cours de régénération car ça impacte à partir du zoom 10): http://tile.openstreetmap.fr/?zoom=13lat=47.29383lon=-2.44937layers=B0F -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
il y a un problème avec le Golfe du Morbihan (moitié est utilisant le nouveau rendu, moitié ouest non, avec une limite verticale visible, au niveau 11, mais pas au niveau 12) Le 9 juin 2013 10:31, Christian Quest cqu...@openstreetmap.fr a écrit : Voilà la dernière évolution du rendu des réserves naturelles (les tuiles sont en cours de régénération car ça impacte à partir du zoom 10): http://tile.openstreetmap.fr/?zoom=13lat=47.29383lon=-2.44937layers=B0F -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Philippe: (les tuiles sont *en cours de régénération* car ça impacte à partir du zoom 10) So, patience... Yohan On 06/09/2013 11:11 AM, Philippe Verdy wrote: il y a un problème avec le Golfe du Morbihan (moitié est utilisant le nouveau rendu, moitié ouest non, avec une limite verticale visible, au niveau 11, mais pas au niveau 12) Le 9 juin 2013 10:31, Christian Quest cqu...@openstreetmap.fr mailto:cqu...@openstreetmap.fr a écrit : Voilà la dernière évolution du rendu des réserves naturelles (les tuiles sont en cours de régénération car ça impacte à partir du zoom 10): http://tile.openstreetmap.fr/?zoom=13lat=47.29383lon=-2.44937layers=B0F -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org mailto:Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Il faut lire aussi ce qui est entre parenthèses: les tuiles sont en cours de régénération car ça impacte à partir du zoom 10 ...en ce moment c'est le zoom 8 qui est en régénération sur les zooms 3 à 11... Ca devrait être terminé pour le pousse café dominical ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
J'attends encore de voir pour le parc marin de la Mer d'Iroise (car il semble que l'intérieur et l'extérieur sont inversés (le parc marin n'inclue pas les terres des îles elles mêmes, mais c'est ce qu'on voit sur les premières tuiles générées. Le 9 juin 2013 11:20, Christian Quest cqu...@openstreetmap.fr a écrit : Il faut lire aussi ce qui est entre parenthèses: les tuiles sont en cours de régénération car ça impacte à partir du zoom 10 ...en ce moment c'est le zoom 8 qui est en régénération sur les zooms 3 à 11... Ca devrait être terminé pour le pousse café dominical ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Il y a une anomalie de géométrie des buffers calculés, qui débordent quand ils partent d'un côté du polygone pour passer par dessus l'autre côté du polygone. Effet visible au sud de l'île de Groix (en mer). Aussi le vert utilisé pour les contours ombrés semble être trop contrasté, il devrait je pense être plus pâle, ou bien les niveaux de transparence pas bien réglés (réduire les valeur alpha). Au faible niveau de zoom, quand le parc naturel devient assez petit sur le rendu, on ne voit plus qu'une tâche d'un vert assez foncé, pas assez transparente (effet aggravé par le débordement apparent des ombres en dehors des polygones, comme signalé au paragraphe précédent). Le 9 juin 2013 11:20, Christian Quest cqu...@openstreetmap.fr a écrit : Il faut lire aussi ce qui est entre parenthèses: les tuiles sont en cours de régénération car ça impacte à partir du zoom 10 ...en ce moment c'est le zoom 8 qui est en régénération sur les zooms 3 à 11... Ca devrait être terminé pour le pousse café dominical ;) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Le 09/06/2013 10:31, Christian Quest a écrit : Voilà la dernière évolution du rendu des réserves naturelles (les tuiles sont en cours de régénération car ça impacte à partir du zoom 10): http://tile.openstreetmap.fr/?zoom=13lat=47.29383lon=-2.44937layers=B0F J'aime beaucoup ! Merci ! Mais là : La prison et le camp militaire apparaissent pareils. J'aime moins... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Le 09/06/2013 11:42, Philippe Verdy a écrit : Il y a une anomalie de géométrie des buffers calculés, qui débordent quand ils partent d'un côté du polygone pour passer par dessus l'autre côté du polygone. Effet visible au sud de l'île de Groix (en mer). Une url, ça aide... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] SOTM 2013... deadline pour les propositions de présentations
Le 09/06/2013 10:13, Christian Quest a écrit : Je viens de proposer une présentation autour de l'accessibilité comprenant intitulée OSM and accessibility: beyond wheelchair=* Le contenu que j'envisage (en vrac): - rappel de l'existant (wheelmap) - les différentes formes de handicap (utilisation de données OSM en rapport avec d'autres sens que la vue par les déficients visuels: l'odeur de la boulangerie, le bruit de la fontaine, etc) - le micromapping indoor: exemples à Orange - les collaborations avec les partenaires: Montpellier, Orange, Transilien - les outils de saisie, de visualisation - un rendu adapté - le thème porteur pour recruter de nouveaux contributeurs La deadline pour proposer des présentations c'est demain... si vous avez des idées, n'hésitez pas à en parler ici. J'en verrai bien une sur le data gardening, c'est à dire comment maintenir à jour les données, un thème qui sera de plus en plus important avec l'ancienneté du projet et le renouvellement des contributeurs actifs. Une présentation des créations françaises : * rendu tile.osm.fr et techniques employées, par exemple pour les terrains de foot. * services, genre umap En glissant quelque chose sur l'intégration du bâti et ses enjeux, notamment le fait que c'est quelque chose que se répand hors Hexagone... histoire d'enfoncer le clou. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] SOTM 2013... deadline pour les propositions de présentations
Le 09/06/2013 11:59, Vincent Pottier a écrit : Le 09/06/2013 10:13, Christian Quest a écrit : Je viens de proposer une présentation autour de l'accessibilité comprenant intitulée OSM and accessibility: beyond wheelchair=* Le contenu que j'envisage (en vrac): - rappel de l'existant (wheelmap) - les différentes formes de handicap (utilisation de données OSM en rapport avec d'autres sens que la vue par les déficients visuels: l'odeur de la boulangerie, le bruit de la fontaine, etc) - le micromapping indoor: exemples à Orange - les collaborations avec les partenaires: Montpellier, Orange, Transilien - les outils de saisie, de visualisation - un rendu adapté - le thème porteur pour recruter de nouveaux contributeurs La deadline pour proposer des présentations c'est demain... si vous avez des idées, n'hésitez pas à en parler ici. J'en verrai bien une sur le data gardening, c'est à dire comment maintenir à jour les données, un thème qui sera de plus en plus important avec l'ancienneté du projet et le renouvellement des contributeurs actifs. Une présentation des créations françaises : * rendu tile.osm.fr et techniques employées, par exemple pour les terrains de foot. * services, genre umap En glissant quelque chose sur l'intégration du bâti et ses enjeux, notamment le fait que c'est quelque chose que se répand hors Hexagone... histoire d'enfoncer le clou. Il y a aussi la possibilité de faire un poster, c'est peut-être plus approprié, en se basant sur la visite de Christian. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
http://tile.openstreetmap.fr/?zoom=11lat=47.61458lon=-3.39151layers=B0F Regarde bien le sud de l'île de Groix au zoom 11, et vois comment ça déborde (côté mer c'est plus facile à voir) par rapport au rendu du zoom 12. Les débordements sont encore plus accentués au zoom 10. Et ça explique pourquoi ces réserves semblent beaucoup plus étendues qu'elles ne sont, et trop visibles aussi. En fait cela affecte *toutes* les petites réserves. Le 9 juin 2013 11:53, Vincent Pottier vpott...@gmail.com a écrit : Le 09/06/2013 11:42, Philippe Verdy a écrit : Il y a une anomalie de géométrie des buffers calculés, qui débordent quand ils partent d'un côté du polygone pour passer par dessus l'autre côté du polygone. Effet visible au sud de l'île de Groix (en mer). Une url, ça aide... -- FrViPofm __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] SOTM 2013... deadline pour les propositions de présentations
Pour le rendu FR je pense qu'un poster suffira, ou alors il faut axer autrement, c'est à dire le côté non technique: comment garder la paternité du rendu OSM tout en l'adaptant localement. C'est un sujet de réflexion que j'ai entendu dans une présentation hier soir à San Francisco, justement celle d'Andy à propos du portage du style OSM en cartocss. La réflexion sur le but de telle ou telle évolution du rendu: - à qui s'adresse-t-il ? - comment le diffuser Avec les évolutions que va apporter TileMill2 (les tuiles vectorielles) nul doute qu'on va voir une explosion de rendus... Le 9 juin 2013 12:04, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Le 09/06/2013 11:59, Vincent Pottier a écrit : Le 09/06/2013 10:13, Christian Quest a écrit : Je viens de proposer une présentation autour de l'accessibilité comprenant intitulée OSM and accessibility: beyond wheelchair=* Le contenu que j'envisage (en vrac): - rappel de l'existant (wheelmap) - les différentes formes de handicap (utilisation de données OSM en rapport avec d'autres sens que la vue par les déficients visuels: l'odeur de la boulangerie, le bruit de la fontaine, etc) - le micromapping indoor: exemples à Orange - les collaborations avec les partenaires: Montpellier, Orange, Transilien - les outils de saisie, de visualisation - un rendu adapté - le thème porteur pour recruter de nouveaux contributeurs La deadline pour proposer des présentations c'est demain... si vous avez des idées, n'hésitez pas à en parler ici. J'en verrai bien une sur le data gardening, c'est à dire comment maintenir à jour les données, un thème qui sera de plus en plus important avec l'ancienneté du projet et le renouvellement des contributeurs actifs. Une présentation des créations françaises : * rendu tile.osm.fr et techniques employées, par exemple pour les terrains de foot. * services, genre umap En glissant quelque chose sur l'intégration du bâti et ses enjeux, notamment le fait que c'est quelque chose que se répand hors Hexagone... histoire d'enfoncer le clou. Il y a aussi la possibilité de faire un poster, c'est peut-être plus approprié, en se basant sur la visite de Christian. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Toujours mieux avec un permalien ! J'ai vu ces défauts sur les petits polygones. C'est lié à la technique utilisée (sans buffers postgis). Il va sûrement falloir changer l'épaisseur en fonction de la surface du polygone ou un truc du genre... Le 9 juin 2013 12:11, Philippe Verdy verd...@wanadoo.fr a écrit : http://tile.openstreetmap.fr/?zoom=11lat=47.61458lon=-3.39151layers=B0F Regarde bien le sud de l'île de Groix au zoom 11, et vois comment ça déborde (côté mer c'est plus facile à voir) par rapport au rendu du zoom 12. Les débordements sont encore plus accentués au zoom 10. Et ça explique pourquoi ces réserves semblent beaucoup plus étendues qu'elles ne sont, et trop visibles aussi. En fait cela affecte *toutes* les petites réserves. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
En gros l'anomalie c'est qu'en calculant un polygone de buffer supposé à l'intérieur du polygone de base, ce polygone calculé en partant d'un côté peut sortir du polygone de base. Pour l'éviter, il faut ensuite lui appliquer un clipping par le polygone de base. Et c'est ce clipping qui manque et provoque l'anomalie (qu'on constate aussi autour des pointes de toutes les réserves, même plus grandes, partout là où il y a des angles de plus de 90 degrés mesurés sur la distance de buffer et pas seulement entre deux segments immédiats connectés au même sommet). Techniquement je ne sais pas comment tu calcule les polygones, mais ce ne sont pas des buffers dans le système de coordonnées géographique, mais dans celui de la projection de rendu carto (coordonnées en pixels, donc à priori pas dans le code SQL lui-même, qui n'a besoin de retourner que le polygone externe de base avant la projection carto). Le 9 juin 2013 12:11, Philippe Verdy verd...@wanadoo.fr a écrit : http://tile.openstreetmap.fr/?zoom=11lat=47.61458lon=-3.39151layers=B0F Regarde bien le sud de l'île de Groix au zoom 11, et vois comment ça déborde (côté mer c'est plus facile à voir) par rapport au rendu du zoom 12. Les débordements sont encore plus accentués au zoom 10. Et ça explique pourquoi ces réserves semblent beaucoup plus étendues qu'elles ne sont, et trop visibles aussi. En fait cela affecte *toutes* les petites réserves. Le 9 juin 2013 11:53, Vincent Pottier vpott...@gmail.com a écrit : Le 09/06/2013 11:42, Philippe Verdy a écrit : Il y a une anomalie de géométrie des buffers calculés, qui débordent quand ils partent d'un côté du polygone pour passer par dessus l'autre côté du polygone. Effet visible au sud de l'île de Groix (en mer). Une url, ça aide... -- FrViPofm __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Bugs de libellés
Bonjour, J'ai trouvé les problèmes suivants : * Chantilly : quelqu'un a tagué ses chiens Fanfareau et Brillador. Du coup, le château n'est même pas indiqué sur la carte. À supprimer !? * Compiègne : le clos des roses apparaît plus gros que le nom de la ville suivant le zoom. À corriger. Pour info, je n'ai que mon smartphone ce week-end. J'ai du mal à écrire ce mél et encore plus à vous envoyer un lien ou à faire les corrections moi-même ;-) -- Yves Envoyé depuis un mobile___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Même constat: http://tile.openstreetmap.fr/?zoom=17lat=48.10082lon=-1.67405layers=B0F Ici la prison des femmes à Rennes, visible avec les hachures rouges miliaires au zoom 17+, mais rien de visible au niveau 16 ou moins, où on ne voit que les bâtiments. On voit aussi les icônes un peu étranges sur certains bâtiments au zoom 17+, aucune au niveau 16 ou moins. Ces icônes sont peu identifiables, et pourraient être améliorées (plutôt qu'un corps et une tête symbolisés, ce devrait être juste la tête et les mains tenant les barreaux, ou une icône monochrome un peu dans le style de la case de Monopoly). Une recherche Google fournit des collections d'icônes monochrome pour jail icon. exemples: http://www.shutterstock.com/pic.mhtml?id=85496875 http://www.canstockphoto.com/illustration/jail.html#file_view.php?id=13599481 (celles là ne sont pas libres, mais c'est l'idée générale) Le 9 juin 2013 11:52, Vincent Pottier vpott...@gmail.com a écrit : Le 09/06/2013 10:31, Christian Quest a écrit : Voilà la dernière évolution du rendu des réserves naturelles (les tuiles sont en cours de régénération car ça impacte à partir du zoom 10): http://tile.openstreetmap.fr/?**zoom=13lat=47.29383lon=-2.** 44937layers=B0Fhttp://tile.openstreetmap.fr/?zoom=13lat=47.29383lon=-2.44937layers=B0F J'aime beaucoup ! Merci ! Mais là : La prison et le camp militaire apparaissent pareils. J'aime moins... -- FrViPofm __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Je ne pense pas que changer les épaisseurs ne soient viable. Il me semble que c'est lalgo qui fait un calcul appromximatif des buffers dans le système de coordonnées en projection carto (pixels) qui est défaillant : on ne doit pas se contenter de calculer un segment parallèle et le joindre au segment suivant et précédent, il faut aussi clipper ces polygones pour qu'il ne sortent pas du polygone de base, et éliminer les parties interne en superposition multiples (c'est le principe compliqué de calcul géométrique des buffers, que réalise PostGIS dans le système de coordonées géographique, mais que tu n'utilises pas ici). Pour cela il existe des algos dans les bibliothèques graphiques, mais là je n'ai aucune idée de ce dont tu disposes dans ton code pour le faire, et si ta blibliothèque de rendu vectoriel le propose parmi ses utilitaires de transformation de géométries (ce n'est pas un algo proposé par défaut pour SVG ou Postscript par exemple) ; il y en a pour GDI+ ou Flash mais là je n'ai aucune idée des nterfaces que tu utilises pour convertir les géométries avant leur rendu vectoriel. Ces algos libres doivent pourtant exister car PostGIS a bien du les implémenter pour calculer ses propres buffers en coordonnées géographiques. Le 9 juin 2013 12:19, Christian Quest cqu...@openstreetmap.fr a écrit : Toujours mieux avec un permalien ! J'ai vu ces défauts sur les petits polygones. C'est lié à la technique utilisée (sans buffers postgis). Il va sûrement falloir changer l'épaisseur en fonction de la surface du polygone ou un truc du genre... Le 9 juin 2013 12:11, Philippe Verdy verd...@wanadoo.fr a écrit : http://tile.openstreetmap.fr/?zoom=11lat=47.61458lon=-3.39151layers=B0F Regarde bien le sud de l'île de Groix au zoom 11, et vois comment ça déborde (côté mer c'est plus facile à voir) par rapport au rendu du zoom 12. Les débordements sont encore plus accentués au zoom 10. Et ça explique pourquoi ces réserves semblent beaucoup plus étendues qu'elles ne sont, et trop visibles aussi. En fait cela affecte *toutes* les petites réserves. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Quelques pistes pour les algos de calculs de buffers de polygones: http://stackoverflow.com/questions/1109536/an-algorithm-for-inflating-deflating-offsetting-buffering-polygons Suivre les liens de cette discussion. La solution naïve que tu utilises n'est pas correcte mais le problème est connu et a des solutions. Plus de détails sur l'article suivant (avec un peu de code): http://www.cgal.org/Manual/3.2/doc_html/cgal_manual/Straight_skeleton_2/Chapter_main.html Le 9 juin 2013 12:50, Philippe Verdy verd...@wanadoo.fr a écrit : Je ne pense pas que changer les épaisseurs ne soient viable. Il me semble que c'est lalgo qui fait un calcul appromximatif des buffers dans le système de coordonnées en projection carto (pixels) qui est défaillant : on ne doit pas se contenter de calculer un segment parallèle et le joindre au segment suivant et précédent, il faut aussi clipper ces polygones pour qu'il ne sortent pas du polygone de base, et éliminer les parties interne en superposition multiples (c'est le principe compliqué de calcul géométrique des buffers, que réalise PostGIS dans le système de coordonées géographique, mais que tu n'utilises pas ici). Pour cela il existe des algos dans les bibliothèques graphiques, mais là je n'ai aucune idée de ce dont tu disposes dans ton code pour le faire, et si ta blibliothèque de rendu vectoriel le propose parmi ses utilitaires de transformation de géométries (ce n'est pas un algo proposé par défaut pour SVG ou Postscript par exemple) ; il y en a pour GDI+ ou Flash mais là je n'ai aucune idée des nterfaces que tu utilises pour convertir les géométries avant leur rendu vectoriel. Ces algos libres doivent pourtant exister car PostGIS a bien du les implémenter pour calculer ses propres buffers en coordonnées géographiques. Le 9 juin 2013 12:19, Christian Quest cqu...@openstreetmap.fr a écrit : Toujours mieux avec un permalien ! J'ai vu ces défauts sur les petits polygones. C'est lié à la technique utilisée (sans buffers postgis). Il va sûrement falloir changer l'épaisseur en fonction de la surface du polygone ou un truc du genre... Le 9 juin 2013 12:11, Philippe Verdy verd...@wanadoo.fr a écrit : http://tile.openstreetmap.fr/?zoom=11lat=47.61458lon=-3.39151layers=B0F Regarde bien le sud de l'île de Groix au zoom 11, et vois comment ça déborde (côté mer c'est plus facile à voir) par rapport au rendu du zoom 12. Les débordements sont encore plus accentués au zoom 10. Et ça explique pourquoi ces réserves semblent beaucoup plus étendues qu'elles ne sont, et trop visibles aussi. En fait cela affecte *toutes* les petites réserves. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net a écrit : Et en toute logique, il faudrait si on l'applique, le propager aussi aux boundary=administrative, à la place d'admin_level. Certainement pas (ou à la limite seulement dans les relations administratives (et qui ne sont QUE administratives et ne servent pas aussi de limites pour autre chose). L'ennui c'est pour les ways (fermés ou non) qui ont des utilisations multiples. Il se posera alors la question de savoir à quel autre tag présent sur ce way correspond ce level car justement le level n'est PAS orthogonal mais lié à un seul autre tag. C'est bien pour ça qu'on a un tag nommé admin_level (lié très fortement à boundary=administrative pour lui apporter une sous-précision) et qu'on a relevé un problème d'interprétation quant on l'a appliqué (à tord) sur les frontières religieuses (qui n'ont rien de commun avec des frontières administratives). Franchement je ne comprend pas l'utilité même de vouloir unifier des tags sous un même nom alors qu'ils ont des significations complètement diférentes et ne sont pas liés aux mêmes données (et clairement pas orthogonaux comme peuvent l'être name, url, wikipedia, natural, landuse et boundary). Il faudrait réfléchir plus sérieusement en terme de modélisation globale des données et de leur interprétation dans un ensemble beaucoup plus vaste qui en plus connaîtra des évolutions : un tel mélange de concepts dès le départ différents est nuisible assez vite et fait apparaître les anomalies. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] possibilité de mixer carte et vues aériennes en dehors d'un éditeur
parfait pour l'adresse http://wms.openstreetmap.fr/toulouse je ne connaissais pas, et ce n'est jamais ressorti au moement de mes recherches dans l'historique de la liste. 2 questions : imaginons que des communes adjacentes à Touliouse métropole veulent libérer leur orthophoto à qui doit-on s'adresser ? dans le nouveau service : umap.openstreetmap.fr je peux utiliser le rendu osmfr qui me convient très bien si je pouvais basculer sur l'orthophoto du Grand Toulouse quitte à rentrer moi-même l'adresse du serveur WMS Laurent Combe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le 09/06/2013 13:08, Philippe Verdy a écrit : Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net mailto:v...@laposte.net a écrit : Et en toute logique, il faudrait si on l'applique, le propager aussi aux boundary=administrative, à la place d'admin_level. Certainement pas (ou à la limite seulement dans les relations administratives (et qui ne sont QUE administratives et ne servent pas aussi de limites pour autre chose). Je veux bien un exemple d'une relation admin qui sert à autre chose. S'il y a réellement 2 notions, alors on fait 2 relations, quitte à ce qu'elles aient les mêmes membres. L'ennui c'est pour les ways (fermés ou non) qui ont des utilisations multiples. Il se posera alors la question de savoir à quel autre tag présent sur ce way correspond ce level car justement le level n'est PAS orthogonal mais lié à un seul autre tag. Ma proposition de généraliser boundary:level était surtout pour les relations, mais je ne l'ai pas précisé. Tu as raison de souligner la question des ways. Dans le cas des ways, il y aurait plusieurs possibilités. Je vois au moins : - garder le couple boundary=administrative+boundary:level=valeur actuelle d'admin_level (status quo, manière de reconnaître l'antériorité des limites admins dans de nombreux cas, les autres limites étant dérivées de celles-ci), - migrer vers le couple boundary=administrative+boundary:level=valeur actuelle d'admin_level = homogénéiser les tags entre ways et relations - aller au bout de la logique de boundary:level, et donc enlever des ways ce tag, vu qu'il peut, selon le type de limite décrite, avoir plusieurs valeurs pour le même way. Les ways seraient juste taggués type=boundary, sans référence à un niveau ni à un type de limite, ces 2 infos étant portées par chaque relation qui référence le way, - affecter boundary:level avec la plus petite valeur de 'level', issue de toutes les relations qui référencent le way (en gros ce qu'on fait déjà, juste pour les relations administratives) Bref, pas simple, et à discuter. Je penche personnellement pour la 3e proposition (enlever les tags). Mais c'est un peu radical vis-à-vis de l'existant... À court terme, ça me semble plus directement applicable aux relations elles-mêmes, quitte à faire cohabiter dans un premier temps pour des questions de compatibilité les tags admin_level et boundary:level. Franchement je ne comprend pas l'utilité même de vouloir unifier des tags sous un même nom alors qu'ils ont des significations complètement diférentes et ne sont pas liés aux mêmes données (et clairement pas orthogonaux comme peuvent l'être name, url, wikipedia, natural, landuse et boundary). La signification n'est pas la même, mai le concept, oui : on parle d'organisations hiérarchiques, où la notion de niveau (level) a tout son sens. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le 09/06/2013 13:08, Philippe Verdy a écrit : Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net mailto:v...@laposte.net a écrit : Et en toute logique, il faudrait si on l'applique, le propager aussi aux boundary=administrative, à la place d'admin_level. Tout à fait. Certainement pas (ou à la limite seulement dans les relations administratives (et qui ne sont QUE administratives et ne servent pas aussi de limites pour autre chose). L'ennui c'est pour les ways (fermés ou non) qui ont des utilisations multiples. Il se posera alors la question de savoir à quel autre tag présent sur ce way correspond ce level car justement le level n'est PAS orthogonal mais lié à un seul autre tag. C'est bien pour ça qu'on a un tag nommé admin_level (lié très fortement à boundary=administrative pour lui apporter une sous-précision) et qu'on a relevé un problème d'interprétation quant on l'a appliqué (à tord) sur les frontières religieuses (qui n'ont rien de commun avec des frontières administratives). ON, je en l'occurrence, l'ai appliqué après réflexion. On, Sly en l'occurrence, avait repéré un problème sur layers.osm.fr et a très bien réussi à le résoudre. ON, toi en l'occurrence, ne semble pas avoir perçu comment Sly avait résolu le problème sur layers.osm.fr Franchement je ne comprend pas l'utilité même de vouloir unifier des tags sous un même nom alors qu'ils ont des significations complètement diférentes et ne sont pas liés aux mêmes données (et clairement pas orthogonaux comme peuvent l'être name, url, wikipedia, natural, landuse et boundary). Franchement je ne comprends pas l'utilité de multiplier les clefs alors qu'une bonne logique booléenne résout les problèmes. Réemployer les mêmes clefs, ça permet de minimiser les clefs ! Ça permet d'alléger les tables dans postgres. Ça permet d'utiliser la logique plutôt que le bavardage. Il faudrait réfléchir plus sérieusement. Tout à fait. Tu peux t'y mettre. Heureusement que d'autres ont déjà commencé ! Ce qui permet d'utiliser des mêmes clefs secondaires conjointement avec des clefs primaires différentes : produce, operator... orthogonaux ou pas. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le cas des relations ayant les mêmes membres s'est déjà posé, parce que JOSM par exempel les signale comme des doublons, malgré leurs tags différents. Certains ne voient pas cela comme étant juste un warning destiné à vérifier qu'il n'y a pas doublon (ce qui cause aussi des problèmes de rendu ou d'analyse dans les applications), et cumulent dans la relation les tags destinés à des fonctions différentes. Dans ce cas, in ne sait plus comment interpréter ces tags Mais sur les éléments de géométrie de base (ways et noeuds), clairement il faut que les tags dont l'interprétation dépend directement d'un autre tag et pas d'un autre, il faut que ce tag soit clairement associé par son nom à cet autre tag qu'il sert à préciser. Ainsi admin_level a clairement été défini dès le départ pour ajouter une précision à boundary=administrative et certainement pas autre chose comme ce qui a été fait (en France seulement et à l'initiative en fait d'une seule personne qui l'a imposé partout sans réfléchir aux conséquences, notamment car le tag n'avait jamais été concu pour être utilisé à autre chose : les prérequis ne fonctionnaient plus, sur un tag qui était déjà très largement utilisé dans la façon dont il avait été décrit, et cette réutilisation abusive a cassé des applications existantes qui ne se sont pas adaptées car elles étaient basées sur les spécifications existantes). La prochaine fois que vous voulez étendre la signification d'un tag pour autre chose, réfléchissez un peu à la compatibilité. Et il ne suffit pas de compléter la doc sur le wiki, car cela resterea unilatéral alors que le tag est déjà utilisé d'une autre façon par énormément de monde qui n'a pas été consulté. Noter aussi que les relations ne sont pas les seuls moyens de représenter une zone: s'il n'y a pas lieu de découper les frontières parce qu'un élément de même type n'est pas présent à ses frontières, OSM suppose déjà qu'une relation n'est ni nécessaire, ni souhaitable (on ne veut pas de relation à un seul membre par exemple), et on se retrouve donc avec des chemins qui devraient disposer exactement des mêmes tags... Il n'y a pas à faire de dichotomie d'usage des tags entre relations, chemins et noeuds dans OSM, les mêmes tags doivent être utilisables pour les trois avec la même signification, et c'est bien plus important qu'une prétendue unification non nécessaire de tags en apparence identiques mais qui ont des rôles bien différents (le pire tag actuel étant type=* qui ne signifie plus rien de valable, devenu impossible à utiliser aujourd'hui et donc devenu clairement redondant et à remplacer partout par des tags spécialisés). Le 9 juin 2013 14:27, Vincent de Château-Thierry v...@laposte.net a écrit : Le 09/06/2013 13:08, Philippe Verdy a écrit : Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net mailto:v...@laposte.net a écrit : Et en toute logique, il faudrait si on l'applique, le propager aussi aux boundary=administrative, à la place d'admin_level. Certainement pas (ou à la limite seulement dans les relations administratives (et qui ne sont QUE administratives et ne servent pas aussi de limites pour autre chose). Je veux bien un exemple d'une relation admin qui sert à autre chose. S'il y a réellement 2 notions, alors on fait 2 relations, quitte à ce qu'elles aient les mêmes membres. L'ennui c'est pour les ways (fermés ou non) qui ont des utilisations multiples. Il se posera alors la question de savoir à quel autre tag présent sur ce way correspond ce level car justement le level n'est PAS orthogonal mais lié à un seul autre tag. Ma proposition de généraliser boundary:level était surtout pour les relations, mais je ne l'ai pas précisé. Tu as raison de souligner la question des ways. Dans le cas des ways, il y aurait plusieurs possibilités. Je vois au moins : - garder le couple boundary=administrative+**boundary:level=valeur actuelle d'admin_level (status quo, manière de reconnaître l'antériorité des limites admins dans de nombreux cas, les autres limites étant dérivées de celles-ci), - migrer vers le couple boundary=administrative+**boundary:level=valeur actuelle d'admin_level = homogénéiser les tags entre ways et relations - aller au bout de la logique de boundary:level, et donc enlever des ways ce tag, vu qu'il peut, selon le type de limite décrite, avoir plusieurs valeurs pour le même way. Les ways seraient juste taggués type=boundary, sans référence à un niveau ni à un type de limite, ces 2 infos étant portées par chaque relation qui référence le way, - affecter boundary:level avec la plus petite valeur de 'level', issue de toutes les relations qui référencent le way (en gros ce qu'on fait déjà, juste pour les relations administratives) Bref, pas simple, et à discuter. Je penche personnellement pour la 3e proposition (enlever les tags). Mais c'est un peu radical vis-à-vis de l'existant... À court terme, ça me semble plus directement applicable aux relations
Re: [OSM-talk-fr] Découpages des académies...
Les clés dans les extractions vers Postgres peuvent être réduites même sans réutiliser les tags dans OSM. Les requêtes faites dans les tables de features Postgres n'ont strictement rien à voir, les modèles de données sont complètement différents. Très mauvais argument donc. C'est hors sujet et ne justifie en rien le fait d'avoir des tags clairement séparés dans OSM (même au prix d'une prétendue économie de stockage, si les tags surchargés deviennent ambigus, non seulement on complique les requêtes d'exportation, mais en plus elles commence à retourner des données qui n'ont rien à voir et ne devraient pas être importées dans Postgres. Postgres n'a aucune obligation d'utiliser les mêmes clés OSM, il utilise des tables séparées pour chaque feature, et avec des colonnes dont les noms sont spécifiques à chaque table (le nom de la table elle-même les isole, même s'ils sont homonymes, ils peuvent donc y être simplifiés). Il n'y a PAS de clé dans Postgres dans un export GIS au même sens que dans OSM. Le 9 juin 2013 15:06, Vincent Pottier vpott...@gmail.com a écrit : Le 09/06/2013 13:08, Philippe Verdy a écrit : Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net a écrit : Et en toute logique, il faudrait si on l'applique, le propager aussi aux boundary=administrative, à la place d'admin_level. Tout à fait. Certainement pas (ou à la limite seulement dans les relations administratives (et qui ne sont QUE administratives et ne servent pas aussi de limites pour autre chose). L'ennui c'est pour les ways (fermés ou non) qui ont des utilisations multiples. Il se posera alors la question de savoir à quel autre tag présent sur ce way correspond ce level car justement le level n'est PAS orthogonal mais lié à un seul autre tag. C'est bien pour ça qu'on a un tag nommé admin_level (lié très fortement à boundary=administrative pour lui apporter une sous-précision) et qu'on a relevé un problème d'interprétation quant on l'a appliqué (à tord) sur les frontières religieuses (qui n'ont rien de commun avec des frontières administratives). ON, je en l’occurrence, l'ai appliqué après réflexion. On, Sly en l’occurrence, avait repéré un problème sur layers.osm.fr et a très bien réussi à le résoudre. ON, toi en l’occurrence, ne semble pas avoir perçu comment Sly avait résolu le problème sur layers.osm.fr Franchement je ne comprend pas l'utilité même de vouloir unifier des tags sous un même nom alors qu'ils ont des significations complètement diférentes et ne sont pas liés aux mêmes données (et clairement pas orthogonaux comme peuvent l'être name, url, wikipedia, natural, landuse et boundary). Franchement je ne comprends pas l'utilité de multiplier les clefs alors qu'une bonne logique booléenne résout les problèmes. Réemployer les mêmes clefs, ça permet de minimiser les clefs ! Ça permet d'alléger les tables dans postgres. Ça permet d’utiliser la logique plutôt que le bavardage. Il faudrait réfléchir plus sérieusement. Tout à fait. Tu peux t'y mettre. Heureusement que d'autres ont déjà commencé ! Ce qui permet d'utiliser des mêmes clefs secondaires conjointement avec des clefs primaires différentes : produce, operator... orthogonaux ou pas. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Philippe, Postgres n'a aucune obligation d'utiliser les mêmes clés OSM, il utilise des tables séparées pour chaque feature, et avec des colonnes dont les noms sont spécifiques à chaque table (le nom de la table elle-même les isole, même s'ils sont homonymes, ils peuvent donc y être simplifiés). Il n'y a PAS de clé dans Postgres dans un export GIS au même sens que dans OSM. Tu peux clarifier ce passage s'il te plaît. Je ne comprends pas ce que tu veux dire. Merci. A. -- Arnaud Vandecasteele SIG - WebMapping - Spatial Ontology - GeoCollaboration Web Site http://www.marinegis.com/?page_id=131 http://geotribu.net/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le 9 juin 2013 15:06, Vincent Pottier vpott...@gmail.com a écrit : Il faudrait réfléchir plus sérieusement. Tout à fait. Tu peux t'y mettre. Commence par te l'appliquer à toi-même. quand tu comprendras que la base OSM pour l'instant n'est pas structurée du tout comme une base GIS et que son modèle de données ne permet pas des distinctions aussi claires. Le seul moyen avec le modèle OSM plat de simuler les tables de features d'une base GIS c'est d'utiliser des conventions de préfixes pour nommer les tags (le préfixe deventant l'équivalent du nom de la table de feature externe, dans laquelle tu ne mélanges pas les choix et les carottes même si ce sont des légumes). Heureusement que d'autres ont déjà commencé ! Ce qui permet d'utiliser des mêmes clefs secondaires conjointement avec des clefs primaires différentes : produce, operator... orthogonaux ou pas. On en reparlera le jour où OSM commencera à supporter dans sa base directement des tables de features et pas seulement des objets indifférenciés, avec aussi l'intégration des schémas de données. Pour l'instant on n'y est pas (et ce n'est même pas envisagé). Alors soyons propre et évitons de tout mélanger (c'est déjà assez compliqué d'interroger la base OSM justement faute du moindre modèle de données). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le 09/06/2013 15:28, Philippe Verdy a écrit : Le cas des relations ayant les mêmes membres s'est déjà posé, parce que JOSM par exempel les signale comme des doublons, malgré leurs tags différents. Certains ne voient pas cela comme étant juste un warning destiné à vérifier qu'il n'y a pas doublon (ce qui cause aussi des problèmes de rendu ou d'analyse dans les applications), et cumulent dans la relation les tags destinés à des fonctions différentes. Dans ce cas, in ne sait plus comment interpréter ces tags Un exemple ? Un lien concret, je veux dire. Mais sur les éléments de géométrie de base (ways et noeuds), clairement il faut que les tags dont l'interprétation dépend directement d'un autre tag et pas d'un autre, il faut que ce tag soit clairement associé par son nom à cet autre tag qu'il sert à préciser. clairement est de trop dans ce paragraphe. Rien compris. La prochaine fois que vous voulez étendre la signification d'un tag pour autre chose, réfléchissez un peu à la compatibilité. Et il ne suffit pas de compléter la doc sur le wiki, car cela resterea unilatéral alors que le tag est déjà utilisé d'une autre façon par énormément de monde qui n'a pas été consulté. réfléchissez un peu à la compatibilité : ça me semble assez bien résumer ce qu'on essaie de faire dans ce fil. Noter aussi que les relations ne sont pas les seuls moyens de représenter une zone: s'il n'y a pas lieu de découper les frontières parce qu'un élément de même type n'est pas présent à ses frontières, OSM suppose déjà qu'une relation n'est ni nécessaire, ni souhaitable (on ne veut pas de relation à un seul membre par exemple), et on se retrouve donc avec des chemins qui devraient disposer exactement des mêmes tags... Une zone, non. Mais un _découpage_ , si. Sauf à dupliquer les frontières, ce qu'on ne fait pas dans OSM. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
J'ai l'impression que j'aurai du mal à expliquer ça vu qu'apparemment tu ne sais pas ce qu'est une base SQL, un modèle de données, et un schéma. Ce que je peux dire c'est qu'OSM est structuré comme si tout était un seul feature unique réunissant tous les features qu'une base GIS normale utilise (y compris les bases utilisées pour faire tous les rendus OSM actuels, car ils ne peuvent pas travailler directement avec le pseudo-schéma OSM où tout est mélangé et horriblement compliqué, sans faire d'abord une traduction, et c'est dans cette traduction que cela se complique énormément dès qu'on commence à réutiliser des tags identiques pour des usages très différents qui n'ont pas à figurer dans la même table de feature externe). La solutoin basée sur des combinaisons booléennes n'est qu'une heuristique, avec des tas d'erreurs. Ce n'est pas viable, et cela échouera dès que quelqu'un tentera à nouveau de surcharger les mêmes tags pour encore un nouvel usage. Bref les requêtes sont de plus en plus compliquées et sans cesse à corriger. C'est une véritable perte de temps et un gachis de ressources sur les serveurs qui doivent faire encore plus de travail. Le 9 juin 2013 15:39, arnaud@gmail.com arnaud@gmail.com a écrit : Philippe, Postgres n'a aucune obligation d'utiliser les mêmes clés OSM, il utilise des tables séparées pour chaque feature, et avec des colonnes dont les noms sont spécifiques à chaque table (le nom de la table elle-même les isole, même s'ils sont homonymes, ils peuvent donc y être simplifiés). Il n'y a PAS de clé dans Postgres dans un export GIS au même sens que dans OSM. Tu peux clarifier ce passage s'il te plaît. Je ne comprends pas ce que tu veux dire. Merci. A. -- --**--** Arnaud Vandecasteele SIG - WebMapping - Spatial Ontology - GeoCollaboration Web Site http://www.marinegis.com/?**page_id=131http://www.marinegis.com/?page_id=131 http://geotribu.net/ __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le 9 juin 2013 15:46, Vincent de Château-Thierry v...@laposte.net a écrit : Noter aussi que les relations ne sont pas les seuls moyens de représenter une zone: s'il n'y a pas lieu de découper les frontières parce qu'un élément de même type n'est pas présent à ses frontières, OSM suppose déjà qu'une relation n'est ni nécessaire, ni souhaitable (on ne veut pas de relation à un seul membre par exemple), et on se retrouve donc avec des chemins qui devraient disposer exactement des mêmes tags... Une zone, non. Mais un _découpage_ , si. Sauf à dupliquer les frontières, ce qu'on ne fait pas dans OSM. Ah bon ??? Comment ne pas oublier le cas des îles (maritimes, ou îles d'un découpage autre que terre/mer). Je maintiens qu'on se retrouve à gérer aussi bien des relations (pour éviter un partage) ou pas de relation du tout (chemin fermé) pour les mêmes types d'objets, et qu'il n'y a pas lieu de les taguer différemment, MÊME et SURTOUT si on éviter de dupliquer les frontières. On a par exemple une règle admise dans la base OSM qui est de ne PAS créer de relation pour un seul membre, ce qui impose de descendre les tags de la relation vers le chemin ou le noued membre et supprimer cette relation parasite (ou ne pas en créer). De fait les tags sont conservés, et doivent pouvoir se mélanger librement sans conflit d'interprétation. Et pas question d'utiliser des tags différents selon que c'est une relation ou un chemin ou un noeud. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
On 09/06/2013 11:18, Philippe Verdy wrote: J'ai l'impression que j'aurai du mal à expliquer ça vu qu'apparemment tu ne sais pas ce qu'est une base SQL, un modèle de données, et un schéma. Oui tu as raison avec un doctorant en informatique, je ne sais pas ce que je sais... Je t'ai demandé dans mon 1er mail, de manière fort polie, de clarifier tes propos. Maintenant je vais le faire d'une manière moins protocolaire. Ton mail précédent, tout comme celui-ci, ne sont qu'une suite de mots, à consonance technique, sans fondements. Mais bon ce ne sera pas la première fois que tu affirmes quelque chose de complètement faux, nous y sommes habitués. La solutoin basée sur des combinaisons booléennes n'est qu'une heuristique, avec des tas d'erreurs. Ce n'est pas viable, et cela échouera dès que quelqu'un tentera à nouveau de surcharger les mêmes tags pour encore un nouvel usage. Bref les requêtes sont de plus en plus compliquées et sans cesse à corriger. C'est une véritable perte de temps et un gachis de ressources sur les serveurs qui doivent faire encore plus de travail. Philippe, honnêtement as-tu, ne serait ce qu'une fois dans ta vie, importé une base OSM et effectué des requêtes? Si oui, je serai heureux de voir un bout de code, même une requête. Car à part brasser du vide, tu ne fais pas avancer grand chose. Ne te sens surtout pas obligé de répondre. A moins que tu ne souhaites vraiment que je redise sur la liste tes 4 vérités. Arnaud ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le 09/06/2013 15:33, Philippe Verdy a écrit : Les clés dans les extractions vers Postgres peuvent être réduites même sans réutiliser les tags dans OSM. Les requêtes faites dans les tables de features Postgres n'ont strictement rien à voir, les modèles de données sont complètement différents. Postgres n'a aucune obligation d'utiliser les mêmes clés OSM, il utilise des tables séparées pour chaque feature, et avec des colonnes dont les noms sont spécifiques à chaque table (le nom de la table elle-même les isole, même s'ils sont homonymes, ils peuvent donc y être simplifiés). Encore une belle illustration de ton ignorance bavarde. Prends un jour le temps de mouliner des données brutes OSM dans une base Postgres via osm2pgsql ou osmosis, qui sont je pense les deux technologies les plus populaires pour charger les données en base. Tu apprendras comment ces logiciels fonctionnent, et ça t'éviteras ce genre de couplet 100% erroné. Il n'y a PAS de clé dans Postgres dans un export GIS au même sens que dans OSM. Encore une phrase qui ne veut rien dire. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Encore un lot de nouveautés dans Osmose
Le 08/06/2013 20:13, François Lacombe a écrit : Bonjour et merci pour cette liste de mises à jour :) Le 8 juin 2013 15:26, Frédéric Rodrigo fred.rodr...@gmail.com mailto:fred.rodr...@gmail.com a écrit : * Type de ligne électrique en fonction du voltage (line/minor_line) http://osmose.openstreetmap.__fr/fr/map/?item=7040class=__70401level=1,2,3 http://osmose.openstreetmap.fr/fr/map/?item=7040class=70401level=1,2,3 http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement power=minor_line pourrait être déprécier ainsi que bon nombre d'autres tags au profit de power=line. C'est pas encore en RFC mais ca mérite un petit coup d'oeuil. Ok, je désactive dans ce cas. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Vous le faites exprès ou quoi pour ne pas comprendre ? Si vous avez des compétences en bases de données (c'est aussi mon boulot, me^me si ça ne vous semble pas évident) ne feignez pas de rien comprendre. OSM n'a dans sa table qu'une table unique (en fait 3 pour séparer seulement noeuds, chemins et relations, plus des tables annexes pour les membres de relation), et les 3 tables utilisent une table unique pour tous les tags (type d'objet=un des 3, id, clé, valeur). Juste de quoi reproduire ce qu'on voit dans les requêtes XML de son API et rien de plus. OSM n'a aucune table de feature, il n'a aucune structure relationelle (ou si peu que ce n'est pas utilisable et qu'on doit tout convertir avec des requêtes déjà compliquées) qui permette de faire ce qu'on a dans un rendu quelconque (où par exemple on stocke séparément les routes, les voies ferrées, les villes, les forêts, etc... le nombre de tables générées étant dépendant de chaque application et de ce qu'elle souhaite représenter). Le 9 juin 2013 16:00, Vincent de Château-Thierry v...@laposte.net a écrit : Le 09/06/2013 15:33, Philippe Verdy a écrit : Les clés dans les extractions vers Postgres peuvent être réduites même sans réutiliser les tags dans OSM. Les requêtes faites dans les tables de features Postgres n'ont strictement rien à voir, les modèles de données sont complètement différents. Postgres n'a aucune obligation d'utiliser les mêmes clés OSM, il utilise des tables séparées pour chaque feature, et avec des colonnes dont les noms sont spécifiques à chaque table (le nom de la table elle-même les isole, même s'ils sont homonymes, ils peuvent donc y être simplifiés). Encore une belle illustration de ton ignorance bavarde. Prends un jour le temps de mouliner des données brutes OSM dans une base Postgres via osm2pgsql ou osmosis, qui sont je pense les deux technologies les plus populaires pour charger les données en base. Tu apprendras comment ces logiciels fonctionnent, et ça t'éviteras ce genre de couplet 100% erroné. Il n'y a PAS de clé dans Postgres dans un export GIS au même sens que dans OSM. Encore une phrase qui ne veut rien dire. vincent __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le 09/06/2013 16:18, Philippe Verdy a écrit : Vous le faites exprès ou quoi pour ne pas comprendre ? Si vous avez des compétences en bases de données (c'est aussi mon boulot, me^me si ça ne vous semble pas évident) ne feignez pas de rien comprendre. OSM n'a dans sa table qu'une table unique (en fait 3 pour séparer seulement noeuds, chemins et relations, plus des tables annexes pour les membres de relation), et les 3 tables utilisent une table unique pour tous les tags (type d'objet=un des 3, id, clé, valeur). Juste de quoi reproduire ce qu'on voit dans les requêtes XML de son API et rien de plus. OSM n'a aucune table de feature, il n'a aucune structure relationelle (ou si peu que ce n'est pas utilisable et qu'on doit tout convertir avec des requêtes déjà compliquées) qui permette de faire ce qu'on a dans un rendu quelconque (où par exemple on stocke séparément les routes, les voies ferrées, les villes, les forêts, etc... le nombre de tables générées étant dépendant de chaque application et de ce qu'elle souhaite représenter). Philippe, Si tu veux survivre plus de cinq minutes à l'incrédulité générale et au fait de passer irrémédiablement pour un c**, je te conseille de nous poster le schéma de tes tables postgis ou le lien vers un schéma que tu utilises. Sinon, je crois qu'on fera tienne cette devinette : La différence entre Philippe et un ventilateur ? Et bien je vous laisse deviner ! ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le 09/06/2013 15:41, Philippe Verdy a écrit : Le 9 juin 2013 15:06, Vincent Pottier vpott...@gmail.com mailto:vpott...@gmail.com a écrit : Il faudrait réfléchir plus sérieusement. Tout à fait. Tu peux t'y mettre. Commence par te l'appliquer à toi-même. Merci, c'est fait. quand tu comprendras que la base OSM pour l'instant n'est pas structurée du tout comme une base GIS et que son modèle de données ne permet pas des distinctions aussi claires. Le seul moyen avec le modèle OSM plat de simuler les tables de features d'une base GIS c'est d'utiliser des conventions de préfixes pour nommer les tags (le préfixe deventant l'équivalent du nom de la table de feature externe, dans laquelle tu ne mélanges pas les choix et les carottes même si ce sont des légumes). Heureusement que d'autres ont déjà commencé ! Ce qui permet d'utiliser des mêmes clefs secondaires conjointement avec des clefs primaires différentes : produce, operator... orthogonaux ou pas. On en reparlera le jour où OSM commencera à supporter dans sa base directement des tables de features et pas seulement des objets indifférenciés, avec aussi l'intégration des schémas de données. Pour l'instant on n'y est pas (et ce n'est même pas envisagé). Alors soyons propre et évitons de tout mélanger (c'est déjà assez compliqué d'interroger la base OSM justement faute du moindre modèle de données). As-tu déjà essayé sur une base osm2psql quelque chose du genre : SELECT name, way FROM france_polygon WHERE boundary='administrative' AND admin_level='8' Si oui, alors on en reparlera... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Pour la troisième fois: je n'utilise aucun buffer mais un line-pattern. C'est un petit PNG qui est dessiné par Mapnik sur le pourtour du polygone et quand les angles sont trop aigus, ça bave un peu en dérapant dans le virage. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] possibilité de mixer carte et vues aériennes en dehors d'un éditeur
C'est dans la todo list de ybon... pouvoir indiquer un layer de son choix en plus de ceux proposés par défaut. A ce sujet, j'en ai ajouté 3: - OSM Mapnik monochrome - Open MapQuest US (légèrement différent du rendu Europe) - Outdoors Le 9 juin 2013 13:56, Laurent Combe laurent.co...@free.fr a écrit : parfait pour l'adresse http://wms.openstreetmap.fr/toulouse je ne connaissais pas, et ce n'est jamais ressorti au moement de mes recherches dans l'historique de la liste. 2 questions : imaginons que des communes adjacentes à Touliouse métropole veulent libérer leur orthophoto à qui doit-on s'adresser ? dans le nouveau service : umap.openstreetmap.fr je peux utiliser le rendu osmfr qui me convient très bien si je pouvais basculer sur l'orthophoto du Grand Toulouse quitte à rentrer moi-même l'adresse du serveur WMS Laurent Combe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Mauvaise méthode donc. Tu fais comment pour dessiner les routes ? Tu utilises bien des lignes en précisant une épaisseur de trait et le moteur de rendu vectoriel calcule un polygone à remplir (ce qui se fait dans le moteur graphique un buffer, non ?) Tout moteur graphique vectoriel (par exemple SVG ou Postscript) fait ainsi : en fait il ne trace pas des lignes mais remplit un polygone. Même pour faire des lignes avec un pattern (tirets, pointillés, ...), ce sont encore des polygones qui sont créés avant d'être remplis. Je ne sais pas ce qu'est ton line-pattern (je n'ai pas le détail de ce que fais ton code) mais ce que tu décris n'a rien à voir avec la terminologie habituelle dans les moteurs vectoriels, où il ne s'agit pas du tout de répéter une image le long d'un trait virtuel. Quand une image est utilisée c'est uniquement pour appliquer une texture pour le remplissage, ou pour des techniques dites de screening (en Postscript par exemple setscreen) destinée à produire des patterns pour produire des demi-tons (halftoning, en Postscript), très utilisés pour l'impression (encre sur papier, que ce soit par lithographie, ou jet d'encre dans les imprimantes, ou sur les lasers, avec des paramètres tenant compte de la diffusion de l'encre sur le papier, de la qualité du papier, de la nature des particules ou goutelettes d'encres, des techniques de fixation, séchage ou cuisson de l'encre, ou de l'opacité des encres en cas de superposition d'encres, etc.). Le 9 juin 2013 16:54, Christian Quest cqu...@openstreetmap.fr a écrit : Pour la troisième fois: je n'utilise aucun buffer mais un line-pattern. C'est un petit PNG qui est dessiné par Mapnik sur le pourtour du polygone et quand les angles sont trop aigus, ça bave un peu en dérapant dans le virage. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Le 9 juin 2013 10:31, Christian Quest cqu...@openstreetmap.fr a écrit : Voilà la dernière évolution du rendu des réserves naturelles (les tuiles sont en cours de régénération car ça impacte à partir du zoom 10): http://tile.openstreetmap.fr/?zoom=13lat=47.29383lon=-2.44937layers=B0F Et avec cette limite verte comment fera-t-on le jour où nous voudrons enregistrer une souris verte dans une réserve naturelle ? Nous ne le pourrons pas ! Déjà avec une forêt verte ça fonctionne moyen la preuve : http://tile.openstreetmap.fr/?zoom=15lat=45.43078lon=4.24989layers=B0F Je pense qu'il faudrait rendre en jaune, car il n'y a ni souris ni forêts jaunes. Et aussi le nom de la réserve a disparu dans le rendu fr, est-ce normal ?... la même dans le rendu osm indique Réserve naturelle des gorges de la Loire - http://osm.org/go/0ApBb0ik-- -- Les dérives de rue : Le projet de théâtre de Saint-Étienne emporté par le venthttp://drivrsdu.fr/le-projet-de-theatre-de-saint-etienne-emporte-par-le-vent/ http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Justement oui, mais tu ne parles pas là du tout de la base OSM elle-même ! Ta base osm2psql n'a rien à voir, c'est le résultat d'un import avec un script de conversion ecrit en C qui effectue des sous-selection compliquées pour traduire le schéma OSM en features importés dans ta base. Bref tu fais encore semblant de ne pas comprendre que les deux bases n'ont absolument rien à voir entre elles, les tables n'ont pas du tout le même structure, et là vous êtres en train de décider quelquechose pour la base OSM (les noms des tags), alors que ces tags sont totalement inexistants dans ta requête donnée en exemple (ta requête contient juste des noms de colonnes dans une table de feature appelée france_polygon). Le 9 juin 2013 16:50, Vincent Pottier vpott...@gmail.com a écrit : Le 09/06/2013 15:41, Philippe Verdy a écrit : Le 9 juin 2013 15:06, Vincent Pottier vpott...@gmail.com a écrit : Il faudrait réfléchir plus sérieusement. Tout à fait. Tu peux t'y mettre. Commence par te l'appliquer à toi-même. Merci, c'est fait. quand tu comprendras que la base OSM pour l'instant n'est pas structurée du tout comme une base GIS et que son modèle de données ne permet pas des distinctions aussi claires. Le seul moyen avec le modèle OSM plat de simuler les tables de features d'une base GIS c'est d'utiliser des conventions de préfixes pour nommer les tags (le préfixe deventant l'équivalent du nom de la table de feature externe, dans laquelle tu ne mélanges pas les choix et les carottes même si ce sont des légumes). Heureusement que d'autres ont déjà commencé ! Ce qui permet d'utiliser des mêmes clefs secondaires conjointement avec des clefs primaires différentes : produce, operator... orthogonaux ou pas. On en reparlera le jour où OSM commencera à supporter dans sa base directement des tables de features et pas seulement des objets indifférenciés, avec aussi l'intégration des schémas de données. Pour l'instant on n'y est pas (et ce n'est même pas envisagé). Alors soyons propre et évitons de tout mélanger (c'est déjà assez compliqué d'interroger la base OSM justement faute du moindre modèle de données). As-tu déjà essayé sur une base osm2psql quelque chose du genre : SELECT name, way FROM france_polygon WHERE boundary='administrative' AND admin_level='8' Si oui, alors on en reparlera... -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le 9 juin 2013 16:18, Philippe Verdy verd...@wanadoo.fr a écrit : Vous le faites exprès ou quoi pour ne pas comprendre ? Si vous avez des compétences en bases de données (c'est aussi mon boulot, me^me si ça ne vous semble pas évident) ne feignez pas de rien comprendre. OSM n'a dans sa table qu'une table unique (en fait 3 pour séparer seulement noeuds, chemins et relations, plus des tables annexes pour les membres de relation), et les 3 tables utilisent une table unique pour tous les tags (type d'objet=un des 3, id, clé, valeur). Juste de quoi reproduire ce qu'on voit dans les requêtes XML de son API et rien de plus. Le schéma de la base utilisé par l'API est destiné à un unique usage: le fonctionnement de l'API d'édition. Ce schéma ne tire même pas partie de PostGIS car cela ne lui servirai à pas grand chose. Ce schéma n'a donc aucun rapport avec l'usage qu'on peut faire des données. C'est d'ailleurs ce que j'explique souvent: les données OSM n'ont pas de structure prédéterminée autre que sémantique, on est dans une logique NoSQL et en fonction de l'usage qu'on veut en faire (rendu, géocodage, routage, etc) on va les structurer de telle ou telle façon (d'où des schémas différents proposés par osm2pgsql, osmosis ou imposm). Tes propos, bien que paraissant cohérents, sont purement théoriques et ne reposent visiblement sur aucune expérience pratique. Pour faire un rendu avec un schéma osm2pgsql, on utilise seulement 3 tables: - une pour les objets ponctuels, - une pour les objets linéaires, - une pour les objets surfaciques. Contrairement à ce que tu crois, routes, voies ferrées, lignes électriques sont dans une seule et même table: planet_osm_line Les polygones de découpages admin (donc les villes), les landuse (donc les forêts), les terrains de sports sont dans la table planet_osm_polygon Philippe, si tu pouvais prendre le temps de te renseigner sérieusement ça ferai gagner du temps à pas mal de monde: - ceux qui lisent et qui savent et qui vont perdre du temps à corriger tes affirmations, - ceux qui lisent et ne savent pas qu'il faut prendre avec des pincettes tes affirmations (l'unique raison qui fait que je lis encore tes messages et que j'y réponds). -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Le 9 juin 2013 17:14, Philippe Verdy verd...@wanadoo.fr a écrit : Mauvaise méthode donc. Tu fais comment pour dessiner les routes ? Tu utilises bien des lignes en précisant une épaisseur de trait et le moteur de rendu vectoriel calcule un polygone à remplir (ce qui se fait dans le moteur graphique un buffer, non ?) Tout moteur graphique vectoriel (par exemple SVG ou Postscript) fait ainsi : en fait il ne trace pas des lignes mais remplit un polygone. Même pour faire des lignes avec un pattern (tirets, pointillés, ...), ce sont encore des polygones qui sont créés avant d'être remplis. Je ne sais pas ce qu'est ton line-pattern (je n'ai pas le détail de ce que fais ton code) mais ce que tu décris n'a rien à voir avec la terminologie habituelle dans les moteurs vectoriels, où il ne s'agit pas du tout de répéter une image le long d'un trait virtuel. https://github.com/mapnik/mapnik/wiki/LinePatternSymbolizer Je croyais avoir déjà mis le lien. Et pour le code (qui n'est pas le mien): https://github.com/mapnik/mapnik/blob/master/src/line_pattern_symbolizer.cpp -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Tombelaine, Tombelaine, Tombelaine et pas Rouen
Bonjour, Quelqu'un a-t-il une minuscule idée du pourquoi du comment le rocher de tombelaine s'appelle rocher de tombelaine normalement et tout le temps, sauf au zoom 15 où il s'appelle Rouen ?? http://osm.org/go/ermtshRW-- http://fr.wikipedia.org/wiki/Tombelaine -- Les dérives de rue : Le projet de théâtre de Saint-Étienne emporté par le venthttp://drivrsdu.fr/le-projet-de-theatre-de-saint-etienne-emporte-par-le-vent/ http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Point d'eau agricole
Bonjour, Je veux saisir un point d'eau agricole [1] mais tout ce que je trouve dans le wiki c'est waterway=water_point [2] pour un point d'eau potable. Quelqu'un aurait une idée comment tagguer ce genre d'installation? Rainer [1] http://cruvierslascours.blogs.midilibre.com/media/02/00/631611651.jpg [2] http://wiki.openstreetmap.org/wiki/Tag:waterway%3Dwater_point ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Enfin tu commences à comprendre ! Les tags dans OSM ne sont pas ce que tu utilises dans ta base issue d'un export et d'une traduction avec osm2pgsql (ou autre chose) vers une base GIS. Toute la discussion portait sur les tables OSM qui n'ont pas de structure (tu l'admets enfin), donc ont besoin d'avoir des tags précis (sinon c'est ton script de traduction osm2pgsql qui va se tromper...) Maintenant si ton problème est que tu mélanges tous les polygones surfaciques dans ta base dans la même table, avec nécessité de créer une colonne pour chaque tag distinct, et si ta base de données limite le nombre de colonnes possibles par table, alors oui tu as un problème dans ta base, mais ce n'est pas le problème d'OSM lui-même. Parce sur tu aurais pu tout autant séparer ces polygones pour avoir une base bien plus facile à exploiter. Tu auras de toute façon autant de problème à distinguer les objets importés de cette façon que dans les données OSM initiales, si tu as mélangé les tags en en surchargeant certains pour des rôles différents. C'est toi qui sur ta base prend la décision de faire ce schéma GIS ultrasimplifié, réduit à pas grand chose d'utilisable. Et même si tu mets tes polygones dans la même table (en fait uniquement pour stoker la géométrie), ta base SQL peut encore stocker les tags par type de feature dans des tables séparées. A mon avis c'est une des premières choses que tu dois faire après cet import avant de pouvoir continuer, tu es amené à grouper un certain nombre de polygones, chercher des équivalences, ou ignorer certaines différences pour les unifier. Une partie de ce traval sera fait dans ton script osm2pgsql modifié localement selon tes besoins, plutôt que d'avoir à le faire après import dans ta base. OSM dans sa base ne t'impose absolument pas de tout mélanger, et c'est ton script osm2pgsql (dont il existe autant de versions que de moteurs de rendu à l'utiliser) qui a besoin d'être amélioré pour mieux classer les choses. C'est toi qu iest entièrement responsable de ton schéma interne, qui ne nous intéresse pas dans la base OSM (donc on n'a pas à être gêné par ça pour nommer correctement et distinguer les tags, qu'en fait tu n'utilises plus directement dans ta base issue de ta propre traduction). Le 9 juin 2013 17:28, Christian Quest cqu...@openstreetmap.fr a écrit : Le 9 juin 2013 16:18, Philippe Verdy verd...@wanadoo.fr a écrit : Vous le faites exprès ou quoi pour ne pas comprendre ? Si vous avez des compétences en bases de données (c'est aussi mon boulot, me^me si ça ne vous semble pas évident) ne feignez pas de rien comprendre. OSM n'a dans sa table qu'une table unique (en fait 3 pour séparer seulement noeuds, chemins et relations, plus des tables annexes pour les membres de relation), et les 3 tables utilisent une table unique pour tous les tags (type d'objet=un des 3, id, clé, valeur). Juste de quoi reproduire ce qu'on voit dans les requêtes XML de son API et rien de plus. Le schéma de la base utilisé par l'API est destiné à un unique usage: le fonctionnement de l'API d'édition. Ce schéma ne tire même pas partie de PostGIS car cela ne lui servirai à pas grand chose. Ce schéma n'a donc aucun rapport avec l'usage qu'on peut faire des données. C'est d'ailleurs ce que j'explique souvent: les données OSM n'ont pas de structure prédéterminée autre que sémantique, on est dans une logique NoSQL et en fonction de l'usage qu'on veut en faire (rendu, géocodage, routage, etc) on va les structurer de telle ou telle façon (d'où des schémas différents proposés par osm2pgsql, osmosis ou imposm). Tes propos, bien que paraissant cohérents, sont purement théoriques et ne reposent visiblement sur aucune expérience pratique. Pour faire un rendu avec un schéma osm2pgsql, on utilise seulement 3 tables: - une pour les objets ponctuels, - une pour les objets linéaires, - une pour les objets surfaciques. Contrairement à ce que tu crois, routes, voies ferrées, lignes électriques sont dans une seule et même table: planet_osm_line Les polygones de découpages admin (donc les villes), les landuse (donc les forêts), les terrains de sports sont dans la table planet_osm_polygon Philippe, si tu pouvais prendre le temps de te renseigner sérieusement ça ferai gagner du temps à pas mal de monde: - ceux qui lisent et qui savent et qui vont perdre du temps à corriger tes affirmations, - ceux qui lisent et ne savent pas qu'il faut prendre avec des pincettes tes affirmations (l'unique raison qui fait que je lis encore tes messages et que j'y réponds). -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tombelaine, Tombelaine, Tombelaine et pas Rouen
encore un effet de bord de la frontière religieuse (pseudo aministrative). Il se trouve que le long d'une frontière peuvent apparaître les noms de toutes les relations qui la référence : on voit donc le nom de l'objet lui-même (si la ligne de côte est nommée), le nom de la commune, de l'arrondissement, du département, de la région, des cantons ou circonscriptions, et des divisions religieuses (ici un évêché). Quels noms seront affichés ou pas, et où c'est imprévisible avec Mapnik et cela change selon le niveau de zoom. Le 9 juin 2013 17:35, Ista Pouss ista...@gmail.com a écrit : Bonjour, Quelqu'un a-t-il une minuscule idée du pourquoi du comment le rocher de tombelaine s'appelle rocher de tombelaine normalement et tout le temps, sauf au zoom 15 où il s'appelle Rouen ?? http://osm.org/go/ermtshRW-- http://fr.wikipedia.org/wiki/Tombelaine -- Les dérives de rue : Le projet de théâtre de Saint-Étienne emporté par le venthttp://drivrsdu.fr/le-projet-de-theatre-de-saint-etienne-emporte-par-le-vent/ http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tombelaine, Tombelaine, Tombelaine et pas Rouen
En plus cela dépend de quel moteur de rendu tu parles, même si c'est du Mapnik on n'a pas la même chose entre le rendu d'osm.org, celui de 2u, ou celui d'OSM.fr, ou ceux de Mapquest, uMap, etc. Le 9 juin 2013 17:35, Ista Pouss ista...@gmail.com a écrit : Bonjour, Quelqu'un a-t-il une minuscule idée du pourquoi du comment le rocher de tombelaine s'appelle rocher de tombelaine normalement et tout le temps, sauf au zoom 15 où il s'appelle Rouen ?? http://osm.org/go/ermtshRW-- http://fr.wikipedia.org/wiki/Tombelaine -- Les dérives de rue : Le projet de théâtre de Saint-Étienne emporté par le venthttp://drivrsdu.fr/le-projet-de-theatre-de-saint-etienne-emporte-par-le-vent/ http://drivrsdu.fr/profession-emotion/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le 09/06/2013 17:47, Philippe Verdy a écrit : Enfin tu commences à comprendre ! Toi, pas. Les tags dans OSM ne sont pas ce que tu utilises dans ta base issue d'un export et d'une traduction avec osm2pgsql (ou autre chose) vers une base GIS. Si, les tags dans OSM sont traduits dans ma base postgis. Toute la discussion portait sur les tables OSM qui n'ont pas de structure (tu l'admets enfin), donc ont besoin d'avoir des tags précis (sinon c'est ton script de traduction osm2pgsql qui va se tromper...) Toute ? Non ! (voir le début d'une célèbre BD gauloise) Tes propos, Philippe. Tes propos portent sur des tables OSM. Et je ne suis même pas sur que tu sois allé voir le schéma. Maintenant si ton problème... Mon problème ? Mais Philippe, on est nombreux à utiliser les données OSM sur base de donnée locale. C'est toi qui sur ta base prend la décision de faire ce schéma GIS ultrasimplifié, réduit à pas grand chose d'utilisable. Philippe. DONNE-NOUS LE SCHÉMA DE TA BASE MIRACLE ! ou arête de dire des âneries. (et je reste poli !) -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Non je ne parlais pas du code source ce la bibliothèque que tu utilises, mais TON code dans ton moteur de rendu. A mon avis au lieu des LinePatternSymbolizer, cela marcherait mieux avec PolyOffsetBuilder dans https://github.com/mapnik/mapnik/blob/master/deps/clipper/src/clipper.cpp (Clipper contient tout un stock d'algorithmes de calcul et dérivation de géométries) Le 9 juin 2013 17:33, Christian Quest cqu...@openstreetmap.fr a écrit : Le 9 juin 2013 17:14, Philippe Verdy verd...@wanadoo.fr a écrit : Mauvaise méthode donc. Tu fais comment pour dessiner les routes ? Tu utilises bien des lignes en précisant une épaisseur de trait et le moteur de rendu vectoriel calcule un polygone à remplir (ce qui se fait dans le moteur graphique un buffer, non ?) Tout moteur graphique vectoriel (par exemple SVG ou Postscript) fait ainsi : en fait il ne trace pas des lignes mais remplit un polygone. Même pour faire des lignes avec un pattern (tirets, pointillés, ...), ce sont encore des polygones qui sont créés avant d'être remplis. Je ne sais pas ce qu'est ton line-pattern (je n'ai pas le détail de ce que fais ton code) mais ce que tu décris n'a rien à voir avec la terminologie habituelle dans les moteurs vectoriels, où il ne s'agit pas du tout de répéter une image le long d'un trait virtuel. https://github.com/mapnik/mapnik/wiki/LinePatternSymbolizer Je croyais avoir déjà mis le lien. Et pour le code (qui n'est pas le mien): https://github.com/mapnik/mapnik/blob/master/src/line_pattern_symbolizer.cpp -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Le 9 juin 2013 17:47, Philippe Verdy verd...@wanadoo.fr a écrit : Toute la discussion portait sur les tables OSM qui n'ont pas de structure (tu l'admets enfin), donc ont besoin d'avoir des tags précis (sinon c'est ton script de traduction osm2pgsql qui va se tromper...) La notion de table OSM n'a pas de sens... c'est ça que je voulais surtout faire passer comme idée, mais visiblement ça te dépasse peut être à cause d'un ancrage trop fort dans les notions GIS historiques. Maintenant si ton problème est que tu mélanges tous les polygones surfaciques dans ta base dans la même table, avec nécessité de créer une colonne pour chaque tag distinct, et si ta base de données limite le nombre de colonnes possibles par table, alors oui tu as un problème dans ta base, mais ce n'est pas le problème d'OSM lui-même. Parce sur tu aurais pu tout autant séparer ces polygones pour avoir une base bien plus facile à exploiter. Tu auras de toute façon autant de problème à distinguer les objets importés de cette façon que dans les données OSM initiales, si tu as mélangé les tags en en surchargeant certains pour des rôles différents. C'est toi qui sur ta base prend la décision de faire ce schéma GIS ultrasimplifié, réduit à pas grand chose d'utilisable. Visiblement tu ne connais pas osm2pgsql, car c'est comme ça que cet outil (très largement utilisé faut-il le rappeler) fonctionne. Je n'ai fait aucun choix sur ce schéma. Et même si tu mets tes polygones dans la même table (en fait uniquement pour stoker la géométrie), ta base SQL peut encore stocker les tags par type de feature dans des tables séparées. A mon avis c'est une des premières choses que tu dois faire après cet import avant de pouvoir continuer, tu es amené à grouper un certain nombre de polygones, chercher des équivalences, ou ignorer certaines différences pour les unifier. Une partie de ce traval sera fait dans ton script osm2pgsql modifié localement selon tes besoins, plutôt que d'avoir à le faire après import dans ta base. Aucune modification de script pour ma part. osm2pgsql est utilisé tel quel. OSM dans sa base ne t'impose absolument pas de tout mélanger, et c'est ton script osm2pgsql (dont il existe autant de versions que de moteurs de rendu à l'utiliser) qui a besoin d'être amélioré pour mieux classer les choses. Bon, c'est confirmé... pour combler tes lacunes sur osm2pgsql c'est ici que ça se passe: http://wiki.openstreetmap.org/wiki/Osm2pgsql C'est toi qu iest entièrement responsable de ton schéma interne, qui ne nous intéresse pas dans la base OSM (donc on n'a pas à être gêné par ça pour nommer correctement et distinguer les tags, qu'en fait tu n'utilises plus directement dans ta base issue de ta propre traduction). Et pourtant... j'utilise les tags directement, étonnant non ? Les tags sont stockés en hstore (nommé tags avec une extrême originalité donc). Au cas où, voilà le lien pour te documenter : http://wiki.openstreetmap.org/wiki/Osm2pgsql#hstore Dans notre cas (vous vous souvenez, les académies), cela donnerai: SELECT way FROM planet_osm_polygon WHERE boundary='educational AND tags-'boundary:level'=5; Dernier post sur le hors-sujet pour moi. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Découpages des académies...
Désolé mais on ne parle visiblement pas de la même chose. Pas la peine d'accuser l'autre de ses lacunes puisque dès le départ vous avez confondu (avec insistance en plus, ce qui est pourtant faux !) la base OSM avec vos bases Pgsql traduites par un script spécifique (tuné en fonction de Mapnik le plus souvent). Tout cela n'a rien à voir avec les tags d'OSM, j'insiste, c'est votre cuisine locale. Et même si vous conservez les tags dans un hstore vous aurez les mêmes ambiguités à résoudre si elles ne sont pas résolues dès le départ dans la base OSM (non structurée). Ce hstore en passant n'a aucune problème à garder les tags OSM originaux, puisqu'en fait votre base ne l'utilise que comme source de métafonnées annexes, dans un vrac aussi informe que la bae OSM d'origine. Personnellement je n'utilise pas du tout Mapnik (en fait je ne fais que visualiser des rendus effectués par d'autres, mais ce n'est pas les seuls rendus que je visualise) ce n'est pas mon problème et je n'en ai absolument pas besoin (et plein de monde utilisant les données d'OSM n'en a pas besoin non plus et n'est pas gêné par les restrictions ou insuffisances ou limitations de Mapnik). Et je ne vois pas pourquoi OSM devrait être contraint par ce que sait (ou ne sait pas) faire Mapnik. Bien au contraire, si on est plus précis dans la base OSM, c'est Mapnik qui aura moins de difficultés à interpréter les résultats puisqu'il n'aura plus d'ambiguités. Le 9 juin 2013 18:27, Christian Quest cqu...@openstreetmap.fr a écrit : Le 9 juin 2013 17:47, Philippe Verdy verd...@wanadoo.fr a écrit : Toute la discussion portait sur les tables OSM qui n'ont pas de structure (tu l'admets enfin), donc ont besoin d'avoir des tags précis (sinon c'est ton script de traduction osm2pgsql qui va se tromper...) La notion de table OSM n'a pas de sens... c'est ça que je voulais surtout faire passer comme idée, mais visiblement ça te dépasse peut être à cause d'un ancrage trop fort dans les notions GIS historiques. Maintenant si ton problème est que tu mélanges tous les polygones surfaciques dans ta base dans la même table, avec nécessité de créer une colonne pour chaque tag distinct, et si ta base de données limite le nombre de colonnes possibles par table, alors oui tu as un problème dans ta base, mais ce n'est pas le problème d'OSM lui-même. Parce sur tu aurais pu tout autant séparer ces polygones pour avoir une base bien plus facile à exploiter. Tu auras de toute façon autant de problème à distinguer les objets importés de cette façon que dans les données OSM initiales, si tu as mélangé les tags en en surchargeant certains pour des rôles différents. C'est toi qui sur ta base prend la décision de faire ce schéma GIS ultrasimplifié, réduit à pas grand chose d'utilisable. Visiblement tu ne connais pas osm2pgsql, car c'est comme ça que cet outil (très largement utilisé faut-il le rappeler) fonctionne. Je n'ai fait aucun choix sur ce schéma. Et même si tu mets tes polygones dans la même table (en fait uniquement pour stoker la géométrie), ta base SQL peut encore stocker les tags par type de feature dans des tables séparées. A mon avis c'est une des premières choses que tu dois faire après cet import avant de pouvoir continuer, tu es amené à grouper un certain nombre de polygones, chercher des équivalences, ou ignorer certaines différences pour les unifier. Une partie de ce traval sera fait dans ton script osm2pgsql modifié localement selon tes besoins, plutôt que d'avoir à le faire après import dans ta base. Aucune modification de script pour ma part. osm2pgsql est utilisé tel quel. OSM dans sa base ne t'impose absolument pas de tout mélanger, et c'est ton script osm2pgsql (dont il existe autant de versions que de moteurs de rendu à l'utiliser) qui a besoin d'être amélioré pour mieux classer les choses. Bon, c'est confirmé... pour combler tes lacunes sur osm2pgsql c'est ici que ça se passe: http://wiki.openstreetmap.org/wiki/Osm2pgsql C'est toi qu iest entièrement responsable de ton schéma interne, qui ne nous intéresse pas dans la base OSM (donc on n'a pas à être gêné par ça pour nommer correctement et distinguer les tags, qu'en fait tu n'utilises plus directement dans ta base issue de ta propre traduction). Et pourtant... j'utilise les tags directement, étonnant non ? Les tags sont stockés en hstore (nommé tags avec une extrême originalité donc). Au cas où, voilà le lien pour te documenter : http://wiki.openstreetmap.org/wiki/Osm2pgsql#hstore Dans notre cas (vous vous souvenez, les académies), cela donnerai: SELECT way FROM planet_osm_polygon WHERE boundary='educational AND tags-'boundary:level'=5; Dernier post sur le hors-sujet pour moi. -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org
Re: [OSM-talk-fr] Point d'eau agricole
On a abordé ce sujet il y a peu sur la liste Il y a un tag pour les abreuvoirs : http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwatering_place La discussion sur les points d'eau hors de la ville et la relative portabilité date d'une semaine il me semble tu devrais la retrouver rapidement. Le dimanche 9 juin 2013, RainerU a écrit : Bonjour, Je veux saisir un point d'eau agricole [1] mais tout ce que je trouve dans le wiki c'est waterway=water_point [2] pour un point d'eau potable. Quelqu'un aurait une idée comment tagguer ce genre d'installation? Rainer [1] http://cruvierslascours.blogs.midilibre.com/media/02/00/631611651.jpg [2] http://wiki.openstreetmap.org/wiki/Tag:waterway%3Dwater_point ___ Talk-fr mailing list Talk-fr@openstreetmap.org javascript:; http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Le 9 juin 2013 18:26, Philippe Verdy verd...@wanadoo.fr a écrit :
https://github.com/mapnik/mapnik/blob/master/deps/clipper/src/clipper.cpp
PolyOffsetBuilder, très bien , mais non exposé par mapnik. Essaies encore.
Sinon je propose l'utilisation des opérations de filtrages et composition
de mapnik. Ca doit résoudre les artefacts, mais c'est sans doute plus
délicat à intégrer dans les règles osm-fr.
J'ai bidouillé un peu, mais j'ai encore du mal avec la gestion des couches
lors de ces opérations!
Un premier exemple (en carto)
#limites[type = 'farm'] {
::outline {
line-width:10;
line-color: green;
image-filters: agg-stack-blur(5,5);
}
polygon-fill: black;
// polygon-smooth : 0.2;
comp-op: dst-in;
}
https://docs.google.com/file/d/0ByriFLbxzg_1ekcyV3FZRHFsNms/edit?usp=sharing
Second exemple :
#limites[type = 'residential'] {
::trait{line-width:0.5;}
::hach{
polygon-pattern-file: url('Diagonal_Pattern_clip_art_hight.png');
}
line-width:10;
line-color: black;
image-filters: agg-stack-blur(10,10);
comp-op: dst-in;
}
https://docs.google.com/file/d/0ByriFLbxzg_1M1hwQUJIZnN5QkE/edit?usp=sharing
Source infinie d'inspiration :
http://www.mapbox.com/tilemill/docs/guides/comp-op/
Bruno
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Et en pratique ce support est intégré dans le LineSymbolizer:
if (sym.clip())
{
double padding = (double)(query_extent_.width()/width_);
double half_stroke = stroke_.get_width()/2.0;
if (half_stroke 1)
padding *= half_stroke;
if (std::fabs(sym.offset()) 0)
padding *= std::fabs(sym.offset()) * 1.2;
padding *= scale_factor_;
clipping_extent.pad(padding);
}
voir https://github.com/mapnik/mapnik/blob/master/src/cairo_renderer.cpp
Bref on fait le rendu avec les attributs offset et width donnés dans la
feuille de style pour le LineSymbolizer, le reste c'est le rendu PNG de
Cairo (ou le rendu en SVG) qui se débrouille pour calculer les buffers
corrects (et je pense même que ce sera bien plus performant que tes
symboles marqueurs en répétés en pattern sur une distance de 1 pixel le
long d'une ligne, la technique qui ne sert en pratique qu'à dessiner les
triangles le long des traits de falaises à distance régulière).
Peut-être qu'il faut bidouiller le code C++ de Mapnik pour activer la bonne
combinaison d'options, mais tout y est pour supporter ça, et ensuite
pouvoir l'utiliser dans la feuille de style XML.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
A noter que ce serait pas mal que Mapnik supporte directement dans ses
feuilles de style XML la possibilité de préciser le côté de l'épaisseur de
ligne qu'on veut afficher (par défaut il affiche les deux côtés,
moitié-moitié à cheval sur le ligne virtuelle), on devrait pouvoir indiquer
une option both (valeur par défaut actuelle), inner ou outer (pour
ne représenter que la moitié interne ou externe du polygone), ou left ou
right (en fonction du sens de parcours, sur les éléments linéaires non
surfaciques).
Le code ci-dessus (qui étend le clipping de la moitié de l'épaisseur de
ligne pourqu'elle reste visible en totalité) devrait être désactivé si on
ne représente que la partie interne, et dans ce cas il suffirait de mettre
clip=false dans l'attribut de style de ligne (mais cela a un effet de bord
car il n'est pas fait pour que pour ça).
Intérêt: pouvoir afficher aussi le long d'une route un coté remarquable
comme sur les cartes Michelin pour les routes touristiques, ou pour créer
des ombres autour de bâtiments à mettre en valeur (mais pas dedans). Ou
encore pour marquer les bons côtés où il y a une piste cyclable, une voie
de bus, ou du stationnement autorisé, ou le côté où il y a une barrière de
sécurité, ou un fossé.
Le 9 juin 2013 19:52, Philippe Verdy verd...@wanadoo.fr a écrit :
Et en pratique ce support est intégré dans le LineSymbolizer:
if (sym.clip())
{
double padding = (double)(query_extent_.width()/width_);
double half_stroke = stroke_.get_width()/2.0;
if (half_stroke 1)
padding *= half_stroke;
if (std::fabs(sym.offset()) 0)
padding *= std::fabs(sym.offset()) * 1.2;
padding *= scale_factor_;
clipping_extent.pad(padding);
}
voir https://github.com/mapnik/mapnik/blob/master/src/cairo_renderer.cpp
Bref on fait le rendu avec les attributs offset et width donnés dans la
feuille de style pour le LineSymbolizer, le reste c'est le rendu PNG de
Cairo (ou le rendu en SVG) qui se débrouille pour calculer les buffers
corrects (et je pense même que ce sera bien plus performant que tes
symboles marqueurs en répétés en pattern sur une distance de 1 pixel le
long d'une ligne, la technique qui ne sert en pratique qu'à dessiner les
triangles le long des traits de falaises à distance régulière).
Peut-être qu'il faut bidouiller le code C++ de Mapnik pour activer la
bonne combinaison d'options, mais tout y est pour supporter ça, et ensuite
pouvoir l'utiliser dans la feuille de style XML.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM-FR à SIG La Lettre... besoin de troupes !
Le 16/04/2013 10:53, Vincent de Chateau-Thierry a écrit : Bonjour, De : rldhont Je serais au FROG puis au Code Sprint OSGEO-fr donc aux Rencontres SIG-la-lettre! Je pense en fait passez plus de temps sur l'OpenData Bar qu'au Code Sprint ;-) Donc compte sur moi René-Luc P.S: j'essayerais d're à la réunion IRC de demain soir. Je serai présent 1 des 3 jours (jour à définir selon les besoins sur le stand). Je serai finalement sur place a priori mercredi journée. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM-FR à SIG La Lettre... besoin de troupes !
Donc... Lundi (FROG): Fred, Marc, René-Luc, Christian (d'autres seront présents ?) Mardi: Fred, Marc, René-Luc, Nicolas, Christian Mercredi: Fred, Vincent, René-Luc, Nicolas, Christian Jeudi: Fred, René-Luc, Nicolas, Christian Le 9 juin 2013 22:30, Vincent de Château-Thierry v...@laposte.net a écrit : Le 16/04/2013 10:53, Vincent de Chateau-Thierry a écrit : Bonjour, De : rldhont Je serais au FROG puis au Code Sprint OSGEO-fr donc aux Rencontres SIG-la-lettre! Je pense en fait passez plus de temps sur l'OpenData Bar qu'au Code Sprint ;-) Donc compte sur moi René-Luc P.S: j'essayerais d're à la réunion IRC de demain soir. Je serai présent 1 des 3 jours (jour à définir selon les besoins sur le stand). Je serai finalement sur place a priori mercredi journée. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] RE : Re: OSM-FR à SIG La Lettre... besoin de troupes !
Je serais demain à FROG jusqu'à 15h :-) Envoyé depuis un mobileChristian Quest cqu...@openstreetmap.fr a écrit :Donc... Lundi (FROG): Fred, Marc, René-Luc, Christian (d'autres seront présents ?) Mardi: Fred, Marc, René-Luc, Nicolas, Christian Mercredi: Fred, Vincent, René-Luc, Nicolas, Christian Jeudi: Fred, René-Luc, Nicolas, Christian Le 9 juin 2013 22:30, Vincent de Château-Thierry v...@laposte.net a écrit : Le 16/04/2013 10:53, Vincent de Chateau-Thierry a écrit : Bonjour, De : rldhont Je serais au FROG puis au Code Sprint OSGEO-fr donc aux Rencontres SIG-la-lettre! Je pense en fait passez plus de temps sur l'OpenData Bar qu'au Code Sprint ;-) Donc compte sur moi René-Luc P.S: j'essayerais d're à la réunion IRC de demain soir. Je serai présent 1 des 3 jours (jour à définir selon les besoins sur le stand). Je serai finalement sur place a priori mercredi journée. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] RE : Re: OSM-FR à SIG La Lettre... besoin de troupes !
Je me fais aussi la semaine complète, Lundi, je viens avec des copains qui sont sur le projet gis-blog.fr Le reste de la semaine, je ferai certaines conférences mais on pourra voir ensemble pour tenir le stand. Sinon, il y a une intéressante présentation de Alyssa Wright sur le SOTM US en ce moment, Elle y aborde le genre et osm . ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Nouvelle mouture: http://tile.openstreetmap.fr/?zoom=11lat=47.42028lon=-2.41356layers=B0F (tuiles regénérées dans le coin à coup de /dirty) C'est fait avec 4 lignes, décalées par line-offset et avec une opacité qui décroit. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] SOTM 2013... deadline pour les propositions de présentations
Bravo pour l'inspiration. Je continue d'insister pour que d'ici là les entrées soient valorisées : entrance=yes/main,exit,emergency... cquest wrote Pour le rendu FR je pense qu'un poster suffira, ou alors il faut axer autrement, c'est à dire le côté non technique: comment garder la paternité du rendu OSM tout en l'adaptant localement. C'est un sujet de réflexion que j'ai entendu dans une présentation hier soir à San Francisco, justement celle d'Andy à propos du portage du style OSM en cartocss. La réflexion sur le but de telle ou telle évolution du rendu: - à qui s'adresse-t-il ? - comment le diffuser Avec les évolutions que va apporter TileMill2 (les tuiles vectorielles) nul doute qu'on va voir une explosion de rendus... Le 9 juin 2013 12:04, Frédéric Rodrigo lt; fred.rodrigo@ gt; a écrit : Le 09/06/2013 11:59, Vincent Pottier a écrit : Le 09/06/2013 10:13, Christian Quest a écrit : Je viens de proposer une présentation autour de l'accessibilité comprenant intitulée OSM and accessibility: beyond wheelchair=* Le contenu que j'envisage (en vrac): - rappel de l'existant (wheelmap) - les différentes formes de handicap (utilisation de données OSM en rapport avec d'autres sens que la vue par les déficients visuels: l'odeur de la boulangerie, le bruit de la fontaine, etc) - le micromapping indoor: exemples à Orange - les collaborations avec les partenaires: Montpellier, Orange, Transilien - les outils de saisie, de visualisation - un rendu adapté - le thème porteur pour recruter de nouveaux contributeurs La deadline pour proposer des présentations c'est demain... si vous avez des idées, n'hésitez pas à en parler ici. J'en verrai bien une sur le data gardening, c'est à dire comment maintenir à jour les données, un thème qui sera de plus en plus important avec l'ancienneté du projet et le renouvellement des contributeurs actifs. Une présentation des créations françaises : * rendu tile.osm.fr et techniques employées, par exemple pour les terrains de foot. * services, genre umap En glissant quelque chose sur l'intégration du bâti et ses enjeux, notamment le fait que c'est quelque chose que se répand hors Hexagone... histoire d'enfoncer le clou. Il y a aussi la possibilité de faire un poster, c'est peut-être plus approprié, en se basant sur la visite de Christian. Frédéric. ___ Talk-fr mailing list Talk-fr@ http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Un nouveau serveur pour OSM... http://donate.osm.org/server2013/ ___ Talk-fr mailing list Talk-fr@ http://lists.openstreetmap.org/listinfo/talk-fr - Cordialement, ZIMMY Jean-Louis ZIMMERMANN Développeur territorial (ville d'Orange,FR84) Mandataire OSM-France sur le Grand-Sud-est -- View this message in context: http://gis.19327.n5.nabble.com/SOTM-2013-deadline-pour-les-propositions-de-presentations-tp5764641p5764745.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] rendu osm-fr et réserves naturelles
Cette fois ça marche, plus d'aberrations géométriques avec ces débordements. Je remarque que tu as réduit l'épaisseur notablement, l'effet d'opacité décroissante est moins visible, et parfois le tracé disparaît lorsque la réserve longe une route (la route recouvre tout le tracé). Le 10 juin 2013 00:07, Christian Quest cqu...@openstreetmap.fr a écrit : Nouvelle mouture: http://tile.openstreetmap.fr/?zoom=11lat=47.42028lon=-2.41356layers=B0F (tuiles regénérées dans le coin à coup de /dirty) C'est fait avec 4 lignes, décalées par line-offset et avec une opacité qui décroit. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
