lwgeom parser robustness and niceness

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

lwgeom parser robustness and niceness

Sandro Santilli-2
I've been testing lwgeom stuff.
I've found it fault on every 'unexpected' format.

All these queries kill the backend:

        -- EMPTY geoms
        SELECT 'POINT()'::lwgeom;
        SELECT 'MULTIPOINT()'::lwgeom;
        SELECT 'LINESTRING()'::lwgeom;
        SELECT 'MULTILINESTRING()'::lwgeom;
        SELECT 'POLYGON()'::lwgeom;
        SELECT 'MULTIPOLYGON()'::lwgeom;
        SELECT 'GEOMETRYCOLLECTION()'::lwgeom;

        -- NON geoms (a check for first letter is performed)
        SELECT 'P()'::lwgeom
        SELECT 'L()'::lwgeom
        SELECT 'M()'::lwgeom
        SELECT 'G()'::lwgeom

        -- INVALID geoms
        SELECT 'POINT(0 0 0 0 0)'::lwgeom;
        SELECT 'LINESTRING(0 0)'::lwgeom;
        SELECT 'POLYGON((0 0, 1 1))'::lwgeom;
        SELECT 'POLYGON(0 0)'::lwgeom;
        ... try your own ...

        -- MIXED dimension geoms
        SELECT 'MULTIPOINT(0 0 0, 0 0)'::lwgeom;
        SELECT 'LINESTRING(0 0 0 0, 0 0 0)'::lwgeom;
        ... try your own ...

Also, I don't like this error message:

        SELECT 'point(0 0)'::lwgeom;
        ERROR:  couldnt determine if input lwgeom is WKB or WKT

I think 1) it's clearly a WKT and 2) we could accept lower or mixed case
lwgeoms, wouldn't it be acceptable in speed ?

--strk;

Reply | Threaded
Open this post in threaded view
|

Re: lwgeom parser robustness and niceness

Markus Schaber-2
Hi,

On Mon, 7 Jun 2004 11:49:53 +0200
strk <[hidden email]> wrote:

>         -- INVALID geoms
>         SELECT 'LINESTRING(0 0)'::lwgeom;
>         SELECT 'POLYGON((0 0, 1 1))'::lwgeom;
>         SELECT 'POLYGON(0 0)'::lwgeom;

As I see those, I think it would be good to add a call to isvalid()
after parsing a lightweight geometry so that only valid geometries can
be written into the database.

Markus


--
markus schaber | dipl. informatiker
logi-track ag | rennweg 14-16 | ch 8001 zürich
phone +41-43-888 62 52 | fax +41-43-888 62 53
mailto:[hidden email] | www.logi-track.com

Reply | Threaded
Open this post in threaded view
|

Re: lwgeom parser robustness and niceness

Carl Anderson-2-2
In reply to this post by Sandro Santilli-2
strk wrote:

> I've been testing lwgeom stuff.
> I've found it fault on every 'unexpected' format.
>
> All these queries kill the backend:
>
>         -- EMPTY geoms
>         SELECT 'POINT()'::lwgeom;
>         SELECT 'MULTIPOINT()'::lwgeom;
>         SELECT 'LINESTRING()'::lwgeom;
>         SELECT 'MULTILINESTRING()'::lwgeom;
>         SELECT 'POLYGON()'::lwgeom;
>         SELECT 'MULTIPOLYGON()'::lwgeom;
>         SELECT 'GEOMETRYCOLLECTION()'::lwgeom;
>
>         -- NON geoms (a check for first letter is performed)
>         SELECT 'P()'::lwgeom
>         SELECT 'L()'::lwgeom
>         SELECT 'M()'::lwgeom
>         SELECT 'G()'::lwgeom
>
>         -- INVALID geoms
>         SELECT 'POINT(0 0 0 0 0)'::lwgeom;
>         SELECT 'LINESTRING(0 0)'::lwgeom;
>         SELECT 'POLYGON((0 0, 1 1))'::lwgeom;
>         SELECT 'POLYGON(0 0)'::lwgeom;
>         ... try your own ...
>
>         -- MIXED dimension geoms
>         SELECT 'MULTIPOINT(0 0 0, 0 0)'::lwgeom;
>         SELECT 'LINESTRING(0 0 0 0, 0 0 0)'::lwgeom;
>         ... try your own ...
>
> Also, I don't like this error message:
>
> SELECT 'point(0 0)'::lwgeom;
> ERROR:  couldnt determine if input lwgeom is WKB or WKT
>
> I think 1) it's clearly a WKT and 2) we could accept lower or mixed case
> lwgeoms, wouldn't it be acceptable in speed ?
>
> --strk;

If you edit the bison/lex files to include rules that cover the above
cases the abends stop.  Not that this is the corrent fix just evidence
that it is in bison/flex

such as in wktparse.y
from
a_point: point_2d | point_3d | point_4d;

to include a rule for POINT()
a_point: empty | point_2d | point_3d | point_4d;



I am not very good with bison/flex but
I suspect that the parser code is emitting a warning that is tripping
Postgres.  I have poked at the passed in error function But I think I
would need to RTFM first.


btw
moving Makefile to

        $(YACC) -vd -b wktparse -p lwg_parse_yy wktparse.y

causes it to produce wktparse..tab.c and wktparse.tab.h directly



Reply | Threaded
Open this post in threaded view
|

Re: lwgeom parser robustness and niceness

Sandro Santilli-2
On Mon, Jun 07, 2004 at 09:03:40AM -0400, Carl Anderson wrote:

> strk wrote:
> >I've been testing lwgeom stuff.
> >I've found it fault on every 'unexpected' format.
> >
> >All these queries kill the backend:
> >
> >        -- EMPTY geoms
> >        SELECT 'POINT()'::lwgeom;
> >        SELECT 'MULTIPOINT()'::lwgeom;
> >        SELECT 'LINESTRING()'::lwgeom;
> >        SELECT 'MULTILINESTRING()'::lwgeom;
> >        SELECT 'POLYGON()'::lwgeom;
> >        SELECT 'MULTIPOLYGON()'::lwgeom;
> >        SELECT 'GEOMETRYCOLLECTION()'::lwgeom;
> >
> >        -- NON geoms (a check for first letter is performed)
> >        SELECT 'P()'::lwgeom
> >        SELECT 'L()'::lwgeom
> >        SELECT 'M()'::lwgeom
> >        SELECT 'G()'::lwgeom
> >
> >        -- INVALID geoms
> >        SELECT 'POINT(0 0 0 0 0)'::lwgeom;
> >        SELECT 'LINESTRING(0 0)'::lwgeom;
> >        SELECT 'POLYGON((0 0, 1 1))'::lwgeom;
> >        SELECT 'POLYGON(0 0)'::lwgeom;
> >        ... try your own ...
> >
> >        -- MIXED dimension geoms
> >        SELECT 'MULTIPOINT(0 0 0, 0 0)'::lwgeom;
> >        SELECT 'LINESTRING(0 0 0 0, 0 0 0)'::lwgeom;
> >        ... try your own ...
> >
> >Also, I don't like this error message:
> >
> > SELECT 'point(0 0)'::lwgeom;
> > ERROR:  couldnt determine if input lwgeom is WKB or WKT
> >
> >I think 1) it's clearly a WKT and 2) we could accept lower or mixed case
> >lwgeoms, wouldn't it be acceptable in speed ?
> >
> >--strk;
>
> If you edit the bison/lex files to include rules that cover the above
> cases the abends stop.  Not that this is the corrent fix just evidence
> that it is in bison/flex
>
> such as in wktparse.y
> from
> a_point: point_2d | point_3d | point_4d;
>
> to include a rule for POINT()
> a_point: empty | point_2d | point_3d | point_4d;
>
>
>
> I am not very good with bison/flex but
> I suspect that the parser code is emitting a warning that is tripping
> Postgres.  I have poked at the passed in error function But I think I
> would need to RTFM first.

I suspect unallocated memory access actually...

Ralph, could you produce a simple test app parsing WKT from stdin
and dumping WKT to stdout ?

>
>
> btw
> moving Makefile to
>
> $(YACC) -vd -b wktparse -p lwg_parse_yy wktparse.y
>
> causes it to produce wktparse..tab.c and wktparse.tab.h directly

Before adding switches $(YACC) compatibilities should be checked.
I belive postgresql guys to be aware of this, and they rename
the output...

--strk;

>
>
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

Reply | Threaded
Open this post in threaded view
|

Re: lwgeom parser robustness and niceness

Sandro Santilli-2
Carl, you were right, it was the error function ....
I've fixed it. Now you get ERRORs instead of traps.

Also, I've unleashed the parser to accept miXeD case.

A rimaning issue is about wheter to accept (MULTI)POINT(),
(MULTI)LINESTRING(), (MULTI)POLYGON(), GEOMETRYCOLLECTION()
as empty geometries... I think that would be nice, are there
comments ?

--strk;

On Mon, Jun 07, 2004 at 03:14:52PM +0200, strk wrote:

> On Mon, Jun 07, 2004 at 09:03:40AM -0400, Carl Anderson wrote:
> > strk wrote:
> > >I've been testing lwgeom stuff.
> > >I've found it fault on every 'unexpected' format.
> > >
> > >All these queries kill the backend:
> > >
> > >        -- EMPTY geoms
> > >        SELECT 'POINT()'::lwgeom;
> > >        SELECT 'MULTIPOINT()'::lwgeom;
> > >        SELECT 'LINESTRING()'::lwgeom;
> > >        SELECT 'MULTILINESTRING()'::lwgeom;
> > >        SELECT 'POLYGON()'::lwgeom;
> > >        SELECT 'MULTIPOLYGON()'::lwgeom;
> > >        SELECT 'GEOMETRYCOLLECTION()'::lwgeom;
> > >
> > >        -- NON geoms (a check for first letter is performed)
> > >        SELECT 'P()'::lwgeom
> > >        SELECT 'L()'::lwgeom
> > >        SELECT 'M()'::lwgeom
> > >        SELECT 'G()'::lwgeom
> > >
> > >        -- INVALID geoms
> > >        SELECT 'POINT(0 0 0 0 0)'::lwgeom;
> > >        SELECT 'LINESTRING(0 0)'::lwgeom;
> > >        SELECT 'POLYGON((0 0, 1 1))'::lwgeom;
> > >        SELECT 'POLYGON(0 0)'::lwgeom;
> > >        ... try your own ...
> > >
> > >        -- MIXED dimension geoms
> > >        SELECT 'MULTIPOINT(0 0 0, 0 0)'::lwgeom;
> > >        SELECT 'LINESTRING(0 0 0 0, 0 0 0)'::lwgeom;
> > >        ... try your own ...
> > >
> > >Also, I don't like this error message:
> > >
> > > SELECT 'point(0 0)'::lwgeom;
> > > ERROR:  couldnt determine if input lwgeom is WKB or WKT
> > >
> > >I think 1) it's clearly a WKT and 2) we could accept lower or mixed case
> > >lwgeoms, wouldn't it be acceptable in speed ?
> > >
> > >--strk;
> >
> > If you edit the bison/lex files to include rules that cover the above
> > cases the abends stop.  Not that this is the corrent fix just evidence
> > that it is in bison/flex
> >
> > such as in wktparse.y
> > from
> > a_point: point_2d | point_3d | point_4d;
> >
> > to include a rule for POINT()
> > a_point: empty | point_2d | point_3d | point_4d;
> >
> >
> >
> > I am not very good with bison/flex but
> > I suspect that the parser code is emitting a warning that is tripping
> > Postgres.  I have poked at the passed in error function But I think I
> > would need to RTFM first.
>
> I suspect unallocated memory access actually...
>
> Ralph, could you produce a simple test app parsing WKT from stdin
> and dumping WKT to stdout ?
>
> >
> >
> > btw
> > moving Makefile to
> >
> > $(YACC) -vd -b wktparse -p lwg_parse_yy wktparse.y
> >
> > causes it to produce wktparse..tab.c and wktparse.tab.h directly
>
> Before adding switches $(YACC) compatibilities should be checked.
> I belive postgresql guys to be aware of this, and they rename
> the output...
>
> --strk;
>
> >
> >
> > _______________________________________________
> > postgis-devel mailing list
> > [hidden email]
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

Reply | Threaded
Open this post in threaded view
|

Re: lwgeom parser robustness and niceness

Carl Anderson-2-2
strk wrote:

> Carl, you were right, it was the error function ....
> I've fixed it. Now you get ERRORs instead of traps.
>
> Also, I've unleashed the parser to accept miXeD case.
>
> A rimaning issue is about wheter to accept (MULTI)POINT(),
> (MULTI)LINESTRING(), (MULTI)POLYGON(), GEOMETRYCOLLECTION()
> as empty geometries... I think that would be nice, are there
> comments ?
>

I am against it becuase it would tend to create in users minds the
concept of a finer grain of null geometry

sort of a null point vs a null polygon vs ...
when really there exists only a null geometry super class




--
Carl Anderson
GIS Manager, Fulton County E&CD
404.730.8026
[hidden email]


Reply | Threaded
Open this post in threaded view
|

NULL geometries (was: lwgeom parser robustness and niceness)

Sandro Santilli-2
On Mon, Jun 07, 2004 at 11:53:03AM -0400, Carl Anderson wrote:

> strk wrote:
>
> >Carl, you were right, it was the error function ....
> >I've fixed it. Now you get ERRORs instead of traps.
> >
> >Also, I've unleashed the parser to accept miXeD case.
> >
> >A rimaning issue is about wheter to accept (MULTI)POINT(),
> >(MULTI)LINESTRING(), (MULTI)POLYGON(), GEOMETRYCOLLECTION()
> >as empty geometries... I think that would be nice, are there
> >comments ?
> >
>
> I am against it becuase it would tend to create in users minds the
> concept of a finer grain of null geometry
>
> sort of a null point vs a null polygon vs ...
> when really there exists only a null geometry super class
>

Currently postgis supports (geometry and lwgeom):
        POINT(EMPTY)
        MULTIPOINT(EMPTY)
        LINESTRING(EMPTY)
        MULTILINESTRING(EMPTY)
        POLYGON(EMPTY)
        MULTIPOLYGON(EMPTY)
        GEOMETRYCOLLECTION(EMPTY)

Do you think it should drop all but last form support ?

Another note: table constraints added by AddGeometryColumn never
allow the NULL geometry to be inserted, as the check goes:

  ((geometrytype(the_geom) = '<type>'::text) OR (the_geom IS NULL))

Maybe we should add an isnullgeom(geometry) returning true for
NULL and GEOMETRYCOLLECTION(EMPTY).

comments ?

--strk;

>
>
>
> --
> Carl Anderson
> GIS Manager, Fulton County E&CD
> 404.730.8026
> [hidden email]
>
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

Reply | Threaded
Open this post in threaded view
|

Re: NULL geometries

Carl Anderson-2-2
strk wrote:

> On Mon, Jun 07, 2004 at 11:53:03AM -0400, Carl Anderson wrote:
>
>>strk wrote:
>>
>>
>>>Carl, you were right, it was the error function ....
>>>I've fixed it. Now you get ERRORs instead of traps.
>>>
>>>Also, I've unleashed the parser to accept miXeD case.
>>>
>>>A rimaning issue is about wheter to accept (MULTI)POINT(),
>>>(MULTI)LINESTRING(), (MULTI)POLYGON(), GEOMETRYCOLLECTION()
>>>as empty geometries... I think that would be nice, are there
>>>comments ?
>>>
>>
>>I am against it becuase it would tend to create in users minds the
>>concept of a finer grain of null geometry
>>
>>sort of a null point vs a null polygon vs ...
>>when really there exists only a null geometry super class
>>
>
>
> Currently postgis supports (geometry and lwgeom):
> POINT(EMPTY)
> MULTIPOINT(EMPTY)
> LINESTRING(EMPTY)
> MULTILINESTRING(EMPTY)
> POLYGON(EMPTY)
> MULTIPOLYGON(EMPTY)
> GEOMETRYCOLLECTION(EMPTY)
>
> Do you think it should drop all but last form support ?
>
> Another note: table constraints added by AddGeometryColumn never
> allow the NULL geometry to be inserted, as the check goes:
>
>   ((geometrytype(the_geom) = '<type>'::text) OR (the_geom IS NULL))
>
> Maybe we should add an isnullgeom(geometry) returning true for
> NULL and GEOMETRYCOLLECTION(EMPTY).
>
> comments ?
>
> --strk;
>
>

Reading the SFSQL 1.0 spec
     postgis is required to accept
       'POINT()', 'LINESTRING()',  etc

But I don't see a requirement that it has to be stored as such

looking at 3.2.10.2 Language Constructs
   IsEmpty(g geometry): Integer
      The return type is Integer, with a return value of 1 for TRUE,
      0 for FALSE, and –1 for UNKNOWN corresponding to a function
      invocation on NULL arguments.


But I think in the bigger picture you may tend to outsmart the statement
parser/planner.


--
Carl Anderson
GIS Manager, Fulton County E&CD
404.730.8026
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: NULL geometries

Carl Anderson-2-2
Carl Anderson wrote:

> strk wrote:
>
>> On Mon, Jun 07, 2004 at 11:53:03AM -0400, Carl Anderson wrote:
>>
>>> strk wrote:
>>>
>>>
>>>> Carl, you were right, it was the error function ....
>>>> I've fixed it. Now you get ERRORs instead of traps.
>>>>
>>>> Also, I've unleashed the parser to accept miXeD case.
>>>>
>>>> A rimaning issue is about wheter to accept (MULTI)POINT(),
>>>> (MULTI)LINESTRING(), (MULTI)POLYGON(), GEOMETRYCOLLECTION()
>>>> as empty geometries... I think that would be nice, are there
>>>> comments ?
>>>>
>>>
>>> I am against it becuase it would tend to create in users minds the
>>> concept of a finer grain of null geometry
>>>
>>> sort of a null point vs a null polygon vs ...
>>> when really there exists only a null geometry super class
>>>
>>
>>
>> Currently postgis supports (geometry and lwgeom):
>>     POINT(EMPTY)
>>     MULTIPOINT(EMPTY)
>>     LINESTRING(EMPTY)
>>     MULTILINESTRING(EMPTY)
>>     POLYGON(EMPTY)
>>     MULTIPOLYGON(EMPTY)
>>     GEOMETRYCOLLECTION(EMPTY)
>>
>> Do you think it should drop all but last form support ?
>>
>> Another note: table constraints added by AddGeometryColumn never
>> allow the NULL geometry to be inserted, as the check goes:
>>
>>   ((geometrytype(the_geom) = '<type>'::text) OR (the_geom IS NULL))
>>
>> Maybe we should add an isnullgeom(geometry) returning true for
>> NULL and GEOMETRYCOLLECTION(EMPTY).
>>
>> comments ?
>>
>> --strk;
>>
>>
>
> Reading the SFSQL 1.0 spec
>     postgis is required to accept
>       'POINT()', 'LINESTRING()',  etc
>
> But I don't see a requirement that it has to be stored as such
>
> looking at 3.2.10.2 Language Constructs
>   IsEmpty(g geometry): Integer
>      The return type is Integer, with a return value of 1 for TRUE,
>      0 for FALSE, and –1 for UNKNOWN corresponding to a function
>      invocation on NULL arguments.
>
Reading what I just wrote I take this back 'POINT()' must equate to a
empty geometry sub type POINT not a NULL.

>
> But I think in the bigger picture you may tend to outsmart the statement
> parser/planner.
>
>


--
Carl Anderson
GIS Manager, Fulton County E&CD
404.730.8026
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: NULL geometries

David Blasby-3
I'm not sure why people are having problems (crashes) with geometries
like 'POINT()' - there are tests in the regression files that test
inputs like this.  I didnt have any crashes.

This is probably a problem with people's FLEX/BISON.  Thats why I put
the actual output file in CVS so everyone would have a common source in
stead of relying on everyones different version of flex/bison to work.



Its a bit ambigeous if the SFSQL spec supports things like "POINT()" or
"POINT(EMPTY)":

2.1.3 Point
A Point is a 0-dimensional geometry and represents a single location in
coordinate space. A Point has a xcoordinate
value and a y-coordinate value.
The boundary of a Point is the empty set.
2.1.3.1 Methods
X( ):Double —The x-coordinate value for this Point.
Y( ):Double —The y-coordinate value for this Point.



PostGIS supports empty geometries like:

lwgeom_reg=# select 'GEOMETRYCOLLECTION(EMPTY)'::geometry;
              geometry
-----------------------------------
  SRID=-1;GEOMETRYCOLLECTION(EMPTY)
(1 row)

lwgeom_reg=# select 'MULTIPOINT(EMPTY)'::geometry;
          geometry
---------------------------
  SRID=-1;MULTIPOINT(EMPTY)
(1 row)

PostGIS does NOT support geometries "POINT(EMPTY)" - only
GEOMETRYCOLLECTION and MULTI* geometries.  The actual representation is,
say, a MULTIPOINT with 0 geometries in it.

Currently, LWGEOM isnt supporting this - its should be simple addition
to handle it.

Things like "POINT(EMPTY)" maybe valid WKT, but I dont think they are
actually valid geometries.  NOTE: there is no WKB representation for
"POINT(EMPTY)".

dave







Reply | Threaded
Open this post in threaded view
|

Re: lwgeom parser robustness and niceness

David Blasby-3
In reply to this post by Markus Schaber-2
Markus Schaber wrote:

> On Mon, 7 Jun 2004 11:49:53 +0200
> strk <[hidden email]> wrote:
>
>
>>        -- INVALID geoms
>>        SELECT 'LINESTRING(0 0)'::lwgeom;
>>        SELECT 'POLYGON((0 0, 1 1))'::lwgeom;
>>        SELECT 'POLYGON(0 0)'::lwgeom;
>
>
> As I see those, I think it would be good to add a call to isvalid()
> after parsing a lightweight geometry so that only valid geometries can
> be written into the database.

We've had discussion on this before - the consensus was that people
didnt want this to happen automatically.

If you want your tables to only allow valid geometries, you can add a
constaint like this:

ALTER TABLE <table> ADD CONSTRAINT <name> CHECK (isvalid(the_geom));

dave


Reply | Threaded
Open this post in threaded view
|

Re: NULL geometries

Sandro Santilli-2
In reply to this post by David Blasby-3
On Mon, Jun 07, 2004 at 10:15:19AM -0700, David Blasby wrote:
> I'm not sure why people are having problems (crashes) with geometries
> like 'POINT()' - there are tests in the regression files that test
> inputs like this.  I didnt have any crashes.
>
> This is probably a problem with people's FLEX/BISON.  Thats why I put
> the actual output file in CVS so everyone would have a common source in
> stead of relying on everyones different version of flex/bison to work.

lwgparse.c:lwg_parse_yyerror() called an undefined error() function
instead of the registered error_func().
I dunno how did it work for you...  I've fixed this now, can you
check if you have problems now ?

>
> Its a bit ambigeous if the SFSQL spec supports things like "POINT()" or
> "POINT(EMPTY)":
>
> 2.1.3 Point
> A Point is a 0-dimensional geometry and represents a single location in
> coordinate space. A Point has a xcoordinate
> value and a y-coordinate value.
> The boundary of a Point is the empty set.
> 2.1.3.1 Methods
> X( ):Double —The x-coordinate value for this Point.
> Y( ):Double —The y-coordinate value for this Point.
>
>
>
> PostGIS supports empty geometries like:
>
> lwgeom_reg=# select 'GEOMETRYCOLLECTION(EMPTY)'::geometry;
>              geometry
> -----------------------------------
>  SRID=-1;GEOMETRYCOLLECTION(EMPTY)
> (1 row)
>
> lwgeom_reg=# select 'MULTIPOINT(EMPTY)'::geometry;
>          geometry
> ---------------------------
>  SRID=-1;MULTIPOINT(EMPTY)
> (1 row)
>
> PostGIS does NOT support geometries "POINT(EMPTY)" - only
> GEOMETRYCOLLECTION and MULTI* geometries.  The actual representation is,
> say, a MULTIPOINT with 0 geometries in it.
>
> Currently, LWGEOM isnt supporting this - its should be simple addition
> to handle it.
>
> Things like "POINT(EMPTY)" maybe valid WKT, but I dont think they are
> actually valid geometries.  NOTE: there is no WKB representation for
> "POINT(EMPTY)".
>
> dave

By 'postgis supports' I meant it parses that WKT.
Internally it converts to GEOMETRYCOLLECTION(EMPTY) but accepts
ANYTYPE (EMPTY).

--strk;

>
>
>
>
>
>
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

Reply | Threaded
Open this post in threaded view
|

Re: NULL geometries

David Blasby-3
strk wrote:
> lwgparse.c:lwg_parse_yyerror() called an undefined error() function
> instead of the registered error_func().
> I dunno how did it work for you...  I've fixed this now, can you
> check if you have problems now ?

error() is defined as (about like 717):

void error(const char* err){
     error_func(err);
     ferror_occured=1;
}


I havent updated my version for a while - what is everyone doing to the
code???

I just looked in the CVS - its at line 773.


> By 'postgis supports' I meant it parses that WKT.
> Internally it converts to GEOMETRYCOLLECTION(EMPTY) but accepts
> ANYTYPE (EMPTY).

okay - I understand.

dave

Reply | Threaded
Open this post in threaded view
|

Re: NULL geometries

Sandro Santilli-2
On Mon, Jun 07, 2004 at 10:36:08AM -0700, David Blasby wrote:

> strk wrote:
> >lwgparse.c:lwg_parse_yyerror() called an undefined error() function
> >instead of the registered error_func().
> >I dunno how did it work for you...  I've fixed this now, can you
> >check if you have problems now ?
>
> error() is defined as (about like 717):
>
> void error(const char* err){
>     error_func(err);
>     ferror_occured=1;
> }
>
>
> I havent updated my version for a while - what is everyone doing to the
> code???
>
> I just looked in the CVS - its at line 773.

You are right. It's there.
Nonetheless calling it kills the backend, while directly
calling error_func() does not (on my machine).
I'll do some valgrinding...

--strk;

>
>
> >By 'postgis supports' I meant it parses that WKT.
> >Internally it converts to GEOMETRYCOLLECTION(EMPTY) but accepts
> >ANYTYPE (EMPTY).
>
> okay - I understand.
>
> dave
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

Reply | Threaded
Open this post in threaded view
|

lwg wkt parser kills postgres (was: NULL geometries)

Sandro Santilli-2
I've reverted the change in lwg_parse_yyerror(), so we can all try
to figure out what the problem is. FYI my YACC is:
        bison (GNU Bison) 1.875a
Carl has the same problem, what yacc Carl?

--strk;

On Mon, Jun 07, 2004 at 07:47:04PM +0200, strk wrote:

> On Mon, Jun 07, 2004 at 10:36:08AM -0700, David Blasby wrote:
> > strk wrote:
> > >lwgparse.c:lwg_parse_yyerror() called an undefined error() function
> > >instead of the registered error_func().
> > >I dunno how did it work for you...  I've fixed this now, can you
> > >check if you have problems now ?
> >
> > error() is defined as (about like 717):
> >
> > void error(const char* err){
> >     error_func(err);
> >     ferror_occured=1;
> > }
> >
> >
> > I havent updated my version for a while - what is everyone doing to the
> > code???
> >
> > I just looked in the CVS - its at line 773.
>
> You are right. It's there.
> Nonetheless calling it kills the backend, while directly
> calling error_func() does not (on my machine).
> I'll do some valgrinding...
>
> --strk;
>
> >
> >
> > >By 'postgis supports' I meant it parses that WKT.
> > >Internally it converts to GEOMETRYCOLLECTION(EMPTY) but accepts
> > >ANYTYPE (EMPTY).
> >
> > okay - I understand.
> >
> > dave
> > _______________________________________________
> > postgis-devel mailing list
> > [hidden email]
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-devel

Reply | Threaded
Open this post in threaded view
|

Re: lwg wkt parser kills postgres

David Blasby-3
strk wrote:

> I've reverted the change in lwg_parse_yyerror(), so we can all try
> to figure out what the problem is. FYI my YACC is:
> bison (GNU Bison) 1.875a
> Carl has the same problem, what yacc Carl?


$bison --version
bison (GNU Bison) 1.32

I've never had a problem with it crashing...

lwgeom_reg=# select 'POINT()'::lwgeom;
ERROR:  parse error - invalid geometry
lwgeom_reg=# select 'POINT(EMPTY)'::lwgeom;
ERROR:  parse error - invalid geometry

This works on the CVS version from a few hours ago and the current one.

dave



Reply | Threaded
Open this post in threaded view
|

Re: lwg wkt parser kills postgres

Carl Anderson-2-2
In reply to this post by Sandro Santilli-2
strk wrote:
> I've reverted the change in lwg_parse_yyerror(), so we can all try
> to figure out what the problem is. FYI my YACC is:
> bison (GNU Bison) 1.875a
> Carl has the same problem, what yacc Carl?
>
> --strk;


   bison-1.875-5
   flex-2.5.4a-30


-C


Reply | Threaded
Open this post in threaded view
|

Re: lwg wkt parser kills postgres

Carl Anderson-2-2
In reply to this post by David Blasby-3
David Blasby wrote:

> strk wrote:
>
>> I've reverted the change in lwg_parse_yyerror(), so we can all try
>> to figure out what the problem is. FYI my YACC is:
>>     bison (GNU Bison) 1.875a
>> Carl has the same problem, what yacc Carl?
>
>
>
> $bison --version
> bison (GNU Bison) 1.32
>
> I've never had a problem with it crashing...
>
> lwgeom_reg=# select 'POINT()'::lwgeom;
> ERROR:  parse error - invalid geometry
> lwgeom_reg=# select 'POINT(EMPTY)'::lwgeom;
> ERROR:  parse error - invalid geometry
>
> This works on the CVS version from a few hours ago and the current one.
>
> dave
>

How did you compile Postgres -- I had to upgrade to the reccommended
bison 1.875 to get Postgres 7.4.2 working

>
> _______________________________________________
> postgis-devel mailing list
> [hidden email]
> http://postgis.refractions.net/mailman/listinfo/postgis-devel


--
Carl Anderson
GIS Manager, Fulton County E&CD
404.730.8026
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: lwg wkt parser kills postgres

David Blasby-3
Carl Anderson wrote:

> How did you compile Postgres -- I had to upgrade to the reccommended
> bison 1.875 to get Postgres 7.4.2 working

I dont think you need bison to compile postgresql - it comes with those
components "pre-converted" to .c files.

They had all sorts of problems with different versions of lex/yacc, so
they made it so you wouldnt need them.

Mapserver did the same thing, I believe.

dave

Reply | Threaded
Open this post in threaded view
|

Re: lwg wkt parser kills postgres

Carl Anderson-2-2
David Blasby wrote:

> Carl Anderson wrote:
>
>> How did you compile Postgres -- I had to upgrade to the reccommended
>> bison 1.875 to get Postgres 7.4.2 working
>
>
> I dont think you need bison to compile postgresql - it comes with those
> components "pre-converted" to .c files.
>
> They had all sorts of problems with different versions of lex/yacc, so
> they made it so you wouldnt need them.
>
> Mapserver did the same thing, I believe.
>
> dave

could you delete  .cvsignore   for the moment so I can pull those files
to see.
C.


12