|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | RE: GISList: re: Linux RS and GIS software for the masses |
| Date: |
06/10/2002 07:58:37 AM |
| From: |
Dimitri Rotow |
|
|
> purpose. I'll just say that I find it interesting that Dimitri's
> "obsolete technology" such as the University of Minnesota MapServer has
> witnessed exponential growth in it's uptake over the past three years
> and now is the engine behind many of the most sophisticated web mapping
> applications I have seen. Within the next few months, MapServer will be
> upgraded to support PDF output, and will be tightly integrated with
> Flash technology providing the ability to develop fully interactive
> mapping applications in a flash environment. Obsolete eh?
>
Well, since you asked, yes. You've actually helped make my point about
blind spots in the Linux community. MapServer is obsolete for two reasons
in the context of this thread ("GIS software for the masses"):
1) It cannot be configured without substantial programming. In that respect
it is a typical Linux appliance bereft of any awareness of how important
interactive interfaces are for mass usage. It is a typically Linux blind
spot response to rise to the defense of MapServer without addressing the key
point, that is cannot be set up without substantial programming.
2) MapServer has zero interactive GIS capabilities, so you have to purchase
a real GIS to get your data squared away. The idea that one should have two
GIS packages, one to edit and arrange one's GIS data interactively and
another one, a perverse server engine with which one must communicate by CGI
scripts, to publish that GIS data to the web is a very obsolete idea.
Leaving WYSIWYG issues aside, it's a dreadfully obsolete idea to think that
one should have to learn two radically different GIS approaches (with all
the attendent risks of getting things wrong in the handoff) just to publish
something to the web.
The internal technical architecture of MapServer is also obsolete compared
to what one would do with a serious programming effort using modern
approaches. However, as my comments about the abacus in my earlier posting
indicate, just because it uses old methods doesn't mean it can't be used to
do cool tricks. If you apply enough time and money to it and are willing to
burn enough computer cycles, sure you can create fine web sites with
MapServer.
> Where was MapServer, Linux, PHP, PostGIS, Apache 10 years ago? It
> didn't exist ... so in less than 10 years, open source technologies have
> gone from near zero to enough propagation that we're even having this
> discussion. That doesn't sound like a dead-end to me.
>
I strongly agree that open source projects are not dead end projects. The
key question is why open source projects, in Linux in particular, have not
resulted in any world-beating interactive applications. I gave my opinion
on that in the previous posting, but I'd like to hear your opinion... why is
it that Linux and open source efforts have not produced any significant
interactive applications that have achieved anywhere near the success of
Linux server appliances?
>
>
> Web mapping - UMN MapServer
> Spatial Database - PostGIS with PostgreSQL
You're kidding, right? Remember, the original posting was about "mass"
markets...
> Desktop mapping - OpenEV and Grass (OpenEV is a bit newer, but still in
> the early stages of it's development)
On the one hand, GRASS is not a very good example of "open source" software
since it was developed by the US Army and was not developed on the open
source model as was Linux. It appears that progress on GRASS has essentially
stopped since it went "open source." On the other hand, as an example of
something that is slow, limited, terribly obsolete and lags the commercial
market by many years it is probably a pretty good example of an "open
source" project that is dead on arrival as regards mass usage.
>
> User Groups that can benefit the most today:
>
> 1. Distributed Data environments
>
> Many organizations have data residing in many different places, and in
> many different formats. Fees for licensing software to handle this
> scenario becomes very quickly, very prohibitive. Save your licensing
> $$$, take on some of the robust base technologies from above, and spend
> it on getting a contractor specializing in the technologies to implement
> those custom features that you just can't get out of the box in the
> commercial world. Our experience has been that this is cheaper in the
> end AND you actually get the functionality you want, not what the vendor
> happens to have available in the current release.
>
So, you've abandoned the idea that "open source" software is free. You're
saying that it costs you a lot of $$$ in the form of contractor expenses to
get it to do what is necessary. That's very perceptive of you (I see you
have exper
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
