Re: [mapserver-users] WMS TIME parameter slow
Am Mittwoch 10 März 2010 16:52:28 schrieb Heiko Schröter:
Done what has been suggested. The 'date_trunc' function forces sequential scans
instead of using the indexed scans.
I've tried and failed:
sc_gis=# CREATE INDEX o_v20_y2007_date_trunc ON o_v20_y2007 (date_trunc('day',
datum at time zone 'GMT'));
ERROR: functions in index expression must be marked IMMUTABLE
Probably the MS list is not the right place to ask.
But may be a kind soul has some pointers to more infos.
I admit that db's are not my field of experience and i'am still learning.
On the other hand it would be nice to have a hint about the indexing issue
inside the MS docs when using the WMS Time extension.
Heiko
sc_gis=# explain analyze select
datum,farbe,encode(AsBinary(force_collection(force_2d(rechteck)),'NDR'),'hex')
as geom,datum from o_v20 where rechteck
GeomFromText('POLYGON((-134.90506329114 -78.2278481012662,-134.90506329114
78.2278481012663,134.90506329114
78.2278481012663,134.90506329114 -78.2278481012662,-134.90506329114
-78.2278481012662))',-1) and (datum = '2007-12-10' and datum = '2007-12-30');
QUERY PLAN
--
Result (cost=0.00..585.37 rows=4420 width=450) (actual time=0.083..35.821
rows=5322 loops=1)
- Append (cost=0.00..541.17 rows=4420 width=450) (actual
time=0.067..13.852 rows=5322 loops=1)
- Seq Scan on o3_v20 (cost=0.00..16.65 rows=1 width=55) (actual
time=0.001..0.001 rows=0 loops=1)
Filter: ((rechteck
'0103000100050035884A47F6DC60C038D93310958E53C035884A47F6DC60C03FD93310958E534035884A47F6DC60403FD93310958E534035884A47F6DC604038D93310958E53C035884A47F6DC60C038D93310958E53C0'::geometry)
AND (datum = '2007-12-10'::date) AND (datum = '2007-12-30'::date))
- Index Scan using o3_v20_y2002_datum on o3_v20_y2002 o3_v20
(cost=0.00..8.28 rows=1 width=450) (actual time=0.012..0.012 rows=0 loops=1)
Index Cond: ((datum = '2007-12-10'::date) AND (datum =
'2007-12-30'::date))
Filter: (rechteck
'0103000100050035884A47F6DC60C038D93310958E53C035884A47F6DC60C03FD93310958E534035884A47F6DC60403FD93310958E534035884A47F6DC604038D93310958E53C035884A47F6DC60C038D93310958E53C0'::geometry)
- Index Scan using o3_v20_y2003_datum on o3_v20_y2003 o3_v20
(cost=0.00..8.28 rows=1 width=450) (actual time=0.006..0.006 rows=0 loops=1)
Index Cond: ((datum = '2007-12-10'::date) AND (datum =
'2007-12-30'::date))
Filter: (rechteck
'0103000100050035884A47F6DC60C038D93310958E53C035884A47F6DC60C03FD93310958E534035884A47F6DC60403FD93310958E534035884A47F6DC604038D93310958E53C035884A47F6DC60C038D93310958E53C0'::geometry)
- Index Scan using o3_v20_y2004_datum on o3_v20_y2004 o3_v20
(cost=0.00..8.28 rows=1 width=450) (actual time=0.005..0.005 rows=0 loops=1)
Index Cond: ((datum = '2007-12-10'::date) AND (datum =
'2007-12-30'::date))
Filter: (rechteck
'0103000100050035884A47F6DC60C038D93310958E53C035884A47F6DC60C03FD93310958E534035884A47F6DC60403FD93310958E534035884A47F6DC604038D93310958E53C035884A47F6DC60C038D93310958E53C0'::geometry)
- Index Scan using o3_v20_y2005_datum on o3_v20_y2005 o3_v20
(cost=0.00..8.28 rows=1 width=450) (actual time=0.005..0.005 rows=0 loops=1)
Index Cond: ((datum = '2007-12-10'::date) AND (datum =
'2007-12-30'::date))
Filter: (rechteck
'0103000100050035884A47F6DC60C038D93310958E53C035884A47F6DC60C03FD93310958E534035884A47F6DC60403FD93310958E534035884A47F6DC604038D93310958E53C035884A47F6DC60C038D93310958E53C0'::geometry)
- Index Scan using o3_v20_y2006_datum on o3_v20_y2006 o3_v20
(cost=0.00..8.28 rows=1 width=450) (actual time=0.005..0.005 rows=0 loops=1)
Index Cond: ((datum = '2007-12-10'::date) AND (datum =
'2007-12-30'::date))
Filter: (rechteck
'0103000100050035884A47F6DC60C038D93310958E53C035884A47F6DC60C03FD93310958E534035884A47F6DC60403FD93310958E534035884A47F6DC604038D93310958E53C035884A47F6DC60C038D93310958E53C0'::geometry)
- Index Scan using o3_v20_y2007_datum on o3_v20_y2007 o3_v20
(cost=0.00..458.27 rows=4411 width=450) (actual time=0.031..10.732 rows=5322
loops=1)
Index Cond: ((datum = '2007-12-10'::date) AND (datum =
'2007-12-30'::date))
Filter: (rechteck
'0103000100050035884A47F6DC60C038D93310958E53C035884A47F6DC60C03FD93310958E534035884A47F6DC60403FD93310958E534035884A47F6DC604038D93310958E53C035884A47F6DC60C038D93310958E53C0'::geometry)
-
Re: [mapserver-users] WMS TIME parameter slow
Good job getting this far on your own! Create a SQL wrapper function
on top of date_trunc which *is* marked as immutable and you'll be able
to build a functional index on it.
P.
On Thu, Mar 11, 2010 at 1:39 AM, Heiko Schröter
schro...@iup.physik.uni-bremen.de wrote:
Am Mittwoch 10 März 2010 16:52:28 schrieb Heiko Schröter:
Done what has been suggested. The 'date_trunc' function forces sequential
scans instead of using the indexed scans.
I've tried and failed:
sc_gis=# CREATE INDEX o_v20_y2007_date_trunc ON o_v20_y2007
(date_trunc('day', datum at time zone 'GMT'));
ERROR: functions in index expression must be marked IMMUTABLE
Probably the MS list is not the right place to ask.
But may be a kind soul has some pointers to more infos.
I admit that db's are not my field of experience and i'am still learning.
On the other hand it would be nice to have a hint about the indexing issue
inside the MS docs when using the WMS Time extension.
Heiko
sc_gis=# explain analyze select
datum,farbe,encode(AsBinary(force_collection(force_2d(rechteck)),'NDR'),'hex')
as geom,datum from o_v20 where rechteck
GeomFromText('POLYGON((-134.90506329114 -78.2278481012662,-134.90506329114
78.2278481012663,134.90506329114
78.2278481012663,134.90506329114 -78.2278481012662,-134.90506329114
-78.2278481012662))',-1) and (datum = '2007-12-10' and datum =
'2007-12-30');
QUERY PLAN
--
Result (cost=0.00..585.37 rows=4420 width=450) (actual time=0.083..35.821
rows=5322 loops=1)
- Append (cost=0.00..541.17 rows=4420 width=450) (actual
time=0.067..13.852 rows=5322 loops=1)
- Seq Scan on o3_v20 (cost=0.00..16.65 rows=1 width=55) (actual
time=0.001..0.001 rows=0 loops=1)
Filter: ((rechteck
'0103000100050035884A47F6DC60C038D93310958E53C035884A47F6DC60C03FD93310958E534035884A47F6DC60403FD93310958E534035884A47F6DC604038D93310958E53C035884A47F6DC60C038D93310958E53C0'::geometry)
AND (datum = '2007-12-10'::date) AND (datum = '2007-12-30'::date))
- Index Scan using o3_v20_y2002_datum on o3_v20_y2002 o3_v20
(cost=0.00..8.28 rows=1 width=450) (actual time=0.012..0.012 rows=0 loops=1)
Index Cond: ((datum = '2007-12-10'::date) AND (datum =
'2007-12-30'::date))
Filter: (rechteck
'0103000100050035884A47F6DC60C038D93310958E53C035884A47F6DC60C03FD93310958E534035884A47F6DC60403FD93310958E534035884A47F6DC604038D93310958E53C035884A47F6DC60C038D93310958E53C0'::geometry)
- Index Scan using o3_v20_y2003_datum on o3_v20_y2003 o3_v20
(cost=0.00..8.28 rows=1 width=450) (actual time=0.006..0.006 rows=0 loops=1)
Index Cond: ((datum = '2007-12-10'::date) AND (datum =
'2007-12-30'::date))
Filter: (rechteck
'0103000100050035884A47F6DC60C038D93310958E53C035884A47F6DC60C03FD93310958E534035884A47F6DC60403FD93310958E534035884A47F6DC604038D93310958E53C035884A47F6DC60C038D93310958E53C0'::geometry)
- Index Scan using o3_v20_y2004_datum on o3_v20_y2004 o3_v20
(cost=0.00..8.28 rows=1 width=450) (actual time=0.005..0.005 rows=0 loops=1)
Index Cond: ((datum = '2007-12-10'::date) AND (datum =
'2007-12-30'::date))
Filter: (rechteck
'0103000100050035884A47F6DC60C038D93310958E53C035884A47F6DC60C03FD93310958E534035884A47F6DC60403FD93310958E534035884A47F6DC604038D93310958E53C035884A47F6DC60C038D93310958E53C0'::geometry)
- Index Scan using o3_v20_y2005_datum on o3_v20_y2005 o3_v20
(cost=0.00..8.28 rows=1 width=450) (actual time=0.005..0.005 rows=0 loops=1)
Index Cond: ((datum = '2007-12-10'::date) AND (datum =
'2007-12-30'::date))
Filter: (rechteck
'0103000100050035884A47F6DC60C038D93310958E53C035884A47F6DC60C03FD93310958E534035884A47F6DC60403FD93310958E534035884A47F6DC604038D93310958E53C035884A47F6DC60C038D93310958E53C0'::geometry)
- Index Scan using o3_v20_y2006_datum on o3_v20_y2006 o3_v20
(cost=0.00..8.28 rows=1 width=450) (actual time=0.005..0.005 rows=0 loops=1)
Index Cond: ((datum = '2007-12-10'::date) AND (datum =
'2007-12-30'::date))
Filter: (rechteck
'0103000100050035884A47F6DC60C038D93310958E53C035884A47F6DC60C03FD93310958E534035884A47F6DC60403FD93310958E534035884A47F6DC604038D93310958E53C035884A47F6DC60C038D93310958E53C0'::geometry)
- Index Scan using o3_v20_y2007_datum on o3_v20_y2007 o3_v20
(cost=0.00..458.27 rows=4411 width=450) (actual time=0.031..10.732 rows=5322
loops=1)
Index Cond: ((datum = '2007-12-10'::date) AND (datum =
'2007-12-30'::date))
Re: [mapserver-users] WMS TIME parameter slow
Am Donnerstag 11 März 2010 14:35:53 schrieben Sie:
Paul,
thanks for staying at it. These timings i get with the variation of the theme.
The second best is to cast 'datum::timestamp'. But still beeing 32times slower
than just a trivial compare on the index as in 1). The slowest run is the brute
force 'date_trunc' without cast 3). So to me this is a bit voodo why postgres
refuses to scan the indices in proper speed in 2) and 3).
The maximum index scan i get with 'date_trunc' is a 'Bitmap Heap Scan' on the
index with scenario 2).
Of what i have found inside the docs/google is that even when casting 'datum'
inside postgres the request, here generated by MS, should or have to be casted
as well which is not (at least by now).
Heiko
1) The brute force compare:
sc_gis=# explain analyze select
datum,farbe,encode(AsBinary(force_collection(force_2d(rechteck)),'NDR'),'hex')
as geom,datum from o_v20 where rechteck
GeomFromText('POLYGON((-134.90506329114 -78.2278481012662,-134.90506329114
78.2278481012663,134.90506329114
78.2278481012663,134.90506329114 -78.2278481012662,-134.90506329114
-78.2278481012662))',-1) and (datum = '2007-12-10' and datum = '2007-12-11');
snipsnap
Total runtime: 41.018 ms
(32 rows)
Now Create Immutable Index on our play table:
CREATE INDEX o_v20_y2007_date_trunc ON o_v20_y2007 (date_trunc('day',
datum::timestamp without time zone));
2)
sc_gis=# CREATE INDEX o3_v20_y2007_date_trunc ON o3_v20_y2007
(date_trunc('day', datum::timestamp without time zone));
ERROR: relation o3_v20_y2007_date_trunc already exists
scia_gis=# explain analyze select
datum,farbe,encode(AsBinary(force_collection(force_2d(rechteck)),'NDR'),'hex')
as geom,datum from o_v20 where rechteck
GeomFromText('POLYGON((-134.90506329114 -78.2278481012662,-134.90506329114
78.2278481012663,134.90506329114
78.2278481012663,134.90506329114 -78.2278481012662,-134.90506329114
-78.2278481012662))',-1) and ((date_trunc('day', datum::timestamp without time
zone) = '2007-12-10' AND date_trunc('day', datum::timestamp without time zone)
= '2007-12-11'));
snipsnap
Total runtime: 1250.679 ms
(26 rows)
3)
sc_gis=# explain analyze select
datum,farbe,encode(AsBinary(force_collection(force_2d(rechteck)),'NDR'),'hex')
as geom,datum from o_v20 where rechteck
GeomFromText('POLYGON((-134.90506329114 -78.2278481012662,-134.90506329114
78.2278481012663,134.90506329114
78.2278481012663,134.90506329114 -78.2278481012662,-134.90506329114
-78.2278481012662))',-1) and ((date_trunc('day', datum) = '2007-12-10' AND
date_trunc('day', datum) = '2007-12-11'));
snipsnap
Total runtime: 2329.380 ms
(23 rows)
Good job getting this far on your own! Create a SQL wrapper function
on top of date_trunc which *is* marked as immutable and you'll be able
to build a functional index on it.
P.
On Thu, Mar 11, 2010 at 1:39 AM, Heiko Schröter
schro...@iup.physik.uni-bremen.de wrote:
Am Mittwoch 10 März 2010 16:52:28 schrieb Heiko Schröter:
Done what has been suggested. The 'date_trunc' function forces sequential
scans instead of using the indexed scans.
I've tried and failed:
sc_gis=# CREATE INDEX o_v20_y2007_date_trunc ON o_v20_y2007
(date_trunc('day', datum at time zone 'GMT'));
ERROR: functions in index expression must be marked IMMUTABLE
Probably the MS list is not the right place to ask.
But may be a kind soul has some pointers to more infos.
I admit that db's are not my field of experience and i'am still learning.
On the other hand it would be nice to have a hint about the indexing issue
inside the MS docs when using the WMS Time extension.
Heiko
sc_gis=# explain analyze select
datum,farbe,encode(AsBinary(force_collection(force_2d(rechteck)),'NDR'),'hex')
as geom,datum from o_v20 where rechteck
GeomFromText('POLYGON((-134.90506329114
-78.2278481012662,-134.90506329114 78.2278481012663,134.90506329114
78.2278481012663,134.90506329114 -78.2278481012662,-134.90506329114
-78.2278481012662))',-1) and (datum = '2007-12-10' and datum =
'2007-12-30');
QUERY PLAN
--
Result (cost=0.00..585.37 rows=4420 width=450) (actual time=0.083..35.821
rows=5322 loops=1)
- Append (cost=0.00..541.17 rows=4420 width=450) (actual
time=0.067..13.852 rows=5322 loops=1)
- Seq Scan on o3_v20 (cost=0.00..16.65 rows=1 width=55) (actual
time=0.001..0.001 rows=0 loops=1)
Filter: ((rechteck
[mapserver-users] OSM2 SqlServer 2008
...I wondered if there is an utility like OSM2pgsql that can import OSM data directly to SqlServer 2008. Has anybody any suggestion about it? Can I import data to PostGIS and then from PostGIS transfer data to SqlServer? thank to all, Kiks -- View this message in context: http://n2.nabble.com/OSM2-SqlServer-2008-tp4716063p4716063.html Sent from the Mapserver - User mailing list archive at Nabble.com. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] OSM2 SqlServer 2008
Hi, I believe that the best way at the moment is to import data with osm2pgsql into PostGIS first and continue then with ogr2ogr. -Jukka Rahkonen- Kiks wrote: ...I wondered if there is an utility like OSM2pgsql that can import OSM data directly to SqlServer 2008. Has anybody any suggestion about it? Can I import data to PostGIS and then from PostGIS transfer data to SqlServer? thank to all, Kiks -- View this message in context: http://n2.nabble.com/OSM2-SqlServer-2008-tp4716063p4716063.html Sent from the Mapserver - User mailing list archive at Nabble.com. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] WMS TIME parameter slow
Sorry, there's not much more I can offer, you've done a great job
debugging, but at the end of the day the SQL being generated by the
WMS Time module is not great. Make sure to run 'ANALYZE' on your
database so the planner has the latest stats.
P.
On Thu, Mar 11, 2010 at 5:59 AM, Heiko Schröter
schro...@iup.physik.uni-bremen.de wrote:
Am Donnerstag 11 März 2010 14:35:53 schrieben Sie:
Paul,
thanks for staying at it. These timings i get with the variation of the
theme. The second best is to cast 'datum::timestamp'. But still beeing
32times slower than just a trivial compare on the index as in 1). The slowest
run is the brute force 'date_trunc' without cast 3). So to me this is a bit
voodo why postgres refuses to scan the indices in proper speed in 2) and 3).
The maximum index scan i get with 'date_trunc' is a 'Bitmap Heap Scan' on the
index with scenario 2).
Of what i have found inside the docs/google is that even when casting 'datum'
inside postgres the request, here generated by MS, should or have to be
casted as well which is not (at least by now).
Heiko
1) The brute force compare:
sc_gis=# explain analyze select
datum,farbe,encode(AsBinary(force_collection(force_2d(rechteck)),'NDR'),'hex')
as geom,datum from o_v20 where rechteck
GeomFromText('POLYGON((-134.90506329114 -78.2278481012662,-134.90506329114
78.2278481012663,134.90506329114
78.2278481012663,134.90506329114 -78.2278481012662,-134.90506329114
-78.2278481012662))',-1) and (datum = '2007-12-10' and datum =
'2007-12-11');
snipsnap
Total runtime: 41.018 ms
(32 rows)
Now Create Immutable Index on our play table:
CREATE INDEX o_v20_y2007_date_trunc ON o_v20_y2007 (date_trunc('day',
datum::timestamp without time zone));
2)
sc_gis=# CREATE INDEX o3_v20_y2007_date_trunc ON o3_v20_y2007
(date_trunc('day', datum::timestamp without time zone));
ERROR: relation o3_v20_y2007_date_trunc already exists
scia_gis=# explain analyze select
datum,farbe,encode(AsBinary(force_collection(force_2d(rechteck)),'NDR'),'hex')
as geom,datum from o_v20 where rechteck
GeomFromText('POLYGON((-134.90506329114 -78.2278481012662,-134.90506329114
78.2278481012663,134.90506329114
78.2278481012663,134.90506329114 -78.2278481012662,-134.90506329114
-78.2278481012662))',-1) and ((date_trunc('day', datum::timestamp without
time zone) = '2007-12-10' AND date_trunc('day', datum::timestamp without
time zone) = '2007-12-11'));
snipsnap
Total runtime: 1250.679 ms
(26 rows)
3)
sc_gis=# explain analyze select
datum,farbe,encode(AsBinary(force_collection(force_2d(rechteck)),'NDR'),'hex')
as geom,datum from o_v20 where rechteck
GeomFromText('POLYGON((-134.90506329114 -78.2278481012662,-134.90506329114
78.2278481012663,134.90506329114
78.2278481012663,134.90506329114 -78.2278481012662,-134.90506329114
-78.2278481012662))',-1) and ((date_trunc('day', datum) = '2007-12-10' AND
date_trunc('day', datum) = '2007-12-11'));
snipsnap
Total runtime: 2329.380 ms
(23 rows)
Good job getting this far on your own! Create a SQL wrapper function
on top of date_trunc which *is* marked as immutable and you'll be able
to build a functional index on it.
P.
On Thu, Mar 11, 2010 at 1:39 AM, Heiko Schröter
schro...@iup.physik.uni-bremen.de wrote:
Am Mittwoch 10 März 2010 16:52:28 schrieb Heiko Schröter:
Done what has been suggested. The 'date_trunc' function forces sequential
scans instead of using the indexed scans.
I've tried and failed:
sc_gis=# CREATE INDEX o_v20_y2007_date_trunc ON o_v20_y2007
(date_trunc('day', datum at time zone 'GMT'));
ERROR: functions in index expression must be marked IMMUTABLE
Probably the MS list is not the right place to ask.
But may be a kind soul has some pointers to more infos.
I admit that db's are not my field of experience and i'am still learning.
On the other hand it would be nice to have a hint about the indexing issue
inside the MS docs when using the WMS Time extension.
Heiko
sc_gis=# explain analyze select
datum,farbe,encode(AsBinary(force_collection(force_2d(rechteck)),'NDR'),'hex')
as geom,datum from o_v20 where rechteck
GeomFromText('POLYGON((-134.90506329114
-78.2278481012662,-134.90506329114 78.2278481012663,134.90506329114
78.2278481012663,134.90506329114 -78.2278481012662,-134.90506329114
-78.2278481012662))',-1) and (datum = '2007-12-10' and datum =
'2007-12-30');
QUERY PLAN
--
Result (cost=0.00..585.37 rows=4420 width=450) (actual
time=0.083..35.821 rows=5322 loops=1)
- Append (cost=0.00..541.17 rows=4420 width=450) (actual
time=0.067..13.852 rows=5322 loops=1)
- Seq
RE: [mapserver-users] OSM2 SqlServer 2008
We have created a lot of custom tools here that we use internally that were used to being OSM into SQL 2005 - we haven't used them for a while - as we use postgres now. We imported the planet dump into a customised format (in SQL 2005) for a set particular purpose. I don't know of any publicly available product - but I am sure that there is some. Thanks Steve -Original Message- From: mapserver-users-boun...@lists.osgeo.org [mailto:mapserver-users-boun...@lists.osgeo.org] On Behalf Of Rahkonen Jukka Sent: Friday, 12 March 2010 12:16 AM To: Kiks; mapserver-users@lists.osgeo.org Subject: Re: [mapserver-users] OSM2 SqlServer 2008 Hi, I believe that the best way at the moment is to import data with osm2pgsql into PostGIS first and continue then with ogr2ogr. -Jukka Rahkonen- Kiks wrote: ...I wondered if there is an utility like OSM2pgsql that can import OSM data directly to SqlServer 2008. Has anybody any suggestion about it? Can I import data to PostGIS and then from PostGIS transfer data to SqlServer? thank to all, Kiks -- View this message in context: http://n2.nabble.com/OSM2-SqlServer-2008-tp4716063p4716063.html Sent from the Mapserver - User mailing list archive at Nabble.com. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Something odd with queries in 5.6.1
Thanks Daniel, I was reading the mapscript documentation before the post of this message and I found this: layer.getShape(int tileindex, int shapeindex)) has been deprecated and renamed to layer.getFeature(int shapeindex [, int tileindex = -1]) to match the SWIG MapScript equivalent. Note that the order of the arguments is reversed since tileindex is optional in getFeature(). But I didn't look the Mapserver RFC 52. Thanks once again ! IC Carlos Ruiz From: Daniel Morissette dmorisse...@mapgears.com To: mapserver-users mapserver-users@lists.osgeo.org Sent: Wed, March 10, 2010 4:54:09 PM Subject: Re: [mapserver-users] Something odd with queries in 5.6.1 Carlos Ruiz wrote: Hi all, I noticed something odd when I do a query with the new 5.6.1 version. The getFeature method seems to return a NULL value, when it was working good before the new version update. Due to a change in the handling of queries in version 5.6, ols scripts must be updated to use the new $layer-resultsGetShape() method instead of $layer-GetShape() or $layer-GetFeature() to read query results. There is a mention of this change in the migration guide, but it may not be clear enough (contributions welcome): http://trac.osgeo.org/mapserver/browser/branches/branch-5-6/mapserver/MIGRATION_GUIDE.TXT Daniel -- Daniel Morissette http://www.mapgears.com/ ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Documentation - Re: [mapserver-users] Something odd with queries in 5.6.1
Maybe the PHP Mapscript documentation must specify in the getFeature method description of the LayerObj Class section (http://www.mapserver.org/mapscript/php/index.html#layerobj-class) that it's deprecated since version 5.6.1, as the getShape method description: Deprecated in v5.0, use getFeature() instead (note that the order of the arguments is reversed since tileindex is optional in getFeature()) IC Carlos Ruiz From: Daniel Morissette dmorisse...@mapgears.com To: mapserver-users mapserver-users@lists.osgeo.org Sent: Wed, March 10, 2010 4:54:09 PM Subject: Re: [mapserver-users] Something odd with queries in 5.6.1 Carlos Ruiz wrote: Hi all, I noticed something odd when I do a query with the new 5.6.1 version. The getFeature method seems to return a NULL value, when it was working good before the new version update. Due to a change in the handling of queries in version 5.6, ols scripts must be updated to use the new $layer-resultsGetShape() method instead of $layer-GetShape() or $layer-GetFeature() to read query results. There is a mention of this change in the migration guide, but it may not be clear enough (contributions welcome): http://trac.osgeo.org/mapserver/browser/branches/branch-5-6/mapserver/MIGRATION_GUIDE.TXT Daniel -- Daniel Morissette http://www.mapgears.com/ ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] Re: OSM2 SqlServer 2008
I manage to install and import data to PostGIS. Now I'm trying to transfer data with ogr2ogr, but I have some problems to understand the syntax: I have a System ODBC data source called CG. I tried to run: ogr2ogr -f ODBC:CG -t_srs EPSG:3003 PG:host=localhost user=postgres dbname=osm password=postgres port=5432 -update -lco OVERWRITE=yes -nlt NONE But it is not accepted. I don't understand where I'm wrong thanks for your help, Kiks -- View this message in context: http://n2.nabble.com/OSM2-SqlServer-2008-tp4716063p4717357.html Sent from the Mapserver - User mailing list archive at Nabble.com. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
Re: [mapserver-users] Re: OSM2 SqlServer 2008
Hi, It must be noted the OGR ODBC driver is read only at the moment, so you cannot import data to SQL server by using ogr2ogr directly. Moreover to support the SQL 2008 spatial data types further enhancements should be implemented in the driver. For an offline solution you might wan to convert your data to shapefiles and use the shapefile importer tool described at: http://www.sharpgis.net/post/2007/12/Shapefile-to-SqlServer-2008-to-WPF.aspx Best regards, Tamas 2010/3/11 Kiks enrico.o...@gmail.com I manage to install and import data to PostGIS. Now I'm trying to transfer data with ogr2ogr, but I have some problems to understand the syntax: I have a System ODBC data source called CG. I tried to run: ogr2ogr -f ODBC:CG -t_srs EPSG:3003 PG:host=localhost user=postgres dbname=osm password=postgres port=5432 -update -lco OVERWRITE=yes -nlt NONE But it is not accepted. I don't understand where I'm wrong thanks for your help, Kiks -- View this message in context: http://n2.nabble.com/OSM2-SqlServer-2008-tp4716063p4717357.html Sent from the Mapserver - User mailing list archive at Nabble.com. ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
RE: [mapserver-users] PHP mapscript and getResult()
I've been using the PHP mapscript method $results = layer-getResults(); to get: $results-numresults -and- $results-bounds of a query result. This is described in the query example in the manual at: http://www.mapserver.org/mapscript/querying.html?highlight=query and in the SWIG mapscript documentation. It was added to a 5.4 branch which I have been using in my development. I just got Mapserver 5.6 running on my test machine and the layer does not have this method. Is the information not available any more? Did this get deleted due to the 1-pass query? Do I need to reinsert the code I previously had to loop through the results to calculate the bounds of the results to set a map extent or is it possible to add this back in? Thanks in advance for clarifying this, Worth -Original Message- From: Yewondwossen Assefa [mailto:yass...@dmsolutions.ca] Sent: Tuesday, June 09, 2009 7:31 AM To: Worth Lutz Cc: mapserver-users@lists.osgeo.org Subject: Re: [mapserver-users] PHP mapscript and getResult() Worth Lutz wrote: Did this get added into PHP mapscript in the 5.4.1 release? If so, is it a layer object method? It missed the release. It is now committed in the the 5.4.x branch and the ticket is updated to reflect that. best regards, -Original Message- From: Yewondwossen Assefa [mailto:yass...@dmsolutions.ca] Sent: Monday, April 06, 2009 1:54 PM To: Worth Lutz Cc: mapserver-users@lists.osgeo.org Subject: Re: [mapserver-users] PHP mapscript and getResult() Worth Lutz wrote: There is a SWIG mapscript reference to a layerObj method getResults() returning a resultCacheObj. The resultCacheObj has an attribute bounds which is the extent of the results. Is this available in PHP mapscript. It seems to be missing. It is missing in php mapscript. Added a ticket on it and It should be available for the 5.4.1 release: http://trac.osgeo.org/mapserver/ticket/2967 Best Regards Worth ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users -- Assefa Yewondwossen Software Analyst Email: ass...@dmsolutions.ca http://www.dmsolutions.ca/ Phone: (613) 565-5056 (ext 14) Fax: (613) 565-0925 ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
[mapserver-users] runtime substitution not working
Hi, I'm obviously doing something wrong, but can't see what it is... I have a Postgis table of species occurences I want to pass a variable to the mapfile to select which speciesusing runtime substitution. The relevant DATA statement (joining species in the catch to locations in the station) in the mapfile is: DATA startp from (select c.id, s.startp, s.trip_code, s.station_no, c.species, c.weight from t_station s, catch c where s.station_no=c.station_no and c.species ilike '%%spp%%') as myquery using unique id using srid=4326 The query works in Postgis in the mapfile (via QGIS) when I hard code the %spp% (eg, to 'TAR') I'm using QGIS to open the layer, with the URL: http://wms-dev/cgi-bin/mapserv?map=/srv/www/htdocs/mapdata/catch.mapspp=TAR QGIS appends the request type, etc it works with the hard coded spp The mapfile also has: METADATA wms_title species wms_srs epsg:4326 wfs_title species wfs_version 1.0.0 wfs_typename species wfs_request_method GET wfs_service WFS spp_validation_pattern '^[A-Z0-9][A-Z0-9][A-Z0-9]$' END The version I'm running is MapServer version 5.4.1 (so no default supported) The docs say I can use shp2img to test runtime substitution in a mapfile, but I can't see how to invoke the substitution with the equivalent of a spp=TAR statement to test this. Any suggestions? Thanks Brent Wood ___ mapserver-users mailing list mapserver-users@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/mapserver-users
