Kyle I enabled the DEBUG for the layers and I discovered the problem with your data definition when applying the query directly on the table:
You specified 'USING UNIQUE gid' but gid is not unique after the joining since you multiply it with the joins. If you specify 'USING UNIQUE pid' then everything works fine because pid is really unique in forecast table. So one cannot blame Mapserver as it does it's job correctly, one has just to understand it's logic. As I understand it, it first grabs the unique identifyer in a 1st run and the uses this in a second run for retrieving the rest of the attributes. But if the ID is the same also the retrived data from the 2nd run are identical. It seems that when applying the filter directly in the DATA string this problem does not appear, but I did not try to understand this. So specifying 'pid' as unique field should sort out the problem. Armin Kyle Wilcox wrote: > Must alter the grid's table creation to add the bathymetry column.. > forgot about that one: > > CREATE TABLE grid (gid serial primary key, bathymetry real); > > Kyle Wilcox wrote: >> I will download the CVS later tonight and let you know tomorrow! Thanks. >> >> Here are the files to reproduce my issue: >> >> Table creation: >> http://155.206.18.162/create.txt >> >> Data for grid table: >> http://155.206.18.162/grid_insert.sql >> >> Data for forecast table: >> http://155.206.18.162/PostGIS-Forecast-2007-11-07.sql >> >> Mapfile for sample data: >> http://155.206.18.162/c3po.map >> >> Classes (via INCLUDE): >> http://155.206.18.162/c3po-classes.map >> >> I'm still stumped. >> >> Armin Burger wrote: >>> Kyle >>> >>> I added the possibility to define custom images for the layer classes. >>> Define it via the KEYIMAGE tag, like >>> >>> CLASS >>> KEYIMAGE "images/legend/custom-icon.png" >>> >>> You can get the updated version either directly via SVN >>> see http://svn.pmapper.net/trac/changeset/232/pmapper/trunk/incphp >>> for the modified files >>> >>> or download the full latest dev version here >>> >>> http://www.pmapper.net/dl/pmapper-dev.zip >>> >>> For me it worked with a fast test, if you get any errors tell me. >>> >>> >>> With regard to your identify problem: if you can provide me with a small >>> PG table dump that can be used for a few layers (e.g. some timestamps) >>> and the corresponding map file etc. I can have a closer look what causes >>> the strange behaviour. >>> >>> armin >>> >>> Kyle Wilcox wrote: >>>> Yes the layers use the same two tables, grid and forecast. The only >>>> thing that changes between layers is the FILTER. I will ask on >>>> Mapserver list, thanks. >>>> >>>> A legend icon for classes would be great. >>>> >>>> Armin Burger wrote: >>>>> I might not understand it completely. Your layers are always using the >>>>> same Postgis table, just setting another FILTER. Is that correct? I >>>>> would guess that the queryByPoint() call does not consider the FILTER >>>>> specifications. I thought that this is only the case for attribute >>>>> queries (therefore attribute queries on Postgis tables use standard PHP >>>>> functions, not Mapscript), but maybe also for point queries. >>>>> >>>>> The whole filter part was messed up in Mapserver 4.8/4.10 and they said >>>>> it has been fixed in 5.0. But in general this kind of issue would be >>>>> best asked on the Mapserver mailing list. >>>>> >>>>> When loading you application it reminds me that I wanted to add again >>>>> the possibility to specify the legend icon image for a class in the map >>>>> file. Otherwise one has to download hundreds of icon images that are >>>>> always the same. >>>>> >>>>> Armin >>>>> >>>>> >>>>> >>>>> Kyle Wilcox wrote: >>>>>> Did the usual searching without finding anything relevant. >>>>>> >>>>>> The pmapper application I am referencing is at: >>>>>> http://155.206.18.162/mapping/map/map.phtml >>>>>> >>>>>> I have time series data in a PostGIS enabled database (current and wind >>>>>> fields from model output). I can display the point data without >>>>>> problems (try any of the current or wind layers). >>>>>> >>>>>> The problem is that when querying a point layer, the data that is always >>>>>> extracted from the first timestamp, rather than the timestamp associated >>>>>> with the layer I am trying to query. I understand what is happening.. >>>>>> the query by point functionality is querying the database at the >>>>>> specific POINT and displaying the first row that returns (the first >>>>>> timestamp). If I delete the first timestep data, the second timestep >>>>>> data is displayed and so on. I have different tables for the model grid >>>>>> and the data and would like to keep it this way if possible. >>>>>> >>>>>> >>>>>> Here is my layer definition: >>>>>> >>>>>> LAYER >>>>>> TYPE POINT >>>>>> CONNECTIONTYPE postgis >>>>>> NAME 'eta-One' >>>>>> CONNECTION 'host=HOST user=USER dbname=DATABASE' >>>>>> DATA "the_geom from (SELECT * from forecast left join >>>>>> grid on grid.gid=forecast.grid_id) as data USING UNIQUE gid USING >>>>>> SRID=4326" >>>>>> FILTER "time=TIMESTAMP'2007-11-06 00:00:00'" >>>>>> METADATA >>>>>> 'DESCRIPTION' '2007-11-06 00:00:00' >>>>>> 'RESULT_FIELDS' >>>>>> 'wind_speed,wind_from_direction,rotation' >>>>>> 'RESULT_HEADERS' 'Wind Speed (m/s), Wind >>>>>> Direction (from TN), Rotation of Image (from TN)' >>>>>> 'LAYER_ENCODING' 'UTF-8' >>>>>> END >>>>>> STATUS OFF >>>>>> PROJECTION >>>>>> 'init=epsg:4326' >>>>>> END >>>>>> TOLERANCE 10 >>>>>> TOLERANCEUNITS pixels >>>>>> LABELMAXSCALE 60000 >>>>>> TEMPLATE void >>>>>> CLASS >>>>>> NAME ">= 0.95 m/s" >>>>>> EXPRESSION ([wind_speed] >= 0.95) >>>>>> STYLE >>>>>> SYMBOL "arrow2" >>>>>> ANGLE [wind_from_direction] >>>>>> COLOR 118 0 0 >>>>>> OUTLINECOLOR 0 0 0 >>>>>> SIZE 10 >>>>>> END >>>>>> TEXT ([wind_speed] m/s - [wind_from_direction] TN) >>>>>> LABEL >>>>>> COLOR 118 0 0 >>>>>> OUTLINECOLOR 0 0 0 >>>>>> POSITION AUTO >>>>>> SIZE small >>>>>> PARTIALS TRUE >>>>>> END >>>>>> END >>>>>> ... >>>>>> END >>>>>> >>>>>> >>>>>> How can I change query.php to select only the data that has to do with >>>>>> the current timestep, rather than selecting all of the timesteps at that >>>>>> POINT and using the first row as the result? >>>>>> >>>>>> >>> ------------------------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. >>> Still grepping through log files to find problems? Stop. >>> Now Search log events and configuration files using AJAX and a browser. >>> Download your FREE copy of Splunk now >> http://get.splunk.com/ >>> _______________________________________________ >>> pmapper-users mailing list >>> [email protected] >>> https://lists.sourceforge.net/lists/listinfo/pmapper-users > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ pmapper-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pmapper-users
