Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Feature ordering lost for database layers using WMS #5008
I have several scenarios where I need to be able to order features, so more recent ones are displayed at the top. I access these layers using WMS. However as soon as the bounding-box WHERE clause is wrapped around the SQL defined in the layer's DATA clause and ORDER BY statement is ignored (silently).
Original DATA clause:
Query passed to database for WMS request - records are returned in a random order, as the ORDER BY is in a subquery, and not the outer SELECT:
When you use an ORDER BY clause in a view, an inline function, a derived table, or a subquery, it does not guarantee ordered output. Instead, the ORDER BY clause is only used to guarantee that the result set that is generated by the Top operator has a consistent makeup. The ORDER BY clause only guarantees an ordered result set when it is specified in the outermost SELECT statement.
I am using MS SQL Server, however I believe this behaviour may be applicable to all databases, and there are many MapServer examples which make use of ORDER BY to define layer drawing order e.g.
To resolve this a LAYER parameter (named perhaps ORDER) could be used to set a field name to add an ORDER BY clause to the outer SELECT.
I posted this issue to the mailing list and thought I had a solution, but the SELECT TOP does not in fact keep ordering.
My temporary workaround is to hard code an ORDER BY field (ROWNUM) into the SQL select statements in the driver I am using (MSSQL):
In the DATA clause for each layer that requires ordering I add the following to the SELECT statement:
In this example I am sorting by two fields. This allows complete flexibility on how features are ordered,
For these layers I set the plugin to the modified DLL:
I'm not sure I like the SORTFIELD keyword: as you said you'd also need a keyword for ASC/DESC, and what happens if you need to sort on multiple columns. I would think that an "order by" keyword in the DATA statement is more flexible as its content would be directly injected in the SQL sent to the database without the need for mapserver to have to interpret it.
@szekerest I just tested this using the dev release package from gisinternals.com (release-1600-x64-gdal-mapserver) and all is fine. I tested with one field, two fields, and a missing field (which correctly threw an error). Many thanks for this update.