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 <aa...@opengeo.org> 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
