Re: [OSM-talk-fr] kosmtik + requête PostGIS exploitant une relation = ERROR
Bon. J’ai tout remis à plat pour repenser le truc et parti de la table planet_osm_point pour que kosmtik / mapnik se concentre sur cette table. Et ça donne la grosse requête avec x sous-requêtes ci-dessous. Ça fonctionne très bien sur un dump Bretagne (administrative) et sous kosmtik. \o/ Mais quand je teste avec kosmtik sur le serveur qui est branché sur la base OSM monde, j’obtiens un méchant « Postgis Plugin: ERREUR: syntaxe en entrée invalide pour l'entier : « » in getAsyncResult » Je ne sais pas encore pourquoi… -- admin_places -- on part de la table planet_osm_point qui contient la géométrie -- et on fait une jointure sur -- la jointure de la requête sans doublons avec la requête avec doublons MAIS admin_level SELECT p.osm_id, p.way, COALESCE(p.tags -> 'name:br'::text,'???') as name, p.place as type, sub_admin.admin_level, sub_admin.admin_name FROM planet_osm_point AS p JOIN ( SELECT sub_unique.admin_centre_id, sub_unique.admin_level, sub_duplicate.admin_name FROM ( -- table sans les niveaux dupliqués : on garde le plus élevé SELECT sub1.admin_centre_id, MAX(sub1.admin_level) AS admin_level FROM ( -- table avec tous les niveaux administratifs cumulés -- préfectures SELECT substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as admin_centre_id, '4' as admin_level FROM planet_osm_rels WHERE tags::text ~ 'admin_level,6' UNION -- sous-préfectures SELECT substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as admin_centre_id, '3' as admin_level FROM planet_osm_rels WHERE tags::text ~ 'admin_level,7' UNION -- chefs-lieux de canton SELECT substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as admin_centre_id, '2' as admin_level FROM planet_osm_rels WHERE tags::text ~ 'political_division,canton' UNION -- communes SELECT substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as admin_centre_id, '1' as admin_level FROM planet_osm_rels WHERE tags::text ~ 'admin_level,8' ) AS sub1 GROUP BY sub1.admin_centre_id ) AS sub_unique LEFT JOIN ( SELECT sub2.admin_centre_id, sub2.admin_level, sub2.admin_name FROM ( -- table avec tous les niveaux administratifs cumulés -- préfectures SELECT substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as admin_centre_id, '4' as admin_level, 'préfecture' as admin_name FROM planet_osm_rels WHERE tags::text ~ 'admin_level,6' UNION -- sous-préfectures SELECT substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as admin_centre_id, '3' as admin_level, 'sous-préfecture' as admin_name FROM planet_osm_rels WHERE tags::text ~ 'admin_level,7' UNION -- chefs-lieux de canton SELECT substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as admin_centre_id, '2' as admin_level, 'chef-lieu de canton' as admin_name FROM planet_osm_rels WHERE tags::text ~ 'political_division,canton' UNION -- communes SELECT substring((regexp_matches(members::text, 'n[0-9]*')::text) from 3 for (char_length(regexp_matches(members::text, 'n[0-9]*')::text))-3)::bigint as admin_centre_id, '1' as admin_level, 'commune' as admin_name FROM planet_osm_rels WHERE tags::text ~ 'admin_level,8' ) AS sub2 ) AS sub_duplicate -- le critère de jointure ON sub_unique.admin_centre_id = sub_duplicate.admin_centre_id AND sub_unique.admin_level = sub_duplicate.admin_level ) AS sub_admin ON p.osm_id = sub_admin.admin_centre_id > Le 8 oct. 2018 à 22:10, Maël REBOUX a écrit : > > Je n’ai toujours pas trouver de solutions malgré différents essais. > J’aimerai éviter de créer une table en dur compliquée à maintenir à jour. > > >> Le 28 sept. 2018 à 08:09, Maël REBOUX >
Re: [OSM-talk-fr] kosmtik + requête PostGIS exploitant une relation = ERROR
en principe c'est toujours l'algo suivant à appliquer : - charger les membres des relations, ne garder que ceux de type "way" et ayant un rôle vide (déprécié), ou "outer"/"inner" (conserver ces rôles en métadonnées) - trouver les ways communs (avec le même id) : il ne devrait y avoir que 1 ou 2 avec le même iD s'il y en en 3 ou plus, la représentation est incorrecte - dans les paires de ways communs, ils ne devraient pas avoir le même rôle (ou bien les deux devraient avoir un rôle vide mais c'est une représentation dépréciée), avec un en "outer" l'autre en "inner", si c'est le cas, on supprime la paire. - avec le reste des ways restants, on charge la liste des noeuds pour chercher à les interconnecter : les interconnexions devraient être aux deux noeuds d'extrémité de chaque noeud, afin de former des "anneaux" (dans un premier temps garder les rôles des ways). Les interconnexions devraient se faire sur ces noeuds un nombre pair de ways - s'il y a un nombre impair de ways, la géométrie est incorrecte (non fermée) et il va falloir tenter de réparer en cherchant un way manquant entre deux noeuds d'extrémité de la liste qui sont les plus proches et pas déjà interconnectés par un way de la liste, afin d'ajouter ce way fictif manquant et compléter les anneaux pour former des interconnexions paires (attention on ne sait pas encore si c'est un way "inner" ou "outer", donc on ne peut que lui donner un rôle vide. - ensuite reste à savoir si les anneaux formée s'entrecroisent sur ces noeuds: si c'est le cas, il faut faire des échanges de listes de ways d'un anneau à l'autre. - à ce stade on peut vérifier les rôles inner/outer ou assigner ceux qui manquent. - enfin on s'intéresse aux autres noeuds (hors des extrémités) et à la géométrie exacte de chaque way pour voir s'il y a des intersections sur des noeuds intermédiaires entre deux ways, et on devra tenter de réparer là aussi (il faudra découper au besoin ces deux ways sur ces noeuds, au passage on peut se retrouver avec une intersection impaire après parcouru toute la liste, lors du découpage, on doit créer des ways plus courts dont on conserve en métadonnées les id's originels en métadonnées, mais come la phase précédente avait déjà rendu les anneaux fermés, la parité paire est garantie; au passage la détermination des rpoles "outer" et "inner" devra être revue dans une seconde passe sur les ways ainsi découpés dans la première passe). - on final on a une liste de ways fermés, les rôles sont tous corrects, on peut donc créer des multipolygones GIS fermés et correctement ordonnés (la seule chose à faire est de vérifier leur orientation, en sens antihoraire pour les "outer", et horaire pour les "inner". On a des métadonnées pour "logguer" les géométries incorrectes avec les id's des ways d'origine et donc aussi l'id des relations dont ils sont issus. On n'est pas obligé de tenter les corrections (les rendus Mapnik d'OSM.org ne le font plus, il préfèrent maintenant produire un polygone manquant en ignorant les géométries incorrectes: cela accélère considérablement le rendu; ce type de traitement est plutôt fait maintenant par les outils de veille qualité, comme Osmose, qui journalisent ces éléments et créent des listes de signalements d'anomalies à corriger). Cela se passe lors de l'import des données OSM en PostGIS qui effectue une telle conversion de géométrie (mais ne fait plus de tentative de correction, qui est très lente et surcharge beaucoup le serveur d'import et ne permettrait pas au rendu de suivre assez vite le flux des modifications). On peut donc supposer que déjà dans PostGIS les géométries sont déjà toutes correctes. Mais faire cela dans une requête PostGIS est très compliquée ! Cela suppose aussi que de toute façon PostGIS a effectué les corrections nécessaires, mais on ne trouvera rien dans la base PostGIS si'il n'y a pas eu de correction car les polygones seront de toute façon manquants dans la base. PostGIS n'est pas vraiment fait pour ça, et c'est plutôt un traitement direct par un outil d'export et d'analyse des données OSM qui convient le mieux. Et là dans cet outil c'est bien plus simple car on s'intéresse juste à un jeu réduit de relations OSM et on peut même faire cet algo "à la main" ici. Ce n'est en effet pas bien compliqué de sortir la liste des ways membres (et leurs rôles à prendre en compte, pour éviter des membres qu'on trouve parfois (dont notamment des "admin_centre" qui ne sont pas des noeuds mais des ways de bâtiments, alors qu'on peut toujours positionner un noeud dans ce bâtiment, mais en général les "admin_centre", les noeuds membres, et les relations membres quelles qu'elles soient peuvent toujours être ignorés), et c'est facile de voir qu'il y a des paires de ways et les éliminer. L'outil "comcom" ne fait pas autre chose que de sortir des listes de ways membres à garder, et comme il ne reste alors que des ways isolés, leurs rôles "inner" ou "outer" (ou vide) dans les relations d'origine peut être gardé tel quel. On peut
Re: [OSM-talk-fr] kosmtik + requête PostGIS exploitant une relation = ERROR
Je n’ai toujours pas trouver de solutions malgré différents essais.
J’aimerai éviter de créer une table en dur compliquée à maintenir à jour.
> Le 28 sept. 2018 à 08:09, Maël REBOUX a écrit :
>
> je vois l’idée mais c’est pas encore ça.
>
> …
> "table": "(
> SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
> FROM planet_osm_point
> JOIN (
> WITH numbered AS(
> SELECT row_number() OVER() AS row, entry
> FROM(
> SELECT unnest(members) AS entry
> FROM planet_osm_rels
> WHERE ARRAY['boundary','administrative']<@tags AND
> ARRAY['admin_level','6']<@tags) AS mylist)
> SELECT ltrim(a.entry,'n')::bigint AS osm_id
> FROM numbered AS a JOIN numbered AS b
> ON a.row = b.row-1 AND b.entry = 'admin_centre'
> ) x
> USING(osm_id)
> ) AS data",
> "geometry_table":"numbered",
> "key_field": "",
> "geometry_field": "way",
> "asynchronous_request": "true",
> "max_async_connection": "4",
> "simplify_geometries": "true",
> "extent_cache": "auto",
> "extent": "-1363990,3994624,1824475,9411676"
> },
> …
>
> donne une erreur différente :
>
> Postgis Plugin: ERROR: relation "numbered" does not exist
> LINE 1: SELECT ST_SRID("way") AS srid FROM numbered WHERE "way" IS N...
>^
> in executeQuery Full sql was: 'SELECT ST_SRID("way") AS srid FROM numbered
> WHERE "way" IS NOT NULL LIMIT 1;'
>
> logique : la géométrie n’est pas dans « numbered » (c’est pour récupérer le
> admin_level dans la table des relations)
> mais dans planet_osm_point
>
> donc on essaie :
>
> "table": "(
> SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
> FROM planet_osm_point
> JOIN (
> WITH numbered AS(
> SELECT row_number() OVER() AS row, entry
> FROM(
> SELECT unnest(members) AS entry
> FROM planet_osm_rels
> WHERE ARRAY['boundary','administrative']<@tags AND
> ARRAY['admin_level','8']<@tags) AS mylist)
> SELECT ltrim(a.entry,'n')::bigint AS osm_id
> FROM numbered AS a JOIN numbered AS b
> ON a.row = b.row-1 AND b.entry = 'admin_centre'
> ) x
> USING(osm_id)
> ) AS data",
> "geometry_table":"planet_osm_point",
> "key_field": "",
> "geometry_field": "way",
> "asynchronous_request": "true",
> "max_async_connection": "4",
> "simplify_geometries": "true",
> "extent_cache": "auto",
> "extent": "-1363990,3994624,1824475,9411676"
> },
>
> et là ça passe : plus d’erreur MAIS je récupère pas de géométrie non plus :(
>
>> Le 27 sept. 2018 à 09:31, Christian Quest > > a écrit :
>>
>> Les requêtes SQL sont ré-empaquetées par le driver postgis de mapnik et là
>> je pense qu'il ne sait pas détecter que c'est dans "data" qu'il va trouver
>> "way".
>>
>> Essaye en ajoutant un paramètre "geometry_table": "data" voire aussi
>> "geometry_field": "way"
>>
>> Pour l'ensemble des paramètres qu'on peut passer, voir:
>> https://github.com/mapnik/mapnik/wiki/PostGIS
>>
>>
>> Je pense aussi qu'un && !bbox! quelque part sera peut être nécessaire pour
>> être sûr que la requête soit limitée à l'emprise à rendre...
>>
>>
>> Le jeu. 27 sept. 2018 à 07:45, Maël REBOUX > > a écrit :
>> J’ai oublié de mettre la déclaration de la couche dans le projet :
>>
>>
>> {
>> "id": "places_admin_6",
>> "name": "places_admin_6",
>> "class": "",
>> "Datasource": {
>> "type": "postgis",
>> "host": "db.openstreetmap.local",
>> "user": "osm",
>> "password": "osm",
>> "dbname": "osm",
>> "table": "(
>> SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
>> FROM planet_osm_point
>> JOIN (
>> WITH c AS(
>> SELECT row_number() OVER() AS row, entry
>> FROM(
>> SELECT unnest(members) AS entry
>> FROM planet_osm_rels
>> WHERE ARRAY['boundary','administrative']<@tags AND
>> ARRAY['admin_level','6']<@tags) AS mylist)
>> SELECT ltrim(a.entry,'n')::bigint AS osm_id
>> FROM c AS a JOIN c AS b
>> ON a.row = b.row-1 AND b.entry = 'admin_centre'
>> ) x
>> USING(osm_id)
>> ) AS data",
>> "key_field": "",
>> "geometry_field": "way",
>> "asynchronous_request": "true",
>> "max_async_connection": "4",
>> "simplify_geometries": "true",
>> "extent_cache": "auto",
>> "extent": "-1363990,3994624,1824475,9411676"
>> },
>> "geometry": "point",
>> "srs-name": "3857",
>> "srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
>> +x_0=0.0 +y_0=0.0 +k=1.0
Re: [OSM-talk-fr] kosmtik + requête PostGIS exploitant une relation = ERROR
je vois l’idée mais c’est pas encore ça.
…
"table": "(
SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
FROM planet_osm_point
JOIN (
WITH numbered AS(
SELECT row_number() OVER() AS row, entry
FROM(
SELECT unnest(members) AS entry
FROM planet_osm_rels
WHERE ARRAY['boundary','administrative']<@tags AND
ARRAY['admin_level','6']<@tags) AS mylist)
SELECT ltrim(a.entry,'n')::bigint AS osm_id
FROM numbered AS a JOIN numbered AS b
ON a.row = b.row-1 AND b.entry = 'admin_centre'
) x
USING(osm_id)
) AS data",
"geometry_table":"numbered",
"key_field": "",
"geometry_field": "way",
"asynchronous_request": "true",
"max_async_connection": "4",
"simplify_geometries": "true",
"extent_cache": "auto",
"extent": "-1363990,3994624,1824475,9411676"
},
…
donne une erreur différente :
Postgis Plugin: ERROR: relation "numbered" does not exist
LINE 1: SELECT ST_SRID("way") AS srid FROM numbered WHERE "way" IS N...
^
in executeQuery Full sql was: 'SELECT ST_SRID("way") AS srid FROM numbered
WHERE "way" IS NOT NULL LIMIT 1;'
logique : la géométrie n’est pas dans « numbered » (c’est pour récupérer le
admin_level dans la table des relations)
mais dans planet_osm_point
donc on essaie :
"table": "(
SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
FROM planet_osm_point
JOIN (
WITH numbered AS(
SELECT row_number() OVER() AS row, entry
FROM(
SELECT unnest(members) AS entry
FROM planet_osm_rels
WHERE ARRAY['boundary','administrative']<@tags AND
ARRAY['admin_level','8']<@tags) AS mylist)
SELECT ltrim(a.entry,'n')::bigint AS osm_id
FROM numbered AS a JOIN numbered AS b
ON a.row = b.row-1 AND b.entry = 'admin_centre'
) x
USING(osm_id)
) AS data",
"geometry_table":"planet_osm_point",
"key_field": "",
"geometry_field": "way",
"asynchronous_request": "true",
"max_async_connection": "4",
"simplify_geometries": "true",
"extent_cache": "auto",
"extent": "-1363990,3994624,1824475,9411676"
},
et là ça passe : plus d’erreur MAIS je récupère pas de géométrie non plus :(
> Le 27 sept. 2018 à 09:31, Christian Quest a écrit :
>
> Les requêtes SQL sont ré-empaquetées par le driver postgis de mapnik et là je
> pense qu'il ne sait pas détecter que c'est dans "data" qu'il va trouver "way".
>
> Essaye en ajoutant un paramètre "geometry_table": "data" voire aussi
> "geometry_field": "way"
>
> Pour l'ensemble des paramètres qu'on peut passer, voir:
> https://github.com/mapnik/mapnik/wiki/PostGIS
>
>
> Je pense aussi qu'un && !bbox! quelque part sera peut être nécessaire pour
> être sûr que la requête soit limitée à l'emprise à rendre...
>
>
> Le jeu. 27 sept. 2018 à 07:45, Maël REBOUX a écrit :
> J’ai oublié de mettre la déclaration de la couche dans le projet :
>
>
> {
> "id": "places_admin_6",
> "name": "places_admin_6",
> "class": "",
> "Datasource": {
> "type": "postgis",
> "host": "db.openstreetmap.local",
> "user": "osm",
> "password": "osm",
> "dbname": "osm",
> "table": "(
> SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
> FROM planet_osm_point
> JOIN (
> WITH c AS(
> SELECT row_number() OVER() AS row, entry
> FROM(
> SELECT unnest(members) AS entry
> FROM planet_osm_rels
> WHERE ARRAY['boundary','administrative']<@tags AND
> ARRAY['admin_level','6']<@tags) AS mylist)
> SELECT ltrim(a.entry,'n')::bigint AS osm_id
> FROM c AS a JOIN c AS b
> ON a.row = b.row-1 AND b.entry = 'admin_centre'
> ) x
> USING(osm_id)
> ) AS data",
> "key_field": "",
> "geometry_field": "way",
> "asynchronous_request": "true",
> "max_async_connection": "4",
> "simplify_geometries": "true",
> "extent_cache": "auto",
> "extent": "-1363990,3994624,1824475,9411676"
> },
> "geometry": "point",
> "srs-name": "3857",
> "srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
> +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over",
> "extent": [ -10, 34, 20, 70 ],
> "advanced": {}
> }
>
>
>> Le 27 sept. 2018 à 00:10, Maël REBOUX > > a écrit :
>>
>> Bonjour tous,
>>
>> Je cherche à faire apparaître sur une carte en ligne les préfectures et leur
>> nom en breton.
>>
>> La façon d’y arriver est « connue » : il faut faire une jointure entre la
>> table planet_osm_point (qui contient le point et le nom) et la
Re: [OSM-talk-fr] kosmtik + requête PostGIS exploitant une relation = ERROR
Les requêtes SQL sont ré-empaquetées par le driver postgis de mapnik et là
je pense qu'il ne sait pas détecter que c'est dans "data" qu'il va trouver
"way".
Essaye en ajoutant un paramètre "geometry_table": "data" voire aussi
"geometry_field": "way"
Pour l'ensemble des paramètres qu'on peut passer, voir:
https://github.com/mapnik/mapnik/wiki/PostGIS
Je pense aussi qu'un && !bbox! quelque part sera peut être nécessaire pour
être sûr que la requête soit limitée à l'emprise à rendre...
Le jeu. 27 sept. 2018 à 07:45, Maël REBOUX a
écrit :
> J’ai oublié de mettre la déclaration de la couche dans le projet :
>
>
> {
> "id": "places_admin_6",
> "name": "places_admin_6",
> "class": "",
> "Datasource": {
> "type": "postgis",
> "host": "db.openstreetmap.local",
> "user": "osm",
> "password": "osm",
> "dbname": "osm",
> "table": "(
> SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
> FROM planet_osm_point
> JOIN (
> WITH c AS(
> SELECT row_number() OVER() AS row, entry
> FROM(
> SELECT unnest(members) AS entry
> FROM planet_osm_rels
> WHERE ARRAY['boundary','administrative']<@tags AND
> ARRAY['admin_level','6']<@tags) AS mylist)
> SELECT ltrim(a.entry,'n')::bigint AS osm_id
> FROM c AS a JOIN c AS b
> ON a.row = b.row-1 AND b.entry = 'admin_centre'
> ) x
> USING(osm_id)
> ) AS data",
> "key_field": "",
> "geometry_field": "way",
> "asynchronous_request": "true",
> "max_async_connection": "4",
> "simplify_geometries": "true",
> "extent_cache": "auto",
> "extent": "-1363990,3994624,1824475,9411676"
> },
> "geometry": "point",
> "srs-name": "3857",
> "srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0
> +x_0=0.0 +y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over",
> "extent": [ -10, 34, 20, 70 ],
> "advanced": {}
> }
>
>
>
> Le 27 sept. 2018 à 00:10, Maël REBOUX a écrit :
>
> Bonjour tous,
>
> Je cherche à faire apparaître sur une carte en ligne les préfectures et
> leur nom en breton.
>
> La façon d’y arriver est « connue » : il faut faire une jointure entre la
> table planet_osm_point (qui contient le point et le nom) et la
> table planet_osm_rels (qui elle contient l’info admin_level).
>
> Cela donne une requête qui s’exécute très bien en temps normal (pgAdmin ou
> dans une vue ou une requête d’insertion de données / create table) :
>
> SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
> FROM planet_osm_point
> JOIN (
> WITH numbered AS(
> SELECT row_number() OVER() AS row, entry
> FROM(
> SELECT unnest(members) AS entry
> FROM planet_osm_rels
> WHERE ARRAY['boundary','administrative']<@tags AND
> ARRAY['admin_level','6']<@tags) AS mylist)
> SELECT ltrim(a.entry,'n')::bigint AS osm_id
> FROM numbered AS a JOIN numbered AS b
> ON a.row = b.row-1 AND b.entry = 'admin_centre'
> ) x
> USING(osm_id);
>
>
> source :
> https://dba.stackexchange.com/questions/104943/osm2pgsql-select-relation-member-by-role
>
>
> Mais si je mets cette requête dans une déclaration de couche pour un
> projet mml servi par kosmtik j’obtiens une erreur dans kosmtik :
>
> Postgis Plugin: ERROR: relation "numbered" does not exist LINE 1: SELECT
> ST_SRID("way") AS srid FROM numbered WHERE "way" IS N... ^ in executeQuery
> Full sql was: 'SELECT ST_SRID("way") AS srid FROM numbered WHERE "way" IS
> NOT NULL LIMIT 1;' encountered during parsing of layer 'places_admin_6' in
> Layer
>
>
> En loggant l’erreur dans PostgreSQL :
>
> 2018-09-26 23:24:56.797 CEST [32589] STATEMENT: SELECT ST_SRID("way") AS
> srid FROM numbered WHERE "way" IS NOT NULL LIMIT 1;
> 2018-09-26 23:24:56.798 CEST [32590] LOG: statement: SELECT
> ST_SRID("way") AS srid FROM numbered WHERE "way" IS NOT NULL LIMIT 1;
> 2018-09-26 23:24:56.798 CEST [32590] ERROR: relation "numbered" does not
> exist at character 36
>
>
> Je n’arrive pas à cerner le problème. Bien sûr si on change le nom
> « numbered » par autre chose, le message d’erreur fera référence à ce
> nouveau nom.
> J’ai pas testé directement sur un serveur de tuiles mais je vois pas
> pourquoi ça passerait.
> Si quelqu’un a une piste…
>
> Cdt,Maël evit osm-bzh
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
--
Christian Quest - OpenStreetMap France
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] kosmtik + requête PostGIS exploitant une relation = ERROR
J’ai oublié de mettre la déclaration de la couche dans le projet :
{
"id": "places_admin_6",
"name": "places_admin_6",
"class": "",
"Datasource": {
"type": "postgis",
"host": "db.openstreetmap.local",
"user": "osm",
"password": "osm",
"dbname": "osm",
"table": "(
SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
FROM planet_osm_point
JOIN (
WITH c AS(
SELECT row_number() OVER() AS row, entry
FROM(
SELECT unnest(members) AS entry
FROM planet_osm_rels
WHERE ARRAY['boundary','administrative']<@tags AND
ARRAY['admin_level','6']<@tags) AS mylist)
SELECT ltrim(a.entry,'n')::bigint AS osm_id
FROM c AS a JOIN c AS b
ON a.row = b.row-1 AND b.entry = 'admin_centre'
) x
USING(osm_id)
) AS data",
"key_field": "",
"geometry_field": "way",
"asynchronous_request": "true",
"max_async_connection": "4",
"simplify_geometries": "true",
"extent_cache": "auto",
"extent": "-1363990,3994624,1824475,9411676"
},
"geometry": "point",
"srs-name": "3857",
"srs": "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0
+y_0=0.0 +k=1.0 +units=m +nadgrids=@null +wktext +no_defs +over",
"extent": [ -10, 34, 20, 70 ],
"advanced": {}
}
> Le 27 sept. 2018 à 00:10, Maël REBOUX a écrit :
>
> Bonjour tous,
>
> Je cherche à faire apparaître sur une carte en ligne les préfectures et leur
> nom en breton.
>
> La façon d’y arriver est « connue » : il faut faire une jointure entre la
> table planet_osm_point (qui contient le point et le nom) et la table
> planet_osm_rels (qui elle contient l’info admin_level).
>
> Cela donne une requête qui s’exécute très bien en temps normal (pgAdmin ou
> dans une vue ou une requête d’insertion de données / create table) :
>
> SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
> FROM planet_osm_point
> JOIN (
> WITH numbered AS(
> SELECT row_number() OVER() AS row, entry
> FROM(
> SELECT unnest(members) AS entry
> FROM planet_osm_rels
> WHERE ARRAY['boundary','administrative']<@tags AND
> ARRAY['admin_level','6']<@tags) AS mylist)
> SELECT ltrim(a.entry,'n')::bigint AS osm_id
> FROM numbered AS a JOIN numbered AS b
> ON a.row = b.row-1 AND b.entry = 'admin_centre'
> ) x
> USING(osm_id);
>
> source :
> https://dba.stackexchange.com/questions/104943/osm2pgsql-select-relation-member-by-role
>
>
>
>
> Mais si je mets cette requête dans une déclaration de couche pour un projet
> mml servi par kosmtik j’obtiens une erreur dans kosmtik :
>
> Postgis Plugin: ERROR: relation "numbered" does not exist LINE 1: SELECT
> ST_SRID("way") AS srid FROM numbered WHERE "way" IS N... ^ in executeQuery
> Full sql was: 'SELECT ST_SRID("way") AS srid FROM numbered WHERE "way" IS NOT
> NULL LIMIT 1;' encountered during parsing of layer 'places_admin_6' in Layer
>
> En loggant l’erreur dans PostgreSQL :
>
> 2018-09-26 23:24:56.797 CEST [32589] STATEMENT: SELECT ST_SRID("way") AS
> srid FROM numbered WHERE "way" IS NOT NULL LIMIT 1;
> 2018-09-26 23:24:56.798 CEST [32590] LOG: statement: SELECT ST_SRID("way")
> AS srid FROM numbered WHERE "way" IS NOT NULL LIMIT 1;
> 2018-09-26 23:24:56.798 CEST [32590] ERROR: relation "numbered" does not
> exist at character 36
>
> Je n’arrive pas à cerner le problème. Bien sûr si on change le nom « numbered
> » par autre chose, le message d’erreur fera référence à ce nouveau nom.
> J’ai pas testé directement sur un serveur de tuiles mais je vois pas pourquoi
> ça passerait.
> Si quelqu’un a une piste…
>
> Cdt,Maël evit osm-bzh
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] kosmtik + requête PostGIS exploitant une relation = ERROR
Bonjour tous,
Je cherche à faire apparaître sur une carte en ligne les préfectures et leur
nom en breton.
La façon d’y arriver est « connue » : il faut faire une jointure entre la table
planet_osm_point (qui contient le point et le nom) et la table planet_osm_rels
(qui elle contient l’info admin_level).
Cela donne une requête qui s’exécute très bien en temps normal (pgAdmin ou dans
une vue ou une requête d’insertion de données / create table) :
SELECT DISTINCT way, COALESCE(tags -> 'name:br'::text) as name
FROM planet_osm_point
JOIN (
WITH numbered AS(
SELECT row_number() OVER() AS row, entry
FROM(
SELECT unnest(members) AS entry
FROM planet_osm_rels
WHERE ARRAY['boundary','administrative']<@tags AND
ARRAY['admin_level','6']<@tags) AS mylist)
SELECT ltrim(a.entry,'n')::bigint AS osm_id
FROM numbered AS a JOIN numbered AS b
ON a.row = b.row-1 AND b.entry = 'admin_centre'
) x
USING(osm_id);
source :
https://dba.stackexchange.com/questions/104943/osm2pgsql-select-relation-member-by-role
Mais si je mets cette requête dans une déclaration de couche pour un projet mml
servi par kosmtik j’obtiens une erreur dans kosmtik :
Postgis Plugin: ERROR: relation "numbered" does not exist LINE 1: SELECT
ST_SRID("way") AS srid FROM numbered WHERE "way" IS N... ^ in executeQuery Full
sql was: 'SELECT ST_SRID("way") AS srid FROM numbered WHERE "way" IS NOT NULL
LIMIT 1;' encountered during parsing of layer 'places_admin_6' in Layer
En loggant l’erreur dans PostgreSQL :
2018-09-26 23:24:56.797 CEST [32589] STATEMENT: SELECT ST_SRID("way") AS srid
FROM numbered WHERE "way" IS NOT NULL LIMIT 1;
2018-09-26 23:24:56.798 CEST [32590] LOG: statement: SELECT ST_SRID("way") AS
srid FROM numbered WHERE "way" IS NOT NULL LIMIT 1;
2018-09-26 23:24:56.798 CEST [32590] ERROR: relation "numbered" does not exist
at character 36
Je n’arrive pas à cerner le problème. Bien sûr si on change le nom « numbered »
par autre chose, le message d’erreur fera référence à ce nouveau nom.
J’ai pas testé directement sur un serveur de tuiles mais je vois pas pourquoi
ça passerait.
Si quelqu’un a une piste…
Cdt,Maël evit osm-bzh
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
