[postgis-users] Get parallel some route.
Rémi Cura
remi.cura at gmail.com
Wed Jan 28 09:39:01 PST 2015
Ah,
effectivement l'erreur n'est pas du tout la même
Il s'agit peut être de géométrie non valide
Vous pouvez le vérifier facilement avec les fonctions
ST_IsValid <http://postgis.net/docs/ST_IsValid.html> , et ST_IsValidDetail
<http://postgis.net/docs/ST_IsValidDetail.html>.
Si vous avez des géométries non valide, vous pouvez les corriger avec
ST_MakeValid <http://postgis.net/docs/ST_MakeValid.html>
Si toutes les géométries sont valides les choses vont se corser :
- Arrondir les coordonnées des points des lignes (fonction ST_SnapToGrid
<http://postgis.net/docs/ST_SnapToGrid.html> )
- translater les données pour diminuer le nombre de chiffre des
coordonnées (547354.26116135239 6344318.7079305416 ---> 354,.... ; 318,...)
Si rien ne marche, pas de panique, il suffit d'extraire un exemple minimal
de ce qui ne marche pas
(par exemple donner publiquement les quelques géométries qui provoquent le
problème),
ainsi que la requete associée.J
e créerais ensuite un ticket pour demander aux developpeurs de régler le
bug.
Je n'aurais pas accès à internet avant Lundi, je vous souhaite donc bon
courage
Salutations,
Rémi-C
Le 28 janvier 2015 16:56, Guillaume ARNAUD <guillaume.arnaud at cg82.fr> a
écrit :
> (re) Bonjour,
>
> Merci pour votre retour rapide, mais, comme je l'indiquais dans le mail
> précédent, j'ai bien vérifié que mes lignes soient bien des linestring en
> utilisant la requête suivante :
> "select st_geometrytype(shape) type_geom, count (*) from
> web.trs_itineraire group by type_geom" ==== > Réponse : 1 ligne : type
> geom = "ST_LineString", count = 292
> Lors de mon tout premier essai, j'avais 3 multilinestring que j'ai
> identifiées et reprise pour les transformer en linestring.
>
> Elles ne sont pourtant pas "simple" :
> "select st_issimple(shape) geom_simple, count (*) from web.trs_itineraire
> group by geom_simple ==== > Réponse : 2 ligne : geom_simple : "f", count
> 244 /// geom_simple : "t", count : 48
>
> Je viens de relire mon mail et je vois que je n'ai jamais écrit le message
> d'erreur :
>
> ERREUR: GEOSOffsetCurve: TopologyException: assigned depths do not match
> at 547354.26116135239 6344318.7079305416
> ********** Erreur **********
> ERREUR: GEOSOffsetCurve: TopologyException: assigned depths do not match
> at 547354.26116135239 6344318.7079305416
> État SQL :XX000
>
> J'ai ce message pour ma requête comme pour la votre (si je l'ai bien
> adapté) :
>
> SELECT ST_OffsetCurve(theGeom, 25, 'quad_segs=4 join=round') AS theOffset
> FROM (
> SELECT (ST_Dump(shape)).geom AS theGeom
> FROM web.trs_itineraire
> where code = '06-20B'
> ) AS subQuery;
>
> l'itineraire pris en exemple a ce dessin :
>
>
>
> Il y a donc 3 aller retour sur les excroissance que l'on peut voir et donc
> autant de point utilisé plusieurs fois que ces branche en comporte.
>
> Pour ce qui est des index, il y en a bien sur code, code + nom et nom.
> Pour ce qui est des injections SQL , nous essayons de respecter les
> préconisation en la matière (bien qu'on ne soit jamais à l'abris)...
>
> Merci encore pour votre aide. En espérant que mon problème est une
> solution.
>
> Guillaume.
>
>
> Le 28/01/2015 16:02, Rémi Cura a écrit :
>
> /* For the list archive : problem is probably using ST_OffsetCurve with
> multilinestring instead of linestring.*/
>
> Bonjour,
>
> St_OffsetCurve ne fonctionne qu'avec des géométries simples.
> Pour PostGIS (et le standard),* les géométries simples sont des
> géométries qui ne sont pas composées*.
> En clair, vous avez probablement des lignes de type multilinestring
> (composition de plusieurs polylignes).
> La solution est immédiate si vous souhaitez simplement faire de la
> visualisation (non testée):
>
> -------------------------------------
> SELECT objectid, nom, code
> , ST_OffsetCurve(dmp.geom, 25, 'quad_segs=4 join=round') as
> offseted_linestring
> FROM web.trs_itineraire , st_Dump(shape) as dmp
> WHERE code = '06-20B'
> -------------------------------------
>
> Attention,
> cette requête duplique les lignes (si votre multi-polyligne comporte par
> exemple 3 polylignes, dans le résultat final vous allez avoir 3 rows,
> identiques si ce n'est la géométrie qui change).
> On peut facilement éviter ce comportement si vous le souhaitez en
> regroupant à nouveau les polylignes qui ont été décalées :
>
> ---------------------------------------
> SELECT objectid, nom, code, ST_Collect(offseted_linestring) as
> offseted_multilinestring
> FROM
> (SELECT objectid, nom, code , dmp.path
> , ST_OffsetCurve(dmp.geom, 25, 'quad_segs=4 join=round') as
> offseted_linestring
> FROM web.trs_itineraire , st_Dump(shape) as dmp
> WHERE code = '06-20B'
> ) as sub
> GROUP BY objectid, nom, code
> ORDER BY dmp.path
> -----------------------------------------
>
> Enfin, je me permets un petit rappel puisque vous êtes probablement dans
> un contexte web ;
> vous insérer probablement le code " '06-20B'" , il est imperatif de le
> faire à l'aide de fonctions sécurisée pour éviter les injections SQL
> (et surtout pas par concaténation de texte)
> Code doit de plus avoir un index /* CREATE INDEX ON web.trs_itineraire
> (code) */ pour que cette requête soit efficace
>
> Salutations,
> Rémi-C
>
>
> Le 28 janvier 2015 14:02, Guillaume ARNAUD <guillaume.arnaud at cg82.fr> a
> écrit :
>
>> (re) Bonjour,
>>
>> Donc, en français... Nous avons une base PosTGIS qui est attaqué par
>> ArcGIS Server and Desktop 10.2.
>>
>> Nous souhaitons gérer, à travers une interface web, les décalages de
>> plusieurs itinéraires de transport scolaire sélectionné et conserver ce
>> décalage en vue d'une réutilisation de cette sélection ultérieurement. Ceci
>> est uniquement dans un but de représentation des itinéraires quand ils se
>> trouvent superposés dans la sélection.
>>
>> Pour cela, je pensais utiliser la fonction ST_OffsetCurve(shape,
>> decalage, 'quad_segs=4 join=round'). Où le decalage prend la valeur -2, -1,
>> 0, 1 ou 2 que multiplie un facteur d'échelle.
>>
>> Toute notre base de données d'itinéraire est de type linestring (quand on
>> fait st_geometrytype(shape)) par contre, 250 des 300 itinéraire ne sont pas
>> simple (st_issimple(shape) = f).
>>
>> Après quelques recherche, j'ai vu que le problème devais venir de là.
>> J'ai essayé, sans trop comprendre d'utiliser "st_simplifypreservetopology"
>> mais le problème reste le même (dans la majorité des cas) et quand ça
>> marche sur un itinéraire ça ne change pas pour autant le st _issimple :
>>
>> SELECT objectid, nom, code, ST_OffsetCurve(shape, 25, 'quad_segs=4
>> join=round') from web.trs_itineraire where code = '06-20B' ====> Ne
>> fonctionne pas.
>>
>> SELECT ST_issimple(shape) from web.trs_itineraire where code =
>> '06-20B' ====> False
>>
>> SELECT objectid, nom, code,
>> ST_OffsetCurve(st_simplifypreservetopology(shape,0.6), 25, 'quad_segs=4
>> join=round') from web.trs_itineraire where code = '06-20B'
>>
>> SELECT ST_issimple(st_simplifypreservetopology(shape,0.6)) from
>> web.trs_itineraire where code = '06-20B' ====> False
>>
>> Nos itinéraires peuvent faire des aller retour sur des même axes de
>> voirie et donc partage des noeuds en communs.
>>
>> Le but est simplement de le voir. J'ai aussi envisagé comme solution un
>> demi buffer mais l'exemple trouvé sur internet ne me parle pas.
>>
>> Un autre solution serait d'eclater l'itineraire en plusieurs partie
>> "simple" et de décaler toutes ces partie mais je n'ai pas trouver comment
>> faire pour éclater cet itineraire.
>>
>> Merci de vos réponses et de votre intérêt pour ma question.
>>
>> Guillaume ARNAUD
>>
>> Le 28/01/2015 12:32, Rémi Cura a écrit :
>>
>> Same,
>>
>> On peut répondre à la question en français,
>> il y en a quelques un sur la mailing list...
>>
>> Rémi-C
>>
>> 2015-01-28 11:44 GMT+01:00 Nicolas Ribot <nicolas.ribot at gmail.com>:
>>
>>> Hi Guillaume,
>>>
>>> Not sure I understand what you want to achieve.
>>> Can you describe it, maybe with an image. (or in french)
>>>
>>> Non-simple lines can be cut at their intersection to make them simple.
>>>
>>> Nicolas
>>>
>>> On 28 January 2015 at 09:16, Guillaume ARNAUD <
>>> guillaume.arnaud at cg82.fr> wrote:
>>>
>>>> Hello,
>>>>
>>>> We use Postgre / Postgis database with ArcGIS Server and Desktop 10.2.
>>>> All our data are inserted with keyword Postgis into our database.
>>>>
>>>> The table that has the trouble is a route table with 292 linestring. I
>>>> need these routes is not bunk. I try to use ST_OffsetCurve function to do
>>>> this. I found on the help and on a ticket that we must have geometry which
>>>> is simple. More than 250 isn't. Is there any solution to fix the problem or
>>>> to bypass the problem .
>>>>
>>>> Thanks for your work.
>>>>
>>>> Greating.
>>>>
>>>> ARNAUD Guillaume
>>>>
>>>> Sorry for my poor english, I'm french.
>>>>
>>>> "PostgreSQL 9.2.2, compiled by Visual C++ build 1600, 64-bit
>>>> POSTGIS="2.0.4" GEOS="3.4.2-CAPI-1.8.2 r0" PROJ="Rel. 4.8.0, 6 March
>>>> 2012" GDAL="GDAL 1.10.0, released 2013/04/24" LIBXML="2.7.8"
>>>> LIBJSON="UNKNOWN" (core procs from "2.0.4" need upgrade) RASTER (raster
>>>> procs from "2.0.4" need upgrade)"
>>>>
>>>> OS : Windows Server Standard SP 2
>>>> --
>>>> Guillaume ARNAUD
>>>> Cellule SIGD
>>>> Direction de l'Informatique
>>>> Conseil Général de Tarn-et-Garonne
>>>>
>>>>
>>>> _______________________________________________
>>>> postgis-users mailing list
>>>> postgis-users at lists.osgeo.org
>>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>>>>
>>>
>>>
>>> _______________________________________________
>>> postgis-users mailing list
>>> postgis-users at lists.osgeo.org
>>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>>>
>>
>>
>> --
>> Guillaume ARNAUD
>> Cellule SIGD
>> Direction de l'Informatique
>> Conseil Général de Tarn-et-Garonne
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at lists.osgeo.org
>> http://lists.osgeo.org/cgi-bin/mailman/listinfo/postgis-users
>>
>
>
> --
> Guillaume ARNAUD
> Cellule SIGD
> Direction de l'Informatique
> Conseil Général de Tarn-et-Garonne
> 05-63-91-82-37
> En interne, utilisez le Click To Call : 8237
> <https://10.200.3.1:8443/webdialer/Webdialer?destination=8237>
>
> [image: test] <http://www.carto.cg82.fr/>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20150128/42cbc3ce/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ceddfehd.png
Type: image/png
Size: 833 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20150128/42cbc3ce/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: logo-sigd.jpg
Type: image/jpeg
Size: 58419 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20150128/42cbc3ce/attachment.jpg>
More information about the postgis-users
mailing list