WhereCamp, June 2nd-3rd

/

Y'all might be interested in this. Hell, I might even go. Via the geowanking list,

A quick reminder: WhereCamp is being held June 2-3 at the Yahoo! Sunnyvale campus. There'll be sessions and whatnot. You might also consider it a Geowanking list meet-up of sorts. Description: WhereCamp un-conference. Free. A hugely energetic overlap of diverse interests ranging from newbies, web 2.0 and mobile developers, social place hackers and artists to grad students, geographers, earth scientists and people focused on humanitarian and environmental efforts. Wiki: http://wherecamp.pbwiki.com/WhereCampSF Directions: http://docs.yahoo.com/info/address/ Registered Attendees: http://wherecamp.pbwiki.com/WhereCampSFRegistrants and: http://upcoming.yahoo.com/event/170065/ See you there! -- Joshua Schachter http://del.icio.us/joshua http://joshua.schachter.org/

Public geodata under threat in Europe

/

Via BoingBoing (of all places), recent moves by the European Commission to orchestrated sharing of government-collected geodata between member nations are become increasingly embroiled with licensing and copyright issues that may limit or completely illiminate public access to the data, data collected using public funds. Now I confess I know next to nothing about this situation (I don't even really know the difference between the EC and the EU), but I understand that public geodata is already a scarce commodity in Europe, so this is probably bad news for Europeans or anyone doing research in Europe.

MapRoom - a multi-user spatial data management tool

/

Hey all. So Brent and I have continued thinking about this whole spatial data management system we've all been discussing. Here are two mock-ups of what we think such a site might look lile. These are, of course, super rough right now, lacking some features and design considerations our first draft will have, but we'd love to get people's comments and thoughts from the get go. Main Page First page you see, with a simple search bar and a Google map to limit your search spatially. You'll be searching on tags and metadata we derive from the files initially, maybe other sources of metadata later. The Categories tab will be an alternate, categorical view of the data, based on hierarchical categories like data type, source, theme, etc.

maproom_mock_main.png

Dataset View This is the view of a single piece of data, or file. Shows all the metadata, tags organized by popularity (or most searched on?), and big bright download button. Oh and imagine an "Add a tag" text box there beneath the tags. WMS/WFS/WCS functionality is sort of something we might like later on down the road, but not immediately.

maproom_mock_dataset.png

The upload view will look very similar. Either you're remote user and you upload a file or you're an admin and you tell the application that you've put some data you'd like to add in a designated holding directory. The app will read the file, try to figure out as much of the metadata as possible, and then the uploader will have to fill in the required fields that the app can't figure out. It'll look a lot like the dataset view, except those fields will be editable.

Open Source Geospatial Foundation

/

Remember a little while ago when Mapserver and AutoDesk's MapGuide congealed into the Mapserver Foundation? Well now there's an even bigger umbrella group called the Open Source Geospatial Foundation, including not only Mapserver and MapGuide, but GRASS, GDAL, and OSSIM. Other big open source projects like PostGIS and QGIS don't seem to have joined yet, but maybe later. Hopefully this will bring about better consistency and interoperability across the world of open source GIS software. You can read about this at Directions Magazine

.

Mapserver Foundation

/

Mapserver is an open source web mapping software package that I use for the VTM site and that Brent uses for the Fire Information Engine. Recently, several core Mapserver developers announced the formation of a Mapserver Foundation, an organization intended to unite Mapserver with several related open source projects under a single banner for the purpose of standardized development and release procedures, and to provide a single body to mediate funding requests and donations, among other things. Most likely modelled after the Apache Software Foundations, this is certainly a Good Thing, as all these kinds of management and governance issues were previously handled in an ad hoc manner by the developers and a handful of contributing organizations like the University of Minnesota and DM Solutions, which has lead to a lot of inconsistency and occasional gaps in documentation.

However, in addition to Mapserver, the new Mapserver Foundation will also host the newly open sourced AutoDesk MapGuide, a web mapping package from the company that makes AutoCAD. Confusingly, MapGuide will now be known as Mapserver Enterprise, and the old Mapserver will be called Mapserver Cheetah (although the naming is apparently still up in the air). Several people in the Mapserver user and developer communities are peeved because the Foundation was planned without community input. Many are also displeased by this alliance with AutoDesk, a company not generally known for its commitment to open source. Some argue that this new naming scheme will confuse potential users and dilute the Mapserver brand, eventually resulting in less use and development for the traditional Mapserver we all know and love. While I think the new naming scheme is stupid and possibly detremental, I think the Foundation will ultimately be a force for good. Anything that provides greater stability and more documentation can't hurt, right? Links for the interested: Mapserver Mapserver Foundation AutoDesk MapGuide Official announcment of the Mapserver Foundation Comments by Ed McNierney (founder of topozone.com) Comments by Gary Lang (a lead MapGuide developer) Discussion on mapserver-users (a search for 'Foundation' should bring up most of the relevant threads, assuming there aren't any Asimov nerds getting way OT)

Open Source GIS Review (plus dynamic web modeling)

/

Aaron Racicot up at Ecotrust has recently posted his review of open source GIS software that he presented at the Oregon State University GIS Day. It's great material, providing an excellent overview of what packages are out there, what they're good for, and what they're not. He's also made some excellent posts on the OPENNR list about his work integrating open source tools in a web-based decision support tools for natural resource management.

Geodata Provider for the GIIF

/

Finding geodata can be frustrating. There is no Google for publicly available geodata, and even within our own lab data exists almost exclusively on individual workstations, fallow and unsearchable, like oil tragically buried under a wildlife refuge. However, the GIIF has the funding, resources, and collective brainpower to alleviate this problem (uh, with the geodata, not the oil). Behold, my vision of the future: a centralized geodata provision service (or G-P-S, not to be confused with Gap, Inc. stock). I see this as a centralized repository for data relevant to us, stored in a standardized, possibly version-controlled manner that enforces metadata creation, and searchable through a usable web interface that allows queries on metadata and spatial queries (i.e. show me all the transportaiton data in Alameda County created after 2003). Here are my thoughts. Does anyone else think this is a good idea or should I seek therapy? What other features would you like to see? Does this software already exist? Please comment!

Geodata Server

Who it would serve

  • GIIF users
  • CNR
  • UC Berkeley
  • general public
  • desktop users
  • GIS application developers (including webGIS projects)

Note this all implies some kind of access control

What it would serve

  • our own data (VTM, SOD models, fire models, wetland maps, etc.)
  • external data (TIGER, FRAP, CaSIL, US Census, anything that allows redistribution
  • spatially indexed links to external data where redistribution is prohibited
  • symbologies (recommended symbologies and/or visualizations for complex data, i.e. Mapserver layer definitions and ESRI .lyr files)

Geodata Portal Application

How it would serve data

How it would store data

  • extents stored in a geodatabase for retrieval via spatial query (box selection, search by distance, etc)
  • metadata stored in a database for retrieval by metadata query (by date, by source, by type, etc)
  • actual data maintained in original format (versioning? how do we deal with data in external geodatabases?)

How users would interact with the data

  • search for data via spatial and non-spatial queries (see above)
  • automatically generated previews (see what you're getting)
  • AJAX development techniques used whenever appropriate
  • submission: users should be able to submit new data, or modified versions of existing data
  • enforced metadata: all data subject must have certain kinds of metadata before being accepted (date created, source, accuracy. We can derive a lot automatically, like extent, file type, projection, file size, etc)

Other ideas

Possible models/inspirations

Possible software tools/components

Note extreme open-source bias... Definitely open to other suggestions.

GRASS and QGIS preview

/

Apparently GRASS and QGIS integration is coming along nicely: check out this really cool movie showing some of the QGIS/GRASS features in development. For those who don't know, GRASS is an open-source GIS software package that has been around forever and is fairly powerful, but has remained somewhat inaccessible by its steep learning curve and lack of a usable GUI. QGIS is another open-source GIS package with a nice ArcView-like GUI but lacking in deep functionality. Together, they fight crime

.

Dynamic GRASS map and PHP

/

Here's a small demo of PHP displaying a dynamically rendered GRASS map. The script just makes GRASS shell commands, and GRASS renders a PNG to a web-readable directory. I don't really understand the GRASS stuff, but the PHP looks dead simple. Tim, if the GRASS commands look relatively simple to you, maybe we could try this with a simple SOD model some time in the unspecified future.