Opened 15 years ago
Closed 15 years ago
#224 closed task (fixed)
Add to test suite sample like UMN Mapserver and GeoServer queries
Reported by: | robe | Owned by: | pramsey |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 1.5.0 |
Component: | postgis | Version: | 1.4 |
Keywords: | Cc: |
Description
I'll try to do this tomorrow for 1.4 (well at least for Mapserver. My geoserver I only have a production one set up that I don't manage). Unless if you have already done it Paul. Given that we changed the extent behavior I was just going to verify it didn't adversely affect Mapserver.
We probably should add as part of our test suite the kinds of queries that MapServer and Geoserver call against PostGIS since we have a large number of users (me included) using these for their apps.
Attachments (1)
Change History (8)
comment:1 by , 15 years ago
comment:3 by , 15 years ago
No? I was thinking we would actually have sample queries run by geoserver and mapserver in our battery of tests (bbox queries and the like). Ideally it would be nice if we could test in the geoserver/mapserver/whatever server environment before deployment, but that may be asking too much too soon.
I would be happy if we could just setup some test data, sample profile run in mapserver/geoserver to see what queries they construct against it, and verify those continue to return the right results.
comment:4 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Added in test SQL as snooped from the PgSQL log file during MapServer/Geoserver draws. At r4839.
comment:5 by , 15 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Unfortunately this is throwing multiple regression failures for me here (see attached).
ATB,
Mark.
comment:7 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Yes thanks, that works now. That's quite a heavy truncation of precision though - I hope it's not enough to affect the usefulness of the test…
ATB,
Mark.
I tested 1.4 against my UMN Mapserver install and still seems to work. It seems slower for some things, but I think that is more to do with the fact that I also upgraded to PostgreSQL 8.4 and changed the encoding of my data and my indexes (that I took for granted varchar/text being the same thing - don't appear to be being picked up by the planner).