Smathermather's Weblog

Remote Sensing, GIS, Ecology, and Oddball Techniques

Archive for November, 2011

Landscape Position: Conclusion?

Posted by smathermather on November 30, 2011

I’ve managed to pilot most of a fast high resolution landscape position workflow with PovRay as my magic tool. The final steps I hope to pipe through PostGIS Raster. In the meantime a screenshot and description: blues are riparian, raw ocre, etc upland categories, grey is mostly flat lake plain and mid slopes, all derived from just a high res DEM input (no hydro lines as input, so it works on areas where you don’t know where the streams may be). There will be more categories in the final, in the meantime, welcome to December.

20111130-221953.jpg

Posted in Analysis, Ecology, Landscape Position, Other, POV-Ray | Tagged: , , , , , , , , , , , | 1 Comment »

Complex Symbolization in GeoServer or Compass Rose Mania– the GeoServer Version

Posted by smathermather on November 30, 2011

At my place of employment, we have a vegetation survey program with enough potential plots to serve 50 years of data collection. The points are laid out in a Generalized Random Tessellation Stratified (GRTS) to maximize the statistical power of the analyses we do with them. Read more about GRTS. I dare you. Actually, it’s not so bad if you understand Quad-Trees and the like– it’s just a wicked clever way to ensure spatially-balanced random sampling in order to maximize power.

But GRTS is not the point. The point is that we wanted to show in a map a 40 ft meter buffer, with some cues for the cardinal directions for our field staff. We also wanted them to be able to make their own maps. Enter some funky complex symbolization with a dashed line for the buffer, and dots for the cardinal directions, kind of like thousands of compass roses across the landscape:

Compass Rose Mania-- the GeoServer Version

.

(BTW, find the flaw in this approach and you get my praise. That and a dollar will buy you a cup of coffee– hint: we’re working in a State Plane that is Lambert Conformal Conic).

SLD below:

<?xml version="1.0" encoding="ISO-8859-1"?>
<StyledLayerDescriptor version="1.0.0" xmlns="http://www.opengis.net/sld" xmlns:ogc="http://www.opengis.net/ogc"
  xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://www.opengis.net/sld http://schemas.opengis.net/sld/1.0.0/StyledLayerDescriptor.xsd">
  <NamedLayer>
    <Name>40 meter buffer</Name>
    <UserStyle>
      <Title>40 meter buffer</Title>
      <Abstract></Abstract>
      <FeatureTypeStyle>
        <Rule>
          <Title>40 meter buffer</Title>
          <Name>40 meter buffer</Name>
          <MaxScaleDenominator>100000</MaxScaleDenominator>
          <PolygonSymbolizer>
            <Geometry>
              <ogc:Function name="buffer">
                <ogc:PropertyName>the_geom</ogc:PropertyName>
                <ogc:Literal>131.2</ogc:Literal>
              </ogc:Function>
            </Geometry>
            <Stroke>
              <CssParameter name="stroke">#d3d3d3</CssParameter>
              <CssParameter name="stroke-width">2</CssParameter>
            <CssParameter name="stroke-dasharray">2 2</CssParameter>
            </Stroke>
          </PolygonSymbolizer>

          <PointSymbolizer>

            <Geometry>
               <ogc:Function name="offset">
                  <ogc:PropertyName>the_geom</ogc:PropertyName>
                  <ogc:Literal>0</ogc:Literal>
                 <ogc:Literal>131.2</ogc:Literal>
                 </ogc:Function>
            </Geometry>

            <Graphic>
              <Mark>
                <WellKnownName>circle</WellKnownName>
                <Fill>
                  <CssParameter name="fill">#bebebe</CssParameter>
                </Fill>
              </Mark>
              <Size>6</Size>
            </Graphic>
          </PointSymbolizer>
       
          <PointSymbolizer>

            <Geometry>
               <ogc:Function name="offset">
                  <ogc:PropertyName>the_geom</ogc:PropertyName>
                  <ogc:Literal>0</ogc:Literal>
                 <ogc:Literal>-131.2</ogc:Literal>
                 </ogc:Function>
            </Geometry>

            <Graphic>
              <Mark>
                <WellKnownName>circle</WellKnownName>
                <Fill>
                  <CssParameter name="fill">#bebebe</CssParameter>
                </Fill>
              </Mark>
              <Size>6</Size>
            </Graphic>
          </PointSymbolizer>
          
          <PointSymbolizer>

            <Geometry>
               <ogc:Function name="offset">
                  <ogc:PropertyName>the_geom</ogc:PropertyName>
                  <ogc:Literal>131.2</ogc:Literal>
                 <ogc:Literal>0</ogc:Literal>
                 </ogc:Function>
            </Geometry>

            <Graphic>
              <Mark>
                <WellKnownName>circle</WellKnownName>
                <Fill>
                  <CssParameter name="fill">#bebebe</CssParameter>
                </Fill>
              </Mark>
              <Size>6</Size>
            </Graphic>
          </PointSymbolizer>
          
          <PointSymbolizer>

            <Geometry>
               <ogc:Function name="offset">
                  <ogc:PropertyName>the_geom</ogc:PropertyName>
                  <ogc:Literal>-131.2</ogc:Literal>
                 <ogc:Literal>0</ogc:Literal>
                 </ogc:Function>
            </Geometry>

            <Graphic>
              <Mark>
                <WellKnownName>circle</WellKnownName>
                <Fill>
                  <CssParameter name="fill">#bebebe</CssParameter>
                </Fill>
              </Mark>
              <Size>6</Size>
            </Graphic>
          </PointSymbolizer>          
          
          
        </Rule>

      </FeatureTypeStyle>
    </UserStyle>
  </NamedLayer>
</StyledLayerDescriptor>
</code></pre>


Posted in GeoServer | Tagged: , , , , | 5 Comments »

CartoDB, Leaflet, and a little anti-generalization

Posted by smathermather on November 28, 2011

CartoDB is one of two hosted (read: cloud) PostGIS database implementations.  It has a maps API, an SQL API, and is some fun to use.  The other hosted PostGIS implementation is SpacialDB which has a Restful API, but can also take SQL.  I just got my key for the free version of that, so hopefully I will be reviewing use of that in the future too.

I can’t beat Bill Dollins’ post CartoDB + Leaflet = Easy, and I hadn’t played with Leaflet before, but am often up to my eyeballs in OpenLayers, so I thought I’d build off Bill’s post.  I haven’t, well, not substantially anyway.  But I did start to and found some strange behavior in displaying GeoJSON in Leaflet, under the right conditions anyway.  This is what I got:

Difference between properly displayed GeoJSON, and GeoJSON with missing point.

The green line shows the correct line, the dark gray line shows how it’s being displayed noticeably incorrectly by Leaflet.  I was about to post to the CartoDB website when I dug a little further:

The problem goes away as you zoom in...

The problem goes away as you zoom in…

and also as you zoom out...

and also as you zoom out… leading me to conclude it’s not a CartoDB issue, but a leaflet issue, as the GeoJSON geometry is not re-requested based on zoom level.  But is it a bug?  I suspect not.  I suspect it’s a feature– I suspect leaflet is auto-generalizing the geometry of the GeoJSON by dropping the occasional node.  Since we have so few nodes along the southern boundary, it matters here.  Maybe they should use a Douglas-Peucker or similar algorithm, but that may not be practical as it’s difficult to know a priori what the tolerance value should be (of course, the Leaflet user might know what value to use, however…).  I’ll post to the leaflet forum tomorrow to find out.  In the mean time, my fix is simple.  Instead of a simple load of the CartoDB geometries:

http://supersecret.cartodb.com/api/v1/sql?q=SELECT%20name,%20the_geom%20FROM%20boundary&format=geojson&callback=?

We’ll use the SQL API to complicate the geometry on the fly with ST_Segmentize, which will add extra nodes in anticipation of Leaflet simplifying it:

http://supersecret.cartodb.com/api/v1/sql?q=SELECT%20name,%20ST_Segmentize%28the_geom,%200.0001%29%20AS%20the_geom%20FROM%20boundary&format=geojson&callback=?

Yup.  It’s a hack.  I’ll have to find out if there are any alternative (less hackish) solutions.

BTW, rockin’ the CartoDB, but hate thinking in geographic to do segmentization.  In market fairness, I’ll try something similar with SpacialDB soon.

Posted in CartoDB, Database, Leaflet, PostGIS, PostgreSQL, SQL | Tagged: , , , , , , , | 5 Comments »

EcoHackNYC– Cool projects, fun new ideas, human waste, CartoDB and other flotsam.

Posted by smathermather on November 7, 2011

I took a bus to New York City this weekend to enjoy the company of fellow hackers at EcoHackNYC, organized by Javier Torre and Andrew Hill of Vizzuality and Robin Kraft of REDD Metrics.  Due to delays in Pittsburg, I missed the ignite talks on Friday, arriving on NYU’s campus on Saturday morning. Several groups formed around topics and we started hacking. I worked on Robin Kraft’s crew– helping to put together a draft visualization of deforestation data for Indonesia. I suspect that something interesting will continue to evolve out of that project. Robin envisions visualizations for tropical deforestation on a monthly basis globally, and he’s not far away from that. It should be really great to see. We also got some wild-eyed data visualization/HTML5/data transfer protocol ideas out of that project, thinking about how to stuff any sort of data into a PNG tile.  The cool thing is that while our wild-eyed plans would require special data prep, they would not necessarily require changes to existing middlewhere/tile-rendering software initially, just client level magic. More on that later, unless we discover we’re re-inventing aluminium rims and someone has already built a hot rod.

It turns out, when I stayed in a hotel in Midtown Manhattan, had it been raining hard enough to activate the CSOs, my waste would have come out just upstream from the UN. True story.

For now though, I’ll highlight one of the more polished products presented at the end of the hacking event the Don’t Flush Me project (warning– potty humor and mild curse words involved). I did not work on this project. With so many pun opportunities I probably would have derailed the project with linguistic abuses of monumental puniness, so maybe it’s for the best. I’m holding back right now. I just want you all to appreciate that. I like potty puns so much, they are my first and second most favorite pun type. That said, the best pun of the night was by a gentleman named Francois who was with the big-carbon-footprint group (meaning they flew in from Brazil for the conference– it was nice to have the international contingent). I’m always particularly impressed with puns done in an individual’s second language. It shows true mastery. Of course, now I can’t remember the pun. Anyway, I digress substantially more than usual.

Quick 3rd party description of the project: Don’t Flush Me took the combined sewer overflow (CSO) pipe diagrams and outfall data for Manhattan and created an interface that geocodes from address or IP and returns a polygon that shows the shared sewershed and overflow location for the input location.

Additionally, it has the Wunderground API wrapped in, in order to report whether there has been rain in the last day for your sewershed. Further work on the project would model capacity vs. rainfall and report whether you should wait to flush, and other such features. There are some small browser-dependent geocoding api bugs, but that’s forgivable considering this was put together in fewer than 8 hours. Also, the code is reportedly not particularly well organized yet. But who cares– the functionality is awesome. As an aside, if memory serves me, the back end PostGIS services are hosted in a CartoDB instance.

I think Don’t Flush Me could serve as a great model for reporting mechanisms for Sewer Districts with CSOs. Brilliant, well-scoped, and well-executed work, also fun to use. If you are not in Manhattan, here are a couple of addresses you can feed into the geocoding engine:

11 West 53 Street  New York, NY 10019

1 Wall Street, New York, NY

and an homage to the kindness of strangers:

Chelsea Park, New York, NY.

Posted in Conferences, EcoHackNYC, Ecology | Tagged: , , | Leave a Comment »