<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hey Paul, I think that is because you explicitly added him, for some
weird reason this list is already set to <b>reply to list</b>. The
change in question would not have made a difference in this case...<br>
<br>
Bob<br>
<br>
Paul Spencer wrote:
<blockquote
cite="mid2ED16901-1E08-478F-8803-0A4D52397516@dmsolutions.ca"
type="cite">Steve's response bounced from the list, but fortunately
reply-to-all was still actually sending to everyone so I actually got
the message ... hint, hint ...
<br>
<br>
Paul
<br>
<br>
<br>
On 16-Jan-07, at 11:18 PM, Steve Lime wrote:
<br>
<br>
<blockquote type="cite">Paul: Er, I spent too much time at the
Camp-to-Camp beer tap so my
<br>
memory is a bit fuzzy. We talked about several things from
pre-computing
<br>
label positions to what you mention below. You are correct in how
<br>
MapServer works. It doesn't have any special "tiled" mode and hence
<br>
considers each tile just as any other map. In a single map context,
<br>
computing label positions post-clip makes sense.
<br>
<br>
Computing label positions pre-clip would result in a single, consistent
<br>
label position for each feature. For points and polygons that's
<br>
generally
<br>
OK I believe. For linear features the results might not always be
<br>
optimal
<br>
since the clipping often provides a nice means of segmenting long
<br>
features
<br>
so that get labeled multiple times. One could work around that at the
<br>
data level by segmenting long features ahead of time.
<br>
<br>
I don't believe it would hard to hack MapServer drawing routine
<br>
to do this and someone could test it out. Let me know if interested.
<br>
<br>
Steve
<br>
<br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Paul Spencer
<a class="moz-txt-link-rfc2396E" href="mailto:pspencer@dmsolutions.ca"><pspencer@dmsolutions.ca></a> 01/15/07 7:03 PM >>>
<br>
</blockquote>
</blockquote>
</blockquote>
Walt,
<br>
<br>
I don't believe it got documented. I spoke with Steve Lime (cc'd)
<br>
directly about this during OSGeo.
<br>
<br>
At the time, I believe Steve suggested label placement would be done
<br>
before features are clipped for rendering. I believe the way
<br>
mapserver works, it grabs all features that intersect a given bbox
<br>
then clips the features to the bbox then renders them. Labelling is
<br>
currently done post-clip. If it were done pre-clip, then labels
<br>
would be in a fixed position and could overlap tile boundaries
<br>
without problems.
<br>
<br>
I do believe that there were some potential problems with this
<br>
approach, but I don't know enough of mapserver internals to remember
<br>
what they were.
<br>
<br>
Steve, perhaps you could jump in and fix my explanation? Also, do
<br>
you think that label rendering changes would be a potential for
<br>
version 5?
<br>
<br>
Cheers
<br>
<br>
Paul
<br>
<br>
On 15-Jan-07, at 2:54 PM, Walt Welton-Lair wrote:
<br>
<br>
<blockquote type="cite">"In lieu of fixing this in MapServer (there
is actually a proposal
<br>
to fix this)..."
<br>
<br>
Paul - is there per chance a public link to this proposal? I'd be
<br>
interested in looking at it.
<br>
<br>
Thanks,
<br>
Walt
<br>
<br>
-----Original Message-----
<br>
From: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals-bounces@lists.osgeo.org">mapguide-internals-bounces@lists.osgeo.org</a> on behalf of
<br>
</blockquote>
Paul
<br>
<blockquote type="cite">Spencer (External)
<br>
Sent: Mon 1/15/2007 7:40 PM
<br>
To: MapGuide Internals Mail List
<br>
Cc:
<br>
Subject: Re: [mapguide-internals] RFC required for tile caching
<br>
</blockquote>
<br>
<blockquote type="cite">changes?
<br>
<br>
<br>
<br>
Trevor,
<br>
<br>
I don't think I got my idea across clearly :) Let me explain a
<br>
little more clearly.
<br>
<br>
In ka-Map, the size of a tile is configurable and by default is
<br>
200x200 px. There is a second concept that I've called a 'meta
<br>
tile'. A meta tile is some number of tiles wide x high,
<br>
</blockquote>
typically 10
<br>
<blockquote type="cite"> x 10. When a request for a tile comes
to the tile server, it
<br>
</blockquote>
checks
<br>
<blockquote type="cite"> the cache.
<br>
<br>
If the tile exists, the tile (200x200px) is returned. This
<br>
</blockquote>
happens
<br>
<blockquote type="cite"> without invoking any map rendering ...
the tile exists as an
<br>
</blockquote>
image on
<br>
<blockquote type="cite"> disk.
<br>
<br>
If the tile does not exist, then a map render happens. A map
<br>
</blockquote>
the
<br>
<blockquote type="cite"> size of the meta tile is rendered and
sliced into tile-sized
<br>
</blockquote>
chunks
<br>
<blockquote type="cite"> that are stored on disk in the cache
directory structure. While
<br>
</blockquote>
the
<br>
<blockquote type="cite"> tiles are being created, a lock file is
used to 'pause' requests
<br>
</blockquote>
for
<br>
<blockquote type="cite"> tiles in the same meta-tile directory
so that they can all be
<br>
</blockquote>
served
<br>
<blockquote type="cite"> from the same map draw when it is
finished.
<br>
<br>
We chose this approach for several reasons. First, MapServer
<br>
</blockquote>
suffers
<br>
<blockquote type="cite"> from edge effects when rendering map
images. This is normally
<br>
</blockquote>
not
<br>
<blockquote type="cite"> noticeable, but when you put several
map draws together in a
<br>
</blockquote>
tiled
<br>
<blockquote type="cite"> client, it becomes horribly obvious.
The solution was to render
<br>
</blockquote>
a
<br>
<blockquote type="cite"> slightly larger map image (about 10
pixels in fact) and clip out
<br>
</blockquote>
the
<br>
<blockquote type="cite"> center as the tile. Second, MapServer
labelling only considers
<br>
</blockquote>
the
<br>
<blockquote type="cite"> current map draw. Depending on the
size of the rendered label,
<br>
</blockquote>
it
<br>
<blockquote type="cite"> may not fit into a single tile.
Depending on the size of a
<br>
</blockquote>
feature,
<br>
<blockquote type="cite"> the label may appear on several
adjacent tiles. In lieu of
<br>
</blockquote>
fixing
<br>
<blockquote type="cite"> this in MapServer (there is actually a
proposal to fix this),
<br>
rendering a much larger map and slicing it into smaller tiles
<br>
produces a reasonable effect. Finally, it is relatively
<br>
</blockquote>
expensive to
<br>
<blockquote type="cite"> parse the map file and find/read the
data compared to rendering
<br>
</blockquote>
so
<br>
<blockquote type="cite"> rendering a single large image and
slicing it is cheaper than
<br>
rendering each smaller tile (with diminishing returns).
<br>
<br>
I don't know how you actually render the tiles in MapGuide, but
<br>
</blockquote>
I
<br>
<blockquote type="cite"> don't think you suffer from the same
edge and label issues.
<br>
<br>
The ka-Map directory structure looks something like this:
<br>
<br>
<br>
</blockquote>
<map>/<layer-group>/<scale>/<row-of-metatile>/<col-of-metatile>/<row-
<br>
<blockquote type="cite"> of-tile><col-of-tile>.<ext>
<br>
<br>
... which is similar to Chris' suggestion :) I don't get the
<br>
impression that you render the entire contents of the metatile
<br>
directory in one go though. Because I do, I only have to check
<br>
</blockquote>
if
<br>
<blockquote type="cite"> the meta-tile directory exists to know
if any tile in the
<br>
</blockquote>
directory
<br>
<blockquote type="cite"> exists, which is a small optimizatin.
<br>
<br>
One difference between Chris' proposal and the way ka-Map works
<br>
</blockquote>
is
<br>
<blockquote type="cite"> that the scale and layer group are
reversed. This makes it
<br>
theoretically possible to share the <layer-group> cache
<br>
</blockquote>
directory
<br>
<blockquote type="cite"> between different maps simply by
creating symlinks or by
<br>
</blockquote>
allowing a
<br>
<blockquote type="cite"> per-layer-group setting that indicates
the root directory to
<br>
</blockquote>
keep the
<br>
<blockquote type="cite"> tile cache in.
<br>
<br>
Cheers
<br>
<br>
Paul
<br>
<br>
On 15-Jan-07, at 11:49 AM, Trevor Wekel wrote:
<br>
<br>
> Hi everyone,
<br>
>
<br>
> I did some analysis on file systems a little while ago in
<br>
</blockquote>
support
<br>
<blockquote type="cite"> > of the
<br>
> directory structure change. Here are some approximate numbers
<br>
</blockquote>
for
<br>
<blockquote type="cite"> > directory entry and file system
entries that I pulled from an
<br>
</blockquote>
<br>
<blockquote type="cite">internet
<br>
> search:
<br>
>
<br>
> Linux ext3 - each file or directory is approx 8 bytes +
<br>
</blockquote>
length of
<br>
<blockquote type="cite"> > file
<br>
> or directory name
<br>
> Linux Reiserfs - each file or directory is 18 bytes + length
<br>
</blockquote>
of
<br>
<blockquote type="cite"> > file or
<br>
> directory name
<br>
>
<br>
> If we assume each file name has a format of R99999_C99999.PNG
<br>
</blockquote>
then
<br>
<blockquote type="cite"> > each
<br>
> file entry will require 26 bytes under ext3 and 34 bytes under
<br>
> ReiserFS.
<br>
>
<br>
> To facilitate fast directory access, tiles which are close to
<br>
</blockquote>
each
<br>
<blockquote type="cite"> > other
<br>
> should like in the same directory. This reduces the directory
<br>
</blockquote>
<br>
<blockquote type="cite">entry
<br>
> reads for each tile request. If we also assume that the read
<br>
</blockquote>
block
<br>
<blockquote type="cite"> > size
<br>
> for the file system is 32kbytes (32/64k is often used in RAID
<br>
</blockquote>
<br>
<blockquote type="cite">arrays)
<br>
> then a directory with 900 entries (30x30 block) will get read
<br>
</blockquote>
in a
<br>
<blockquote type="cite"> > single IOP (900*34 = 30600). And
since the tiles are blocked
<br>
> together,
<br>
> it is very likely that adjacent tiles will fall within the
<br>
</blockquote>
same
<br>
<blockquote type="cite"> > directory. Since the directory
was just read, it will be
<br>
</blockquote>
cached
<br>
<blockquote type="cite">and
<br>
> there will be no disk access required.
<br>
>
<br>
> If we increase the size of the directories to more than 900
<br>
</blockquote>
entries
<br>
<blockquote type="cite"> > then
<br>
> we will incur more than IOP to read the bottom-most directory
<br>
> structure.
<br>
>
<br>
> I also think Traian's suggestion of Base Layer Group/
<br>
30/60/3_4.png is
<br>
> reasonable. It is more readable than the original mod scheme.
<br>
>
<br>
>> From a rendering perspective, dealing with 2000x2000 pixel
<br>
</blockquote>
blocks
<br>
<blockquote type="cite"> >> may be
<br>
> more efficient but cutting the tiles up from these larger
<br>
</blockquote>
images
<br>
<blockquote type="cite">will
<br>
> require some computational effort. Rendering the tiles in the
<br>
</blockquote>
same
<br>
<blockquote type="cite"> > size
<br>
> as requested from the client reduces server load because the
<br>
</blockquote>
HTTP
<br>
<blockquote type="cite"> > request ends up being simply a
file serving operation.
<br>
>
<br>
> With some of the latest optimizations I have been working on,
<br>
</blockquote>
<br>
<blockquote type="cite">MapGuide
<br>
> tile serving speeds using "client-sized" tiles are quite
<br>
respectable.
<br>
> On a machine with a single 3GHz CPU, MapGuide can service more
<br>
</blockquote>
than
<br>
<blockquote type="cite"> > 100
<br>
> tiles per second assuming the tiles are being served from
<br>
</blockquote>
memory,
<br>
<blockquote type="cite"> > ie. no
<br>
> disk access. The additional computational effort required to
<br>
</blockquote>
<br>
<blockquote type="cite">generate
<br>
> "client" tiles from larger pixel blocks will significantly
<br>
</blockquote>
impact
<br>
<blockquote type="cite"> > performance.
<br>
>
<br>
>
<br>
> Thanks,
<br>
> Trevor
<br>
>
<br>
> -----Original Message-----
<br>
> From: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals-bounces@lists.osgeo.org">mapguide-internals-bounces@lists.osgeo.org</a>
<br>
> [<a class="moz-txt-link-freetext" href="mailto:mapguide-internals-bounces@lists.osgeo.org">mailto:mapguide-internals-bounces@lists.osgeo.org</a>] On Behalf
<br>
</blockquote>
Of
<br>
<blockquote type="cite">Paul
<br>
> Spencer (External)
<br>
> Sent: Sunday, January 14, 2007 11:59 AM
<br>
> To: MapGuide Internals Mail List
<br>
> Subject: Re: [mapguide-internals] RFC required for tile
<br>
</blockquote>
caching
<br>
<blockquote type="cite"> > changes?
<br>
>
<br>
> FWIW, Traian's suggestion for naming folders based on a mod of
<br>
</blockquote>
r/
<br>
<blockquote type="cite">c is
<br>
> essentially the same approach I took with ka-Map (for the same
<br>
</blockquote>
<br>
<blockquote type="cite">reason
<br>
> that Chris brought this up) and it seems to work very well.
<br>
</blockquote>
In ka-
<br>
<blockquote type="cite"> > Map,
<br>
> tiles are rendered in blocks of about 2000x2000 pixels (tile
<br>
size is
<br>
> configurable but you might get 10 x 10 tiles in a typical
<br>
> configuration) and they would go in one of these sub-
<br>
directories. I
<br>
> think I figured out that this would be enough directories to
<br>
decently
<br>
> cache a pretty large area (say, all of the US) without running
<br>
</blockquote>
into
<br>
<blockquote type="cite"> > file
<br>
> system limits for most scales.
<br>
>
<br>
> It would be interesting to know the limits on:
<br>
>
<br>
> * files per directory
<br>
> * directories per directory
<br>
> * total number of directories
<br>
> * total number of files
<br>
> * minimum block(?) size in the file system compared to typical
<br>
</blockquote>
size
<br>
<blockquote type="cite"> > of a
<br>
> tile (wasted space per tile).
<br>
>
<br>
> for various operating systems/file system combinations. I
<br>
</blockquote>
know
<br>
<blockquote type="cite">we use
<br>
> ReiserFS because it handles lots of small files better than
<br>
</blockquote>
ext3
<br>
<blockquote type="cite">for
<br>
> instance. Knowing some of this might help make the caching
<br>
</blockquote>
system
<br>
<blockquote type="cite"> > more
<br>
> tunable in different environments.
<br>
>
<br>
> Paul
<br>
>
<br>
> On 13-Jan-07, at 11:09 AM, Traian Stanev wrote:
<br>
>
<br>
>> Can you also give an example for tiles with negative
indices?
<br>
>> For example if in the current scheme the tile is -33, -64,
<br>
</blockquote>
what
<br>
<blockquote type="cite">would
<br>
>> be the resulting directory path?
<br>
>>
<br>
>> R-2/C-3/-3_-4
<br>
>>
<br>
>> What about tile -1,-1
<br>
>>
<br>
>> Another suggestion I have -- name the folder part of the
path
<br>
</blockquote>
<br>
<blockquote type="cite">(30 *
<br>
>> tile index div 30) and then the file part would be (tile
<br>
</blockquote>
index mod
<br>
<blockquote type="cite"> >> 30).
<br>
>>
<br>
>> So for tile 33,64 the folder would be:
<br>
>>
<br>
>> Base Layer Group/30/60/3_4.png
<br>
>>
<br>
>> And for tile -33,-64 the folder would be:
<br>
>>
<br>
>> Base Layer Group/-30/-60/-3_-4.png
<br>
>>
<br>
>> For tile 1,1, the folder would be:
<br>
>>
<br>
>> Base Layer Group/0/0/1_1.png
<br>
>>
<br>
>> For tile -1,-1 the folder would be:
<br>
>>
<br>
>> Base Layer Group/-0/-0/-1_-1.png
<br>
>>
<br>
>>
<br>
>> It's a little weird around 0, but it allows for arbitrary
<br>
>> groupings of
<br>
>
<br>
>> tiles in folders (they don't have to be 30x30) since the
tile
<br>
</blockquote>
<br>
<blockquote type="cite">index
<br>
>> can be computed directly from the file path, by adding the
<br>
</blockquote>
folder
<br>
<blockquote type="cite"> >> term
<br>
>
<br>
>> to the file path term.
<br>
>>
<br>
>> Also, can you tell us what the problem is with having too
<br>
</blockquote>
many
<br>
<blockquote type="cite">images
<br>
>> in one directory? Is it a file system issue? And how many
<br>
</blockquote>
tiles is
<br>
<blockquote type="cite"> >> the
<br>
>
<br>
>> limit, i.e. why is 30x30 the preferred grouping and not
<br>
1000x1000 for
<br>
>> example?
<br>
>>
<br>
>> Traian
<br>
>> -----Original Message-----
<br>
>> From: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals-bounces@lists.osgeo.org">mapguide-internals-bounces@lists.osgeo.org</a> on behalf
of
<br>
</blockquote>
<br>
<blockquote type="cite">Jason
<br>
>> Birch
<br>
>> Sent: Fri 1/12/2007 8:57 PM
<br>
>> To: MapGuide Internals Mail List
<br>
>> Cc:
<br>
>> Subject: RE: [mapguide-internals] RFC required for tile
<br>
</blockquote>
caching
<br>
<blockquote type="cite"> >> changes?
<br>
>>
<br>
>> Can I forward this to the "tiling" list for comment?
<br>
>>
<br>
>>
<br>
>> From: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals-bounces@lists.osgeo.org">mapguide-internals-bounces@lists.osgeo.org</a> on behalf
of
<br>
</blockquote>
<br>
<blockquote type="cite">Chris
<br>
>> Claydon
<br>
>> Sent: Fri 2007-01-12 12:24 PM
<br>
>> To: MapGuide Internals Mail List
<br>
>> Subject: RE: [mapguide-internals] RFC required for tile
<br>
</blockquote>
caching
<br>
<blockquote type="cite"> >> changes?
<br>
>>
<br>
>> A sample tile location would be as follows:
<br>
>>
<br>
>>
<br>
>> ......\
<br>
</blockquote>
Repositories\TileCache\Samples_Sheboygan_Maps_Sheboygan\7
<br>
<blockquote type="cite"> >> \Base
<br>
>> Layer Group\R2\C3\3_4.png
<br>
>>
<br>
>>
<br>
>> The R and C indices correspond to rows and columns where
each
<br>
</blockquote>
row
<br>
<blockquote type="cite"> >> contains 30 tiles vertically
and each column contains 30
<br>
</blockquote>
tiles
<br>
<blockquote type="cite"> >> horizontally.
<br>
>>
<br>
>>
<br>
>> This indicates that:
<br>
>>
<br>
>>
<br>
>> 1) We're at zoom level 7
<br>
>>
<br>
>> 2) We're in grouped row 2
<br>
>>
<br>
>> 3) We're in grouped column 3
<br>
>>
<br>
>> 4) The tile location within this grouped row/column
<br>
>> combination is (3,4).
<br>
>>
<br>
>>
<br>
>> The R and C indices never take a zero value (to avoid
issues
<br>
</blockquote>
with
<br>
<blockquote type="cite"> >> negative values around the
origin), so this tile corresponds
<br>
</blockquote>
to a
<br>
<blockquote type="cite"> >> location of (33, 64) in the
old scheme.
<br>
>>
<br>
>>
<br>
>> I took a quick look at the Tile Map Service Specification,
<br>
</blockquote>
but it
<br>
<blockquote type="cite"> >> doesn't appear to support the
concept of grouping blocks of
<br>
</blockquote>
tiles
<br>
<blockquote type="cite"> >> into subfolders in its current
form. Can you provide more
<br>
>> information on whether this is possible?
<br>
>>
<br>
>>
<br>
>> Chris.
<br>
>>
<br>
>>
<br>
>> _______________________________________________
<br>
>> mapguide-internals mailing list
<br>
>> <a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals@lists.osgeo.org">mapguide-internals@lists.osgeo.org</a>
<br>
>> <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-internals">http://lists.osgeo.org/mailman/listinfo/mapguide-internals</a>
<br>
>
<br>
>
<br>
</blockquote>
+-----------------------------------------------------------------+
<br>
<blockquote type="cite"> > |Paul
Spencer <a class="moz-txt-link-abbreviated" href="mailto:pspencer@dmsolutions.ca">pspencer@dmsolutions.ca</a>
<br>
</blockquote>
|
<br>
<blockquote type="cite"> >
<br>
</blockquote>
+-----------------------------------------------------------------+
<br>
<blockquote type="cite"> > |Chief Technology Officer
<br>
</blockquote>
|
<br>
<blockquote type="cite"> > |DM Solutions Group Inc
<br>
</blockquote>
<a class="moz-txt-link-freetext" href="http://www.dmsolutions.ca/">http://www.dmsolutions.ca/</a> |
<br>
<blockquote type="cite"> >
<br>
</blockquote>
+-----------------------------------------------------------------+
<br>
<blockquote type="cite"> >
<br>
>
<br>
>
<br>
>
<br>
> _______________________________________________
<br>
> mapguide-internals mailing list
<br>
> <a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals@lists.osgeo.org">mapguide-internals@lists.osgeo.org</a>
<br>
> <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-internals">http://lists.osgeo.org/mailman/listinfo/mapguide-internals</a>
<br>
>
<br>
> _______________________________________________
<br>
> mapguide-internals mailing list
<br>
> <a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals@lists.osgeo.org">mapguide-internals@lists.osgeo.org</a>
<br>
> <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-internals">http://lists.osgeo.org/mailman/listinfo/mapguide-internals</a>
<br>
<br>
<br>
</blockquote>
+-----------------------------------------------------------------+
<br>
<blockquote type="cite"> |Paul Spencer
<a class="moz-txt-link-abbreviated" href="mailto:pspencer@dmsolutions.ca">pspencer@dmsolutions.ca</a>
<br>
</blockquote>
|
<br>
<blockquote type="cite"><br>
</blockquote>
+-----------------------------------------------------------------+
<br>
<blockquote type="cite"> |Chief Technology Officer
<br>
</blockquote>
|
<br>
<blockquote type="cite"> |DM Solutions Group Inc
<br>
</blockquote>
<a class="moz-txt-link-freetext" href="http://www.dmsolutions.ca/">http://www.dmsolutions.ca/</a> |
<br>
<blockquote type="cite"><br>
</blockquote>
+-----------------------------------------------------------------+
<br>
<blockquote type="cite">
<br>
<br>
<br>
<br>
_______________________________________________
<br>
mapguide-internals mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals@lists.osgeo.org">mapguide-internals@lists.osgeo.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-internals">http://lists.osgeo.org/mailman/listinfo/mapguide-internals</a>
<br>
<br>
<br>
<winmail.dat>
<br>
_______________________________________________
<br>
mapguide-internals mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals@lists.osgeo.org">mapguide-internals@lists.osgeo.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-internals">http://lists.osgeo.org/mailman/listinfo/mapguide-internals</a>
<br>
</blockquote>
<br>
+-----------------------------------------------------------------+
<br>
|Paul Spencer <a class="moz-txt-link-abbreviated" href="mailto:pspencer@dmsolutions.ca">pspencer@dmsolutions.ca</a> |
<br>
+-----------------------------------------------------------------+
<br>
|Chief Technology Officer |
<br>
|DM Solutions Group Inc <a class="moz-txt-link-freetext" href="http://www.dmsolutions.ca/">http://www.dmsolutions.ca/</a> |
<br>
+-----------------------------------------------------------------+
<br>
<br>
<br>
<br>
<br>
<br>
</blockquote>
<br>
+-----------------------------------------------------------------+
<br>
|Paul Spencer <a class="moz-txt-link-abbreviated" href="mailto:pspencer@dmsolutions.ca">pspencer@dmsolutions.ca</a> |
<br>
+-----------------------------------------------------------------+
<br>
|Chief Technology Officer |
<br>
|DM Solutions Group Inc <a class="moz-txt-link-freetext" href="http://www.dmsolutions.ca/">http://www.dmsolutions.ca/</a> |
<br>
+-----------------------------------------------------------------+
<br>
<br>
<br>
<br>
<br>
_______________________________________________
<br>
mapguide-internals mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:mapguide-internals@lists.osgeo.org">mapguide-internals@lists.osgeo.org</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-internals">http://lists.osgeo.org/mailman/listinfo/mapguide-internals</a>
<br>
<br>
</blockquote>
<br>
</body>
</html>