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" <[email protected]> wrote: > Paolo, > > On Fri, Apr 29, 2011 at 15:19, Paolo Crosato <[email protected]> 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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/mapserver-users _______________________________________________ mapserver-users mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapserver-users
