[mapserver-users] Mapserver usage with commercial vendors data

[Umberto Nicoletti]

On Fri, Apr 29, 2011 at 3:19 PM, Paolo Crosato <paolo.crosato at ubiest.com>wrote:

>  Hi,
>
> I work for an LBS based company, we have our own proprietary rendering
> engine for producing maps, and we work mainly with data from Navteq and
> Teleatlas. Presently our rendering engine is behind the competition in terms
> of visual quality (we have a bad support for antialiasing, label names with
> both native and transliterate names are missing, and so on). Introducing new
> features in our current rendering architecture would require quite a lot of
> coding and re-engineering, so we are looking for alternative renderers,
> possibly open sourced. During this research project I came across Mapserver,
> and it seems it would suit our needs in terms of high quality rendering and
> customization.
> However, there are still some open issues, mainly questions, I'd like to
> ask.
>
> In regards to rendering:
> 1) Is there any way to align labels in different encondings for the same
> city? I mean something like writing Москва́ and *Moskvá *vertically
> aligned, like on Google Maps.
> 2) Is there any plan to support 2.5D rendering for buildings?
>
> In regards to working with high loads of data:
> 1) We render our maps from data provided by vendors like Navteq, and they
> have a lot of details and features. Is there anyone working in the same
> field, who could share some of his experience?
> 2) Is it more efficient to work with PostGis/Oracle Spatial or with
> shapefiles? I suppose the former would be faster, since shapefiles provided
> by Navteq would require about 100gigs for Europe only, just to store the
> data.
>

As Thomas said probably a database like Postgis or Oracle (if your budget
allows for the hefty license fee) is a sensible choice because it makes
complex manipulations (like adding a translation for a label) easy.
In that case a machine dedicated to the db backend with a fast network (GB
or better) link to the rendering workstation is also *probably* recommended
to free CPU resources and memory (for caching resultsets) on the rendering
side (but that depends on your queries).
If a query is particularly CPU or I/O intensive consider using a
materialized view instead (Oracle has builtin support, postgres not yet but
it can be done).

3) In regards to the hardware, I reckon we would need at least one
> workstation dedicated to rendering. Currently we are hosting our rendering
> service on dual Xeon (quad core), with 16G of ram and SAS arrays of hard
> disks, would one server like this be ok or would it be better to have more
> machines, especially if planning to use RDBMS to hold the data? I'm asking
> this because with currently work with detailed data from Europe, North and
> South America, so it's quite a lot of stuff :)
>

One issue to consider (might not be critical, just informing you) is that
mapserver will perform the layer rendering serially.
Another is that disks are only involved when it is writing the image to a
file so I would also think about saving money on disks and get more servers
instead or use a fast primary for file generation (think SSD) and then move
them async'ly to a slower (but cheaper) storage (think NFS).
Last: too much ram might never get used because of the cpu bottleneck
kicking in before so I would also make sure that I could shuffle ram around
if necessary (i.e.: one server's CPUs are consistently maxed out, but memory
isn't: in that case I would buy a new server and move memory to the new one
instead of buying more and waste it).

HTH,
Umberto


> Thanks in advance for any feedback.
>
> Regards,
>
> Paolo Crosato
>
> --
>
> Paolo Crosato
> Ubiest SPAhttp://www.ubiest.com
>
>
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-users/attachments/20110503/d1802fc3/attachment.htm>