Hello,
I have two tables with geometry columns defined as
geometry(POINT), geometry(LINESTRING), and geometry(MULTIPOLYGON), passed in as
a sequence of lon/lat coordinates.
I don't have any projection defined on these tables, so I believe it's using
the system SRID of 0.
Would I get accurate re
Thanks to everyone who contributed to this thread, either on the PostGIS
[1] or the PostgreSQL [2] mailing lists. I will try to summarize everything
in this message, which I will actually post on both lists to give an update
to everyone. I hope it can be useful for other people interested. Pleas
Greetings all,
I am working on a set of data where I have noded linestrings. All
linestrings have just two points and the nodes were derived from the
endpoints.
I've found one instance where st_intersects and st_equals return the
incorrect value (AFAICT).
==
select
Own setup : dell precision 2*6 cores, 20 go RAM, SSD for index, 7200 HDD
for big tables.
I do very different stuff with the server :
- base for visualisation of classical vector table (Usually few users
mostly reading.)
- base for automatic road generation (topology + very very complex query)
-
Hey,
for the following I make the hypothesis that
1. for you trip A->B should be separated from trip B->A.
2. od1.taz.geom are non overlaping polygon (ie your zone are non
overlaping)
3. whatever startloc, endloc, there exist a zone overlapping it.
Now you querry look like this
--compute the o
Hi Birgit,
Thanks very much.
I'm not familiar with the "with" clause but will look into that. There are also
indices on startts and z.uuid ( time range condition is ok, since these are
timestamps and not days).
I am also finding that a cause of slowness was due to the OR condition:
ST_intersec
Hi Trang,
I think, it could help to create btree indices on "startts" and "uuid",
too, since you are using them in your where clause as a filter (a
probably unnecessary question regarding your date filter: I would expect
the result of "t.startts > '2015-01-16' and t.startts < '2015-01-17'" to