[postgis-devel] Testing on Windows PostGIS 1RC1

Wed Sep 22 15:18:37 PDT 2010

This was an evening of regression.
I have to go to bed so I will just write some notes about the walls I ran into with head first.

 don't think anything means problem for release, but is more of my installation problems and things like that.

I succeeded compiling postgresql 9 on the other box. 

Regina, I saw in configure output when configuring postgresql that it wasn't happy about the Perl version. It wanted a newer version. Can that be the reason that it didn't set the ${PERL} global. Your hack seems to work for me to but can it affect something else if the version is to low?

Anyway, I gave up to compile against postrgesql 9.0 earlier so I thought I should do some testing against 8.4 to at least success with something.

So I just compiled 1.5.2rc1 against an old postgresql84 server that I have compiled earlier.

But on that one I get the error:

could not load library "c:/pg84/lib/postgresql/postgis-1.5.dll" unknown error 126

it puts "postgresql" into the path. Why? do you have that problem Regina?

Ok, I also wanted to see more about the regression failure in ubuntu 32bit so I compiled svn branch for 1.5 and I get the same failure. instead of LINESTRING(0 0, 0 0)  I get some very small numbers on the coordinates the like 6e-15

I thought I should just put ST_SnapToGrid into it to round it a little
but since st_shortestline returns a zero-length linestring when inputed geometries intersect
st_snaptogrid then removes one of the vertexes from the linestring and returns nothing.

like:
select st_snaptogrid('LINESTRING(1 2, 1 2)'::geometry, 0.1)

So we don't get a parse error or an empty geometry, but... nothing

Maybe empty geometry would be better?

Anyway that makes st_shortestline not working very well with st_snaptogrid
Can anyone come with a better answer from st_shortestline when the two geometries intersect than a zero-length linestring in any of the intersecting points?

On other words I have spent an evening in front of monitors without doing anything at all

I give up for now. 
Tell me if it is anything of above that worries and should be investigated before release then I will try to get more information on that.

/Nicklas

2010-09-22 Nicklas Avén  wrote:

Regina> >My problem was already when compiling postgresql 9.0>I guess I have something outdated. I will try again now and maybe get back if I don't figure out what the error-messege is about.> >everybody> >I know I have had some regression tests failiurs on measures the other week. It is one of those small differences and it only shows for me on a ubuntu 32bit installation. On windows (on the same machine as ubuntu 32 bit) and ubuntu 64bit on another box, it passes.> >Is someone getting running the regression tests on linux 32 bit with sucess on measures?> >One thing that is a little interesting about it is that the installations that passes regression tests is the same installations that gives the fenomena in #503.> >So the installations passing the regreesion tests are the same installations as rounds the answer of area to closest multiple of 0.001953125> >I just wanted to mention it if it can be a clue for someone smart about #503> >/Nicklas
>
>2010-09-22 Paragon Corporation wrote:
>
>
>>Nicklas,
>>
>>> I will try to do some testing this evening. I tried yesterday on windows
>>but had problems with compiling postgresql 9.0I don't remember the error
>>message now. I will try on another > box. Regina has there been any special
>>things compiling 9.0 in mingw for you? I have not updated anything (have
>>just been glad it has worked :-) )so maybe I should just reinstall 
>>> mingw and everything. /Nicklas 
>>
>>
>>We do use some hacks to compile against PostgreSQL 9.0 on windows that we
>>don't need to do for prior versions.
>>
>>That's why I said -- maybe the issues I have on Windows are not really a
>>good measure of what others will experience and someone needs to test on
>>Linux or Mac.
>>
>> 1) can't get it to install without this:
>>sed 's,$(PERL),perl,g'postgis/Makefile2
>>mv postgis/Makefile2 postgis/Makefile
>>
>>Which I documented in the PostGIS 1.5 section of
>>
>>trac.osgeo.org/postgis/wiki/UsersWikiWinCompile
>>
>>
>>2) For some reason we can't do a make check against the MingW build of
>>PostgreSQL 9.0. It always gives this error
>>
>>createdb: could not connect to database postgres: FATAL: parameter "port"
>>cannot be changed without restarting the server
>>
>>(could be because we have so many versions of PostgreSQL, but the other
>>versions of PostgreSQL don't have this issue)
>>
>>So to get around this mess -- after make install on MingW, our script copies
>>the files to our Windows PostgreSQL 9.0 install and then does the 
>>
>>make check
>>
>>For the others -- make check against the mingW builds works fine and all
>>checks for 8.3 and 8.4 against mingW builds pass with flying colors.
>>
>>
>>-- Mark to answer your question about the diffs in the PostgreSQL 9.0 --
>>they look like below - so it seems to me that the PostgreSQL 9.0 (and it
>>could be some default sent in the Windows build just providing the count
>>of records (more information) than what the regress is expecting.
>>
>>*** wmsservers_expected Tue Nov 17 12:23:16 2009
>>--- /tmp/pgis_reg_124/test_46_out Mon Sep 20 08:54:34 2010
>>***************
>>*** 1,6 ****
>> Starting up MapServer/Geoserver tests...
>> Setting up the data table...
>>! SELECT
>> NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index
>>"wmstest_pkey" for table "wmstest"
>> ALTER TABLE
>> Running Geoserver 2.0 NG tests...
>>--- 1,6 ----
>> Starting up MapServer/Geoserver tests...
>> Setting up the data table...
>>! SELECT 2343
>> NOTICE: ALTER TABLE / ADD PRIMARY KEY will create implicit index
>>"wmstest_pkey" for table "wmstest"
>> ALTER TABLE
>> Running Geoserver 2.0 NG tests...
>>
>>
>>*** tickets_expected Mon Feb 8 14:19:23 2010
>>--- /tmp/pgis_reg_124/test_47_out Mon Sep 20 08:54:36 2010
>>***************
>>*** 45,51 ****
>> #210b|
>> #213|17
>> #234|COMPOUNDCURVE((0 0,1 1))
>>! SELECT
>> #241|0
>> #254|010700000000000000
>> #259|
>>--- 45,51 ----
>> #210b|
>> #213|17
>> #234|COMPOUNDCURVE((0 0,1 1))
>>! SELECT 1
>> #241|0
>> #254|010700000000000000
>> #259|
>>
>>
>>Thanks,
>>Regina
>>
>>
>>----------------
>>
>>
>>
>>>
>>>> Remember that because postgis_comments.sql has extra dependencies for the
>>>documentation build that it needs to be installed from the documentation
>>>Makefile. This is now under PGXS control too, so all you need to do is:
>>>
>>>> cd doc/
>>>> make comments-install
>>>
>>>> ...and you're golden.
>>>
>>>For this then we probably should put a note somewhere in the docs that if
>>>they aren't doing a make install of comments, then the comments will have
>>to
>>>be manually copied.
>>>
>>>The point why we package the postgis_comments.sql in the tar is so that
>>>people don't need the extra xsltproc dependency and don't need to run the
>>>step you describe above. So yah I know the step above works but that is not
>>>the point.
>>>
>>>I'll have to get back to you other issue as I don't have my difffs around.
>>>
>>>All I recall is the output was something like
>>>
>>>SELECT 3456
>>>
>>>And the regress just had
>>>
>>>
>>>SELECT
>>>
>>>
>>>But lets see what others say. We are on windows so who cares since things
>>>don't quite work the same for us anyway.
>>>
>>>Thanks,
>>>Regina
>>>
>>>
>>
>>
>>_______________________________________________
>>postgis-devel mailing list
>>postgis-devel at postgis.refractions.net
>>postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20100923/e46f6b55/attachment.html>