actually, yes you have a spatial index : sidx_tuile_geom
Le jeu. 6 déc. 2018 à 17:49, Manchon Pierre a
écrit :
> Ha yes it’s because it’s a screenshot from a SGBD modeler not a graph view
> of the actual database (which is the same)
>
> I did not created index on my geometry …
>
> (from database
Well, to my surprise this already exists... and it even has the same name
as I proposed...
https://postgis.net/docs/ST_Relate.html
Guess it's time to do some experimenting with that...
___
postgis-users mailing list
postgis-users@lists.osgeo.org
https://l
Thanks for your elaborate answer,, I will have a good think about it.
Just a random thought I had:
As I was doing some experiments with st_intersection, I noticed some
strange thing though.
On our prod. machine (windows, pg11, postgis 2.5.0 (not 100% sure), geos
3.7.0), it takes about a minute to
Okay that works good now thank you !
Sorry I should’ve taken a look at this which is a bit obvious now I know
where was the error.
De : postgis-users De la part de
Darafei "Kom?pa" Praliaskouski
Envoyé : jeudi 6 décembre 2018 17:43
À : PostGIS Users Discussion
Objet : Re: [postgis-users] Ve
Ha yes it’s because it’s a screenshot from a SGBD modeler not a graph view
of the actual database (which is the same)
I did not created index on my geometry …
(from database manager on qgis it look more like this):
De : postgis-users De la part de
Darafei "Kom?pa" Praliaskouski
Envoyé : j
Hi,
did you create spatial index on your geometry?
your screenshot also does not show any geometry field.
On Thu, Dec 6, 2018 at 7:29 PM Manchon Pierre
wrote:
> Hello,
>
> The indexes are code_zoneinteret and code_tuile on recouvrement
>
>
>
>
>
> *De :* postgis-users *De la part
> de* Darafei
It is pretty simple :
The query take data from the orange tables and insert it into the purple one
De : postgis-users De la part de
Tumasgiu Rossini
Envoyé : jeudi 6 décembre 2018 17:19
À : PostGIS Users Discussion
Objet : Re: [postgis-users] Very long query time
And I am not really sur
Hello,
The indexes are code_zoneinteret and code_tuile on recouvrement
De : postgis-users De la part de
Darafei "Kom?pa" Praliaskouski
Envoyé : jeudi 6 décembre 2018 17:18
À : PostGIS Users Discussion
Objet : Re: [postgis-users] Very long query time
Hello,
What are the indexes on t
And I am not really sure that what you are willing to achieve with the
GROUP BY
I am not aware of you data model, though.
Maybe you have upgraded recently to postgis 2.4 which change GROUP BY
behavior
when it comes to geometries [1]?
Geometries in 2.4 are no more grouped using bbox comparison but
Hello,
What are the indexes on the table?
On Thu, Dec 6, 2018 at 7:16 PM Manchon Pierre
wrote:
> Yes the request took about ~100ms to be executed before but now it never
> ends (I left it 1h)
>
> (thx for the tip with where clause)
>
>
>
> *De :* postgis-users *De la part
> de* Tumasgiu Rossin
Yes the request took about ~100ms to be executed before but now it never
ends (I left it 1h)
(thx for the tip with where clause)
De : postgis-users De la part de
Tumasgiu Rossini
Envoyé : jeudi 6 décembre 2018 17:09
À : PostGIS Users Discussion
Objet : Re: [postgis-users] Very long query ti
I do not really understand.
Is it a query which used to be faster ?
A little remark on your where clause :
it is unnecesseraly complicated and could be shortened to :
WHERE st_intersects(zi.geom, tile.geom)
True and false value doesn't need to be surronded by quote,
here you are implicitly ca
Hello there,
I'm new on the list and for a premiere I would like to know if some of you
have a very long runtime for some of their queries (even with a LIMIT 5),
whereas those queries were working well before (nothing changed from
that). I'm using Postgre10, pgAdmin4 and postgis 2.4.4 on windows
Mahdi
I have read the documentation of post gis and i could not find the
answer of my question. I want to pass a polygon to post gis and get
the list of circles with radius=500 meters which can fill that
polygon. I need to find the center of those circles. I need this for
educational purpose for
Hi,
I once developed a custom solution for this that I don't have source code
for. Logic for that was the following:
1. unbuffer the polygon by 500m. Now the contour of the unbuffered polygon
is candidate center points.
2. find the most distant point on it. this is a creative task, I just took
a
Hi,
Checking whether upgrade path is supported is easy: you open your source
package and look up your "from" version in upgradeable_versions.mk file in
extensions directory. 2.5.1 contains a record for upgrading from 2.4.6.
On Thu, Dec 6, 2018 at 11:05 AM Ahsan Hadi
wrote:
>
>
> On Wed, Dec 5,
On Wed, Dec 5, 2018 at 5:53 PM Ahsan Hadi
wrote:
>
>
> On Wed, Dec 5, 2018 at 3:55 PM Darafei "Komяpa" Praliaskouski <
> m...@komzpa.net> wrote:
>
>> Hi Ashan,
>>
>> PostGIS 2.4.6 was released after PostGIS 2.5.0. You need to upgrade to
>> 2.5.1 that was released after 2.4.6.
>>
>
> Okay so they
17 matches
Mail list logo
