2007 (old posts, page 3)

Atom feed RSS feed

More Geo-JSON

Platial's Chris Goad is offering JDIL as a way forward for Geo-JSON. JDIL (I presume this is an acronym for JSON Data Integration Language) is used at Platial to map RSS 1.0 XML feeds to JSON [example feed]. It's thorough and seems a decent solution to the problems particular to RSS 1.0, but those problems don't exist in my applications.

The reason for the interest in Geo-JSON, for those who aren't familiar with JSON, is twofold: JSON can be evaluated by your browser's javascript engine, and, wrapped in javascript, can exploit a hole in your browser's same-domain policy (nicely explained by Douglas Crockford here) and allow you to integrate geo-data from diverse sites. The same-domain policy prevents us from using XML, and efforts to port XML features to JSON seem to be an inevitable result. I'm not as pessimistic about these efforts as some.

The Geo-JSON I am using for Pleiades [wiki, example] is inspired by Atom 1.0. There's no pastiche of namespaces, and, as far as I'm concerned, any specialized content could be carried as an escaped XML string property. I also prefer arrays of numeric coordinates to JDIL's georss:type string property, as it removes the need to parse a string on the client end. What to do about polygons with holes or multi- types is an open question. I think the way to go is to follow WKT, but with arrays of numbers instead of text.

Comments

Re: More Geo-JSON

Author: Tom Kralidis

Have you tried processing remote-site XML with proxies? Note that, in Apache, you can do a bit with mod_proxy, or you can have a proxy script (Mapbuilder has this for remote XML services).

Re: More Geo-JSON

Author: Sean

Sure, but that's beyond the ability or means of most users.

Re: More Geo-JSON

Author: chris goad

Putting coordinates inside strings, rather then in arrays or structures, comes from GeoRSS . JDIL itself doesn't care - it provides encoding for whatever vocab is of interest (the examples happen to use GeoRSS) I agree that it's better to expose the structure of the data directly in JSON, rather than requiring string parsing. The w3c geo vocab does this, but only for points. Maybe a future standard will fill this gap ....

Re: More Geo-JSON

Author: Rob

We've done something very similar... 
{
  "version": "1.1",
  "srid": "EPSG:2193",
  "items": [
    {
      "id": 1234,
      "point": [1729539, 5914273],
      "title": "TEST_1234",
      "link": "http://example.com/url/for/poi/1234"
    }
  ]
}
(it's also valid to use 'linestring' or 'polygon', in which case it's an array [x0,y0,x1,y1, ...]) Which is similar to the content transferred via GeoRSS... 
<feed xmlns="..." xmlns:georss="..." xmlns:gml="..." >
  <id>http://url/of/georss/atom/feed</id>
  <title>GeoRSS Atom Example</title>
  <updated>2005-06-06T00:00:00Z</updated>
  <entry>
    <id>2230</id>
    <updated>2005-06-06T00:00:00Z</updated>
    <title>Test Point 2230</title>
    <summary>Summary of Test Point 2230</summary>
    <georss:point>174.568911290684 -36.9276921875886</georss:point>
    <link href="http://url/to/detail/on/point/2230" />
  </entry>
</feed>

Plone Snowsprint Roundup

Kai Lautaportti launches his brand-new blog with a roundup of PrimaGIS activities at the Snowsprint. What I'm most excited about is the new WMS support, which paves the way for integration with OpenLayers.

For PrimaGIS itself the WMS support means that, for example, it's now possible to chain multiple PrimaGIS maps together so that one PrimaGIS instance is able to use the data provided by another. Another cool thing was that we can now provide alternate UIs for the PrimaGIS maps. As an experiment I integrated the Open Layers Javascript UI into PrimaGIS which worked right out of the box. All this code is still very experimental and in the future we will need push most of it into OWSLib and have PrimaGIS use that to implement WMS support.

Suprisingly Quiet

I can understand letting the birthday of the MapServer Foundation quietly slide by, but I expected a little more buzz about this OSGeo milestone.

1 year ago.

Comments

Re: Suprisingly Quiet

Author: markusN

In fact - we were just overcommitted! Now there is a posting available at http://www.osgeo.org/tyler/: "OSGeo Celebrates 1st Anniversary"

Sprint Track at FOSS4G 2007

Paul Ramsey has been thinking about software sprints too. My experience at the Plone Conference sprint is that one day isn't enough unless the participants do this kind of work regularly.

The Wehlener Sundial

Over the weekend I went on a few virtual vineyard tours in preparation for WBW #30. In Germany, on a slope above the Moselle, facing the town of Wehlen, I found the Wehlener Sundial. The vineyards around the sundial are hot, steep, rocky, and worked almost entirely by hand. I know very little about German wines, but found the 2002 Wehlener Sonnenuhr Reisling-Kabinett from Dr. H. Thanisch to be a fine introduction. I haven't yet read a good explanation for how the Moselle winemakers can get such ripe-tasting, fruity wines with only 8-9% alcohol. Good stuff. The physiography of the Moselle region is equally fascinating.

Geospatial Code Sprinting

Jason Birch writes:

P.S. OK, one thing annoys me more than non-contributing users: businesses that use open source software and give nothing back. If you're leveraging open source software for competitive advantage, spin some of that back to the development community in code or $$$. Something as simple as contributing space, cola, and pizza for a code sprint can make a huge difference.

The open source GIS community, with a few exceptions, hasn't done code sprints. I used to advocate for MapServer code sprints at past meetings, but there was little interest. OpenLayers is one project that could have successful community sprints. There are a lot of energetic, can-do programmers, a solid testing framework, and all you need is a text editor and a modern web browser. My understanding is that MetaCarta already has in-house sprints of a sort, and these could someday be expanded to include community developers.

Comments

Re: Geospatial Code Sprinting

Author: Paul Ramsey

One thing (but not the only thing) we are going to add to FOSS4G is a day at the end for code sprints and project team meetings. Self organized, self directed, we'll provide a conference room and internet connectivity, the projects provide the rest. Watching the Geotools team spend last years conference sprinting on the exhibition floor made me say "there has to be some way these guys can do this without missing the whole conference".

Re: Geospatial Code Sprinting

Author: Christopher Schmidt

The biggest problem with code sprints for OpenLayers is actually getting everyone in one place. Even within MetaCarta, it's difficult, which is why they probably seem like sprints in the first place: Basically, any time that Erik is in town, the three of us hack on OpenLayers. This leads to a major development push about every 3 months, since that's how often he flies through. There are no other major developers of OpenLayers within 4 hours, though, which means that offering the space for a sprint is less useful. I'm sure that if we had anyone else in town other than Schuyler and I who were working on code, we'd be happy to have them around, and typically the weeks that we have developer time, I spend a lot of time on IRC trying to make sure we're doing the right thing with all the patches we have outstanding. It's not a perfect solution, but geographic distance provides a lot of difficulties -- communication and logistics chief among them -- to the extent that I'm not convinced that a company can actually offer space for a code sprint effectively without being near a conference location to begin with.

Re: Geospatial Code Sprinting

Author: Jason Birch

Hmm. Guess I should have added in airfare and accommodations :) I see your point. Is there anything else that businesses can do that is easy for them and typically difficult or costly for the community to do on its own? Jason

Re: Geospatial Code Sprinting

Author: Andy

When I worked for AT&T which later became Comcast and now I hear it became Cingualr or Cingular became it, whatever I can't keep track of it anymore. Anyway at AT&T we used a lot of open source and we would frequently pick functionality that we thought we would like or that we thought the community in general would like and we would pay to have it put in there. Collections in the MITAB library is one example I can remember off the top of my head. After the Mapserver / Autodesk thing though I am not sure how often the Oregon & SW Washington market of Comcast does this anymore last I heard they had stopped doing it due to that little fiasco but up until then they did it quite often. I am just saying not all large companies are bad about using Open Source and not giving back.

Re: Geospatial Code Sprinting

Author: Christopher Schmidt

I think the biggest thing that can be offered by many companies is computing resources. Via MetaCarta Labs, we provide over a half dozen tile sources -- from Blue Marble to Vmap0 to TIGER -- against a TileCache source. The result is that the world is now getting over 300,000 map tiles a day served by MetaCarta servers. The Telascience resources coming online via OSGeo are another example of this type of support: Landsat served from some set of high-powered servers which is not controlled by NASA, and therefore is not subject to the same beuracratic limitations. I think that fast server resources are the single thing that large companies have lots of that open source projects don't, and making them more available is the benefit that companies can offer.

No Fan Love

Often it seems that the Fair Use and anti-DRM movements have no greater ally than the big media companies themselves. Everytime a company loads rootkits on customer machines, sues the family of music-downloading a teen for all it's worth, or comes after churches for showing the Superbowl on too large a TV screen, more damage is done to the old copyright regime than I could do in a million blog posts.