This is a well-chewed issue, and we have come down repeatedly in
favour of allowing invalid geometry to be loaded. Which, I suppose,
means we should loosen the parser to allow even non-closed rings.
What *does* need to be done (issue for me, it's not that hard) is a
few additional hooks to the
Paul Ramsey wrote:
This is a well-chewed issue, and we have come down repeatedly in
favour of allowing invalid geometry to be loaded. Which, I suppose,
means we should loosen the parser to allow even non-closed rings.
Dropping the checks from the parser is a relatively straightforward
thing
On Sat, 2007-11-17 at 20:34 +, Mark Cave-Ayland wrote:
So the real bug in this case is that the (E)WKB parser doesn't seem to
attempt to validate any geometries being passed through it :( I've had
a look at the parser code and it's quite a complicated beast with not
many comments, so I
Thanks, I hope it will help to others...
Mark Cave-Ayland wrote:
On Sat, 2007-11-17 at 20:34 +, Mark Cave-Ayland wrote:
So the real bug in this case is that the (E)WKB parser doesn't seem to
attempt to validate any geometries being passed through it :( I've had
a look at the parser
On Mon, 2007-11-19 at 22:40 +0100, Ivan Mincik wrote:
thanks a lot. these wrong are coming from some special format of
cadastral data in my country. data where first saved to ESRI
shapefile by OGR, then imported to postgis by shp2pgsgl. I think that
they are invalid also for the shapefile.
thanks a lot. these wrong are coming from some special format of
cadastral data in my country. data where first saved to ESRI
shapefile by OGR, then imported to postgis by shp2pgsgl. I think that
they are invalid also for the shapefile. can it be similar issue?
again thank you very much
ivan
On Mon, 2007-10-29 at 23:25 +0100, ivan minčík wrote:
I made pg_dump from the table. You can download it here:
http://disk.jabbim.cz/[EMAIL PROTECTED]/bug_db.tar.gz
You have to:
1. change my database user (called ivo) to Your user
2. createdb somedb
3. psql -U
hi, Mark
SELECT version();
version
---
PostgreSQL 8.1.9 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.1.2
20061115 (prerelease)
Well, I've spent several fruitless hours trying to upgrade us to a
more recent spam-resistant version of phpbt, and I hereby declare
failure. The new version may well be more spam resistant, but it's
also entirely PostgreSQL resistant -- it seems quite dependent on a
MySQL group by syntax
On Mon, 2007-10-29 at 23:25 +0100, ivan minčík wrote:
I made pg_dump from the table. You can download it here:
http://disk.jabbim.cz/[EMAIL PROTECTED]/bug_db.tar.gz
You have to:
1. change my database user (called ivo) to Your user
2. createdb somedb
3. psql -U
Halo,
I cannot find where to register to be able to submit bug at
http://postgis.refractions.net/bugs/ . Am I missing something?
Thanks
Ivan
___
postgis-users mailing list
postgis-users@postgis.refractions.net
thanks, I just wanted to submit bug described in this thread
http://postgis.refractions.net/pipermail/postgis-users/2007-October/017365.html
this is one of the objects which was the reason
MULTIPOLYGON(((-99.63 -1270249.25,-333416.78 -1270247.43,-333415.54
-1270231.88,-333411.49
my detail are:
Debian Etch stable.
select postgis_full_version();
postgis_full_version
--
POSTGIS=1.1.6 GEOS=2.2.3-CAPI-1.1.1 PROJ=Rel. 4.5.0, 22 Oct 2006
USE_STATS
(1 row)
but the
On Mon, 2007-10-29 at 18:46 +0100, ivan minčík wrote:
my detail are:
Debian Etch stable.
select postgis_full_version();
postgis_full_version
--
POSTGIS=1.1.6
On Mon, 2007-10-29 at 18:20 +0100, ivan minčík wrote:
thanks, I just wanted to submit bug described in this thread
http://postgis.refractions.net/pipermail/postgis-users/2007-October/017365.html
this is one of the objects which was the reason
MULTIPOLYGON(((-99.63
I made pg_dump from the table. You can download it here:
http://disk.jabbim.cz/[EMAIL PROTECTED]/bug_db.tar.gz
You have to:
1. change my database user (called ivo) to Your user
2. createdb somedb
3. psql -U youruser -f bug_db.sql somedb
try
select simplify(the_geom,100)
16 matches
Mail list logo
