2006 (old posts, page 9)

Community Map Symbols

I was just asked if I knew of a comprehensive set of openly licensed map symbols:

I have been searching for a set of fairly 'classic' map symbols, that is reasonably complete; classic meaning that the symbols actually convey some meaning, without being overly fuzzy and complex, so it is easy to extend the set without having to imitate somebodies idiosyncratic style.

I'm not aware of such a thing. But it occurs to me that this might be just the job for the OSGeo foundation. High quality free and open source symbols would break down another one of our long-standing barriers to deployment. They might even be able to pay for themselves. OSGeo could relicense them for use with MapGuide Enterprise or other commercial editions of OSGeo products.

Here are the requirements, as I see them:

The time is now for scalable vector graphics. With the help of several style sheets, we'd have a whole family of symbol sets: greyscale, section 508, or retro web-safe. MapServer can't use them directly (yet) but there are a number of open source tools -- like GIMP -- that can convert SVG to old school pixmaps. It also wouldn't be terribly difficult to convert simple SVG symbols back to MapServer's own symbology language with a little mapscript fu. Future versions of OSGeo software, like a MapServer 5.0, will want to use SVG directly.


Re: Community Map Symbols

Author: Holger Will

just some thoughts on this: you might want to ask at http://openClipart.org, there are a lot of talented artists, who are very helpful. these sybols is exactly what fits into the OpenClipartLibrary i think. for converting SVG to bitmaps, i suggest the Batik rasterizer ( http://xmlgraphics.apache.org/batik/ ). anyways, great idea ;-) cheers Holger

Re: Community Map Symbols

Author: Matt Perry

You might want to check out the Green Map icon system... a collaboratively developed set of symbols for "linking ecological and cultural resources" on a map: http://www.greenmap.com/home/icons.html I'm not sure what kind of license they fall under or what format they're available in. But the idea is alive.

Re: Community Map Symbols

Author: Chris Tweedie

From my experience its sometimes impossible to determine licensing restrictions based on symbols. ESRI font symbols come with a copyright attached (no mention of restricted use though) and i think Mapinfo also does, but many other font based (truetype) and graphic based (bmp, png, svg) ones come with no attribution at all. I recently was stumbling around the web trying to find these elusive "open symbols" but a lot were actually combined collections of copyrighted works or of terrible cartographic quality. Talk about confusion. I ended up using the good old pencil in Freehand to create my own works ... imo, OSGeo would be a good medium to start an "open cartographic library" project

Re: Community Map Symbols

Author: Rob McCulley

I agree completely. It would be great to see an svg library of map symbols under a creative commons license. Kind of like the tango project for maps (http://tango.freedesktop.org/Tango_Icon_Gallery). Hopefully the major players would allow SVG as a symbol option as well (ESRI, MapInfo, Autodesk etc. I'm looking at you).

Re: Community Map Symbols

Author: Micah Cochran

> you might want to ask at http://openClipart.org, there are a lot of talented artists, who are very helpful. these sybols is exactly what fits into the OpenClipartLibrary i think. If you look in the Signs and Symbols collection of the openclipart.org, http://www.openclipart.org/cgi-bin/navigate/signs_and_symbols you can find many symbols that could be used to various mapping purposes. The licenses of those symbols vary, but are generally Public Domain.

Planet Geospatial is not a Group Blog

I disagree with Adena's take on Planet Geospatial as a group blog. Boing Boing is a group blog. The GeoRSS Blog is a group blog. The Stoa Consortium is a group blog. Planet Geospatial is a feed aggregator. I've worked with James Fee to get markup that is easy to monkey with, but that's as far as I consider it a joint venture. Not that I'd be opposed to participating in a group blog.

Speaking of the blogosphere: I'm looking to blog swap for a week or so with a food or wine blogger that has a equal itch to try writing about the software and data side of viticulture, terroir, geography, and maps. Interested? Send me an email.


Re: Planet Geospatial is not a Group Blog

Author: Adena Schutzberg

Right, I can't disagree. My appologies for using shorthand in my discussion; I know PlanetGS is a feed aggregator. I think it fullfils the role of a group blog in our arena.

Re: Planet Geospatial is not a Group Blog

Author: Sean

I forgot to mention All Points Blog! Imagine if the other writers cranked out posts more regularly. A group blog that's plainly missing is an OSGeo blog. There's no way to know what's going on in that hive without lurking on #osgeo or subscribing to its score of email lists.

Ruby, REST and YAML

Here's a good article by Charlie Savage: A Community for REST. I appreciate the work that the Rails community is doing to push back against WS-*. The other thing I think Rails does exactly right is use of YAML for configuration instead of XML.

Users of GDAL have a couple virtual formats at their service. The Python Cartographic Library is using these for configuration of filesystem-based data stores. The thing is, there are no schemas for these XML languages, there's no way to validate, there are no fancy tools for making virtual files other than your text editor. So why bother with XML? As I see it, here's a great use case for YAML. Instead of:

  <OGRVRTLayer name="world_borders">
    <SrcDataSource relativeToVRT="0">world_borders.shp</SrcDataSource>

we could have:

    - name  : world_borders
      path  : /data/world/world_borders.shp
      layer : world_borders
      srs   : EPSG:4326


Re: Ruby, REST and YAML

Author: Tom Kralidis

Good point. I posted about this a couple of months ago, and I agree. XML is not for everything, that's for sure. Some may argue that having this type of info in XML allows for easy parsing across a wide variety of languages, but then again there are many YAML parsers out there too. YAML wouldn't be a bad MapServer mapfile format, don't ya think? :)

Pro Cycling, You're Killing Me

I feared that it might be too good to be true. Perfect bookend scandals. I sincerely hope that Landis' B sample clears him.


Re: Pro Cycling, You're Killing Me

Author: Chris

I hear ya! I'm hoping for a clean B sample too but even if that's the case many people will still be suspicious...

Re: Pro Cycling, You're Killing Me

Author: Matt

Argh! Howwa bout it. This sucks. I think Floyd is really a angry warthog under the Mennonite exterior. That might explain the high levels. I hate that cycling is a "guilty until proven innocent" sport. If Landis is clean, his name is now soiled. Why do they leak crap like this before they have the B sample tested. If Floyd did do it, I don't know if any pro can be trusted. "Free Floyd" ;)

Re: Pro Cycling, You're Killing Me

Author: Morten

I'll bet he got his shot of testoterone the day after Alps Duez, where he went out of top 10. At least that explains how he got back into the game the day after. All bikers gets shots of this and that. Most just don't over-do it and keep their levels below the threshold (as long as they are below the limits, it's not illegal is it?).

Incubation Follow-Up

Last week I objected to the OSGeo Foundation overselling the rigorousness of their software incubation process, and challenged the incubation committee to raise their standards. The sitting OSGeo president, Frank Warmerdam, wrote (in comments) to suggest that I could have worked within the committee, using vetos to hold back projects until they'd made serious progress.

I'm a programmer, not a politician, and I've no interest in playing politics like that. I've got many other better things to do with my time. There are tests to write, tickets to be resolved, milestones to be set, and code to be released. And the other folks in the committee wouldn't stand for it. I'd be tarred and feathered. Every project in the incubator has been guaranteed that they'll be promoted. Every member of the committee (except for me, at the time) is also representing an incubating or "on-deck" project, and there is rather high social pressure on committee members to not impede each other's projects.

Does unwillingness to spend a big chunk of free time trying to reform the incubation committee disqualify me from criticising the process? Not in the least. I'm an open source geospatial software developer too, and will be profoundly affected by the actions of OSGeo. Let me try a metaphor on you: I'm not the guy in the back seat of your car second-guessing how you drive, I'm the guy on the bicycle yelling at you to drive carefully.

Ruby and Geospatial?

Ruby is the best thing since sliced bread. It embraces Perl refugees, gurus love it, and you're nothing but a chump if you're using a sucky language like Python or Java. So says the blogosphere. Why then -- with the exception of Charlie Savage's work with GDAL and GEOS -- does it seem that there is nothing significant going on at the intersection of Ruby and Geospatial? There are a few Ruby MapServer users, but no committers. There are a few modules for Google Maps (even I wrote a simple one), but that's just pushpin country. Where are the Ruby modules for cartographic projections? Where are the Ruby W*S clients? Am I missing something right under my nose?


Re: Ruby and Geospatial?

Author: Dave

I think that this just shows the size of the "geo" developer community as compared to the main stream developer community. Ruby will catch on in the geo-space, but it's gonna be slower. And since it's coming from the leading edge of main stream, those people will look for geo-API integration before whipping up full WMS connectors. I'd bet that it will be push-pin land for a while. It would be really cool to see a Ruby back end integrated with OpenLayers - so you have a server side layer that can control the access to the WMS, rather than an uncontrolled client side JS festivus. Cheers, Dave

Re: Ruby and Geospatial?

Author: Shaun Walbridge

I sense a partially rhetorical question, but I'll bite: From what I've seen, Ruby does seem to be an elegant, enjoyable to use language. But the second step, implying that all other languages are sucky is patently false: If you're Paul Graham, you see everything as just being weak rehashes of Lisp, but languages are tools, not one-size-fits-all baseball caps. Python, Java, C# all have their virtues over Ruby in particular scopes. A concurrency wieldin', Unicode passing code jockey would probably bristle at the idea of using Ruby. As Dave mentions, the size of the community also matters: both the geo-developer and Ruby communities are small. Ruby is too new to have a fleshed out set of libraries, even compared to its brethren dynamic languages it must have an order of magnitude more available libraries. It is the reason why the best RoR blogging software, Mephisto is almost unheard of, and David Heinemeier Hansson uses PHP stalwart gallery — it takes time to gain that critical mass of applications that make a language really attractive. I think its a testament to the alpha geekness of geo-developers that they have Ruby bindings. P.S. the comment box sucks rocks, could you bump the cols to 80+?

Re: Ruby and Geospatial?

Author: Sean

I know. Coreblog smells, but I'm hooked on using restructured text to write posts. I'll see what I can do.

Watch Your Back, World Wind

NASA's mission statement has been modified. Look out for the Kiss of Death in a form like this:

President Bush today praised the NASA World Wind project, calling it an "amazing new way of discovering our environment".

How Rigorous is OSGeo Software Incubation?

It pains me to have to continue to write about what I consider to be faults of the new OSGeo Foundation, but as an unaffiliated developer of open source geospatial software, it's the only influence I have. I want these faults to be addressed. OSGeo must succeed, if only because its failure would wreck the wider open source geospatial domain. I've got friends who are deeply involved, and I'd like success for their sakes. I'm also worried that in this early stage, before it really finds its feet, our gentle OSGeo giant is going to stumble around and break things, or tread on worthy, but less ambitious software projects.


As Rigorous as we want it to be :-)

Author: Jody Garnett

For the first round of projects we are setting our own benchmarks and taking stock of the result. Some projects like GeoTools are raising their own bar fairly high resulting in a marked improvement. So far on our list is: - (C) to OSGEO (to pack IP check) - User Documentation with complete Coverage (something we have not had in 10 years) And I expect many more requirements will surface as we look at what these initial projects accomplish: - marketing materials - documented release cycle

Re: How Rigorous is OSGeo Software Incubation?

Author: Frank Warmerdam

Sean, You raise some interesting points. I was a bit surprised to read "but as an unaffiliated developer of open source geospatial software, it's the only influence I have." You were on the committee, and could have stayed there, and veto'ed graduation till you felt reasonable steps had been taken. I would claim that OSGeo is a do-ocracy, and you could have had a direct influence if you had wanted to. Second, the Mapbender PSC does have a functioning, albeit lightly used Sourceforge bug tracker. In a Mapbender PSC meeting they discussed it and agreed to encourage use of the bug tracker in the future. I'll agree this isn't quite the same as demonstrating a culture of using the bug tracker, but we made a call that this was a reasonable step in the right direction. Third, while two of the GDAL's PSC have subcontracted to me in the past, I don't think they are terribly dependent on me. However, I did select the initial PSC I did based in part on them being folks I felt were comfortable with how the project works, and I could work with fairly well. In the past I have described this as "packing the PSC with my cronies". In the Apache process they stress the need to take "ability to cooperate effectively" as an important criteria for their equivelent of PSC membership. In other venues I think I might deliberately try and include a wide diversity of views in a democratic group, but I don't feel especially constrained to do so for software projects PSCs which need to have quite a degree of mutual trust and respect to operate effectively (IMHO). I do feel that each of the members brings experience and a unique view point even if they aren't dramatically divergent. And they have all been willing to beat me into more progressive approaches in the past. Best regards,