[mapserver-users] Mapserver usage with commercial vendors data

[Smith, Michael D ERDC-CRREL-NH]

Paolo,

You can also do labeling via the TEXT directive with something like

TEXT "[LABEL_INT]#[LABEL_EN]"  #MapServer 6 syntax
WRAP "#"

Performance on Oracle Spatial (which we use for national and international
scale datasets, including NavTeq and TomTom) is quite good.

Mike


-- 
Michael Smith
Remote Sensing/GIS Center
US Army Corps of Engineers
Hanover, NH



On 4/29/11  10:03 AM, "thomas bonfort" <thomas.bonfort at gmail.com> wrote:

> Paolo,
> 
> On Fri, Apr 29, 2011 at 15:19, 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.
> MapServer itself currently only supports a single label per feature,
> but it does support label wrapping on specific characters so you can
> pass it both Москва́ and Moskvá with a bit of database scripting.
> You'd probably have to use utf8 encoding and have a font that supports
> all international characters, but that shouldn't be a problem.
> Extending mapserver so it supports multiple labels per feature could
> also be a possible solution.
> 
> for the wrapping method, supposing you have a label_int (Москва́) and
> label_en (Moscow) fields, you'd use something like "select id,
> the_geom, label_int||'#('||label_en||')' as label from mytable" in
> your data statement, and then
> 
> LABELITEM "label"
> LABEL
>  ENCODING UTF8
>  WRAP '#'
>  ALIGN CENTER
>  ....
> END
> 
> 
>> 2) Is there any plan to support 2.5D rendering for buildings?
> There's a bug open for that in the bug tracker, with no concrete
> follow-up recently due to lack of funding and/or developper interest.
> Adding such support would be feasible.
> 
> 
>> 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?
> building a relatively complete mapfile for navteq data isn't a
> daunting task, although getting everything to display correctly at all
> scales can be time-consuming.
> 
>> 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.
> Indexed shapefiles will be slightly faster than postgis, but the
> flexibility you gain by being able to do "complex" queries with
> postgis (like ordering the data to get most important ones to show up
> first, etc...) is largely worth the slight overhead. I'd say that if
> you want high quality map rendering, postgis is going to be a must,
> otherwise shapefiles will do. (I have no experience with oracle)
> 
>> 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 :)
>> From my tests in these scenarios, the db backend is the bottleneck, so
> you can beaf that one up as much as you can (i.e. lots of ram and ssd
> disks). A fast cpu and a reasonable amount of memory for the rendering
> host can do no harm, although that is a less important factor from my
> testing.
> 
> regards,
> thomas
> _______________________________________________
> mapserver-users mailing list
> mapserver-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-users