Re: [OSGeo-Discuss] OSGeo Next five years

[Chris Puttick]

Not entirely an OSGeo specific point, but this type of criticism "open source 
is hard, closed source is easy" is not uncommon. Some 17 years of experience 
working with IT in organisations gets me a one word response to such a claim I 
will not repeat here, but it starts with a "b" and sounds a lot like hillocks...

What closed source, marketing driven, products tend to focus on is the 
appearance of easy. It has been easy to set up a Microsoft Exchange server for 
over 10 years, in the sense of starting with a server and successfully sending 
and receiving email, etc.. As so many compromised servers over the same 10 
years easily demonstrate, it is hard (and requires expertise) to setup said 
server to only send/receive email just for those who should be able to 
send/receive email, hard to get said mail server to scale with your 
organisation, hard to unpick it after a malware infestation (or bad AV update), 
hard to migrate it to another mail server, nearly impossible to use it from 
your choice of desktop platforms and actually impossible to deploy it on your 
choice of server platforms. There are many other examples, many of which from 
Microsoft, with the same story - deceptively easy to get going, desperately 
hard to make it do what you finally realise is best for *your* organisation.

Simplicity in the sense of does not require expertise to make work almost 
certainly means impossible or very, very difficult to finally make it work the 
way you need it. My exposure to .net developments and the final convoluted 
efforts developers go through to bend to their will have provided sufficient 
evidence for me to tell colleagues in other organisations that it is a mistake 
to be deceived by rapid early progress. The tortoise and the hare is a very old 
story...

So if you want simplicity, put some of the building blocks together for the new 
user; build VMs with complete working setups that just need network 
configuration and data to start doing things. But please don't repeat the 
approach of the marketeers, make something simple and restricted and then claim 
something that just ain't true!

Cheers

Chris


- "Arnie Shore"  wrote:

> As a very interested lurker, and as one who has developed an Open
> Source Computer-Aided-Dispatch system that has embedded google's maps
> product, I can tell you that one of the deterrents I see is the
> relative complexity of an Open Source GIS implementation - as compared
> to the use of GMaps, which also, of course and notably, is free. The
> single source of both the tiles as well as the API is relatively
> straightforward for the non-cartographer novice.
> 
> My user community includes a fair-sized portion who have never before
> implemented a web-server-based system, and our package is designed to
> minimize the number of elements that need separate collection and
> configuration. To tell them that they need a map server in addition to
> the stack that WAMP, XAMPP, MAMP, installs in a single executable will
> turn away too many candidates, IMO. In our case, the tile-serving
> capabilities could be met by a rather limited set of server-side
> functions that are OL-aware. But I haven't seen anything like that in
> the panoply of products that comprises the OSGeo world. Please correct
> me on this if such exits.
> 
> (Further evidence of the importance of the ease-of-implementation
> issue is the proliferation of open source libraries that include
> capabilities taht are based on a GMaps foundation.)
> 
> I will say that my users - many of whom are into emergency operations
> - indeed are asking for an implementation that wd allow operation
> while disconnected from the Internet. Impossible in a GMaps-based
> solution, but completely feasible in one based on OpenLayers plus
> locally stored OSM tiles. Users I've pointed to the available OSM
> sites have told me that the level of detail wd be completely
> satisfactory as a suitable replacement for GMaps. Which is a
> critically important data point, IMO.
> 
> My perception of the current evolution of the world of Open Source GIS
> is toward greater complexity and richness. Which certainly makes for
> excitement and challenge for its enthusiasts; but that isn't doing
> much for those of us along the borders looking over the fences, and
> with limited hours available to hop that fence and get involved.
> 
> Make entry easier than it is, folks. Please?
> 
> A. Shore
> Annapolis, MD
> 
> 
> 
> On Wed, Sep 16, 2009 at 5:09 PM, Ravi < ravivundava...@yahoo.com >
> wrote:
> 
> 
> Hi,
> have been going through all the wishes, all the arguments about how
> Open Source GIS must evolve etc. ...
> 
> ___
> Discuss mailing list
> Discuss@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/discuss


--
Files attached to this email may be in ISO 26300 format (OASIS Open Document 
Format). If you have difficulty opening them, please visit http://iso26300.info 
for more informa

Re: [OSGeo-Discuss] OSGeo Next five years

[Bob Basques]

All,

Related to Arnie's posting here.  I would like to see some community 
organization around business specific products like the the items that 
Arie is describing here.  Example that meet customers needs more readily 
than by requiring the first time implementer to assemble a bunch of 
pieces (which it the right way to do it BTW!) to get what they need.  
While some business needs are fairly specific, there are certain things 
generic enough that they can scoped out and set up for the masses as 
examples where the potential useser can just plug any play so to speak.


This type of approach would leak over into training and education easily 
if done right and made very simple to get things going.




bobb


Arnie Shore wrote:
As a very interested lurker, and as one who has developed an Open 
Source Computer-Aided-Dispatch system that has embedded google's maps 
product, I can tell you that one of the deterrents I see is the 
relative complexity of an Open Source GIS implementation - as compared 
to the use of GMaps, which also, of course and notably, is free. The 
single source of both the tiles as well as the API is relatively 
straightforward for the non-cartographer novice.


My user community includes a fair-sized portion who have never before 
implemented a web-server-based system, and our package is designed to 
minimize the number of elements that need  separate collection and 
configuration.  To tell them that they need a map server in addition 
to the stack that WAMP, XAMPP, MAMP, installs in a single executable 
will turn away too many candidates, IMO.  In our case, the 
tile-serving capabilities could be met by a rather limited set of 
server-side functions that are OL-aware. But I haven't seen anything 
like that in the panoply of products that comprises the OSGeo world.  
Please correct me on this if such exits.


(Further evidence of the importance of the ease-of-implementation 
issue is the proliferation of open source libraries that include 
capabilities taht are based on a GMaps foundation.)


I will say that my users - many of whom are into emergency operations 
- indeed are asking for an implementation that wd allow operation 
while disconnected from the Internet.   Impossible in a GMaps-based 
solution, but completely feasible in one based on OpenLayers plus 
locally stored OSM tiles.  Users I've pointed to the available OSM 
sites have told me that the level of detail wd be completely 
satisfactory as a suitable replacement for GMaps.  Which is a 
critically important data point, IMO.


My perception of the current evolution of the world of Open Source GIS 
is toward greater complexity and richness.  Which certainly makes for 
excitement and challenge for its enthusiasts; but that isn't doing 
much for those of us along the borders looking over the fences, and 
with limited hours available to hop that fence and get involved.


Make entry easier than it is, folks.  Please?

A. Shore
Annapolis, MD


On Wed, Sep 16, 2009 at 5:09 PM, Ravi > wrote:


Hi,
have been going through all the wishes, all the arguments about
how Open Source GIS must evolve etc. ...



___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
  
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo Next five years

[Bob Basques]

Arnie,

I'm working on something almost exactly as you describe, a connect 
and/or standalone map service.  I cal it a cascaded map service (might 
be a mis-label), that can stay in sync with the remote server, and act 
as a standalone when the network connection is not available.


My buisness needs go beyond emergency management however some some of 
the guts are still harder to grasp by the beginner/sometimer admins.  
But the hope is to make that all transparent, and reply on the 
local(standalone) service to keep it self up to date based on a remote 
service (that may or may not require the highend capabilities to set up. 
(we use GeoMoose for example.).


I can keep you in the loop on things if you are interested.

bobb


Arnie Shore wrote:
As a very interested lurker, and as one who has developed an Open 
Source Computer-Aided-Dispatch system that has embedded google's maps 
product, I can tell you that one of the deterrents I see is the 
relative complexity of an Open Source GIS implementation - as compared 
to the use of GMaps, which also, of course and notably, is free. The 
single source of both the tiles as well as the API is relatively 
straightforward for the non-cartographer novice.


My user community includes a fair-sized portion who have never before 
implemented a web-server-based system, and our package is designed to 
minimize the number of elements that need  separate collection and 
configuration.  To tell them that they need a map server in addition 
to the stack that WAMP, XAMPP, MAMP, installs in a single executable 
will turn away too many candidates, IMO.  In our case, the 
tile-serving capabilities could be met by a rather limited set of 
server-side functions that are OL-aware. But I haven't seen anything 
like that in the panoply of products that comprises the OSGeo world.  
Please correct me on this if such exits.


(Further evidence of the importance of the ease-of-implementation 
issue is the proliferation of open source libraries that include 
capabilities taht are based on a GMaps foundation.)


I will say that my users - many of whom are into emergency operations 
- indeed are asking for an implementation that wd allow operation 
while disconnected from the Internet.   Impossible in a GMaps-based 
solution, but completely feasible in one based on OpenLayers plus 
locally stored OSM tiles.  Users I've pointed to the available OSM 
sites have told me that the level of detail wd be completely 
satisfactory as a suitable replacement for GMaps.  Which is a 
critically important data point, IMO.


My perception of the current evolution of the world of Open Source GIS 
is toward greater complexity and richness.  Which certainly makes for 
excitement and challenge for its enthusiasts; but that isn't doing 
much for those of us along the borders looking over the fences, and 
with limited hours available to hop that fence and get involved.


Make entry easier than it is, folks.  Please?

A. Shore
Annapolis, MD


On Wed, Sep 16, 2009 at 5:09 PM, Ravi > wrote:


Hi,
have been going through all the wishes, all the arguments about
how Open Source GIS must evolve etc. ...



___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
  
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] OSGeo Next five years

[Arnie Shore]

As a very interested lurker, and as one who has developed an Open Source
Computer-Aided-Dispatch system that has embedded google's maps product, I
can tell you that one of the deterrents I see is the relative complexity of
an Open Source GIS implementation - as compared to the use of GMaps, which
also, of course and notably, is free. The single source of both the tiles as
well as the API is relatively straightforward for the non-cartographer
novice.

My user community includes a fair-sized portion who have never before
implemented a web-server-based system, and our package is designed to
minimize the number of elements that need  separate collection and
configuration.  To tell them that they need a map server in addition to the
stack that WAMP, XAMPP, MAMP, installs in a single executable will turn away
too many candidates, IMO.  In our case, the tile-serving capabilities could
be met by a rather limited set of server-side functions that are OL-aware.
But I haven't seen anything like that in the panoply of products that
comprises the OSGeo world.  Please correct me on this if such exits.

(Further evidence of the importance of the ease-of-implementation issue is
the proliferation of open source libraries that include capabilities taht
are based on a GMaps foundation.)

I will say that my users - many of whom are into emergency operations -
indeed are asking for an implementation that wd allow operation while
disconnected from the Internet.   Impossible in a GMaps-based solution, but
completely feasible in one based on OpenLayers plus locally stored OSM
tiles.  Users I've pointed to the available OSM sites have told me that the
level of detail wd be completely satisfactory as a suitable replacement for
GMaps.  Which is a critically important data point, IMO.

My perception of the current evolution of the world of Open Source GIS is
toward greater complexity and richness.  Which certainly makes for
excitement and challenge for its enthusiasts; but that isn't doing much for
those of us along the borders looking over the fences, and with limited
hours available to hop that fence and get involved.

Make entry easier than it is, folks.  Please?

A. Shore
Annapolis, MD


On Wed, Sep 16, 2009 at 5:09 PM, Ravi  wrote:

> Hi,
> have been going through all the wishes, all the arguments about how Open
> Source GIS must evolve etc. ...
>
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

[OSGeo-Discuss] OSGeo Next five years

[Ravi]

Hi,
have been going through all the wishes, all the arguments about how Open Source 
GIS must evolve etc.
Yet to see one that is from or for a developing country.. (or have I missed ?)
This is yet another occassion, to think how different are the priorities for 
developing countries including India. Spread of sustainable GIS for societal 
use is only possible using Open Source GIS. 

Please see my blog, 'The Indian GIS scene--Hype and reality'.

http://wiki.osgeo.org/wiki/User_talk:Ravivundavalli#The_Indian_GIS_scene_--_Hype_and_reality

Cheers

Ravi Kumar


  Now, send attachments up to 25MB with Yahoo! India Mail. Learn how. 
http://in.overview.mail.yahoo.com/photos
___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

[OSGeo-Discuss] internet is not my friend

[Jody Garnett]

Evening:

Today I asked a bunch of community leaders to remind their mailing  
list about the opportunity to do a demo at FOSS4G (ie http://wiki.osgeo.org/wiki/FOSS4G_2009_Demonstration_Theatre 
).


The fates have conspired against me and the fibre optic cable to  
LISAsoft was cut; so any email is not really getting through to me  
promptly.


Jody


___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss

Re: [OSGeo-Discuss] Next 5 years for OSGeo

[Henning Lorenz]

In my opinion, a major challenge is to extend OSGeo beyond it's  
present topical range. Presently, OSGeo deals mainly with "classical"  
GIS, webmapping, and underlying technologies (generalised). I think  
this is also captured in this thread where references to and  
comparison with commercial GIS packages are common, and votes refer to  
GIS functionality (analytical functions, cartography). But geospatial  
is more than that. Investigating and describing the planet Earth in  
three (or four) dimensions is a necessity in Earth Sciences and  
related industry, in engineering (sciences) and societal planning  
(amongst others). This includes data acquisition, processing,  
interpretation and storage in three dimensions (from geological field  
work, drilling, geophysical experiments, in-situ and lab-experiments).  
Often commercial software packages are used for these purposes, but  
also opensource tools are available (OpenDTect, Seismic Unix,  
GMT, ...). The potential user base is broad and numerous, and the  
potential to attract developers high - many researchers, and maybe  
also companies, are used to develop their own tools.


I think it's a challenge in the two meanings of the word. It's  
necessary to do justice to the meaning of geospatial. And I think it  
is difficult to put in practice without a major project as a "catalyst".


Henning



___
Discuss mailing list
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss