[MAPSERVER-DEV] feedback on possible mapserver enhancements

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[MAPSERVER-DEV] feedback on possible mapserver enhancements

tbonfort
hi list,

I'd like to have some feedback from you on these possible enhancements:

On a probably "only AGG" side:

* I'd like to add a new symbology type that can be used to create
"heat maps", as seen for example at
http://terriscope.fr/ms_tmp/heat.png . the principle is to have a
semi-transparent circular gradient around a point, and when many
points fall close together the surrounding color sums up until the max
specified color. This could be specified as
SYMBOL
 NAME 'gradient'
 TYPE GRADIENT
END

and called in a POINT layer as

STYLE
 SYMBOL 'gradient'
 COLOR r g b
 OPACITY xx  #the opacity of the center of a single symbol
 SIZE xx ## at xx distance from the point center, the symbol is fully
transparent
END

* I'd like to start implementing STYLE-level transparency - there will
be a few quirks notably in line layers where the rounded caps of
consecutive linestrings won't render correctly (they overlap therefore
the final transparency is more or less twice as what was specified),
but at least that functionality can be there for polygons and point
layers

And last but not least :
* what would you think of having a wfs-t implementation for mapserver,
probably at first limited to postgis backends, and based on the
tinyows project?

comments most welcome !

thomas
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Steve Lime
>>> On 1/30/2008 at 1:37 PM, in message
<[hidden email]>, thomas bonfort
<[hidden email]> wrote:

> hi list,
>
> I'd like to have some feedback from you on these possible enhancements:
>
> On a probably "only AGG" side:
>
> * I'd like to add a new symbology type that can be used to create
> "heat maps", as seen for example at
> http://terriscope.fr/ms_tmp/heat.png . the principle is to have a
> semi-transparent circular gradient around a point, and when many
> points fall close together the surrounding color sums up until the max
> specified color. This could be specified as
> SYMBOL
>  NAME 'gradient'
>  TYPE GRADIENT
> END
>
> and called in a POINT layer as
>
> STYLE
>  SYMBOL 'gradient'
>  COLOR r g b
>  OPACITY xx  #the opacity of the center of a single symbol
>  SIZE xx ## at xx distance from the point center, the symbol is fully
> transparent
> END

There was/is a gradient capability already. Any chance of resurrecting and fixing that
to achieve your variable opacity objective but also color transitions (red => blue)?

> * I'd like to start implementing STYLE-level transparency - there will
> be a few quirks notably in line layers where the rounded caps of
> consecutive linestrings won't render correctly (they overlap therefore
> the final transparency is more or less twice as what was specified),
> but at least that functionality can be there for polygons and point
> layers

I'd support this. We'd still have layer level transparency anyway. Is there no way that
this could also be applied in the GD environment at least on a limited basis?

Are you thinking RGBA colors or an opacity keyword at the style level?

> And last but not least :
> * what would you think of having a wfs-t implementation for mapserver,
> probably at first limited to postgis backends, and based on the
> tinyows project?

A year ago I would have said no, but several times in recent months I've had questions
from folks that seem to use WFS-T as a means of selecting their web rendering tool. It's
becoming a differentiating feature. I'm not familiar with TinyOWS though. Are you
suggesting assimilating TinyOWS?

> comments most welcome !
>
> thomas

Steve
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

tbonfort
On Jan 30, 2008 9:27 PM, Steve Lime <[hidden email]> wrote:

>
>
> >>> On 1/30/2008 at 1:37 PM, in message
> <[hidden email]>, thomas bonfort
> <[hidden email]> wrote:
> > hi list,
> >
> > I'd like to have some feedback from you on these possible enhancements:
> >
> > On a probably "only AGG" side:
> >
> > * I'd like to add a new symbology type that can be used to create
> > "heat maps", as seen for example at
> > http://terriscope.fr/ms_tmp/heat.png . the principle is to have a
> > semi-transparent circular gradient around a point, and when many
> > points fall close together the surrounding color sums up until the max
> > specified color. This could be specified as
> > SYMBOL
> >  NAME 'gradient'
> >  TYPE GRADIENT
> > END
> >
> > and called in a POINT layer as
> >
> > STYLE
> >  SYMBOL 'gradient'
> >  COLOR r g b
> >  OPACITY xx  #the opacity of the center of a single symbol
> >  SIZE xx ## at xx distance from the point center, the symbol is fully
> > transparent
> > END
>
> There was/is a gradient capability already. Any chance of resurrecting and fixing that
> to achieve your variable opacity objective but also color transitions (red => blue)?

are you referring to the colorrange item with mincolor/maxcolor? If so
I looked into that, but we're missing the keywords to specify the
opacity.

>
> > * I'd like to start implementing STYLE-level transparency - there will
> > be a few quirks notably in line layers where the rounded caps of
> > consecutive linestrings won't render correctly (they overlap therefore
> > the final transparency is more or less twice as what was specified),
> > but at least that functionality can be there for polygons and point
> > layers
>
> I'd support this. We'd still have layer level transparency anyway. Is there no way that
> this could also be applied in the GD environment at least on a limited basis?
>
> Are you thinking RGBA colors or an opacity keyword at the style level?

I was thinking opacity at the style level. I'll have a look at what
could be done on the gd side.

>
> > And last but not least :
> > * what would you think of having a wfs-t implementation for mapserver,
> > probably at first limited to postgis backends, and based on the
> > tinyows project?
>
> A year ago I would have said no, but several times in recent months I've had questions
> from folks that seem to use WFS-T as a means of selecting their web rendering tool. It's
> becoming a differentiating feature. I'm not familiar with TinyOWS though. Are you
> suggesting assimilating TinyOWS?

the advantage of this would be to avoid having to deploy another
server along side mapserver in order to treat the wfs-t side of an
application,as you pointed out. in finality it would mean porting of
the tinyows code into mapserver.

>
> > comments most welcome !
> >
> > thomas
>
> Steve
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Daniel Morissette
thomas bonfort wrote:

>>> And last but not least :
>>> * what would you think of having a wfs-t implementation for mapserver,
>>> probably at first limited to postgis backends, and based on the
>>> tinyows project?
>> A year ago I would have said no, but several times in recent months I've had questions
>> from folks that seem to use WFS-T as a means of selecting their web rendering tool. It's
>> becoming a differentiating feature. I'm not familiar with TinyOWS though. Are you
>> suggesting assimilating TinyOWS?
>
> the advantage of this would be to avoid having to deploy another
> server along side mapserver in order to treat the wfs-t side of an
> application,as you pointed out. in finality it would mean porting of
> the tinyows code into mapserver.
>

There is so much demand for WFS-T by our users that I am slowly giving
up and starting to think that we may have to do WFS-T in the end. Please
don't tell anyone that I wrote that. ;) ;)

I am not sure about integrating TinyOWS code... I have never looked at
TinyOWS, but wouldn't a simple merge be messy? How would that fit with
existing mapwfs.c code? Could we not just extend the current
implementation (and make the necessary architecture changes) to support
transactions?

Daniel
--
Daniel Morissette
http://www.mapgears.com/
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Kralidis,Tom [Ontario]
 

> -----Original Message-----
> From: UMN MapServer Developers List
> [mailto:[hidden email]] On Behalf Of Daniel Morissette
> Sent: 04 February, 2008 12:16 PM
> To: [hidden email]
> Subject: Re: [MAPSERVER-DEV] feedback on possible mapserver
> enhancements
>
> thomas bonfort wrote:
> >>> And last but not least :
> >>> * what would you think of having a wfs-t implementation for
> >>> mapserver, probably at first limited to postgis backends,
> and based
> >>> on the tinyows project?
> >> A year ago I would have said no, but several times in
> recent months
> >> I've had questions from folks that seem to use WFS-T as a means of
> >> selecting their web rendering tool. It's becoming a
> differentiating
> >> feature. I'm not familiar with TinyOWS though. Are you
> suggesting assimilating TinyOWS?
> >
> > the advantage of this would be to avoid having to deploy another
> > server along side mapserver in order to treat the wfs-t side of an
> > application,as you pointed out. in finality it would mean
> porting of
> > the tinyows code into mapserver.
> >
>
> There is so much demand for WFS-T by our users that I am
> slowly giving up and starting to think that we may have to do
> WFS-T in the end. Please don't tell anyone that I wrote that. ;) ;)
>

Yes! :)

> I am not sure about integrating TinyOWS code... I have never
> looked at TinyOWS, but wouldn't a simple merge be messy? How
> would that fit with existing mapwfs.c code? Could we not just
> extend the current implementation (and make the necessary
> architecture changes) to support transactions?
>

I think extending mapwfs.c with optional transaction would be preferred,
IMHO.  Assefa and I discussed this awhile back and mapwfs.c we would
need mapwfs.c to handle the messaging and (maybe) maptransaction.c to
take care of the lower level stuff (and thus make it available to other
interfaces if / when).  Specifying transactional support could either be
thrown as a ./configure flag, or a metadata value, depending.

..Tom
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Steve Lime
I'd like to hear feedback from the folks at camptocamp...

Steve

>>> On 2/4/2008 at 11:27 AM, in message
<[hidden email]>,
"Kralidis,Tom [Burlington]" <[hidden email]> wrote:

>
>> -----Original Message-----
>> From: UMN MapServer Developers List
>> [mailto:[hidden email]] On Behalf Of Daniel Morissette
>> Sent: 04 February, 2008 12:16 PM
>> To: [hidden email]
>> Subject: Re: [MAPSERVER-DEV] feedback on possible mapserver
>> enhancements
>>
>> thomas bonfort wrote:
>> >>> And last but not least :
>> >>> * what would you think of having a wfs-t implementation for
>> >>> mapserver, probably at first limited to postgis backends,
>> and based
>> >>> on the tinyows project?
>> >> A year ago I would have said no, but several times in
>> recent months
>> >> I've had questions from folks that seem to use WFS-T as a means of
>> >> selecting their web rendering tool. It's becoming a
>> differentiating
>> >> feature. I'm not familiar with TinyOWS though. Are you
>> suggesting assimilating TinyOWS?
>> >
>> > the advantage of this would be to avoid having to deploy another
>> > server along side mapserver in order to treat the wfs-t side of an
>> > application,as you pointed out. in finality it would mean
>> porting of
>> > the tinyows code into mapserver.
>> >
>>
>> There is so much demand for WFS-T by our users that I am
>> slowly giving up and starting to think that we may have to do
>> WFS-T in the end. Please don't tell anyone that I wrote that. ;) ;)
>>
>
> Yes! :)
>
>> I am not sure about integrating TinyOWS code... I have never
>> looked at TinyOWS, but wouldn't a simple merge be messy? How
>> would that fit with existing mapwfs.c code? Could we not just
>> extend the current implementation (and make the necessary
>> architecture changes) to support transactions?
>>
>
> I think extending mapwfs.c with optional transaction would be preferred,
> IMHO.  Assefa and I discussed this awhile back and mapwfs.c we would
> need mapwfs.c to handle the messaging and (maybe) maptransaction.c to
> take care of the lower level stuff (and thus make it available to other
> interfaces if / when).  Specifying transactional support could either be
> thrown as a ./configure flag, or a metadata value, depending.
>
> ..Tom
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Howard Butler
In reply to this post by Daniel Morissette
On Feb 4, 2008, at 11:15 AM, Daniel Morissette wrote:

> thomas bonfort wrote:
>>>> And last but not least :
>>>> * what would you think of having a wfs-t implementation for  
>>>> mapserver,
>>>> probably at first limited to postgis backends, and based on the
>>>> tinyows project?
>>> A year ago I would have said no, but several times in recent  
>>> months I've had questions
>>> from folks that seem to use WFS-T as a means of selecting their  
>>> web rendering tool. It's
>>> becoming a differentiating feature. I'm not familiar with TinyOWS  
>>> though. Are you
>>> suggesting assimilating TinyOWS?
>> the advantage of this would be to avoid having to deploy another
>> server along side mapserver in order to treat the wfs-t side of an
>> application,as you pointed out. in finality it would mean porting of
>> the tinyows code into mapserver.
>
> There is so much demand for WFS-T by our users that I am slowly  
> giving up and starting to think that we may have to do WFS-T in the  
> end. Please don't tell anyone that I wrote that. ;) ;)
>
> I am not sure about integrating TinyOWS code... I have never looked  
> at TinyOWS, but wouldn't a simple merge be messy? How would that fit  
> with existing mapwfs.c code? Could we not just extend the current  
> implementation (and make the necessary architecture changes) to  
> support transactions?


MapServer is not a GIS!  MapServer is not a GIS!  I am not supportive  
at all of implementing WFS-T in MapServer.  What benefit is there to  
be gained by doing so that can't be accomplished by setting up a  
GeoServer instance alongside MapServer?  IMO, it is the best-of-breed  
open source WFS-T that's out there, with tons of momentum and  
development force behind it -- why go to the trouble to re-implement  
it in MapServer?

Technically, one challenge I see for MapServer implementing WFS-T is  
that MapServer apps generally expect to be transient and stateless.  
MapServer does not do well in long running processes (any MapScripter  
who's tried can give you gobs of complaints about this), and it has no  
concept of transactional operations which I think would be very  
challenging to bolt on in any smooth sort of way.

IMO, MapServer should continue to improve upon what it is good at, and  
WFS-T is not something that I think it would be good at without a lot  
of re-engineering (we hate churn, remember?).  With some effort, we  
could have something workable and maybe even functional, but it will  
get nowhere close to what GeoServer has.

Howard
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Kralidis,Tom [Ontario]
 

> -----Original Message-----
> From: UMN MapServer Developers List
> [mailto:[hidden email]] On Behalf Of Howard Butler
> Sent: 04 February, 2008 12:49 PM
> To: [hidden email]
> Subject: Re: [MAPSERVER-DEV] feedback on possible mapserver
> enhancements
>
> On Feb 4, 2008, at 11:15 AM, Daniel Morissette wrote:
>
> > thomas bonfort wrote:
> >>>> And last but not least :
> >>>> * what would you think of having a wfs-t implementation for
> >>>> mapserver, probably at first limited to postgis
> backends, and based
> >>>> on the tinyows project?
> >>> A year ago I would have said no, but several times in
> recent months
> >>> I've had questions from folks that seem to use WFS-T as a
> means of
> >>> selecting their web rendering tool. It's becoming a
> differentiating
> >>> feature. I'm not familiar with TinyOWS though. Are you suggesting
> >>> assimilating TinyOWS?
> >> the advantage of this would be to avoid having to deploy another
> >> server along side mapserver in order to treat the wfs-t side of an
> >> application,as you pointed out. in finality it would mean
> porting of
> >> the tinyows code into mapserver.
> >
> > There is so much demand for WFS-T by our users that I am
> slowly giving
> > up and starting to think that we may have to do WFS-T in the end.
> > Please don't tell anyone that I wrote that. ;) ;)
> >
> > I am not sure about integrating TinyOWS code... I have
> never looked at
> > TinyOWS, but wouldn't a simple merge be messy? How would
> that fit with
> > existing mapwfs.c code? Could we not just extend the current
> > implementation (and make the necessary architecture changes) to
> > support transactions?
>
>
> MapServer is not a GIS!  MapServer is not a GIS!  I am not
> supportive at all of implementing WFS-T in MapServer.  What
> benefit is there to be gained by doing so that can't be
> accomplished by setting up a GeoServer instance alongside
> MapServer?  IMO, it is the best-of-breed open source WFS-T
> that's out there, with tons of momentum and development force
> behind it -- why go to the trouble to re-implement it in MapServer?
>
> Technically, one challenge I see for MapServer implementing WFS-T is  
> that MapServer apps generally expect to be transient and stateless.  
> MapServer does not do well in long running processes (any
> MapScripter who's tried can give you gobs of complaints about
> this), and it has no concept of transactional operations
> which I think would be very challenging to bolt on in any
> smooth sort of way.
>
> IMO, MapServer should continue to improve upon what it is
> good at, and WFS-T is not something that I think it would be
> good at without a lot of re-engineering (we hate churn,
> remember?).  With some effort, we could have something
> workable and maybe even functional, but it will get nowhere
> close to what GeoServer has.
>

Wouldn't it be great if MapServer and GeoServer worked off similar
configurations?

..Tom
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Steve Lime
In reply to this post by Howard Butler
Users don't seem to buy the install 'em both argument. I think for the real basic use
of WFS-T folks ask why should they bother. So, even basic support for one data
provider (e.g. PostGIS) may well meet 90% of the demand. Perhaps those folks should
be steered towards feature server...

Personally I have little or no interest in working on WFS-T but if someone else does
and it doesn't impact other areas of the code then it's worth the debate. Integration
of an existing solution, providing it's viable, makes the most sense to me. It would be
somewhat compartmentalized so would likely need little re-engineering.

Steve

>>> On 2/4/2008 at 11:49 AM, in message
<[hidden email]>, Howard Butler
<[hidden email]> wrote:

> On Feb 4, 2008, at 11:15 AM, Daniel Morissette wrote:
>
>> thomas bonfort wrote:
>>>>> And last but not least :
>>>>> * what would you think of having a wfs-t implementation for  
>>>>> mapserver,
>>>>> probably at first limited to postgis backends, and based on the
>>>>> tinyows project?
>>>> A year ago I would have said no, but several times in recent  
>>>> months I've had questions
>>>> from folks that seem to use WFS-T as a means of selecting their  
>>>> web rendering tool. It's
>>>> becoming a differentiating feature. I'm not familiar with TinyOWS  
>>>> though. Are you
>>>> suggesting assimilating TinyOWS?
>>> the advantage of this would be to avoid having to deploy another
>>> server along side mapserver in order to treat the wfs-t side of an
>>> application,as you pointed out. in finality it would mean porting of
>>> the tinyows code into mapserver.
>>
>> There is so much demand for WFS-T by our users that I am slowly  
>> giving up and starting to think that we may have to do WFS-T in the  
>> end. Please don't tell anyone that I wrote that. ;) ;)
>>
>> I am not sure about integrating TinyOWS code... I have never looked  
>> at TinyOWS, but wouldn't a simple merge be messy? How would that fit  
>> with existing mapwfs.c code? Could we not just extend the current  
>> implementation (and make the necessary architecture changes) to  
>> support transactions?
>
>
> MapServer is not a GIS!  MapServer is not a GIS!  I am not supportive  
> at all of implementing WFS-T in MapServer.  What benefit is there to  
> be gained by doing so that can't be accomplished by setting up a  
> GeoServer instance alongside MapServer?  IMO, it is the best-of-breed  
> open source WFS-T that's out there, with tons of momentum and  
> development force behind it -- why go to the trouble to re-implement  
> it in MapServer?
>
> Technically, one challenge I see for MapServer implementing WFS-T is  
> that MapServer apps generally expect to be transient and stateless.  
> MapServer does not do well in long running processes (any MapScripter  
> who's tried can give you gobs of complaints about this), and it has no  
> concept of transactional operations which I think would be very  
> challenging to bolt on in any smooth sort of way.
>
> IMO, MapServer should continue to improve upon what it is good at, and  
> WFS-T is not something that I think it would be good at without a lot  
> of re-engineering (we hate churn, remember?).  With some effort, we  
> could have something workable and maybe even functional, but it will  
> get nowhere close to what GeoServer has.
>
> Howard
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Perry Nacionales
In reply to this post by Howard Butler
Howard Butler wrote:

> On Feb 4, 2008, at 11:15 AM, Daniel Morissette wrote:
>
>> thomas bonfort wrote:
>>>>> And last but not least :
>>>>> * what would you think of having a wfs-t implementation for
>>>>> mapserver,
>>>>> probably at first limited to postgis backends, and based on the
>>>>> tinyows project?
>>>> A year ago I would have said no, but several times in recent months
>>>> I've had questions
>>>> from folks that seem to use WFS-T as a means of selecting their web
>>>> rendering tool. It's
>>>> becoming a differentiating feature. I'm not familiar with TinyOWS
>>>> though. Are you
>>>> suggesting assimilating TinyOWS?
>>> the advantage of this would be to avoid having to deploy another
>>> server along side mapserver in order to treat the wfs-t side of an
>>> application,as you pointed out. in finality it would mean porting of
>>> the tinyows code into mapserver.
>>
>> There is so much demand for WFS-T by our users that I am slowly
>> giving up and starting to think that we may have to do WFS-T in the
>> end. Please don't tell anyone that I wrote that. ;) ;)
>>
>> I am not sure about integrating TinyOWS code... I have never looked
>> at TinyOWS, but wouldn't a simple merge be messy? How would that fit
>> with existing mapwfs.c code? Could we not just extend the current
>> implementation (and make the necessary architecture changes) to
>> support transactions?
>
>
> MapServer is not a GIS!  MapServer is not a GIS!  I am not supportive
> at all of implementing WFS-T in MapServer.  What benefit is there to
> be gained by doing so that can't be accomplished by setting up a
> GeoServer instance alongside MapServer?  IMO, it is the best-of-breed
> open source WFS-T that's out there, with tons of momentum and
> development force behind it -- why go to the trouble to re-implement
> it in MapServer?
>
> Technically, one challenge I see for MapServer implementing WFS-T is
> that MapServer apps generally expect to be transient and stateless.  
> MapServer does not do well in long running processes (any MapScripter
> who's tried can give you gobs of complaints about this), and it has no
> concept of transactional operations which I think would be very
> challenging to bolt on in any smooth sort of way.
>
> IMO, MapServer should continue to improve upon what it is good at, and
> WFS-T is not something that I think it would be good at without a lot
> of re-engineering (we hate churn, remember?).  With some effort, we
> could have something workable and maybe even functional, but it will
> get nowhere close to what GeoServer has.
My $0.02...  I agree that MapServer is not a GIS.  But adding a WFS-T
support still doesn't make MapServer a GIS.  ...maybe one step closer.
:)  Also, what's the point for a user to install GeoServer and MapServer
when GeoServer can do what MapServer does?  Won't you agree that
MapServer loses out in that scenario?  I doubt many users would want to
install both and manage all those configuration files.  I also agree
that it would be a technical challenge to add WFS-T support in MapServer
but having TinyOWS code already available for review/merge should help
some in that regard.

If WFS-T is to be supported--and I support the idea--it should be
optional and that it should not have a drastic effect on MapServer's
rendering performance.

-Perry
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Arnulf Christl (OSGeo)
Pericles S. Nacionales wrote:

> Howard Butler wrote:
>> On Feb 4, 2008, at 11:15 AM, Daniel Morissette wrote:
>>
>>> thomas bonfort wrote:
>>>>>> And last but not least :
>>>>>> * what would you think of having a wfs-t implementation for
>>>>>> mapserver,
>>>>>> probably at first limited to postgis backends, and based on the
>>>>>> tinyows project?
>>>>> A year ago I would have said no, but several times in recent months
>>>>> I've had questions
>>>>> from folks that seem to use WFS-T as a means of selecting their web
>>>>> rendering tool. It's
>>>>> becoming a differentiating feature. I'm not familiar with TinyOWS
>>>>> though. Are you
>>>>> suggesting assimilating TinyOWS?
>>>> the advantage of this would be to avoid having to deploy another
>>>> server along side mapserver in order to treat the wfs-t side of an
>>>> application,as you pointed out. in finality it would mean porting of
>>>> the tinyows code into mapserver.
>>>
>>> There is so much demand for WFS-T by our users that I am slowly
>>> giving up and starting to think that we may have to do WFS-T in the
>>> end. Please don't tell anyone that I wrote that. ;) ;)
>>>
>>> I am not sure about integrating TinyOWS code... I have never looked
>>> at TinyOWS, but wouldn't a simple merge be messy? How would that fit
>>> with existing mapwfs.c code? Could we not just extend the current
>>> implementation (and make the necessary architecture changes) to
>>> support transactions?
>>
>>
>> MapServer is not a GIS!  MapServer is not a GIS!  I am not supportive
>> at all of implementing WFS-T in MapServer.  What benefit is there to
>> be gained by doing so that can't be accomplished by setting up a
>> GeoServer instance alongside MapServer?  IMO, it is the best-of-breed
>> open source WFS-T that's out there, with tons of momentum and
>> development force behind it -- why go to the trouble to re-implement
>> it in MapServer?
>>
>> Technically, one challenge I see for MapServer implementing WFS-T is
>> that MapServer apps generally expect to be transient and stateless.  
>> MapServer does not do well in long running processes (any MapScripter
>> who's tried can give you gobs of complaints about this), and it has no
>> concept of transactional operations which I think would be very
>> challenging to bolt on in any smooth sort of way.
>>
>> IMO, MapServer should continue to improve upon what it is good at, and
>> WFS-T is not something that I think it would be good at without a lot
>> of re-engineering (we hate churn, remember?).  With some effort, we
>> could have something workable and maybe even functional, but it will
>> get nowhere close to what GeoServer has.
> My $0.02...  I agree that MapServer is not a GIS.  But adding a WFS-T
> support still doesn't make MapServer a GIS.  ...maybe one step closer.
> :)  Also, what's the point for a user to install GeoServer and MapServer
> when GeoServer can do what MapServer does?  Won't you agree that
> MapServer loses out in that scenario?  I doubt many users would want to
> install both and manage all those configuration files.  I also agree
> that it would be a technical challenge to add WFS-T support in MapServer
> but having TinyOWS code already available for review/merge should help
> some in that regard.
>
> If WFS-T is to be supported--and I support the idea--it should be
> optional and that it should not have a drastic effect on MapServer's
> rendering performance.
>
> -Perry

Hello,
if I may interject... Why don't you include a simple transactional RESTful WFS? That way you can stay stateless which was one of the major issues iirc. I think Sean Gillies or Chris Schmidt were doing some experiments (I can look up the links if it is of interest). This would give people a quick alternative to get going. I doubt that we really need a full fledged WFS-T with all the related problems.

Having MapServer and GeoServer in one infrastructure is good for us consultants and is appropriate for large infrastructures running on several distributed machines. But it is a pain to have to maintain a CGI interface and a servlet container and to plunge into a full fledged GeoServer if all you want is to do is write back a few point coordinates. (/me runs for cover...)

Best regards,
Arnulf.
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Steve Lime
In reply to this post by tbonfort
Good suggestions Arnulf. I too think a WFS-T-lite makes good sense.

Steve
 
>>> Arnulf Christl <[hidden email]> 02/05/08 9:08 AM >>>
Pericles S. Nacionales wrote:

> Howard Butler wrote:
>> On Feb 4, 2008, at 11:15 AM, Daniel Morissette wrote:
>>
>>> thomas bonfort wrote:
>>>>>> And last but not least :
>>>>>> * what would you think of having a wfs-t implementation for
>>>>>> mapserver,
>>>>>> probably at first limited to postgis backends, and based on the
>>>>>> tinyows project?
>>>>> A year ago I would have said no, but several times in recent months
>>>>> I've had questions
>>>>> from folks that seem to use WFS-T as a means of selecting their web
>>>>> rendering tool. It's
>>>>> becoming a differentiating feature. I'm not familiar with TinyOWS
>>>>> though. Are you
>>>>> suggesting assimilating TinyOWS?
>>>> the advantage of this would be to avoid having to deploy another
>>>> server along side mapserver in order to treat the wfs-t side of an
>>>> application,as you pointed out. in finality it would mean porting of
>>>> the tinyows code into mapserver.
>>>
>>> There is so much demand for WFS-T by our users that I am slowly
>>> giving up and starting to think that we may have to do WFS-T in the
>>> end. Please don't tell anyone that I wrote that. ;) ;)
>>>
>>> I am not sure about integrating TinyOWS code... I have never looked
>>> at TinyOWS, but wouldn't a simple merge be messy? How would that fit
>>> with existing mapwfs.c code? Could we not just extend the current
>>> implementation (and make the necessary architecture changes) to
>>> support transactions?
>>
>>
>> MapServer is not a GIS!  MapServer is not a GIS!  I am not supportive
>> at all of implementing WFS-T in MapServer.  What benefit is there to
>> be gained by doing so that can't be accomplished by setting up a
>> GeoServer instance alongside MapServer?  IMO, it is the best-of-breed
>> open source WFS-T that's out there, with tons of momentum and
>> development force behind it -- why go to the trouble to re-implement
>> it in MapServer?
>>
>> Technically, one challenge I see for MapServer implementing WFS-T is
>> that MapServer apps generally expect to be transient and stateless.  
>> MapServer does not do well in long running processes (any MapScripter
>> who's tried can give you gobs of complaints about this), and it has no
>> concept of transactional operations which I think would be very
>> challenging to bolt on in any smooth sort of way.
>>
>> IMO, MapServer should continue to improve upon what it is good at, and
>> WFS-T is not something that I think it would be good at without a lot
>> of re-engineering (we hate churn, remember?).  With some effort, we
>> could have something workable and maybe even functional, but it will
>> get nowhere close to what GeoServer has.
> My $0.02...  I agree that MapServer is not a GIS.  But adding a WFS-T
> support still doesn't make MapServer a GIS.  ...maybe one step closer.
> :)  Also, what's the point for a user to install GeoServer and MapServer
> when GeoServer can do what MapServer does?  Won't you agree that
> MapServer loses out in that scenario?  I doubt many users would want to
> install both and manage all those configuration files.  I also agree
> that it would be a technical challenge to add WFS-T support in MapServer
> but having TinyOWS code already available for review/merge should help
> some in that regard.
>
> If WFS-T is to be supported--and I support the idea--it should be
> optional and that it should not have a drastic effect on MapServer's
> rendering performance.
>
> -Perry

Hello,
if I may interject... Why don't you include a simple transactional RESTful WFS? That way you can stay stateless which was one of the major issues iirc. I think Sean Gillies or Chris Schmidt were doing some experiments (I can look up the links if it is of interest). This would give people a quick alternative to get going. I doubt that we really need a full fledged WFS-T with all the related problems.

Having MapServer and GeoServer in one infrastructure is good for us consultants and is appropriate for large infrastructures running on several distributed machines. But it is a pain to have to maintain a CGI interface and a servlet container and to plunge into a full fledged GeoServer if all you want is to do is write back a few point coordinates. (/me runs for cover...)

Best regards,
Arnulf.
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Daniel Morissette
Steve Lime wrote:
> Good suggestions Arnulf. I too think a WFS-T-lite makes good sense.
>

Without having done much research, I like that idea as well.

Daniel
--
Daniel Morissette
http://www.mapgears.com/
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Stephen Woodbridge
Daniel Morissette wrote:
> Steve Lime wrote:
>> Good suggestions Arnulf. I too think a WFS-T-lite makes good sense.
>
> Without having done much research, I like that idea as well.
>
> Daniel

I would like to add my +1 to having some type of WFS-T support within
mapserver.

My basic use-case would be something like using OpenLayers with
mapserver serving images, and want to be able to support simple point,
line, polygon, box, circle like objects that can be displayed, created,
edited using OpenLayers vector support, and saved these back to a
postgis database? without the need to install and manage any additional
major applications, like geoserver, featureserver, etc.

my $0.02,
   -Steve W
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Howard Butler
On Feb 5, 2008, at 1:24 PM, Stephen Woodbridge wrote:

> Daniel Morissette wrote:
>> Steve Lime wrote:
>>> Good suggestions Arnulf. I too think a WFS-T-lite makes good sense.
>> Without having done much research, I like that idea as well.
>> Daniel
>
> I would like to add my +1 to having some type of WFS-T support  
> within mapserver.
>
> My basic use-case would be something like using OpenLayers with  
> mapserver serving images, and want to be able to support simple  
> point, line, polygon, box, circle like objects that can be  
> displayed, created, edited using OpenLayers vector support, and  
> saved these back to a postgis database?


> without the need to install and manage any additional major  
> applications, like geoserver, featureserver, etc.


This seems totally silly to me.  FeatureServer is a simple cgi  
application just like MapServer.  Drop it in your cgi directory, tweak  
a configuration (mapfile), and be on your way.  No code to write and  
no datasource limitations (MapServer's wfs-t likely will only support  
one or two drivers, not all).   In fact, you can do this right now  
without compiling *a thing*.

What is the driving factor for having WFS-T in MapServer?  Is there a  
funder with some really, really deep pockets and strong commitment to  
make it happen?  Is it a "gee, that would be nice" sort of feature  
with a couple of folks musing and a tiny bit of funding to take a  
crack at something?  Is it really related to the fact that you can't  
share configuration between MapServer and any other application server  
in the GFOSS domain and people want simple/single configuration ability?

MapServer has no history of doing anything like WFS-T AFAIK.  We don't  
do schema validation, we serialize GML with printf for chrissakes, and  
we don't have consistent behavior of our data drivers.  I'm not at all  
convinced that we can do right with WFS-T and end up with something  
that's less than a PITA of installing another software that is  
designed from the ground up to be doing WFS-T.  Use the right tool for  
the job is many folks' mantra, and IMO, MapServer isn't going to be  
the right tool for this job even with WFS-T-lite.

I'll gladly eat crow and wait to be proven wrong when MapServer comes  
out with a bulletproof and complete WFS-T implementation that  
interoperates with everybody and shines as *the* reference  
implementation of such a thing.  GeoServer has *years* of development  
invested in WFS-T.  Are we prepared to do the same?

Howard
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Christopher Schmidt-2
In reply to this post by Stephen Woodbridge
On Tue, Feb 05, 2008 at 02:24:13PM -0500, Stephen Woodbridge wrote:

> Daniel Morissette wrote:
> >Steve Lime wrote:
> >>Good suggestions Arnulf. I too think a WFS-T-lite makes good sense.
> >
> >Without having done much research, I like that idea as well.
> >
> >Daniel
>
> I would like to add my +1 to having some type of WFS-T support within
> mapserver.
>
> My basic use-case would be something like using OpenLayers with
> mapserver serving images, and want to be able to support simple point,
> line, polygon, box, circle like objects that can be displayed, created,
> edited using OpenLayers vector support, and saved these back to a
> postgis database? without the need to install and manage any additional
> major applications, like geoserver, featureserver, etc.

Note that WFS-T doesn't get you this: OpenLayers has no support for
writing modified data out as WFS-T by default. (Also note that
FeatureServer has no support for WFS-T, because it's extremely complex
in comparison to serving data as WFS.)

Regards,
--
Christopher Schmidt
MetaCarta
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Christopher Schmidt-2
In reply to this post by Howard Butler
On Tue, Feb 05, 2008 at 01:46:57PM -0600, Howard Butler wrote:
> I'll gladly eat crow and wait to be proven wrong when MapServer comes  
> out with a bulletproof and complete WFS-T implementation that  
> interoperates with everybody and shines as *the* reference  
> implementation of such a thing.  GeoServer has *years* of development  
> invested in WFS-T.  Are we prepared to do the same?

 + many more than 1

(Also, note that FeatureServer is unlikely to ever implement WFS-T, for
exactly this reason: If you want WFS-T, use GeoServer, damnit.)

Regards,
--
Christopher Schmidt
MetaCarta
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Steve Lime
In reply to this post by Christopher Schmidt-2
Maybe folks just want some FeatureServer-like functionality... (yes, I know that's already been written too)

Steve

>>> On 2/5/2008 at 1:56 PM, in message <[hidden email]>,
Christopher Schmidt <[hidden email]> wrote:

> On Tue, Feb 05, 2008 at 02:24:13PM -0500, Stephen Woodbridge wrote:
>> Daniel Morissette wrote:
>> >Steve Lime wrote:
>> >>Good suggestions Arnulf. I too think a WFS-T-lite makes good sense.
>> >
>> >Without having done much research, I like that idea as well.
>> >
>> >Daniel
>>
>> I would like to add my +1 to having some type of WFS-T support within
>> mapserver.
>>
>> My basic use-case would be something like using OpenLayers with
>> mapserver serving images, and want to be able to support simple point,
>> line, polygon, box, circle like objects that can be displayed, created,
>> edited using OpenLayers vector support, and saved these back to a
>> postgis database? without the need to install and manage any additional
>> major applications, like geoserver, featureserver, etc.
>
> Note that WFS-T doesn't get you this: OpenLayers has no support for
> writing modified data out as WFS-T by default. (Also note that
> FeatureServer has no support for WFS-T, because it's extremely complex
> in comparison to serving data as WFS.)
>
> Regards,
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Stephen Woodbridge
In reply to this post by Christopher Schmidt-2
Christopher Schmidt wrote:

> On Tue, Feb 05, 2008 at 02:24:13PM -0500, Stephen Woodbridge wrote:
>> Daniel Morissette wrote:
>>> Steve Lime wrote:
>>>> Good suggestions Arnulf. I too think a WFS-T-lite makes good sense.
>>> Without having done much research, I like that idea as well.
>>>
>>> Daniel
>> I would like to add my +1 to having some type of WFS-T support within
>> mapserver.
>>
>> My basic use-case would be something like using OpenLayers with
>> mapserver serving images, and want to be able to support simple point,
>> line, polygon, box, circle like objects that can be displayed, created,
>> edited using OpenLayers vector support, and saved these back to a
>> postgis database? without the need to install and manage any additional
>> major applications, like geoserver, featureserver, etc.
>
> Note that WFS-T doesn't get you this: OpenLayers has no support for
> writing modified data out as WFS-T by default. (Also note that
> FeatureServer has no support for WFS-T, because it's extremely complex
> in comparison to serving data as WFS.)
>
> Regards,

Ok, Thanks I have learned something about featureserver and OpenLayers.

The driver is trying to keep client installation simple. The more
packages and applications that need to be loaded on a webserver makes it
much harder to sell the installation. If a client is not using python or
java or tomcat, etc then you need to justify adding any of that into
their infrastructure. Production sites are pretty locked down.

So, I stand by my use-case with the possible modification that maybe it
doesn't need to be WFS-T.

What are the other use-cases that people are looking at that started
this discussion. Maybe we should be looking at them before discussing
technical solutions.

-Steve W
Reply | Threaded
Open this post in threaded view
|

Re: [MAPSERVER-DEV] feedback on possible mapserver enhancements

Christopher Schmidt-2
In reply to this post by Steve Lime
On Tue, Feb 05, 2008 at 02:30:12PM -0600, Steve Lime wrote:
> Maybe folks just want some FeatureServer-like functionality... (yes, I know that's already been written too)

If they just want FeatureServer-like functionality, it's likely that
they should be looking at something like-FeatureServer.

Is there a cost to installing FeatureServer? Yes.
Is there a cost to developing Feature Updating Services in MapServer?
Absolutely.

I don't think we have a strong enough idea of what users actually want
from updating features in MapServer to understand whether the total cost
on users of installing FeatureServer is more or less expensive than the
total costs of modifying MapServer to do it.

I think that, based on my (admittedly limited) understanding of
MapServer's internals, developing Feature updating support is unlikely
to be a seamless integration. The reason for this is that MapServer
supports multiple different vector providers (as I understand it): there
is 'built in' support for Shapefiles and PostGIS, as well as support for
'external' vectors via OGR. I believe that MapServer does have an
internal representation of features -- but how do you take thosoe
features and update a PostGIS layer where the CONNECTION string is based
on a subselect? Can you really know that you have enough information to
update the datasource without it being specifically configured for
updates... and if the user has to learn a lot to configure MapServer to
do this updating, is that really lower cost than installing
FeatureServer (which really only requires Python)?

The cost of building something like FeatureServer in C is high -- this
is why it's written in Python in the first place. Reading in GML --
especially when people expect to be able to throw random crap at you --
is possibly hard, and ensuring that it fits a schema may be harder, etc.

FeatureServer has survived through this becasue:
 1. It's specialized. Since the entire framework is written with the
    challenges of the problem in mind, it's well-suited to the solving
    the problem: there is nothing like a subselect-query from
    FeatureServer, because that's not something you can update.
 
 2. It's easy to hack to bits when something doesn't work: Python is way
    more hackable than C, so I've been able to hack it apart
    significantly in order to change support for just the PostGIS
    provider (for example).

 3. The abstraction barrier between datasources and output is well defined.
     Everything is super-seperated, and the end result is that
     DataSources have no knowledge of the formats that features are in.
     This is a problem for implementing WFS-T, for example, because
     information in WFS-T isn't passed along in the feature model of
     FeatureServer (because it's solving a different problem).

All these things allow FeatureServer to be much more quick to respond to
problems with specific setups -- and also lead to a situation where
MapServer is not (based on my understanding) in a suitable flexible
position to be able to implement the types of actions that are being
discussed.

I'm interested in understanding why FeatureServer is so much more
difficult than MapServer to get installed: It seems to me like it would
be easier to set up FeatureServer in almost any environment than
MapServer would be, but maybe I'm not understanding something. Perhaps
attacking that problem, if it exists, would reduce the feeling of a need
for FeatureServer-like access to MapServer.

FeatureServer is about Serving Features. MapServer is about serving
*maps*, and anything that isn't about *serving maps* should perhaps be
considered strongly before too many people get in a rush to change the
situation. There's a lot of differences between something like
FeatureServer and MapServer which make the fundamental development cost
seriously different between the two libraries, and it seems to me that
perhaps there are other problems that it would make more sense to solve
in MapServer while addressing the need to make select/update/modify/delete
of features more easy seperately.

Regards,
--
Christopher Schmidt
MetaCarta
12