[Geoserver-devel] Some feedback from my recent GeoServer course

[Andrea_Aime3]

Hi,
so this week I've been in Lugano making a GeoServer course.

The class was small but the average student had minimum
a deegree, more than half had a PhD or were still working
in a research institute. Most of them did not have a previous
open source GIS usage experience, and all of them were
ArcGis power users but had no real experience with
nitty gritty details about http, xml, command line and
all that stuff that we take for granted, but that is
obscure to the rest of the world.

Coming from a point and click GUI background being thrown
in the GeoServer env was painful for them,
and for a number of reasons:
- no easy way to deal with the nitty gritty detail of map
   styling. Ok, you can get some way with uDig, but they
   are used to fine tune label positioning and other
   stuff for which we require hand tuning of the generated
   SLD. I had the strong impression SLD was just ok,
   even when used 100% of its power, and they are used
   to more
- no good support for hatched fills, and hatches are mandated
   by law in Europe. Yes, one can create a small transparent
   png that creates a diagonal line fill effect, but
   it's painful. Using markers would be better, but it
   simply does not work right now (e.g., use the "x"
   marker to get a cross hatch) due to bugs in the renderer.
- many little detail in the UI, such as having to type
   in shapefile paths and the like
- dealing with coverages, ArcGis builds on the fly a
   pyramid to speed up access, here you have to deal with
   command line tools such as gdal ones
- having to work with stuff that requires you to drop
   the UI and hand edit files (see security for example)
- not having a good full stack integration with desktop
   tools, and solid lack of basic functionality in those
   ("what do you mean there is no point snapping during
     editing?")
- not having an easy way to generate a WMS front end.
   They did not want a tailored front end, they just
   wanted "any" frontend that could be generated without
   knowing anything about programming
- not having an easy way to generate a WFS front end,
   as some of them had data they wanted to share,
   and to allow for download after some kind of filtering,
   but again they cannot code the f.e. by themselves

All in all the whole usage experience seemed to be
setup to torture them, as with quite some extra effort
compared to their usual workflow they could have been
able to put up a service, but the last mile (the
frontends) was not there, making all the effort
not seem worthy.

I have the impression things would have gone much
better with:
- a better UI (wicket to the rescue)
- a SLD editor geared towards web mapping, and with
   every damned feature we can pull out of it, including
   vendor options, ready to use
- a simple front end generator (list of layers,
   project, gmaps integration, wfs download of selected
   layers in the current visualized area)

If you add to this a hosting service that allows
them to forget about network issues, backups, ...
(all admin headaches) and allows them to upload
their stuff and configure it for the world to use,
well, I'd say we would have a winner for this kind
of target user.

So well, in the end, I wasn't happy about how GeoServer
fared with this target (and it's GeoServer fault imho),
but I'm hopeful that if we want, we can make it better.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[jive]

Hey Andrea; thanks for the nice clear look at the state of things - sometimes we get so deep into the technical problems we forget to look at the bigger (ie product) picture.

I recently completed a talking tour (3 cities in Austrlia) where I was presenting the open source software stack. Other people on this tour were varried and included several people from the Autodesk project (including a bloke called Eric who I consider to be the first normal open source contact I have for mapguide).

I could not go into much detail (since I had an overview talk) but I was very impressed with the how well mapguide covered the front end generation part. As I went through the other open source components the only other thing I could point to that had this sorted out was Deegree. Indeed I had to talk about GeoServer, PostGIS, MapServer and so on *as* components (occasionally mentioning the standards they were implementing). And while standards went over well (and are a good measure of security and lower risk etc...) it was not as strong a position to talk from. Moving on to things like ... use GeoServer to publish data to google maps / earth is fine. However I could not match the MapGuide representatives for generating a website; you could watch the audience respond as they cycled through several "themes" of website to make the point about branding etc... so yes the "last mile" requires work.

I had a bit more luck with you with SLD - however that was during a Q&A session where I could fire up uDig and show SLD generation; and show that there was some XML behind the scenes that was also understood by GeoServer. I would like to catch up our SLD support (ie SE 1.1.) ... the stuff you mention about hatching patterns I recall seeing in the specification somewhere Andrea (I do not think we need hacks to pull that off it is boiled in).

Cheers and thanks for the open discussion,
Jody

Andrea Aime wrote:

Hi,
so this week I've been in Lugano making a GeoServer course.

The class was small but the average student had minimum
a deegree, more than half had a PhD or were still working
in a research institute. Most of them did not have a previous
open source GIS usage experience, and all of them were
ArcGis power users but had no real experience with
nitty gritty details about http, xml, command line and
all that stuff that we take for granted, but that is
obscure to the rest of the world.

Coming from a point and click GUI background being thrown
in the GeoServer env was painful for them,
and for a number of reasons:
- no easy way to deal with the nitty gritty detail of map
   styling. Ok, you can get some way with uDig, but they
   are used to fine tune label positioning and other
   stuff for which we require hand tuning of the generated
   SLD. I had the strong impression SLD was just ok,
   even when used 100% of its power, and they are used
   to more
- no good support for hatched fills, and hatches are mandated
   by law in Europe. Yes, one can create a small transparent
   png that creates a diagonal line fill effect, but
   it's painful. Using markers would be better, but it
   simply does not work right now (e.g., use the "x"
   marker to get a cross hatch) due to bugs in the renderer.
- many little detail in the UI, such as having to type
   in shapefile paths and the like
- dealing with coverages, ArcGis builds on the fly a
   pyramid to speed up access, here you have to deal with
   command line tools such as gdal ones
- having to work with stuff that requires you to drop
   the UI and hand edit files (see security for example)
- not having a good full stack integration with desktop
   tools, and solid lack of basic functionality in those
   ("what do you mean there is no point snapping during
     editing?")
- not having an easy way to generate a WMS front end.
   They did not want a tailored front end, they just
   wanted "any" frontend that could be generated without
   knowing anything about programming
- not having an easy way to generate a WFS front end,
   as some of them had data they wanted to share,
   and to allow for download after some kind of filtering,
   but again they cannot code the f.e. by themselves

All in all the whole usage experience seemed to be
setup to torture them, as with quite some extra effort
compared to their usual workflow they could have been
able to put up a service, but the last mile (the
frontends) was not there, making all the effort
not seem worthy.

I have the impression things would have gone much
better with:
- a better UI (wicket to the rescue)
- a SLD editor geared towards web mapping, and with
   every damned feature we can pull out of it, including
   vendor options, ready to use
- a simple front end generator (list of layers,
   project, gmaps integration, wfs download of selected
   layers in the current visualized area)

If you add to this a hosting service that allows
them to forget about network issues, backups, ...
(all admin headaches) and allows them to upload
their stuff and configure it for the world to use,
well, I'd say we would have a winner for this kind
of target user.

So well, in the end, I wasn't happy about how GeoServer
fared with this target (and it's GeoServer fault imho),
but I'm hopeful that if we want, we can make it better.

Cheers
Andrea

[Andrea_Aime3]

Jody Garnett ha scritto:

Hey Andrea; thanks for the nice clear look at the state of things - sometimes we get so deep into the technical problems we forget to look at the bigger (ie product) picture.

I recently completed a talking tour (3 cities in Austrlia) where I was presenting the open source software stack. Other people on this tour were varried and included several people from the Autodesk project (including a bloke called Eric who I consider to be the first normal open source contact I have for mapguide).

I could not go into much detail (since I had an overview talk) but I was very impressed with the how well mapguide covered the front end generation part. As I went through the other open source components the only other thing I could point to that had this sorted out was Deegree. Indeed I had to talk about GeoServer, PostGIS, MapServer and so on *as* components (occasionally mentioning the standards they were implementing). And while standards went over well (and are a good measure of security and lower risk etc...) it was not as strong a position to talk from. Moving on to things like ... use GeoServer to publish data to google maps / earth is fine. However I could not match the MapGuide representatives for generating a website; you could watch the audience respond as they cycled through several "themes" of website to make the point about branding etc... so yes the "last mile" requires work.

Yeah, pretty much my experience, in front of a non programmers audience
(non programmers as in not even knowing HTML usually) most of the
open source stuff falls desperately short, and is seen as a toy
for the "initiated". MapGuide looks like a product instead.

I had a bit more luck with you with SLD - however that was during a Q&A session where I could fire up uDig and show SLD generation; and show that there was some XML behind the scenes that was also understood by GeoServer.

Yeah, thought that kind of audience would very much prefer to ignore
the very existence of that XML, having to deal (even if it's just
cut and paste) with it puts them out of their comfort zone
(and this is not to criticize them, if they started to talk
in and out about the biology/geology science behind a specific
map I would soon be out of my comfort zone as well).

I would like to catch up our SLD support (ie SE 1.1.) ... the stuff you mention about hatching patterns I recall seeing in the specification somewhere Andrea (I do not think we need hacks to pull that off it is boiled in).

To support SLD 1.1 and SE 1.1 we have to write a parser/encoder,
and we have to change the renderer to support the new classification
functions, support ground units and the like.

This requires some significant effort, no one stepped up to work on
it. Wondering if we should take some time to make an economic
estimate of it, and then start a bounty.

As for hatches, looked into SE 1.1 and found nothing.
Anyways, I'm having a hard time understanding why hatching by
using markers is a "hack" from your point of view, I see it
as the cleanest solution: markers can scale, recolored,
be stroked and filled as one sees fit.
Making hatches with external PNG, well yeah, that's painful,
very much agreed, you have to make a carefully built
image for each orientation/size/line thickness/color you need.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Rob_Atkinson1]

I dont know how many times I've said this, in many contexts - content
management as well as spatial - but if we rely on getting people who
care about the content working with technology then there is a
problem.

Glossy UIs are not a bad thing by any means, but only make them
believe for a short time they can do the technology side. There will
always be issues the content folks will never be capable of dealing
with (connection pools and dimensioning databases, security of web
services etc. )

Provisioning of information is simply a problem with many aspects.

Making sure the components can do the job is still more important than
ease of config. Ability to repeat config is more important than ease
of config for a production service. That is why my experience is
always UI lets you familiarise yourself with the tool, but all real
configuration management is done by version controlling the underlying
artefacts.

Why should we compete with MapGuide anyway? It does a very specific
job quite neatly, and still wasnt a compelling enough business to
retain as a commercial product. maybe that the "suck and see data" job
is not the driver.

Remember, many people spend lots of money on Oracle databases, because
reliable data provisioning and management is still the real game. The
cost of software is generally small compared to the business issues.
They employ database experts to drive them. Oracle's UI (plethora of
them!) is probably similar to Geoservers in terms of coverage of
functionality, ease of use and stablity between versions (!)

Geoserver has a potential role as the data provisioning component of
the next generation of data-rich Web infrastructure. Until then, its
arguably a technology for experiments - and the UI need is obviously
real, but perhaps needs to be seen in that context.

Rob A

On Mon, Dec 22, 2008 at 6:58 PM, Andrea Aime <aaime@anonymised.com> wrote:

Jody Garnett ha scritto:

Hey Andrea; thanks for the nice clear look at the state of things -
sometimes we get so deep into the technical problems we forget to look
at the bigger (ie product) picture.

I recently completed a talking tour (3 cities in Austrlia) where I was
presenting the open source software stack. Other people on this tour
were varried and included several people from the Autodesk project
(including a bloke called Eric who I consider to be the first normal
open source contact I have for mapguide).

I could not go into much detail (since I had an overview talk) but I was
very impressed with the how well mapguide covered the front end
generation part. As I went through the other open source components the
only other thing I could point to that had this sorted out was Deegree.
Indeed I had to talk about GeoServer, PostGIS, MapServer and so on *as*
components (occasionally mentioning the standards they were
implementing). And while standards went over well (and are a good
measure of security and lower risk etc...) it was not as strong a
position to talk from. Moving on to things like ... use GeoServer to
publish data to google maps / earth is fine. However I could not match
the MapGuide representatives for generating a website; you could watch
the audience respond as they cycled through several "themes" of website
to make the point about branding etc... so yes the "last mile" requires
work.

Yeah, pretty much my experience, in front of a non programmers audience
(non programmers as in not even knowing HTML usually) most of the
open source stuff falls desperately short, and is seen as a toy
for the "initiated". MapGuide looks like a product instead.

I had a bit more luck with you with SLD - however that was during a Q&A
session where I could fire up uDig and show SLD generation; and show
that there was some XML behind the scenes that was also understood by
GeoServer.

Yeah, thought that kind of audience would very much prefer to ignore
the very existence of that XML, having to deal (even if it's just
cut and paste) with it puts them out of their comfort zone
(and this is not to criticize them, if they started to talk
in and out about the biology/geology science behind a specific
map I would soon be out of my comfort zone as well).

I would like to catch up our SLD support (ie SE 1.1.) ... the
stuff you mention about hatching patterns I recall seeing in the
specification somewhere Andrea (I do not think we need hacks to pull
that off it is boiled in).

To support SLD 1.1 and SE 1.1 we have to write a parser/encoder,
and we have to change the renderer to support the new classification
functions, support ground units and the like.

This requires some significant effort, no one stepped up to work on
it. Wondering if we should take some time to make an economic
estimate of it, and then start a bounty.

As for hatches, looked into SE 1.1 and found nothing.
Anyways, I'm having a hard time understanding why hatching by
using markers is a "hack" from your point of view, I see it
as the cleanest solution: markers can scale, recolored,
be stroked and filled as one sees fit.
Making hatches with external PNG, well yeah, that's painful,
very much agreed, you have to make a carefully built
image for each orientation/size/line thickness/color you need.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[jive]

Andrea Aime wrote:

Yeah, pretty much my experience, in front of a non programmers audience
(non programmers as in not even knowing HTML usually) most of the
open source stuff falls desperately short, and is seen as a toy
for the "initiated". MapGuide looks like a product instead.

Just so.

I had a bit more luck with you with SLD - however that was during a Q&A session where I could fire up uDig and show SLD generation; and show that there was some XML behind the scenes that was also understood by GeoServer.

Yeah, thought that kind of audience would very much prefer to ignore the very existence of that XML, having to deal (even if it's just cut and paste) with it puts them out of their comfort zone (and this is not to criticize them, if they started to talk in and out about the biology/geology science behind a specific
map I would soon be out of my comfort zone as well).

I expected that ... however I found that the people I talked to liked the fact that the application (udig in this case) was not hiding any functionality from them.

I would like to catch up our SLD support (ie SE 1.1.) ... the stuff you mention about hatching patterns I recall seeing in the specification somewhere Andrea (I do not think we need hacks to pull that off it is boiled in).

To support SLD 1.1 and SE 1.1 we have to write a parser/encoder, and we have to change the renderer to support the new classification
functions, support ground units and the like.

Supporting ground units is the tricky one.

This requires some significant effort, no one stepped up to work on it. Wondering if we should take some time to make an economic
estimate of it, and then start a bounty.

Yeah that would help me; much like with the "DataAccess" upgrade that Gabriel and Ben talk about it really helps me to have an outline of the required work.

As for hatches, looked into SE 1.1 and found nothing. Anyways, I'm having a hard time understanding why hatching by
using markers is a "hack" from your point of view, I see it as the cleanest solution: markers can scale, recolored,
be stroked and filled as one sees fit.

I agree it is a clear solution; perhaps I saw something in code ... let me have a look. SLD 1.0 has GraphicFill which has a Graphic etc...

Making hatches with external PNG, well yeah, that's painful, very much agreed, you have to make a carefully built
image for each orientation/size/line thickness/color you need.

Okay I see one thing they are getting at; if you use an SVG you can supply the thickness/color etc (so a little better than a PNG). In SE 1.1 they use Mark and MarkIndex with the example of a true type font file.

Happy holidays,
Jody

[Chris_Holmes1]

I definitely lean more towards your end of the spectrum Rob, focusing on the data, not rushing to compete. But as we continue to match functionality of other products our list of remaining features grows smaller, so this has been crawling up the priority queue.

The cool thing though is that GeoExt stuff should align really nicely. We build the viewers and viewer-builders in a true open source community, instead of a one-off sub project of GeoServer. We’ll share components with MapFish off the bat, and hopefully others in time. And I’m pretty sure that community will soon get to the wizard map generation utilities, with an ever growing set of components that can be configured. So I imagine we’ll get to even better than MapGuide functionality within a year, maybe a bit more.

Thanks a ton for the feedback Andrea, it’s really good to hear about real users, and where the next points of improvement should lie.

Chris

On Mon, Dec 22, 2008 at 6:09 PM, Rob Atkinson <robatkinson101@anonymised.com> wrote:

I dont know how many times I’ve said this, in many contexts - content
management as well as spatial - but if we rely on getting people who
care about the content working with technology then there is a
problem.

Glossy UIs are not a bad thing by any means, but only make them
believe for a short time they can do the technology side. There will
always be issues the content folks will never be capable of dealing
with (connection pools and dimensioning databases, security of web
services etc. )

Provisioning of information is simply a problem with many aspects.

Making sure the components can do the job is still more important than
ease of config. Ability to repeat config is more important than ease
of config for a production service. That is why my experience is
always UI lets you familiarise yourself with the tool, but all real
configuration management is done by version controlling the underlying
artefacts.

Why should we compete with MapGuide anyway? It does a very specific
job quite neatly, and still wasnt a compelling enough business to
retain as a commercial product. maybe that the “suck and see data” job
is not the driver.

Remember, many people spend lots of money on Oracle databases, because
reliable data provisioning and management is still the real game. The
cost of software is generally small compared to the business issues.
They employ database experts to drive them. Oracle’s UI (plethora of
them!) is probably similar to Geoservers in terms of coverage of
functionality, ease of use and stablity between versions (!)

Geoserver has a potential role as the data provisioning component of
the next generation of data-rich Web infrastructure. Until then, its
arguably a technology for experiments - and the UI need is obviously
real, but perhaps needs to be seen in that context.

Rob A

On Mon, Dec 22, 2008 at 6:58 PM, Andrea Aime <aaime@anonymised.com> wrote:

Jody Garnett ha scritto:

Hey Andrea; thanks for the nice clear look at the state of things -
sometimes we get so deep into the technical problems we forget to look
at the bigger (ie product) picture.

I recently completed a talking tour (3 cities in Austrlia) where I was
presenting the open source software stack. Other people on this tour
were varried and included several people from the Autodesk project
(including a bloke called Eric who I consider to be the first normal
open source contact I have for mapguide).

I could not go into much detail (since I had an overview talk) but I was
very impressed with the how well mapguide covered the front end
generation part. As I went through the other open source components the
only other thing I could point to that had this sorted out was Deegree.
Indeed I had to talk about GeoServer, PostGIS, MapServer and so on as
components (occasionally mentioning the standards they were
implementing). And while standards went over well (and are a good
measure of security and lower risk etc…) it was not as strong a
position to talk from. Moving on to things like … use GeoServer to
publish data to google maps / earth is fine. However I could not match
the MapGuide representatives for generating a website; you could watch
the audience respond as they cycled through several “themes” of website
to make the point about branding etc… so yes the “last mile” requires
work.

Yeah, pretty much my experience, in front of a non programmers audience
(non programmers as in not even knowing HTML usually) most of the
open source stuff falls desperately short, and is seen as a toy
for the “initiated”. MapGuide looks like a product instead.

I had a bit more luck with you with SLD - however that was during a Q&A
session where I could fire up uDig and show SLD generation; and show
that there was some XML behind the scenes that was also understood by
GeoServer.

Yeah, thought that kind of audience would very much prefer to ignore
the very existence of that XML, having to deal (even if it’s just
cut and paste) with it puts them out of their comfort zone
(and this is not to criticize them, if they started to talk
in and out about the biology/geology science behind a specific
map I would soon be out of my comfort zone as well).

I would like to catch up our SLD support (ie SE 1.1.) … the
stuff you mention about hatching patterns I recall seeing in the
specification somewhere Andrea (I do not think we need hacks to pull
that off it is boiled in).

To support SLD 1.1 and SE 1.1 we have to write a parser/encoder,
and we have to change the renderer to support the new classification
functions, support ground units and the like.

This requires some significant effort, no one stepped up to work on
it. Wondering if we should take some time to make an economic
estimate of it, and then start a bounty.

As for hatches, looked into SE 1.1 and found nothing.
Anyways, I’m having a hard time understanding why hatching by
using markers is a “hack” from your point of view, I see it
as the cleanest solution: markers can scale, recolored,
be stroked and filled as one sees fit.
Making hatches with external PNG, well yeah, that’s painful,
very much agreed, you have to make a carefully built
image for each orientation/size/line thickness/color you need.

Cheers
Andrea

–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

---

---

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

---

---

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Andrea_Aime3]

Rob Atkinson ha scritto:

I dont know how many times I've said this, in many contexts - content
management as well as spatial - but if we rely on getting people who
care about the content working with technology then there is a
problem.

Glossy UIs are not a bad thing by any means, but only make them
believe for a short time they can do the technology side. There will
always be issues the content folks will never be capable of dealing
with (connection pools and dimensioning databases, security of web
services etc. )

Rob, you're missing the point there.

I remember you saying one/two years ago that GeoServer was useless
without complex features... well, look again, it's been some time
and we're still here and growing.

Not everybody needs to put online a big set of correlated data
with top level security on a big hardware infrastructure for
thousands of users to share.
There's also lots of smaller entities that have small data sets,
no in house IT support (or IT support that does not favour
open source solutions) and just want to put _something_ online.

GeoServer became popular due to the relative ease by which you
get started. Yes I know you have to go to the pros when you
have to setup something big, but you usually start small and
cut your teeth with a prototype, if you can have the damn
prototype ready in a matter of days without having to ask
for external help that's a big win.

And quite frankly, what's the last time you enjoyed putting
together an SLD by writing it directly, all or in part?
Or when did you had fun putting together yet another
OL based viewer?

I for sure hate the first and find the second annoying at best.
Please please (please!) give me a UI so that I don't have
to waste my time doing that again! If you like so much
dealing with the tech details having a UI won't force you
to use it.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Andrea_Aime3]

Chris Holmes ha scritto:

I definitely lean more towards your end of the spectrum Rob, focusing on the data, not rushing to compete.

Eh well, I know it sounds like rushing to compete, but the fact
is that I don't want to apologize for my work, and I felt
pretty much ashamed by GeoServer during that course.

More so since the need for a better UI was the first reaction
I had to GeoServer usage two years ago (I showed a small prototype
of modular, Wicket based UI at FOSS4G2006 in Lausanne, remember?),
and that was because I found it a pain to use for _myself_.

In time I sort of got used to it, but it feels like a chronic
illness, I accept it, but by no means I like having it.

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Chris_Holmes2]

Oh, don’t get me wrong, I’m all for improving the UI, and even doing basic front end generation. It’s just the whole ‘wizard’ and ‘theming’ aspects of MapGuide that I don’t want to rush to compete.

Could you turn your feedback in to jira issues Andrea? So we can track them?

On Tue, Dec 23, 2008 at 4:08 AM, Andrea Aime <aaime@anonymised.com> wrote:

Chris Holmes ha scritto:

I definitely lean more towards your end of the spectrum Rob, focusing on
the data, not rushing to compete.

Eh well, I know it sounds like rushing to compete, but the fact
is that I don’t want to apologize for my work, and I felt
pretty much ashamed by GeoServer during that course.

More so since the need for a better UI was the first reaction
I had to GeoServer usage two years ago (I showed a small prototype
of modular, Wicket based UI at FOSS4G2006 in Lausanne, remember?),
and that was because I found it a pain to use for myself.

In time I sort of got used to it, but it feels like a chronic
illness, I accept it, but by no means I like having it.

Cheers
Andrea

–
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

---

---

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

[Ben_Caradoc-Davies]

Andrea Aime wrote:

Rob Atkinson ha scritto:

Glossy UIs are not a bad thing by any means, but only make them
believe for a short time they can do the technology side. There will
always be issues the content folks will never be capable of dealing
with (connection pools and dimensioning databases, security of web
services etc. )

Rob, you're missing the point there.
I remember you saying one/two years ago that GeoServer was useless
without complex features... well, look again, it's been some time
and we're still here and growing.

Meanwhile, deegree is eating our lunch. Those delivering application-schema-conforming WFS use deegree, Cocoon-based XSLT, or commercial solutions.

And quite frankly, what's the last time you enjoyed putting
together an SLD by writing it directly, all or in part?
Or when did you had fun putting together yet another
OL based viewer?
I for sure hate the first and find the second annoying at best.
Please please (please!) give me a UI so that I don't have
to waste my time doing that again!

Those using deegree to deliver application-schema-conforming WFS yearn for the (relative) elegance and simplicity of hand-edited XML configuration files. Ugly, yes, but at the moment they have to write many complicated XSLT to postprocess their output, and corresponding XSLT to preprocess incoming queries. Nasty.

We have a window of opportunity in which GeoServer can provide a more robust and repeatable solution. Of course, a good UI is desirable in the long term, but the immediate priority must be to deliver application schema WFS with the minimum of fuss.

Kind regards,

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

[Ben_Caradoc-Davies]

Andrea Aime wrote:

More so since the need for a better UI was the first reaction
I had to GeoServer usage two years ago (I showed a small prototype
of modular, Wicket based UI at FOSS4G2006 in Lausanne, remember?),
and that was because I found it a pain to use for _myself_.
In time I sort of got used to it, but it feels like a chronic
illness, I accept it, but by no means I like having it.

If we can ever get app-schema GeoServer to be as easy to use as vanilla GeoServer is *now*, I will be delighted.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia

[Andrea_Aime3]

Ben Caradoc-Davies ha scritto:

Andrea Aime wrote:

Rob Atkinson ha scritto:

Glossy UIs are not a bad thing by any means, but only make them
believe for a short time they can do the technology side. There will
always be issues the content folks will never be capable of dealing
with (connection pools and dimensioning databases, security of web
services etc. )

Rob, you're missing the point there.
I remember you saying one/two years ago that GeoServer was useless
without complex features... well, look again, it's been some time
and we're still here and growing.

Meanwhile, deegree is eating our lunch. Those delivering application-schema-conforming WFS use deegree, Cocoon-based XSLT, or commercial solutions.

And quite frankly, what's the last time you enjoyed putting
together an SLD by writing it directly, all or in part?
Or when did you had fun putting together yet another
OL based viewer?
I for sure hate the first and find the second annoying at best.
Please please (please!) give me a UI so that I don't have
to waste my time doing that again!

Those using deegree to deliver application-schema-conforming WFS yearn for the (relative) elegance and simplicity of hand-edited XML configuration files. Ugly, yes, but at the moment they have to write many complicated XSLT to postprocess their output, and corresponding XSLT to preprocess incoming queries. Nasty.

We have a window of opportunity in which GeoServer can provide a more robust and repeatable solution. Of course, a good UI is desirable in the long term, but the immediate priority must be to deliver application schema WFS with the minimum of fuss.

Then act. Nobody is stopping you, we just ask that things are done
properly that they don't break a successful product solid to deal with
a use case that, for the moment, is for a minority of users.

Do you see tons of users asking for complex features on the users
list (I'm not saying there are any, but that's not exactly what
is being requested day in day out)?

Put under another perspective, look at a sample GeoServer site
such as MASSGIS, here is their layer list:
http://giswebservices.massgis.state.ma.us/geoserver/mapPreview.do

Out of 300+ layers only a handful are rasters (the last two only
afaik), everything else is vector and it's published using both
WMS and WFS. Now, can you tell me how many of those layers
have a community schema that could be used to publish them
in a "compliant" way? 2? 10?

I'm not saying community schema is not important, and I'm not saying
we should drop it or anything. I'm just stating my priorities and
my reactions to a course gone bad.
Is it really such news that in _my_ book (my book, not OpenGeo one)
the important elements are spatial analysis, good cartographic output,
decent performance and a good UI?
(and that we fall short on 3 out of 4 of them?)

If those in your book are community schema related, act on them,
we won't stop you, we'll even provide enough review time to
do basic damage control. Just don't pretend everybody jumps
on your bandwagon because you say it's important, accept
that other people have different priorities.

When we did more KML, or better labelling, or a security
subsystem, and so on, did we ask for buy in, or for other people
to join the battle and provide resources?
Or when GeoSolutions worked on coverages, raster symbolizer,
or GDAL support, did they ask anything other than a review
when it was time to merge?

Then why every time we speak about doing anything other than
community schema you jump the gun? Aren't we free to allocate
resources to what we feel is important? We already agreed
to give a helping hand in terms of review and merge, why is
that not enough?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

[Rob_Atkinson1]

I dont think you read my post very carefully - I supported the mass
market (KML etc) focus as a short term goal. I dont think its me
criticising your position as a default here. I simply feel its worth
pointing out that since UI investment is a massive burden, we should
be aware there are definitely multiple perspectives on what the
product (and hence UI) should focus on.

for example - I dont want a fancy UI to allow me to manually enter
virus signatures - it works very nicely distributing updates. We need
to "work smarter, not just harder". Do we go round the hill, over it,
or through it?

Merry Christmas

Rob

On Wed, Dec 24, 2008 at 6:49 PM, Andrea Aime <aaime@anonymised.com> wrote:

Ben Caradoc-Davies ha scritto:

Andrea Aime wrote:

Rob Atkinson ha scritto:

Glossy UIs are not a bad thing by any means, but only make them
believe for a short time they can do the technology side. There will
always be issues the content folks will never be capable of dealing
with (connection pools and dimensioning databases, security of web
services etc. )

Rob, you're missing the point there.
I remember you saying one/two years ago that GeoServer was useless
without complex features... well, look again, it's been some time
and we're still here and growing.

Meanwhile, deegree is eating our lunch. Those delivering
application-schema-conforming WFS use deegree, Cocoon-based XSLT, or
commercial solutions.

And quite frankly, what's the last time you enjoyed putting
together an SLD by writing it directly, all or in part?
Or when did you had fun putting together yet another
OL based viewer?
I for sure hate the first and find the second annoying at best.
Please please (please!) give me a UI so that I don't have
to waste my time doing that again!

Those using deegree to deliver application-schema-conforming WFS yearn for
the (relative) elegance and simplicity of hand-edited XML configuration
files. Ugly, yes, but at the moment they have to write many complicated XSLT
to postprocess their output, and corresponding XSLT to preprocess incoming
queries. Nasty.

We have a window of opportunity in which GeoServer can provide a more
robust and repeatable solution. Of course, a good UI is desirable in the
long term, but the immediate priority must be to deliver application schema
WFS with the minimum of fuss.

Then act. Nobody is stopping you, we just ask that things are done
properly that they don't break a successful product solid to deal with
a use case that, for the moment, is for a minority of users.

Do you see tons of users asking for complex features on the users
list (I'm not saying there are any, but that's not exactly what
is being requested day in day out)?

Put under another perspective, look at a sample GeoServer site
such as MASSGIS, here is their layer list:
http://giswebservices.massgis.state.ma.us/geoserver/mapPreview.do

Out of 300+ layers only a handful are rasters (the last two only
afaik), everything else is vector and it's published using both
WMS and WFS. Now, can you tell me how many of those layers
have a community schema that could be used to publish them
in a "compliant" way? 2? 10?

I'm not saying community schema is not important, and I'm not saying
we should drop it or anything. I'm just stating my priorities and
my reactions to a course gone bad.
Is it really such news that in _my_ book (my book, not OpenGeo one)
the important elements are spatial analysis, good cartographic output,
decent performance and a good UI?
(and that we fall short on 3 out of 4 of them?)

If those in your book are community schema related, act on them,
we won't stop you, we'll even provide enough review time to
do basic damage control. Just don't pretend everybody jumps
on your bandwagon because you say it's important, accept
that other people have different priorities.

When we did more KML, or better labelling, or a security
subsystem, and so on, did we ask for buy in, or for other people
to join the battle and provide resources?
Or when GeoSolutions worked on coverages, raster symbolizer,
or GDAL support, did they ask anything other than a review
when it was time to merge?

Then why every time we speak about doing anything other than
community schema you jump the gun? Aren't we free to allocate
resources to what we feel is important? We already agreed
to give a helping hand in terms of review and merge, why is
that not enough?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.