fusion and projection support

[Andreas Morf]

Some javascript/style in this post has been disabled (why?)

With rev. 1907 Mike added projection support to fusion – this screwed up my fusion app where I use  projected coordinates (swiss grid): the oMapOL was set to default value EPSG:4326 which was the source of malfunction.

I normally set the CRS in my MG-mapdefinition and I don’t want to set it again in fusion and additionally provide a EPSGxy.js (). Shouldn’t fusion read out CRS-def from MG-server mapdef for the actual map and use that for client-side calculations?

 

IMHO 1907 looks a bit like a quick and dirty fix for mapserver concerns – the whole matter shoud be discussed an planned from ground up (RFC?).

 

Greets, Andreas

 

 

_______________________________________________
fusion-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fusion-dev

[Mike Adair]

That change is required so that the Measure widget can work with maps in
various projections, otherwise the distances measured don't make sense
at all (for both MapServer and MapGuide).

I don't see how that revision would break a MapGuide application,
perhaps you can explain?

I am working on a patch for MapGuide side of things to set the
projection automatically. Ideally the MapGuide API would have a way of
returning the EPSG code for a map and indeed it does have
$csFactory->ConvertWktToEpsgCode($srs), however I am getting an error
whenever I try to use that "Could not convert to EPSG code from WKT". It
is for this reason that I put support for that in the Map extension
element in AppDef. If you can point to a better way of informing the
client about the EPSG code for the map I would be happy to hear it.

Mike



Andreas Morf wrote:

>
> With rev. 1907 Mike added projection support to fusion – this screwed
> up my fusion app where I use projected coordinates (swiss grid): the
> oMapOL was set to default value EPSG:4326 which was the source of
> malfunction.
>
> I normally set the CRS in my MG-mapdefinition and I don’t want to set
> it again in fusion and additionally provide a EPSGxy.js (). Shouldn’t
> fusion read out CRS-def from MG-server mapdef for the actual map and
> use that for client-side calculations?
>
> IMHO 1907 looks a bit like a quick and dirty fix for mapserver
> concerns – the whole matter shoud be discussed an planned from ground
> up (RFC?).
>
> Greets, Andreas
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> fusion-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fusion-dev
>  

--
   Michael Adair
   Senior Software Architect
   DM Solutions Group Inc.

   Office: [phone] x26
   [hidden email]
   http://www.dmsolutions.ca
   http://research.dmsolutions.ca


_______________________________________________
fusion-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fusion-dev

[Andreas Morf]

The default projection of mgMapOL is set to "EPSG:4326" on line 14636 in
Openlayers.js. If Proj4js is available the initialisation of the OL
projection with the followinge statements (around line 10855)

  if (window.Proj4js) {
      this.proj = new Proj4js.Proj(projCode);
  }

results in this.proj being defined - and finally this leads to my map being
screwed up (wrong scale, extents...) becaus my coords are in another CRS

Andreas

> -----Original Message-----
> From: Mike Adair [mailto:[hidden email]]
> Sent: Tuesday, October 06, 2009 8:09 PM
> To: Andreas Morf
> Cc: [hidden email]
> Subject: Re: [fusion-dev] fusion and projection support
>
> That change is required so that the Measure widget can work with maps
> in
> various projections, otherwise the distances measured don't make sense
> at all (for both MapServer and MapGuide).
>
> I don't see how that revision would break a MapGuide application,
> perhaps you can explain?
>
> I am working on a patch for MapGuide side of things to set the
> projection automatically. Ideally the MapGuide API would have a way of
> returning the EPSG code for a map and indeed it does have
> $csFactory->ConvertWktToEpsgCode($srs), however I am getting an error
> whenever I try to use that "Could not convert to EPSG code from WKT".
> It
> is for this reason that I put support for that in the Map extension
> element in AppDef. If you can point to a better way of informing the
> client about the EPSG code for the map I would be happy to hear it.
>
> Mike
>
>
>
> Andreas Morf wrote:
> >
> > With rev. 1907 Mike added projection support to fusion - this screwed
> > up my fusion app where I use projected coordinates (swiss grid): the
> > oMapOL was set to default value EPSG:4326 which was the source of
> > malfunction.
> >
> > I normally set the CRS in my MG-mapdefinition and I don't want to set
> > it again in fusion and additionally provide a EPSGxy.js (). Shouldn't
> > fusion read out CRS-def from MG-server mapdef for the actual map and
> > use that for client-side calculations?
> >
> > IMHO 1907 looks a bit like a quick and dirty fix for mapserver
> > concerns - the whole matter shoud be discussed an planned from ground
> > up (RFC?).
> >
> > Greets, Andreas
> >
> > ---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > fusion-dev mailing list
> > [hidden email]
> > http://lists.osgeo.org/mailman/listinfo/fusion-dev
> >
>
> --
>    Michael Adair
>    Senior Software Architect
>    DM Solutions Group Inc.
>
>    Office: [phone] x26
>    [hidden email]
>    http://www.dmsolutions.ca
>    http://research.dmsolutions.ca

_______________________________________________
fusion-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fusion-dev

[Andreas Morf]

Mike
I investigated a little bit:

With the following Code, it is possible to get the EPSG code from the
Server:

Mapguide.js:

    convertWKT2EPSGRequest: function(wkt) {
        var r = new Fusion.Lib.MGRequest.MGEPSGfromWKT(wkt);
        Fusion.oBroker.dispatchRequest(r,
OpenLayers.Function.bind(this.processWKT2EPSGresponse, this));

    },
   
    processWKT2EPSGresponse: function (r) {
        if (r.responseText)
            alert(r.responseText);
    },

MGBroker.js

Fusion.Lib.MGRequest.MGEPSGfromWKT = OpenLayers.Class(Fusion.Lib.MGRequest,
{

    initialize : function( wkt )
    {
        this.initializeRequest();
        this.setParams( {
            operation : 'CS.CONVERTWKTTOEPSGCODE',
            version: '1.0.0',
            cswkt: wkt
        } );
    }
});

The main problem was that the server always returned a '0' as result for my
WKT:

PROJCS["SWISS",GEOGCS["LLCH1903",DATUM["CH-1903",SPHEROID["BESSEL",6377397.1
55,299.15281535],TOWGS84[660.0770,13.5510,369.3440,0.804816,0.577692,0.95223
6,5.66000000]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PR
OJECTION["Swiss_Oblique_Cylindrical"],PARAMETER["false_easting",600000.000],
PARAMETER["false_northing",200000.000],PARAMETER["latitude_of_origin",46.952
40555555556],PARAMETER["central_meridian",7.43958333333333],UNIT["Meter",1.0
0000000000000]]

There is a mapping file in CS-Map/Dictionaries which maps from CS-Code to
EPSG (NameMapper.csv) - the CS-Code 'SWISS' was not in there so I added the
following line:

21781,16,Autodesk,0,"SWISS",0,0,0,0,,

After restarting httpd (this took me quite a bit of time to find out...) the
server answers the request with the right EPSG-Code of 21781!

Greets
Andreas

> -----Original Message-----
> From: [hidden email] [mailto:fusion-dev-
> [hidden email]] On Behalf Of Andreas Morf
> Sent: Wednesday, October 07, 2009 8:40 AM
> To: [hidden email]
> Subject: RE: [fusion-dev] fusion and projection support
>
> The default projection of mgMapOL is set to "EPSG:4326" on line 14636
> in
> Openlayers.js. If Proj4js is available the initialisation of the OL
> projection with the followinge statements (around line 10855)
>
>   if (window.Proj4js) {
>       this.proj = new Proj4js.Proj(projCode);
>   }
>
> results in this.proj being defined - and finally this leads to my map
> being
> screwed up (wrong scale, extents...) becaus my coords are in another
> CRS
>
> Andreas
>
> > -----Original Message-----
> > From: Mike Adair [mailto:[hidden email]]
> > Sent: Tuesday, October 06, 2009 8:09 PM
> > To: Andreas Morf
> > Cc: [hidden email]
> > Subject: Re: [fusion-dev] fusion and projection support
> >
> > That change is required so that the Measure widget can work with maps
> > in
> > various projections, otherwise the distances measured don't make
> sense
> > at all (for both MapServer and MapGuide).
> >
> > I don't see how that revision would break a MapGuide application,
> > perhaps you can explain?
> >
> > I am working on a patch for MapGuide side of things to set the
> > projection automatically. Ideally the MapGuide API would have a way
> of
> > returning the EPSG code for a map and indeed it does have
> > $csFactory->ConvertWktToEpsgCode($srs), however I am getting an error
> > whenever I try to use that "Could not convert to EPSG code from WKT".
> > It
> > is for this reason that I put support for that in the Map extension
> > element in AppDef. If you can point to a better way of informing the
> > client about the EPSG code for the map I would be happy to hear it.
> >
> > Mike
> >
> >
> >
> > Andreas Morf wrote:
> > >
> > > With rev. 1907 Mike added projection support to fusion - this
> screwed
> > > up my fusion app where I use projected coordinates (swiss grid):
> the
> > > oMapOL was set to default value EPSG:4326 which was the source of
> > > malfunction.
> > >
> > > I normally set the CRS in my MG-mapdefinition and I don't want to
> set
> > > it again in fusion and additionally provide a EPSGxy.js ().
> Shouldn't
> > > fusion read out CRS-def from MG-server mapdef for the actual map
> and
> > > use that for client-side calculations?
> > >
> > > IMHO 1907 looks a bit like a quick and dirty fix for mapserver
> > > concerns - the whole matter shoud be discussed an planned from
> ground
> > > up (RFC?).
> > >
> > > Greets, Andreas
> > >
> > > -------------------------------------------------------------------
> --
> > ---
> > >
> > > _______________________________________________
> > > fusion-dev mailing list
> > > [hidden email]
> > > http://lists.osgeo.org/mailman/listinfo/fusion-dev
> > >
> >
> > --
> >    Michael Adair
> >    Senior Software Architect
> >    DM Solutions Group Inc.
> >
> >    Office: [phone] x26
> >    [hidden email]
> >    http://www.dmsolutions.ca
> >    http://research.dmsolutions.ca
>
>
> _______________________________________________
> fusion-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fusion-dev

_______________________________________________
fusion-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fusion-dev

[Mike Adair]

Andreas,

I've just added the equivalent support for this for MapGuide to trunk,
but I implemented the call to convertWKTToEPSG in the LoadMap.php script
to avoid another trip to the server.

You will still need to do some setup in MapGuide so that the lookup of
WKT to EPSG works, or else optionally include the projection definition
string and or EPSG code in the AppDefinition.xml file.   If neither of
those options are used, then the map will default to the OpenLayers
default of EPSG:4326.

In the older version of MapGuide that I am running (v2.0.0), it looks
like the WKT/EPSG lookup table is in MG/server/data/*.wkt but I'm not at
all sure of that. (I was able to lookup one of the EPSG codes in those
files, but haven't successfully added a custom projection def to those).

Mike



Andreas Morf wrote:

> Mike
> I investigated a little bit:
>
> With the following Code, it is possible to get the EPSG code from the
> Server:
>
> Mapguide.js:
>
>     convertWKT2EPSGRequest: function(wkt) {
>         var r = new Fusion.Lib.MGRequest.MGEPSGfromWKT(wkt);
>         Fusion.oBroker.dispatchRequest(r,
> OpenLayers.Function.bind(this.processWKT2EPSGresponse, this));
>
>     },
>    
>     processWKT2EPSGresponse: function (r) {
>         if (r.responseText)
>             alert(r.responseText);
>     },
>
> MGBroker.js
>
> Fusion.Lib.MGRequest.MGEPSGfromWKT = OpenLayers.Class(Fusion.Lib.MGRequest,
> {
>
>     initialize : function( wkt )
>     {
>         this.initializeRequest();
>         this.setParams( {
>             operation : 'CS.CONVERTWKTTOEPSGCODE',
>             version: '1.0.0',
>             cswkt: wkt
>         } );
>     }
> });
>
> The main problem was that the server always returned a '0' as result for my
> WKT:
>
> PROJCS["SWISS",GEOGCS["LLCH1903",DATUM["CH-1903",SPHEROID["BESSEL",6377397.1
> 55,299.15281535],TOWGS84[660.0770,13.5510,369.3440,0.804816,0.577692,0.95223
> 6,5.66000000]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PR
> OJECTION["Swiss_Oblique_Cylindrical"],PARAMETER["false_easting",600000.000],
> PARAMETER["false_northing",200000.000],PARAMETER["latitude_of_origin",46.952
> 40555555556],PARAMETER["central_meridian",7.43958333333333],UNIT["Meter",1.0
> 0000000000000]]
>
> There is a mapping file in CS-Map/Dictionaries which maps from CS-Code to
> EPSG (NameMapper.csv) - the CS-Code 'SWISS' was not in there so I added the
> following line:
>
> 21781,16,Autodesk,0,"SWISS",0,0,0,0,,
>
> After restarting httpd (this took me quite a bit of time to find out...) the
> server answers the request with the right EPSG-Code of 21781!
>
> Greets
> Andreas
>
>
>
>
>
>  
>> -----Original Message-----
>> From: [hidden email] [mailto:fusion-dev-
>> [hidden email]] On Behalf Of Andreas Morf
>> Sent: Wednesday, October 07, 2009 8:40 AM
>> To: [hidden email]
>> Subject: RE: [fusion-dev] fusion and projection support
>>
>> The default projection of mgMapOL is set to "EPSG:4326" on line 14636
>> in
>> Openlayers.js. If Proj4js is available the initialisation of the OL
>> projection with the followinge statements (around line 10855)
>>
>>   if (window.Proj4js) {
>>       this.proj = new Proj4js.Proj(projCode);
>>   }
>>
>> results in this.proj being defined - and finally this leads to my map
>> being
>> screwed up (wrong scale, extents...) becaus my coords are in another
>> CRS
>>
>> Andreas
>>
>>    
>>> -----Original Message-----
>>> From: Mike Adair [mailto:[hidden email]]
>>> Sent: Tuesday, October 06, 2009 8:09 PM
>>> To: Andreas Morf
>>> Cc: [hidden email]
>>> Subject: Re: [fusion-dev] fusion and projection support
>>>
>>> That change is required so that the Measure widget can work with maps
>>> in
>>> various projections, otherwise the distances measured don't make
>>>      
>> sense
>>    
>>> at all (for both MapServer and MapGuide).
>>>
>>> I don't see how that revision would break a MapGuide application,
>>> perhaps you can explain?
>>>
>>> I am working on a patch for MapGuide side of things to set the
>>> projection automatically. Ideally the MapGuide API would have a way
>>>      
>> of
>>    
>>> returning the EPSG code for a map and indeed it does have
>>> $csFactory->ConvertWktToEpsgCode($srs), however I am getting an error
>>> whenever I try to use that "Could not convert to EPSG code from WKT".
>>> It
>>> is for this reason that I put support for that in the Map extension
>>> element in AppDef. If you can point to a better way of informing the
>>> client about the EPSG code for the map I would be happy to hear it.
>>>
>>> Mike
>>>
>>>
>>>
>>> Andreas Morf wrote:
>>>      
>>>> With rev. 1907 Mike added projection support to fusion - this
>>>>        
>> screwed
>>    
>>>> up my fusion app where I use projected coordinates (swiss grid):
>>>>        
>> the
>>    
>>>> oMapOL was set to default value EPSG:4326 which was the source of
>>>> malfunction.
>>>>
>>>> I normally set the CRS in my MG-mapdefinition and I don't want to
>>>>        
>> set
>>    
>>>> it again in fusion and additionally provide a EPSGxy.js ().
>>>>        
>> Shouldn't
>>    
>>>> fusion read out CRS-def from MG-server mapdef for the actual map
>>>>        
>> and
>>    
>>>> use that for client-side calculations?
>>>>
>>>> IMHO 1907 looks a bit like a quick and dirty fix for mapserver
>>>> concerns - the whole matter shoud be discussed an planned from
>>>>        
>> ground
>>    
>>>> up (RFC?).
>>>>
>>>> Greets, Andreas
>>>>
>>>> -------------------------------------------------------------------
>>>>        
>> --
>>    
>>> ---
>>>      
>>>> _______________________________________________
>>>> fusion-dev mailing list
>>>> [hidden email]
>>>> http://lists.osgeo.org/mailman/listinfo/fusion-dev
>>>>
>>>>        
>>> --
>>>    Michael Adair
>>>    Senior Software Architect
>>>    DM Solutions Group Inc.
>>>
>>>    Office: [phone] x26
>>>    [hidden email]
>>>    http://www.dmsolutions.ca
>>>    http://research.dmsolutions.ca
>>>      
>> _______________________________________________
>> fusion-dev mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/fusion-dev
>>    
>
> _______________________________________________
> fusion-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fusion-dev
>
>  

--
   Michael Adair
   Senior Software Architect
   DM Solutions Group Inc.

   Office: [phone] x26
   [hidden email]
   http://www.dmsolutions.ca
   http://research.dmsolutions.ca


_______________________________________________
fusion-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fusion-dev

[Jason Birch]

With mgos 2.1, those proj.4 files are no longer there or used.

It would be useful to have andreas' procedure or the appdef override
method documented on the wiki for others who run into same problem.

On 2009-10-07, Mike Adair <[hidden email]> wrote:

> Andreas,
>
> I've just added the equivalent support for this for MapGuide to trunk,
> but I implemented the call to convertWKTToEPSG in the LoadMap.php script
> to avoid another trip to the server.
>
> You will still need to do some setup in MapGuide so that the lookup of
> WKT to EPSG works, or else optionally include the projection definition
> string and or EPSG code in the AppDefinition.xml file.   If neither of
> those options are used, then the map will default to the OpenLayers
> default of EPSG:4326.
>
> In the older version of MapGuide that I am running (v2.0.0), it looks
> like the WKT/EPSG lookup table is in MG/server/data/*.wkt but I'm not at
> all sure of that. (I was able to lookup one of the EPSG codes in those
> files, but haven't successfully added a custom projection def to those).
>
> Mike
>
>
>
> Andreas Morf wrote:
>> Mike
>> I investigated a little bit:
>>
>> With the following Code, it is possible to get the EPSG code from the
>> Server:
>>
>> Mapguide.js:
>>
>>     convertWKT2EPSGRequest: function(wkt) {
>>         var r = new Fusion.Lib.MGRequest.MGEPSGfromWKT(wkt);
>>         Fusion.oBroker.dispatchRequest(r,
>> OpenLayers.Function.bind(this.processWKT2EPSGresponse, this));
>>
>>     },
>>
>>     processWKT2EPSGresponse: function (r) {
>>         if (r.responseText)
>>             alert(r.responseText);
>>     },
>>
>> MGBroker.js
>>
>> Fusion.Lib.MGRequest.MGEPSGfromWKT =
>> OpenLayers.Class(Fusion.Lib.MGRequest,
>> {
>>
>>     initialize : function( wkt )
>>     {
>>         this.initializeRequest();
>>         this.setParams( {
>>             operation : 'CS.CONVERTWKTTOEPSGCODE',
>>             version: '1.0.0',
>>             cswkt: wkt
>>         } );
>>     }
>> });
>>
>> The main problem was that the server always returned a '0' as result for
>> my
>> WKT:
>>
>> PROJCS["SWISS",GEOGCS["LLCH1903",DATUM["CH-1903",SPHEROID["BESSEL",6377397.1
>> 55,299.15281535],TOWGS84[660.0770,13.5510,369.3440,0.804816,0.577692,0.95223
>> 6,5.66000000]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]],PR
>> OJECTION["Swiss_Oblique_Cylindrical"],PARAMETER["false_easting",600000.000],
>> PARAMETER["false_northing",200000.000],PARAMETER["latitude_of_origin",46.952
>> 40555555556],PARAMETER["central_meridian",7.43958333333333],UNIT["Meter",1.0
>> 0000000000000]]
>>
>> There is a mapping file in CS-Map/Dictionaries which maps from CS-Code to
>> EPSG (NameMapper.csv) - the CS-Code 'SWISS' was not in there so I added
>> the
>> following line:
>>
>> 21781,16,Autodesk,0,"SWISS",0,0,0,0,,
>>
>> After restarting httpd (this took me quite a bit of time to find out...)
>> the
>> server answers the request with the right EPSG-Code of 21781!
>>
>> Greets
>> Andreas
>>
>>
>>
>>
>>
>>
>>> -----Original Message-----
>>> From: [hidden email] [mailto:fusion-dev-
>>> [hidden email]] On Behalf Of Andreas Morf
>>> Sent: Wednesday, October 07, 2009 8:40 AM
>>> To: [hidden email]
>>> Subject: RE: [fusion-dev] fusion and projection support
>>>
>>> The default projection of mgMapOL is set to "EPSG:4326" on line 14636
>>> in
>>> Openlayers.js. If Proj4js is available the initialisation of the OL
>>> projection with the followinge statements (around line 10855)
>>>
>>>   if (window.Proj4js) {
>>>       this.proj = new Proj4js.Proj(projCode);
>>>   }
>>>
>>> results in this.proj being defined - and finally this leads to my map
>>> being
>>> screwed up (wrong scale, extents...) becaus my coords are in another
>>> CRS
>>>
>>> Andreas
>>>
>>>
>>>> -----Original Message-----
>>>> From: Mike Adair [mailto:[hidden email]]
>>>> Sent: Tuesday, October 06, 2009 8:09 PM
>>>> To: Andreas Morf
>>>> Cc: [hidden email]
>>>> Subject: Re: [fusion-dev] fusion and projection support
>>>>
>>>> That change is required so that the Measure widget can work with maps
>>>> in
>>>> various projections, otherwise the distances measured don't make
>>>>
>>> sense
>>>
>>>> at all (for both MapServer and MapGuide).
>>>>
>>>> I don't see how that revision would break a MapGuide application,
>>>> perhaps you can explain?
>>>>
>>>> I am working on a patch for MapGuide side of things to set the
>>>> projection automatically. Ideally the MapGuide API would have a way
>>>>
>>> of
>>>
>>>> returning the EPSG code for a map and indeed it does have
>>>> $csFactory->ConvertWktToEpsgCode($srs), however I am getting an error
>>>> whenever I try to use that "Could not convert to EPSG code from WKT".
>>>> It
>>>> is for this reason that I put support for that in the Map extension
>>>> element in AppDef. If you can point to a better way of informing the
>>>> client about the EPSG code for the map I would be happy to hear it.
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>> Andreas Morf wrote:
>>>>
>>>>> With rev. 1907 Mike added projection support to fusion - this
>>>>>
>>> screwed
>>>
>>>>> up my fusion app where I use projected coordinates (swiss grid):
>>>>>
>>> the
>>>
>>>>> oMapOL was set to default value EPSG:4326 which was the source of
>>>>> malfunction.
>>>>>
>>>>> I normally set the CRS in my MG-mapdefinition and I don't want to
>>>>>
>>> set
>>>
>>>>> it again in fusion and additionally provide a EPSGxy.js ().
>>>>>
>>> Shouldn't
>>>
>>>>> fusion read out CRS-def from MG-server mapdef for the actual map
>>>>>
>>> and
>>>
>>>>> use that for client-side calculations?
>>>>>
>>>>> IMHO 1907 looks a bit like a quick and dirty fix for mapserver
>>>>> concerns - the whole matter shoud be discussed an planned from
>>>>>
>>> ground
>>>
>>>>> up (RFC?).
>>>>>
>>>>> Greets, Andreas
>>>>>
>>>>> -------------------------------------------------------------------
>>>>>
>>> --
>>>
>>>> ---
>>>>
>>>>> _______________________________________________
>>>>> fusion-dev mailing list
>>>>> [hidden email]
>>>>> http://lists.osgeo.org/mailman/listinfo/fusion-dev
>>>>>
>>>>>
>>>> --
>>>>    Michael Adair
>>>>    Senior Software Architect
>>>>    DM Solutions Group Inc.
>>>>
>>>>    Office: [phone] x26
>>>>    [hidden email]
>>>>    http://www.dmsolutions.ca
>>>>    http://research.dmsolutions.ca
>>>>
>>> _______________________________________________
>>> fusion-dev mailing list
>>> [hidden email]
>>> http://lists.osgeo.org/mailman/listinfo/fusion-dev
>>>
>>
>> _______________________________________________
>> fusion-dev mailing list
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/fusion-dev
>>
>>
>
> --
>    Michael Adair
>    Senior Software Architect
>    DM Solutions Group Inc.
>
>    Office: [phone] x26
>    [hidden email]
>    http://www.dmsolutions.ca
>    http://research.dmsolutions.ca
>
>
> _______________________________________________
> fusion-dev mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/fusion-dev
>

_______________________________________________
fusion-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/fusion-dev