date:20130609

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  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-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=13&lat=47.29383&lon=-2.44937&layers=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  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=13&lat=47.29383&lon=-2.44937&layers=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  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=13&lat=47.29383&lon=-2.44937&layers=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  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=13&lat=47.29383&lon=-2.44937&layers=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

2013-06-09 Par sujet Yohan Boniface


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 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=13&lat=47.29383&lon=-2.44937&layers=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




___
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  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  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=13&lat=47.29383&lon=-2.44937&layers=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

2013-06-09 Par sujet Frédéric Rodrigo


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=11&lat=47.61458&lon=-3.39151&layers=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  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-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  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  a écrit :
> http://tile.openstreetmap.fr/?zoom=11&lat=47.61458&lon=-3.39151&layers=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  a écrit :

>
> http://tile.openstreetmap.fr/?zoom=11&lat=47.61458&lon=-3.39151&layers=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  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-fr
>>
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Bugs de libellés

2013-06-09 Par sujet Yves Pratter

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=17&lat=48.10082&lon=-1.67405&layers=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  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=13&lat=47.29383&lon=-2.**
>> 44937&layers=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
>
___
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 l"algo 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  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  a écrit :
> >
> http://tile.openstreetmap.fr/?zoom=11&lat=47.61458&lon=-3.39151&layers=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  a écrit :

> Je ne pense pas que changer les épaisseurs ne soient viable. Il me semble
> que c'est l"algo 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  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  a écrit :
>> >
>> http://tile.openstreetmap.fr/?zoom=11&lat=47.61458&lon=-3.39151&layers=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  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

2013-06-09 Par sujet Laurent Combe

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 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=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=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 > 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  a écrit
:

>
> Le 09/06/2013 13:08, Philippe Verdy a écrit :
>
>> Le 8 juin 2013 16:05, Vincent de Château-Thierry > > 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= 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= 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 direct

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  a écrit :

>  Le 09/06/2013 13:08, Philippe Verdy a écrit :
>
> Le 8 juin 2013 16:05, Vincent de Château-Thierry  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...

2013-06-09 Par sujet arnaud....@gmail.com


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  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  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=131
> http://geotribu.net/
>
>
>
> __**_
> 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 15:46, Vincent de Château-Thierry  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...

2013-06-09 Par sujet arnaud....@gmail.com


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

2013-06-09 Par sujet Frédéric Rodrigo


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 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=7040&class=__70401&level=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  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-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 > 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  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  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

2013-06-09 Par sujet Ista Pouss

Le 9 juin 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=13&lat=47.29383&lon=-2.44937&layers=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=15&lat=45.43078&lon=4.24989&layers=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
vent

___
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  a écrit :

>  Le 09/06/2013 15:41, Philippe Verdy a écrit :
>
>
>
>
> Le 9 juin 2013 15:06, Vincent Pottier  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  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  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

2013-06-09 Par sujet Ista Pouss

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
vent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Point d'eau agricole

2013-06-09 Par sujet RainerU

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  a écrit :

> Le 9 juin 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.
> >
>
> 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/li

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  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 
> vent
> 
>
> ___
> 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  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 
> vent
> 
>
> ___
> 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  a écrit :

> Le 9 juin 2013 17:14, Philippe Verdy  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  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  a écrit :

> Le 9 juin 2013 17:47, Philippe Verdy  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/
>
> _

Re: [OSM-talk-fr] Point d'eau agricole

2013-06-09 Par sujet Tetsuo Shima

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 
> 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

2013-06-09 Par sujet Bruno Cortial

Le 9 juin 2013 18:26, Philippe Verdy  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  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  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 !

2013-06-09 Par sujet Yves Pratter

Je serais demain à FROG jusqu'à 15h :-)


Envoyé depuis un mobileChristian Quest  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  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 !

2013-06-09 Par sujet bobo

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=11&lat=47.42028&lon=-2.41356&layers=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

2013-06-09 Par sujet ZIMMY

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 <

> fred.rodrigo@

> > 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