Zsort ?

[Stephen Woodbridge]

Daniel Morissette wrote:
> Doesn't the sortshp command-line program allow you to do this already?
> http://mapserver.gis.umn.edu/docs/reference/utilityreference/sortshp
> 
> 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 
> performance.

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.

Attila,

Is there a special use case for this?
Would pre-sorting the data solve your problem?

-Steve W


> Daniel
> 
> 
> 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 
>> storages.
>>
>> 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, 
>> etc.
> 
>