Bug #2406
openAutomate homepage map- color by number of plots per state
0%
Description
This could potentially be done with some software that USDA uses on their plants site. But now, that homepage map is generated manually by michael any time new plots are added. For this to continue being useful, it will need to be autogenerated.
Updated by Michael Lee over 18 years ago
now that we have no more funding after August, we need this to be done. Matt Jones has been emailed to try to get ideas. Fall-back plan would be a google-map.
Updated by Michael Lee about 18 years ago
later! For now, MLee will just update it.
Updated by Michael Lee about 18 years ago
I saw that USDA Plants
uses GD (http://www.boutell.com/gd/) in their dynamic maps (e.g.,
http://plants.usda.gov/java/profile?symbol=ACRU#blankmap). I don't have
the skills to unpackage how GD works and get it going, and Chad took a
quick glance and thought it would be a fair amount of work.
Ideally, there would be a site that you could send a query to, like
http://maps.ecoinformatics.org/northamerica.jsp?NC=3&SC=2&CA=41&colorscheme=FOO
which would return a map properly filled in and we'd either include it as
an iframe in our site or with a jsp include. (I know I'm probably asking
for the moon here, but why not, while we're just talking about what we'd
like to be able to do?)
Updated by Michael Lee about 18 years ago
There's a freely available library which allows you to read and write
PNG files. It can be used in C and other compiled languages. We use
this in a couple of products, and it works very well.
http://www.libpng.org/pub/png/libpng.html
If you decide you want to do the job in C, I can probably give dig up
a bit of code to get you started with reading and writing the file and
reading and writing the image data once you have it in memory.
I'm fairly sure this job could be done in Java as well. I have a
colleague who rents some office space from us who is a Java expert.
He assures me that Java has functions for reading and writing PNG
files and that it's possible to access the image data as well.
Off the top of my head, here's an easy way for the program to do the job.
What if you created a grayscale image where a given gray level
represents a region you wish to colorize? For example, the region of
Nevada might be gray level 1, California might be 2, etc. For an 8
bit grayscale image, that gives you a maximum of 256 different
regions. If you need more, you could use a 16-bit image for 65536
regions – PNG supports both bit depths.
Then, you could produce an XML data file associating regions with a
count of plots. For example, region 1 (Nevada, in our example) might
have 1100 plots, and region 2 (California) might have 300.
You would also need a file which associates plot counts with a RGB color.
The computer program could put this all together. It would read the
two data files and the input image and create a color image for
output. To fill the color image, it would traverse the pixels of the
grayscale input image. For each pixel it would check the gray value
to determine what region the pixel belongs to. Then, it would look up
the plot count for that region and the color for that plot count and
write the appropriate color to the output image.
For each geographical scale, you would need a separate grayscale image
and XML data file containing plot data. You could reuse the color
mapping file though.
This plan assumes that every pixel in the output is associated with a
region. If you have other map details, you could read a second color
input image instead of creating a blank one and use the grayscale
image to colorize it. Some specific gray level (such as zero) could
indicate an area that doesn't contain a gray level and isn't affected
by colorization.