Lawn Mowing

In Class Exercise

package agentSystem;

import igeo.IVec;
import igeo.IPoint;

public class MowingAgent extends Agent {

float vel = 25;
double mowerwidth = 25;
double desiredoverlap = 0.25;
IVec baseDir;
IVec currDir;
boolean done = false;
int time = 0;
IPoint pt;
IVec newPos;
double turn = 1.57;

public MowingAgent(AgentManager _p5, IVec _pos, IVec _bdir) {
super(_p5,_pos); = new IPoint(this.pos);
this.newPos = new IVec(this.pos);
this.baseDir = _bdir;

public void mow() {

//determine which direction I need to be going
//change direction
//turn opposite each time
this.turn = -this.turn;
//turn around and shift down to get the desired mower overlap
this.newPos = this.pos.dup().add(this.currDir.dup().rot(this.turn).len(mowerwidth-(mowerwidth*desiredoverlap)));
//get back into the lawn


//determine how far Im mowing


public boolean inBounds() {
return this.p5.boundaryCrv.isInside2d(this.pos);

public void update() {
if(!done) {
} else {
System.out.println("whew, time for a beer");

public void redraw() {
pt.pos = this.pos;



Routing the water path

593 Yikai_4weeks

— 2. create topology
drop table street_vertices_pgr;
alter table street drop column source;
alter table street drop column target;
alter table street add column source integer;
alter table street add column target integer;
select pgr_createTopology(‘street’, 0.0001, ‘geom’, ‘id’); — function create table ‘street_vertices_pgr’
— 1.join building information
WITH building_updated
AS (
SELECT, b.geom, b.bldg_id, b.shape_area, n.pri_neigh, st_centroid(b.geom) AS cen_pt, z.zone_type, b.shape_area*z.zone_type AS water FROM building AS b
LEFT JOIN neighboorhood AS n
ON st_within(b.geom, n.geom) — result table will be called ‘building_center’ or update ‘builidng’
LEFT JOIN zoning AS z
ON st_within(b.geom, z.geom)

— 3. finding nearest pt
AS (
SELECT DISTINCT ON( g1.*, ::INT4 As node_id,
FROM building_updated As g1, street_vertices_pgr As g2 — g1 = source table ; g2 = target table
AND ST_DWithin(g1.geom, g2.the_geom, 1000)
ORDER BY, ST_Distance(g1.geom,g2.the_geom)

— 4. routing
AS (
SELECT seq,id1, id2 as node, id3 as gid, route.cost, street.geom FROM pgr_kdijkstraPath(‘
SELECT id as id,
st_length(geom) as cost
FROM street’, 001, array(SELECT “node_id” from building_final), false, false )
AS route
LEFT JOIN street
ON route.id3 =

— 5. Join water usage to route
SELECT SUM(bf.water), r.gid, r.geom
FROM building_final AS bf
LEFT JOIN route AS r
ON bf.”node_id” = r.id1
GROUP by r.gid, r.geom;

Nearest point ref:

Zoning Reference:

Screen Shot 2014-02-21 at 12.27.42 PM

Screen Shot 2014-02-21 at 1.35.38 PM

Tutorials and Resources for Spatial Analytics in PostGIS SQL and QGIS

This post is a repository of useful tutorials, workshops, demonstrations, and reference for spatial analytics and modeling in the Postgres, PostGIS, and QGIS. Please add links to this post as you discover useful sites (include a brief description of the site).

  1. w3schools – a very useful site on the fundamentals of (non-spatial) SQL queries, including tutorials on joins and SQL functions such as AVG()
  2. boundlessgeo – an excellent primer on many of the PostGIS spatial functions, great place to get your feet wet with PostGIS spatial analytics/modeling
  3. spatialthoughts – this site provides tutorials in a wide range of techniques in QGIS
  4. linfinity – this site provides a number of tutorials clearly illustrating spatial analytic approaches using QGIS
  5. Geospatial Analysis – 4th Edition” by de Smith, Goodchild, Longley – this textbook provides the conceptual and geometric principles of spatial analytics and modeling – an excellent resource.

UML Modeling + Class Diagrams

UML (Unified Modeling Language) is a standardized notational system for diagramming the relationships between objects. It is designed to help organize programming code, particularly in object-oriented programming languages. It is a useful way to quickly diagram the various components of a code and their relationships to each other. It provides a bridge between the real world elements to be modeled and the logic of the computer code.

We will be using UML Class Diagrams as a way to organize our research and specify the relevant objects in the system we intend to model. Class diagrams describe the structure of objects to be modeled and their relationships to each other. Understood in its simplest form, it describes a taxonomy of objects. For instance, a taxonomy of animal “objects”:


The most important question when making a class diagram is: WHAT IS ESSENTIAL?

If we were interested in modeling cats, we might ask what is essential to the family felidae? What characteristics and behaviors are shared by all members of this family? When starting a Class Diagram, begin with the objects themselves, before considering any relationship between objects. An object has three types of components: NameAttributes, and Operations. Attributes are the variables that define the characteristics of a class (size, color, id, etc.), operations are behaviors the class is capable of preforming (move(), eat(), addValue(), etc.).

Screen Shot 2014-01-30 at 1.02.52 AM

The Tiger Class inherits all of the attributes and operations from the Felidae Class, adding additional attributes and operations that are essential and particular to the tiger. The class diagrams moves from the general to the specific by way of inheritance. Inheritance describes the parent-child relationship, and the passing of shared traits. The inheritance relationship is of the form ‘IS-A.’ a Tiger IS A Felidae.

When we define an attribute, we give it a name and a data type. For instance, the attribute “weight” is of data type “double” (a floating point number), and “numberStripes” is an “int” (an integer). So, weight could be 356.45, while number of stripes will always be a whole number, i.e 37. Common data types are:

  1. int: integer (1,2,3,4,5…)
  2. float: floating point number (4.5353)
  3. double: a more accurate kind of floating point number (5.23423545)
  4. character: one character of any kind (“a”, “6”, “%”)
  5. String: a list of characters (“hello world”, “5555”, “test123”)
  6. Boolean: true/false
  7. Other classes!!!

Data type #7 is a special case. Once you start defining attributes in one class as an object from another class, you introduce the second kind of relationship in Class Diagrams. This is called association. If inheritance is a ‘IS-A‘ relationship, association is a ‘HAS-A‘ relationship. In the example below, a person HAS A cup and a cup HAS A owner – The attribute “item” has data type “Cup”:

Screen Shot 2014-01-30 at 12.08.22 AM

In the above diagram, you can start to see the power of inheritance. By defining the data type of “item” as the class “Cup”, we have established a relatively simple structure to allow the “person” to hold many different kinds of cups. Any child of Cup could be used in the attribute “item.” A person could hold a coffee cup or a plastic cup, or both, with all their particular characteristics and behaviors.

As you can see, a Class Diagram with only 4 classes already begins to describe fairly complex relationships. With this in mind, I would encourage you to start your diagrams small and  work through the implications of their attributes, operations and data types. Make a separate class diagram for each of the objects with which you are working . Only start connecting them when an explicit inheritance or association relation will allow you to describe the system you are modeling with more clarity. It is much better to have a number of smaller diagrams that are fully worked out and legible then one big spaghetti diagram that nobody can understand.

Always, the question in your head should be WHAT IS ESSENTIAL? What is essential to your model, and what is essential to each class? Remove anything that does not have a specific, real, verifiable relationship to your model. The goal of UML diagramming is to find the simplest way to model complex situations.

There are many resources on the web for UML modeling. You can find more detailed information on the notation of class diagrams here. Some video tutorials for making class diagrams in the Astah UML modeler can be found here and here.


Laster semester we utilize two kinds of clustering  algorithms to do our analyze. The first one is distance based clustering, the second  one is grid based clustering. Although logically they are very similar, both of them are forming clusters based on distances, they are different in doing this, and results can be different. Below is the logic of these 2 algorithms.

A. distance based  clustering:

1. Buffering every single points with a distance which can be set by analyzers.

LB cluster1

2. Merging circles which have larger overlaps than the setting number into clusters.

LB cluster2

B. Grid based clustering

1. Set the distance of grid lines. Divide the target area by grid.

grid cluster1

2. Locate points into cells, then look at neighbor cells of target cell. If there is point in theses neighbor cells, merge these points as core of a cluster.

grid cluster2

3. Making convex hulls based on these cores of cluster. There is a parameter through which you can control the size of clusters.

grid cluster3

Blow is the SQL for Grid based clustering

WITH clstrtags AS ( SELECT *, tag.geom as tgeom FROM gridcluster(30,’urbantag’,’geom’) as grid
JOIN urbantag as tag
ON st_contains(st_setsrid(grid.geom,3435),st_setsrid(tag.geom,3435))
ORDER BY rid,cid
counts AS (SELECT count(tagid) as count, clusterid, activity FROM clstrtags GROUP BY clusterid, activity),
countss AS (SELECT count(tagid) as count, clusterid FROM clstrtags GROUP BY clusterid)

select counts.clusterid, counts.activity as act, counts.count as actct,countss.count as tagid, counts.count/(countss.count + 0.00) as percentage
from counts join countss
on counts.clusterid=countss.clusterid
where countss.count>1
order by clusterid