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,
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
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
Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net a écrit
:
Et en toute logique, il faudrait si on l'applique, le propager aussi aux
boundary=administrative, à la place d'admin_level.
Certainement pas (ou à la limite seulement dans les relations
administratives (et qui ne
Le 09/06/2013 13:08, Philippe Verdy a écrit :
Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net
mailto:v...@laposte.net a écrit :
Et en toute logique, il faudrait si on l'applique, le propager aussi
aux boundary=administrative, à la place d'admin_level.
Certainement
Le 09/06/2013 13:08, Philippe Verdy a écrit :
Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net
mailto:v...@laposte.net a écrit :
Et en toute logique, il faudrait si on l'applique, le propager
aussi aux boundary=administrative, à la place d'admin_level.
Tout à fait.
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
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
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
Le 9 juin 2013 15:06, Vincent Pottier vpott...@gmail.com a écrit :
Il faudrait réfléchir plus sérieusement.
Tout à fait. Tu peux t'y mettre.
Commence par te l'appliquer à toi-même. quand tu comprendras que la base
OSM pour l'instant n'est pas structurée du tout comme une base GIS et que
son
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
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
Le 9 juin 2013 15:46, Vincent de Château-Thierry v...@laposte.net a écrit
:
Noter aussi que les relations ne sont pas les seuls moyens de
représenter une zone: s'il n'y a pas lieu de découper les frontières
parce qu'un élément de même type n'est pas présent à ses frontières, OSM
suppose
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é
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.
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
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
Le 09/06/2013 15:41, Philippe Verdy a écrit :
Le 9 juin 2013 15:06, Vincent Pottier vpott...@gmail.com
mailto:vpott...@gmail.com a écrit :
Il faudrait réfléchir plus sérieusement.
Tout à fait. Tu peux t'y mettre.
Commence par te l'appliquer à toi-même.
Merci, c'est fait.
quand
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
Le 9 juin 2013 16:18, Philippe Verdy verd...@wanadoo.fr a écrit :
Vous le faites exprès ou quoi pour ne pas comprendre ? Si vous avez des
compétences en bases de données (c'est aussi mon boulot, me^me si ça ne vous
semble pas évident) ne feignez pas de rien comprendre.
OSM n'a dans sa table
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
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
Le 9 juin 2013 17:47, Philippe Verdy verd...@wanadoo.fr a écrit :
Toute la discussion portait sur les tables OSM qui n'ont pas de structure
(tu l'admets enfin), donc ont besoin d'avoir des tags précis (sinon c'est
ton script de traduction osm2pgsql qui va se tromper...)
La notion de table OSM
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
admin_level vaut pour boundary=administrative, on a vu l'effet pervers
de l'utiliser ailleurs (Nominatim qui ressort les diocèses par
exemple).
Si il est utile, un boundary:level serait plus cohérent, non ?
Par contre un petit tag pour indiquer la zone A/B/C de vacances y
aurait bien sa place...
Le samedi 8 juin 2013 08:36:02 Christian Quest a écrit :
admin_level vaut pour boundary=administrative, on a vu l'effet pervers
de l'utiliser ailleurs (Nominatim qui ressort les diocèses par
exemple).
Si il est utile, un boundary:level serait plus cohérent, non ?
Je verrai plutôt
pourquoi a-t-on même besoin d'un level pour les académies ? C'est quoi la
hiérarchie envisagée ???
N'est pas suffisant d'avoir boundary=educational (meilleur terme en anglais
pour le secteur éducatif) ?
Ou l'idée c'est de créer la carte scolaire locale (qui en fait est du
ressort des
Ca fait penser à un niveau d'éducation plus qu'un niveau de découpage
et l'intérêt c'est que boundary:level pourrait être utilisé sur
d'autres types de découpages (religieux par exemple).
Multiplier les clés de tags ne me semble pas une bonne idée, mais bon
c'est qu'une impression.
Le 8 juin
Le niveau d'éducation serait en fait plutôt educational:grade, non ?
Sinon on a déjà des tags de classification française pour les écoles
maternelles primaires, secondaires, professionelles, supérieures, mais rien
de vraiment probant par niveau de type Bac-2 ou Bac+5, ou CE1.
Je répète aussi que
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
Dans les autres pays les cartes scolaires sont fortement orientés selon les
confession religieuses, et encore moins bien régulé par l'état, avec plus
de concurrence. Ce qui rend ces hiérarchies supposées encore moins
pertinentes.
Pour l'instant pas la peine de faire des suppositions, on ne devrait
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...
Le 08/06/2013 16:05, Vincent de Château-Thierry a écrit :
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
Le 08/06/2013 18:10, Vincent Pottier a écrit :
Le 08/06/2013 16:05, Vincent de Château-Thierry a écrit :
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
Zut... un multipolygone sans autre tag signifiant est transformé par
osm2pgsql... et reprend les tags de ses membres. Là l'algo d'osm2pgsql
a visiblement repris des trucs ici ou là, comme des admin_level et
remplace le name par celui d'un morceau de cours d'eau (l'Epte).
Bon, je vais rajouter un
Tu parles des académies de l'Éducation Nationale, c'est bien ça ?
Je proposerais bien boundary=educative, éventuellement couplé à un
admin_level (mais pour quel usage ?), pour rester cohérent avec les
boundary=administrative et les boundary=religious
Francescu
Le 7 juin 2013 22:59, Christian
Le 07/06/2013 23:07, Francescu GAROBY a écrit :
Tu parles des académies de l'Éducation Nationale, c'est bien ça ?
Je proposerais bien boundary=educative, éventuellement couplé à un
admin_level (mais pour quel usage ?), pour rester cohérent avec les
boundary=administrative et les
37 matches
Mail list logo
