TrueType-character used on lines

MapServer has the ability of drawing truetype symbols that follows the inclination of lines, like described @ Cartographic symbol Construction with MapServer (from where I took the sample bellow):


I just would like to mention that:

1. GAP value must be negative.
2. do not use GEOTRANSFORM.
3. Add a ";" to the CHARACTER "&#84" line.

thus, you'd have the follow instead:

SYMBOL
  NAME "T"
  TYPE TRUETYPE
  FONT "arial"
  CHARACTER "T"
  ANTIALIAS TRUE
  GAP -10
END

That's it. Now it should work fine.

MapServer + OpenStreetMap

+ good news: I'm pleased to announce I've been trying to import OpenStreetMap data into my PostGIS database like described here and I got it working fine some days ago.

I won't repeat the steps of Thomas (the author of the article cited above) but I'll add some notes one may find useful (specially if that one is a Windows user):

About the topic "Preparing the database":

1. do not use capitals (uppercase chars) in the name of the database (nor in the prefix name of the database).

2. you may find lwpostgis.sql and spatial_ref_sys.sql files under the Postgre's installation folder, subfolder "share\contrib".

3. Probably, you'll have to comment the last line "VACUUM ANALYZE spatial_ref_sys;" of the spatial_ref_sys.sql file, run the SQL script, and then run only that line (after you've ran the first part of that file).

4. You'll find the "epsg" database file under the "share\contrib\postgis\proj" path of your Postgre's installation folder. Just append the projection 900913 to the end of that file.

Topic "Importing the OSM data":

1. After downloading Osm2pgsql, add it to your system's path environment variable.

2. Maybe, you'll get an error complaining about a "style" file. If so, you can run the osm2pgsql command directly from its installation directory (you'll have to provide the full path to your OSM data).

Topic "Creating the Mapfile":

1. I didn't get the "make" script running (Thomas thinks it can be my version of GNU compiler).

2. I wrote a small console application (in C#) to replace the hundreds of "define", as I wasn't able to get it running neither (just let me know if you need this).

Finally, I got the following (at the image, neighborhoods of Copacabana's beach, Brazil):


Last, but not least: pay attention to the units of your custom layers - if you want to add them to the mapfile create above - its layers are all in meters.

I think that's all. Best.

shapeObj.index (Fatality!)

Finally, a good news: my bug ticket got closed.

I didn't try the new "trunk" source yet, but I'm goin' to download and compile that this week, maybe tomorrow. Then, I'll let you know the results of my tests.

Best.

shapeObj.index (round two, fight!)

I love bad news. Although it can be just a mistake of mine, it really behaves like a bug (I think so).

My previous topic has commented about the new self-incremented shapeObj.index property of MapServer 5.x and this one will focus at some implications I may have found - actually, I really don't know whether this is a bug or not. By the way...

First, take a look at the piece of code that follows, taken from an open source library (thanks to Edmar Moretti):

function pegaValores($mapa,$layer,$item,$numerico=false)
{
  ...
  if (@$layer-›queryByrect($mapa-›extent) == MS_SUCCESS)
  {
    $layer-›open();
    $res_count = $layer-›getNumresults();
    ...
    for ($i=0;$i‹$res_count;$i++)
    {
      $result = $layer-›getResult($i);
      $shp_index  = $result-›shapeindex;
      $shape = $layer-›getshape(-1, $shp_index);
      ...

I've ommited some statements, but pay attention at the functions getResult() and getShape(). What if we would try the same thing above in the brand new MapServer release?

I tried that (in C#) and * surprise * got the follow:

results.getResult(0)
{OSGeo.MapServer.resultCacheMemberObj}
    classindex: 0
    shapeindex: 1
    tileindex: -1
results.getResult(1)
{OSGeo.MapServer.resultCacheMemberObj}
    classindex: 1
    shapeindex: 1
    tileindex: -1
results.getResult(2)
{OSGeo.MapServer.resultCacheMemberObj}
    classindex: 0
    shapeindex: 1
    tileindex: -1

The classindex property of each result are OK but what about the shapeindex? Doesn't it should be evaluated with 1, 2, 3, etc?

Thus, when I try to do a queryByRect (or whatever), in general I always get the same feature - the one I've firstly added to the layer.

Is this a bug? I really don't know, but it smells kind of strange for me.

I've tried to investigate a little bit closer and spent some time digging the mapquery.c file. I took a look at the

int msQueryByRect(mapObj *map, int qlayer, rectObj rect)

method and I didn't find any reference that would may evaluate the shape.index property, although the shape.classindex I did so.

I'll recompile MapServer source code next week without the index = index + 1 statement. Maybe I find out something. Cheers.

shapeObj.index in MS 5.x

Unlike the previous versions of MapServer (4.x and older), the recent release (5.x) has its shapeObj().index property self-incremented and * I'm afraid * it hasn't been documented in the change log.

I know this is a pretty small change to worry about but, in my special case, I had to replace some pieces of code like that:

myShape.index = myObj.GetHashCode();

with:

myShape.InitValues(1);
myShape.SetValue(0, myObj.GetHashCode().ToString());
myShape.GetValue(0);

It's easy to find out why - just take a look at the mapscript_i.c file taken from the MapServer's 5.4.1 source code (lines 558 through 565):

int layerObj_addFeature(layerObj *self, shapeObj *shape){
  if (self-›features == NULL) shape-›index = 0;
  else shape-›index = self-›features-›shape.index + 1;
  if(insertFeatureList(&(self-›features), shape) == NULL)
    return -1;
  else
    return 0;
}

The bad news is: we still can set the shapeObj.index property * but * as soon as it's added to a layer object, our poor index value is replaced by a new one (note the shapeObj parameter is a reference parameter).

So, if you use to employ the shapeObj.index property to store some non-sequential feature ID (like me), you may find yourself in troubles. I'm so sorry, man..

Problem with Projections (act I)

Some days ago, I was joking with projections (C# and MapScript 5.x) and I realized that whatever projection I may specify in my mapfile, either in the MAP or LAYER level, the output is the same.

I'm 99% sure I'm doing something wrong, but til now I don't know where, exactly, is the problem. First of all, I tried to reproduce the example below, without success:


Actually, my problem is: If I suppress (or not) any projection information in my mapfile, the output is the same - I can't see any kind of distortion or displacement between the shapes.

MapServer just seems to ignore the PROJECTION...END blocks of my mapfiles. I'll keep investigating what I may doing wrong, but if someone has any tip, please, let me know.

See you.

Intro

Hi, there.

I'd like to introduce you to my brand new blog. Mainly, it's about MapServer and, secondly, GIS (Geographic Information Systems) development in general.

I've being trying to find some useful references and known-bugs's workarounds in portuguese, but it seems the brazilian community are not that big. Thus, I decided to post in both english and portuguese as an effort to support developers in general - and as I'm not a native english speaker, you may find some strange things written here - so don't worry about it.

Most of the time, I develop using MapServer/MapScript + PostgreSQL/PostGIS in .NET C# and I could say that it isn't a well-covered language (for GIS development).

I've been experiencing dozens of troubles and I'll try to keep this site up-to-date with my doubts and recent discovers.

By the moment, I think that's enough. Best regards.