Slashdot Mirror
Open Source GIS Conference Wrapup
Wugger writes "The open source GIS community has been around for a long time, but has only been meeting regularly for the past three years. The most recent conference wrapped up on the weekend in Minneapolis. An excellent summary article and blog postings are available from Directions Magazine. Other attendees have also
posted
blogs
and
observations.
The conference was attended by 300 people this year (up from 200 the previous year) and all the major open source GIS hackers were in attendance. In addition, some proprietary corporate players showed up to check out the scene: Autodesk, ERMapper, and ESRI, the Microsoft of the GIS industry."
400 people were registered, but the missing 100 people were not able to locate the convention center thanks to faulty map software.
Google Image Search...?
... the Microsoft of the GIS industry
/.
That's like saying "these guys club baby penguins to death", especially on
GRASS http://grass.itc.it/ is the primary open source GIS solution. The summary could have at least mentioned it in passing.
Odd that they mention AutoDesk too, considering their mapping software doesn't feature as nice spatial analysis stuff as ArcGIS does, although I haven't used it enough to make any other conclusions about it.
Now if GRASS would only improve their text interface and revamp their GUI.
Another critical open source GIS application for webmaps is MapServer http://mapserver.gis.umn.edu/
I've found that doing the data analysis with ArcGIS and displaying it with mapserver is the only way to go. ArcIMS is a bit too complex, at least compared to mapserver.
Um, if you mean the excellent summary article mentioned, GRASS is item number one.
That said, GRASS could be as powerful as Almighty God, but most people would never get past what is surely the worst user-interface known to man. C'mon guys, fix the damn thing already.
aside from a user interface that doesn't make ordinary users scream in agony, is a geocoding engine. You put "123 Maple Street, Anytown, OH" and get coordinates. Pretty essential to the google maps kind of functionality, although for lots of stuff like store locaters you can go with zip code or town centroids.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Well, sure, it's not hard to do if your standards of accuracy and peformance aren't very high, but people do put addresses in all kinds of odd ways. For example the same address can be "125 Joe Shmoe Highway W" or "125 State Highway 19B" or "125 Rt 19 Bypass". It gets even more fun when you have spanglish and franglish addresses as are common in some parts of the country "123B Calle de Ingenieros Locos North".
You can force the user to put things into different fields, like this:
Street Number:
Prefix Direction:
Prefix Type:
Name:
Suffix Type:
Suffix Direction:
Postal: code
But it would be really nice (as some commercial geocoding products do) to parse an address string into it's components, and provide a combination of standardizing and distance matching services on top of those. If you could keep a list of synonyms (probably postGIS!) you'd be waaay head.
Maybe I've found a new project to start.
If you're serious, I'd contribute.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
Microsoft treats its developers and resellers well. ESRI exploits them. We once had a lead we worked into a pretty significant sale, but there was one item on the list that we didn't have a price for. So we called ESRI and found out that policy said that quotes that included the product had to come direct from ESRI. We were told that if we sent them the lead, we'd get a commision. So, later we follow up with the customer, and they have all their goodies. So we call the ESRI manager we'd talked to, and asked about our commission. He said that he changed his mind about it, because we hadn't really done enough work to justify a commission. Needless to say we never sent a lead to ESRI again.
Their behavior is similar or even worse from the developer end of things. They literally say things like, "You have to understand that we'll be your business partner and your toughest competitor -- at the same time." Of course this is absurd. If you're smart, you'll realize this means you'll never make a significant profit on a product.
Of course, in a way you have to expect this from any company. Microsoft does it too. The difference is Microsoft crushes its partners when they become strategic issues; ESRI does it for short term disadvantage. The sense I have is that their cut-throat culture is even more deeply rooted than Microsoft's. The people I know who work for MS are, by in large pretty happy. The people I know who work for ESRI always strike me as a bit nervous.
"primary open source GIS solution"
You're in sales, aren't you? Only people in sales (and maybe high-level executives who don't really know what they're talking about) use the word "solution" in such a manner.
GRASS UI - You can now run the beautiful QGIS on top of GRASS, which gives you the best of both worlds.
The posters who mention the GRASS user interface neglect to mention that the prime GRASS UI is the unix shell. You can do _anything_ that GRASS can do within shell scripts, or python or perl, etc.
This also means that your scripting language has the power of the full UNIX tool chain philosophy.
The new GRASS Vector model also rocks, very hard, and you have full connectivity to PostGIS-the geospatial extensions to PostgreSQL that also rock, very hard.
There is the free http://geocoder.us/ web site that uses the Geo::Coder::US perl module.
The perl module is free software, and the Tiger data that it uses is also free.
The Geocoder.us web site runs this module to do lookups for non-profits for free (commercial use of the web site is not free-but you are welcome to download the code and the data and do it yourself for free).
As a note: The full census data when loaded into Postgis is something like 40 gb, and is dog slow. Refractions is working (or was working) on a pure SQL geocoder. The Geo::Coder::US version uses Berkeley DB files and is about 800 mb.