Mark,

thanks for a good analysis. Probably one thing to comment:

>>.dbf: X, Y in dbf not yet understood as coordinates by MW or any other GIS.
Don't know about all GIS, but QGis can open it even now. It's enough to choose the fields from the combo (QGIS rather heavily relies on storing various rendering options in .dbf).

So, current conclusion:
1. The support of .lbl files will be returned - it's settled.
2. A testing is needed to compare XML/dbf approach in terms of speed (yet another alternative is to write labels to XML in base64 string format). Then a decision on .dbf approach can be made (probably can be used as an option for large shapefiles).

I've almost finished XML parsing in ocx, will return to MW4 soon. With some tests results it will be easier to make a choice.

Thanks,
Sergei

Sergei Wrote:
-------------------------------------------------------
> So, current conclusion:
> 1. The support of .lbl files will be returned -
> it's settled.
> 2. A testing is needed to compare XML/dbf approach
> in terms of speed (yet another alternative is to
> write labels to XML in base64 string format). Then
> a decision on .dbf approach can be made (probably
> can be used as an option for large shapefiles).

Very good. One question: Isn't the .mwlyr file a 5th option or am I missing something? Where does it fit in? And are label expressions still planned as a way to define labels? The current .lbl file has Field and Field2 attributes for setting the _column number_ of the .dbf data to use. I tried to convince MW devs years ago to use column name instead, but for whatever reason they stayed with column numbers. Could there be an alternate way of specifying column name instead - or maybe the labeler could just figure it out (i.e., if "AREA" is specified for Field attribute and it's a column, just use it; otherwise treat as number).

I think the decision to stay with .lbl files is a good one. An app like MW probably needs to retain some good backward compatibility. However, even though we ended up where we started, the discussion was useful and enlightening.

Thanks.

-Phil

Some info on my progress:

I've implemented new methods in ocx:

Labels.SaveToXml
Labels.LoadFromXml
Labels.SaveToDbf
Labels.LoadFromDbf
Labels.Generate(string Expression, ...)

XML part uses GDAL based code and can open old-format .lbl files. It seems to be considerably faster than .NET-based code. Something like 1.5-2 versus 6 seconds on 100000 labels.

The speed of dbf is quite close to XML. So in MW4 I'll use XML representation only, as .dbf doesn't have speed benefits.

<And are label expressions still planned as a way to define labels?
Yes, they are, either through Labels.Generate or Labels.put_Expression.

Hi Everyone,

I've been lurking in this thread for a little while and I really appreciate everyones input. I think its been a great discussion thats really narrowed down the work to be done.

Sergei you stated in your post that you planned to have dynamic label expressions. I assume you mean that labels will be stored as X,Y coords + field expression.

I was wondering if it would be possible to implement dynamic label coordinates as well. With perhaps a few different label position options such as centroid, envelop center, etc. Centroid calculations using the new GEOS library are faster than they were with MapWinGeoProc and are also natively in the OCX now providing this functionality at a relatively low level.

Great work everyone!

Brian

Brian,

there is no problem to calculate label coordinates on the fly on each loading. The problem is speed.

Calculation of the center can be done fast, as bounds are stored in the shapefile explicitly. So it can be used for quite large shapefiles indeed (BTW, QGis generates labels in such manner). Though the quality is poor and in most cases more precise methods are used.

Centroid or interior point are more precise, but calculation is slow. I suppose it would be fast enough for shapefiles with less than 3-5k shapes only.

So in both cases there are just half-measures. But if anyone will need it in app, it's no problem to store necessary LabelPositioning constant in the project and regenerate labels on each loading (Shapefile.GenerateLabels).

Sergei

Hi Sergei,

Most of the commercial GIS programs I've seen label things this way dynamically. Yes it can be slow if you have too many features. Which is why label extent limits are usually used.

Brian M.

Hi Everyone,

here are screenshots of the new labels form with support of expression. The checking of expression is carried out on the fly in the key_press event (see lower left corner of the screen). The forms for generation and style are merged as suggested by Phil.

Sergei




[Edit:] Made he images inline



Edited 1 time(s). Last edit at 05/18/2011 01:40PM by pmeems.