[mapserver-dev] One more decision related to 7.0/RFC 91...

[Rahkonen Jukka (Tike)]

Hi,

A Mapserver user here asks if you developers have thought about how to filter if LAYER has no DATA but it takes the contents from another LAYER like in kernel density layers http://mapserver.org/development/rfc/ms-rfc-108.html or with layers utilizing OGR tileindex?

Does/should filtering work at all on TILEINDEX or on CONNECTIONTYPE-CONNECTION layers if they point to another layer? If it does, what users should write into, let's say, tileindex layer? It filtering does not work on tileindex layer, how to prevent users from trying it anyway?

A real world example follows. I have created yearly orthophoto layers by using "DATA---SELECT---"  at layer level and used that layer as a TILEINDEX. What if I would like to filter further and split images by year and by contractor? Should I create as many layers as there are unique year-contractor combinations, or can I filter the year 2006 layer further at the next level where it is used as TILEINDEX? I believe that myself I would use whole lot of copy-paste and make those unique year-contractor layers. How about you? Imagine that you have 15 years and 4 contractors, it makes 60+60 layers in total.
LAYER #this is the yearly tileindex
        NAME "spatialite_tileindex_2006"
        STATUS ON
        TYPE POLYGON
        CONNECTIONTYPE OGR
        CONNECTION "xxx.sqlite"
        DATA "select * from xxx where year=2006"
        METADATA
        "wms_title"    "y2006"
        "wms_srs" "EPSG:2393 EPSG:3067 EPSG:4326 EPSG:3857"
        END #METADATA
CLASS
        NAME "y2006"
          STYLE
                               WIDTH 0.91
                               OUTLINECOLOR 0 0 0
            OPACITY 30
                               COLOR 39 200 55
                             END #STYLE
                           END #CLASS
       PROJECTION
                              "init=epsg:3067"
       END #PROJECTION
END #LAYER yearly index
LAYER #this draws the orthos for the people
        NAME "orthos_2006"
        STATUS ON
        TILEINDEX "spatialite_tileindex_2006"
        TILESRS "src_srs"
        #PROCESSING "EXTENT_PRIORITY=WORLDFILE"
        PROCESSING "CLOSE_CONNECTION=DEFER"
....

-Jukka Rahkonen-




Lime, Steve D wrote:

So, when you get into implementation of an RFC you notice things. One thing that has come up is ambiguity around the way native SQL is specified. In older versions of MapServer  you'd set FILTER with a string value and the underlying driver would interpret that as SQL. Easy enough at first glance. RFC 91 aims to enable translation from MapServer expression syntax to native SQL plus handling FILTER merging with query operations. That's where the ambiguity sets in - it's not clear how you define native SQL, even the codebase handled it differently.

That ticket aims talks about ways to resolve this ambiguity and you can see the full discussion here:  https://github.com/mapserver/mapserver/issues/5001.  Ultimately we arrived at a point where we needed to bring the discussion back to the list.

Here's a summary of potential options:


1.      Do nothing, live with the ambiguity and resulting code complexity.

2.      Adopt the current OGR method of prefixing the FILTER string with "WHERE ".

3.      Adopt a new delimiter (e.g. <>) to explicitly define native SQL.

4.      Remove the ability to set native SQL altogether - FILTERs would use MapServer expression syntax only and we rely on translations.

Option 4 sounds drastic but probably gets us the most streamlined code to maintain - merging is much more straight forward. The native SQL in FILTER functionality was added long ago before more complex DATA handling was implemented. It's easy to argue that since all of the drivers that support some sort of SQL do so in the DATA definition that there's no need for native SQL FILTERs at all.

Why now? We'll we only want to break things at major releases so...

Steve

StEVE LIME  | DATA & Applications MANAGER
MN.IT Services @ MnDNR
651-259-5473 (w)  |  651-297-4946 (f) |  steve.lime at state.mn.us<mailto:Your.name at state.mn.us>

[cid:image001.jpg at 01CFD817.97B5B870]<http://www.mn.gov/oet>

Information Technology for Minnesota Government   |   mn.gov/oet<http://www.mn.gov/oet>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20140924/4118abb9/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 1611 bytes
Desc: image001.jpg
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20140924/4118abb9/attachment-0001.jpg>