Steve,
Thanks for your suggestions; some comments inserted after the numbered items
below. My general response is that I would like to get some more detailed
sketches of some of these capabilities you have in mind, especially for #1 and
for what I numbered as (6).
On 6/12/2013 5:20 PM, Robert Hollingsworth wrote:
>> I'm looking at implementing RFC 74 "Includes from non-file connections,"
>> ...
>> I'd invite interested parties to look at the RFC and
>> comment back with possible additional use cases, to see how well the
>> prescribed mapfile syntax for this supports those uses.
>Hi Robert,
>
>Here are some thoughts on this:
>
>1. We may want to be able to pass additional mapserver variable
>into the SQL. For example the BBOX of the request classification can
>be limited to that extent. SCALE of the map request so different
>tables can be
configured based on the SCALE.
>
the RFC seems to imply 'yes' to this in general (with possible limitations that
would be addressed by my comments to #2 below?), and that would be my
inclination. I need to review the variables documentation to speak more
authoritatively on the subject.
>
>2. If I need to perform a complex join and other complex SQL
>can I do that using the DATA statement like I can now as a sub-select?
>
the RFC suggests composing a query from the DATA, INCLUDEITEM, and FILTER, but
I think I'd prefer to simply have the DATA statement carry all the information
as the literal query (plus the variables substitution) rather than have it
composed from pieces. Perhaps if the query results in a single column, then
that is taken automatically to be the text inserted to mapfile. So I'd think
no particular limit on the complexity of the query in DATA.
>
>3. Can these be embedded in a regular INCLUDE and vica versa?
>
from looking at the code (maplexer.l), seems that it would actually be cleaner
to allow file includes to contain db includes, and allow db includes to contain
file includes. There's an arbitrary include depth of 5 at the moment. The
design seems to center on a notion of 'resolve this to literal mapfile syntax
RIGHT NOW and insert into the the stream and continue.'
if this scheme were to expand to allow includes from a URL, I'd think same
tolerance for mixed includes would apply.
>
>4. How would we pass USER into the request? via normal
>mapserver variable substitution? via the webserver authenticated user?
>
will have to research further
>
>(5) You might want to add these to the RFC, it is common to include
a section in the RFC to track ideas that are outside the scope of the
>project and comment on why.
>
good idea. I'd say the scope is not set in concrete at this point. I think
would be wise to simply require that the query fully resolves to a block of
legal mapfile syntax, however it manages to do so from whatever mix of literal
SQL, whatever is stored in the data tables that are being queried, and whatever
variable substitutions. And that all this resolves from the INCLUDE block
alone, rather than permitting/requiring other mapfile constructs to react to
the results from the query.
>
>(6) One of the things that has been asked for in the past is
>"named styles" ie: reuseable named snippets, like highways, toll-roads,
>major->roads, minor-roads, streets, or points of interest
>by "type", etc. It seems like this would allow for that and an example
>demonstrating this would be
ideal.
>
would definitely like to hear more from you on this. One thing occurs to me,
this mechanism might definitely help where the combinatorial styling gets
really dense, say, picking symbol/color/labeling/etc based on several column
values ('type' 'status' 'owner' etc) each with a large number of legal values.
I'm also intrigued by what was suggested in the RFC, namely setting the exact
number and expression of CLASS based on actual distinct data values at the
moment.
thanks again,
Robert
_______________________________________________
mapserver-users mailing list
mapserver-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/mapserver-users
