[Benchmarking] Sample Barcelona Vector Dataset

Andrea Aime aaime at opengeo.org
Sat Jul 10 10:10:56 EDT 2010


Jeff McKenna ha scritto:
> I have went through the sample layers and I have posted working 
> MapServer WMS links for each layer 
> (http://wiki.osgeo.org/wiki/Benchmarking_2010#Sample_Dataset_Styling). I 
> also have links to an SLD document for each layer if you chose to use that.
> 
> I would like feedback from all teams as they look at these layers in 
> their server.  For example, if you zoom in (with QGIS for example) where 
> the building/polygon layers are dense, you will see that those zoomed-in 
> street/roads are missing from our proposed classifications 
> (http://wiki.osgeo.org/wiki/Benchmarking_2010/How_to_get_some_sample_data#Vector_data_issues). 
> 
> 
> Awaiting other team's feedback.

Hi,
I've loaded up the themes with GeoServer as well.
I don't have a public server to show you, but I'm linking some
screen shots:
http://sigma.openplans.org/~aaime/barcelona1.png
http://sigma.openplans.org/~aaime/barcelona2.png
http://sigma.openplans.org/~aaime/barcelona3.png
http://sigma.openplans.org/~aaime/barcelona5.png

Just as Jeff I still haven't added scale dependencies, nor I added
halos for the moment.

As Jeff noted, the road network is incomplete. Afaik this is
due to the biggest road layer not fitting inside the shapefile
size limits (maybe I'm just getting confused).

Scale dependencies wise, I'm easy and I'll try out Marco suggestions
soon. What I'm wondering most is, are we agreeing on the scale
computation? Otherwise the same request won't give the same results.

Now, afaik MapServer uses a dpi other than the OGC recommended one
to compute the scale (75 vs 90 if memory serves me right), so the scale
computation would be different.
Is that a tunable in MapServer?
And more in general, are we all going to compute the scale according
to the SLD specification (1)?

About having different types of labels and symbols, does anyone
have a legend of what the values in the TIPO_0802 and TIPO_0801
fields mean?

Labelling wise, I was also wondering about just using the contour
lines to display labels along the lines, if we don't get a full
road network.

I was also wondering about label priorities, wrapping, and conflict
resolution.
If we were to make a nice map, some labels, like "Barcelona" or
"Mar Mediterraneo" should robably be big, light gray, and do not
conflict with other labels.
Some labels should probably have higher priority than others.
And long labels should be probably wrapped into multiple lines
automatically.
However, I understand asking for the above is probably going to
look for troubles, as different servers might implement the
above features only partially, and each adds some work
(so we either all do it, or the less featureful servers will
be at an advantage performance wise).
Anyways, just wondering what others think about it.

Cheers
Andrea


(1) -------------------------------------------------------------
     The scale computation according to OGC
     -------------------------------------------------------------

To insure consistent behaviour, scales relative to coordinate spaces 
must be handled
consistently between map servers. For geographic coordinate systems, 
which use angular
units, the angular coverage of a map should be converted to linear units 
for computation
of scale by using the circumference of the Earth at the equator and by 
assuming perfectly
square linear units. For linear coordinate systems, the size of the 
coordinate space should
be used directly without compensating for distortions in it with respect 
to the shape of the
real Earth. For example, if a map to be displayed covers a 2-degree by 
1-degree area in
the WGS-1984 geographic coordinate space, the linear size of this area 
for conversion to
scales would be considered to be:
2° × (6378137m × 2 × π) ÷ 360° = 222638.9816m
1° × (6378137m × 2 × π) ÷ 360° = 111319.4908m
So, the map extent would be approximately 222639m × 111319m linear 
distance for the
purpose of calculating the scale. If the image size for the map is 
600×300 pixels, then the
standard scale denominator for the map would be:
222638.9816m ÷ 600 pixels ÷ 0.00028m/pixel = 1325226.19
or approximately 1.33M. (Only one dimension needs to be calculated since the
coordinate-system space covered by each pixel is square.)
Floating-point roundoff-error control should also be applied to these 
calculations, to
ensure consistency between systems. Since the scale denominators used in 
rules will
often be “round” figures, such as 250000, if a calculation of the 
current scale results in a
value of 249999.99999999, it should be considered to match 250000. A 
reasonable test
for range matching of scale denominators would be defined as follows:
    scale >= min_scale – epsilon && scale < max_scale + epsilon
where epsilon defined as 1e-6.




-- 
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.


More information about the Benchmarking mailing list