I'm working on a sketch that visualizes municipal census data, and I've added a feature that allows users to export PDF images of the current frame. This feature works fine when I'm running the sketch from the IDE or as an application, but when I attempt to export a PDF from an applet running on my website, the applet hangs. The applet (with accompanying error) can be found here:
http://jeemang.ca/projects/metroview/index.html.
The method I used to implement this feature is outlined briefly below:
1. In the draw loop, before stuff is written, check boolean variable indicating if pdf should be written or not.
2. If this variable is true, prompt the user for the export path (using selectOutput()). Use the output from this to call beginRecord (ie "beginRecord(PDF, <path from previous step>)").
3. Draw stuff I want in pdf.
4. Check boolean variable indicating if pdf is to be written or not and, if it's true, switch it back to false.
The boolean variable I mention above can be "flicked" by a button I created using the controlP5 library. If this isn't enough detail, code can be found here:
http://code.google.com/p/metroview/source/browse/. (The draw() and setup() loops are located in "MV.pde.")
So far, I've tried a couple of things to fix this:
1. Based on the advice at the controlP5 website, I made basically every variable and method in the sketch "public." This did not fix the problem.
2. The sketch also uses some stuff from the giCentre Utilities. Just to check, I removed all references to these libraries, but this also did not fix the problem.
So, I'm a little stuck. My hunch right now is that the problem lies in the way that I'm specifying the output path in beginRecord(). When using this command within an applet, can one simple specify a path to the user's hard drive as my sketch does? Is it even possible to write pdf's to the user's hard drive using this command? Or, alternatively, could the problem lie elsewhere?
Any suggestions or help would be very much appreciated.
I'm fairly new to processing, and I'm working on a sketch that is meant to draw the neighbourhoods of my city and colour them based on various data (e.g. people per dwelling, population density, crime rate, etc.).
The neighbourhoods are drawn for every frame, ie:
void draw() {
// DRAW OBJECTS
// neighbourhoods
for(int i = 0; i < hoods.length; i++) { // neighbourhoods are stored in "hoods" array
hoods[i].draw(dMode, maxMins); // each neighbourhood's "draw" method called here
}
}
The data for the outline of the neighbourhoods comes from a KML file provided by the city. Each neighbourhood's outline is defined by a series of points specified in terms of latitude and longitude, which my code converts to pixel values for rendering.
My problem is that the on-screen rendering doesn't look as great as I'd like it to:
As illustrated above, the edges of the neighbourhoods are jagged and uneven, and in some places (particularly in the outermost neighbourhoods in the northwest corner of the city) the border of the fill seems to exceed the stroke.
I thought that this may have had something to do with my data/algorithm, as there were some precision issues involved owing to the fact that coordinates were specified in latitude and longitude (in these terms, the span of the entire city is about 0.4 units, meaning the smallest neighbourhood features were being traced out in terms about 5-6 decimal points deep) and the inability of Processing to use doubles for plotting functions. To check this, I thought I'd plot the data using another method and see how that worked out. Below is a screenshot of a pdf generated using exactly the same algorithm:
This version looks much better, which suggests the problem probably isn't precision.Unfortunately, however, I have no idea what the heck the problem might be.
I've already enabled anti-aliasing, and I tried the other rendering engines available with Processing (and found that the default renderer works the best). So, I'm kind of stumped. Any suggestions to improve the quality of the first image -- to make it look more like the second image, essentially -- would be very much appreciated.
(And: bonus points for any suggestions on jazzing up this display a little bit; even the pdf version, though rendered acceptably, seems a bit flat).
I'm trying to implement a program that draws objects according to latitude and longitudes read from a kml file. Because the area over which I'm drawing is relatively small (ie one city), a great degree of precision in the coordinates is required. Here's a sample of the coordinates I'm dealing with:
<coordinates>
-113.442808503237,53.6048438750671,0
-113.442833924505,53.6022101984654,0
-113.442935216077,53.5996562420879,0
-113.43884754156,53.5996087723271,0
-113.43515332971,53.5995059467105,0
I'm having trouble preserving more than about 4-5 decimal points of precision (which is seems to be the approximate limit of the float type). These coordinates are initially read from the kml file as Strings, and my plan was to convert them from Strings to doubles, multiply them by a large number (say 1000000000) and then convert them to floats, a la:
double d = Double.parseDouble(h[l]) * 1000000000; // h[l] is a single coordinate in String form
float f = (float) d;
but this doesn't do the trick; if I display the results using nf() and compare them to the original String, the precision again tails off at about 4-5 decimal points (that is, the String will look like -113.421129528347 and the float will look like
-113421131776.000).
Any insight as to why my plan isn't working or suggestions of better plans would be very much appreciated.
I'm encountering a very frustrating problem with the below IF statement:
String test = placemark.getChild(3).getName();
if (test == "Polygon") {
XMLElement polygon = placemark.getChild(3);
XMLElement outerBound = polygon.getChild(0);
For some reason, test == "Polygon" will NOT return true. I've verified that the output from the getName() method is indeed a String, and that it is "Polygon" with identical capitalization and no leading or trailing spaces. Does anyone have any ideas what else could be the problem?