Steve.Lime at DNR.STATE.MN.US
Fri May 18 17:42:47 EDT 2007
Hi guys: Sorry, a bit late to the discussion. I looked into dynamic sorting long ago and
concluded the performance hit was just too big to take. That's why you see sortshp in the
distribution. Plus, the DBs give this option through their SQL interfaces so it really won't
benefit many data sources.
The main benefit I see for sorting is on the labeling side of things so you can get prominent
labels into the cache ahead of other less important labels. We've outlined a label prioritization
scheme that would help address this with little or no performance loss. Dan, correct me if
I'm wrong but wasn't that in your list of 5.0 enhancements?
Attribute indexing for DBF files would be a nice addition regardless and would set up sorting
if that might be desirable in the future. Attribute queries would certainly benefit...
>>> Stephen Woodbridge <woodbri at SWOODBRIDGE.COM> 05/17/07 10:01 AM >>>
Daniel Morissette wrote:
> Doesn't the sortshp command-line program allow you to do this already?
> I am also worried that an ORDERITEM keyword/mechanism would be awfully
> slow on large shapefiles since the primary index used to fetch shapes on
> large files is the spatial index (.qix). There is currently no attribute
> index support on shapefile DBF's in MapServer and even if we added that,
> the primary index would remain the spatial index so I can't see how we
> could easily implement dynamic ordering of shapes without hurting
Great point Daniel! That had slipped my mind. The spatial index if I
understand it, only does a potential preselect of possible objects in
the shapefile to be drawn, but the objects are still read in the order
they are in the file.
So in the small result set, these could be sorted on the fly, but it
would get a little convoluted to have an attribute index in combination
with the spatial index. That would probably require having a spatial
index for each attribute index to preserve the order of that index,
which seems a little much.
Is there a special use case for this?
Would pre-sorting the data solve your problem?
> Attila Csipa wrote:
>> Maybe this would require a RFC, but I do not see this issue addressed
>> in existing .map references or RFC, I wanted to hear your opinion on
>> this (there was a short discussion about this, but a lot has changed
>> in Mapserver since then).
>> What would you say if we introduced a drawing sort order inside layers
>> ? As it is now, all the features are drawn by their order in the data
>> storage. If using SQL queries one can define a sort order, but for
>> shapefiles or other local file storages this is not an option. This
>> would mean introducing a sort of ORDERITEM keyword (or an 'order'
>> binding if we are thinking along the lines of RFC19) which, if
>> present, would be used to build a sorting table, and then provide a
>> seek function which would help the nextItem approach for these data
>> The advantages of this should be obvious - for example if you have an
>> area column in your dbf you could draw large polygons first so you
>> would not obstruct small ones, or if you need to sort on a timestamp,
More information about the mapserver-dev