Paul
I suggest you chaeck the XY coords in your data, it looks like you have
mislabeled lat & lon, your "lat" values are > 90 & <180.
If you have loaded these into Postgis with the coords reversed, then they will
not be in the correct location, which could be why ST_contains fails
Brent Wood
Hi Paul,
AFAICT you are using ST_Cointains correctly, and MultiPolygons shouldn't
be an issue. I assume that your geometries have the same SRID, otherwise
PostGIS would complain.
Can you post a full example (including the WKT of both geometries) where
you get false but expect true for ST_Co
That's what I thought ... my morning coffee hadn't kicked in yet :)
It still looks like PostGIS might benefit from a
ShiftCoordinates(linearring geometry) function to solve this particular
problem.
-- Kevin
On 10/22/2010 10:45 AM, David William Bitner wrote:
D-P simplification is not going to
D-P simplification is not going to modify your start/end points. For a bit
of reference on the Douglas-Peuker simplification algorithm, see
http://en.wikipedia.org/wiki/Ramer%E2%80%93Douglas%E2%80%93Peucker_algorithm
On Fri, Oct 22, 2010 at 11:13 AM, Kevin Neufeld wrote:
> I don't see any pdf pos
Lee,
No you can't ignore the type geometry does not exist error.
We usually do compressed tar backups since you have more control over what
you restore and whether to ignore errors, overwrite etc etc.
I haven't tried restoring full dumps in a while, but they are mostly
designed for disaster rec
I don't see any pdf posted, but that's ok, I get the idea.
Isn't that interesting. To me, this looks like a robustness issue with
ST_Simplify. Here, the starting point of the polygon's exterior ring is
not on the corner.
select
st_astext(
st_simplify(
'POLYGON ((
25 300,
Dharmendra Goyal wrote:
Hi Mark,
I added one CFLAG /GS- and security cookie related warnings went away
but following symbols still could not be found:
c:/pginstaller.pune-repo/proj-4.7.0.staging/lib/proj.lib(pj_gridinfo.obj):(.text+0x6e7):
undefined reference to `_ftol2_sse'
c:/pginstaller.
>Great. But I also specifically meant if the way of binary encoding is stable?
>That's probably important for those application which read/write WKB
>with their own means i.a. without PostGIS libraries.
I am pretty confident it will stay stable until we add new stuff to it.
Probably not before Po
> Exact. There are lots of things that we could include/discuss in WKB for
> raster like:
Great. But I also specifically meant if the way of binary encoding is stable?
That's probably important for those application which read/write WKB
with their own means i.a. without PostGIS libraries.
-S.
2
>> As I said: no. They are not specified in public. I wish there would have
>> been a public spec to tell
>me how to store raster but there is not.
>
>I'd like to understand and support this better:
>
>1. You write "They are not specified in public.": But now they are at
>least in the sense of "Po
Salut Pierre, Hallo Peter
Many thanks for your explanations.
Pierre answered:
> >=> Do you mean by WKB that these formats are specified in public
> >accessible specs.?
>
>
> As I said: no. They are not specified in public. I wish there would have been
> a public spec to tell me how to store rast
Hi Kevin,
Hopefully the attached (hopefully) PDF will help to show what i mean.
In producing the PDF i think i can see why the issue happens. It seems that
the start and end point of the polygon geometery are the node i was hoping
might be removed during the simplify process.
Not sure if there
Thanks. Solved!
That worked like a charm.
Exactly what i wanted.
Andreas
2010/10/21 Nicklas Avén
> Ok
>
> still don't get the second query. If I understand you right you could try
> this:
>
> CREATE TABLE borddisttest2 AS
> select a.gid, a.cell, MIN(ST_Distance(a.centroid, b.the_geom)) AS dist
13 matches
Mail list logo
