I'm working on a PHP application that needs to obtain data from a topographical map (different elevations denoted by different colors). I need to do two things:
Using this map (800x600), find a way to determine the exact pixel location of a particular city. For example, San Francisco is located at precisely 121x585.
Using the location from (1) above, I need to read the exact color at that location.
Note: The map provider does not provide location-based data, only a colored map. I suspect multiple libraries would be needed to map coordinates to locations on the map (via a ratio?) and then use OCR to read the color.
Are there any PHP libraries/tools that do this? How would you pull this off?
Once you know the pixel-coordinates, you can use PHP's built-in GD library to sample the color of an arbitrary pixel quite easily.
The tricky bit will be determining the pixel to sample, which can get pretty darned tricky. The earth being sphere-like, maps use various projections to produce a 2-d representation. If you know how the colored map image is projected, and you know the latitude/longitude of the pixel at (0,0), you should be able to write a function to convert lat/long to a pixel coordinate.
I may not have understood the problem entirely, but you should map the locations you want into an array (of objects?)
$city_mapping = array(new City("San Francisco", 121, 585), new City....); //Map your cities to an array.
Where City should be defined as a class to contain those variables.
Then use imagecolorat() to check for the color.
Related
I am looking for a method, preferably in PHP, to analyze a group of polygons to detect the outer boundaries of the group.
Specifically, this is for a Google Maps v3 application that renders territories. Each polygon in the territory is a ZIP Code. I'm trying to detect and draw only the territory boundary. Here's a mock-up of what I'm trying to accomplish:
The challenges I face in solving this problem:
ZIP Codes within each territory can be (and often are) non-contiguous (see the red and green territories in the example above).
ZIP Codes are not necessarily convex, so a convex hull technique wouldn't work (maybe I'm wrong?)
Although it looks like it in the image above, vertices are rarely truly redundant from one ZIP to another. Each lat/lon coordinate (i.e. each vertex of the polygon) has 10 decimal points of precision. I have already tried and rejected a rounding technique as it never produced a clean data set that still resembled the original shape.
On the positive side, these territories never change once they're established. Therefore, this process can be run offline to calculate and store the resulting territory polysets.
Clarification:
My data is stored at the ZIP Code level. Each ZIP Code is defined by one or more large sets of lat/lon coordinates. Each lat/lon coordinate defines a single vertex in the Google Maps polygon. As with the bigger territories, each ZIP Code may or may not be convex, and it may or may not be a single contiguous polygon. The larger territory is simply stored as a list of ZIP Codes; no polygonal data is stored for territories--which is the problem I'm trying to solve here.
Many thanks in advance for any pointers in the right direction.
It sounds like you have a list of which zip codes relate to which territories. You also have a polygon for each zip code.
If this is the case, then the solution is fairly straightforward. The key observation/assumption is that bordering zip codes should share edges, which need to be removed. If this isn't the case, then the following is a moot point.
For each territory:
Create a dictionary that is keyed to the sorted edge, and which it's item is a list of polygons with that edge. Then go through the polygons in the territory and fill out the dictionary. This may be tricky as you need to ensure that Edge(A,B) is the same as Edge(B,A), which could be done by sorting the points in the edge.
Once you've gone through all of the polygons, you'll end up with essentially a table of edges and which polygon they are associated with. Convert this table into a graph, ignoring all edges that are in two or more polygons, although the "or more" is probably not possible. The result should be an undirected cyclic graph, that you should be able to extract the territory polygon from the graph using an algorithm similar to depth-first search.
The performance should be O(N), where N is the total number of edges/vertices.
I'm trying to figure out how to build a statistical map for my web app. Here's what I've got:
I have a MySQL database of zip codes, and each zip code has latitude & longitude.
I have users who have declared what zip code they live in.
I even have a haversine query which will show how many users exist within, for example, 25 miles of a given latitude/longitude, based on their zip code.
My question is this: Using this information, how could I approach building a statistical map for a web application using PHP?
I would be fine with using just a US map or even a North American map for now, but I'm just not sure how to build that map. Some options I've considered:
Show a colored dot on the map, larger or smaller depending on the number of users near that location. I'm not sure how to do this, though, especially if those dots were to overlap!
Show individual "pushpins" where the users are. Seems like this could get out of hand if my user base grows significantly
So back to my question. If I had 300 users in Dallas, 4,000 in NYC, 45 users in Detroit, 403 in Chicago... how would I be able to represent that on a map -- and also how would I draw that map in a web application built on PHP?
You are trying to build a three-dimensional (probably even more dimensions) data display.
Your dimensions are:
X-Location
Y-Location
The value at every location
This really does not define anything about the visual appearance, though.
A simple approach might be to calculate the absolute number of users per state and then color the state on the map according to some scale. You also might calculate the percentage of users living in a state compared to the absolute number and color that instead.
A different approach would be to put a dot for every user on the map, and if this dot was printed before, to change it's color instead, e.g. make it brighter.
In the end, it really depends on what your actual data is and if your approach on visualizing it displays some significant information - but this can only be confirmend after you see it.
As you are looking for a web application have you considered Google Maps. Factor 1. can be implemented using the MarkerClusterer library. A DEMO showing this. The data from your database can be loaded using AJAX.
I have a country map in .png format, I need to highlight specific states in this map dynamically using PHP. What's the best way to do this?
Thanks
You would need to create a list of all the points defining the polygon encasing each state, then use imagepolygon to fill in the appropriate polygons on the map image with some color.
Realistically you probably want to find a 3rd party library/component (i.e. Flash movie, JavaScript map and library, or PHP class designed for this) rather than writing it on your own from scratch. Highlighting a map isn't exactly a new problem and solving it again from scratch is tedious.
If you're talking about US States, I would recommend trying Google Maps, and the following links. I used them for the exact purpose you're talking about (votes by state) recently, and it worked great:
http://econym.org.uk/gmap/example_states2.htm
http://econym.org.uk/gmap/epoly.htm
http://econym.org.uk/gmap/states.xml
First off, I don't mean google image search!
I would like to give users the ability to select a hex color value and then have a search programatically return (from specified sites/directories online) images where the dominant color is the color they specified (or close to it).
Is there a technology that can do this? I'd prefer PHP/MySQL, but I'd be willing to use other languages if it would be simpler.
EDIT
Taking several suggestions, I managed to find this: http://www.coolphptools.com/color_extract which does a decent job at extracting the most common colors from the image.
The next step is calculating distance from the extracted colors to the color being searched for. I have no issue implementing it except I'm unclear on the best way to calculate the color distance?
I've scoured this site and google for a concrete answer, but come up dry. The tool above extracts colors into hex color codes. I am currently converting this to RGB and using those.
Should I attempt to convert RGB to Y'UV? I'm attempting that by using:
sqrt(((r - r1) * .299)^2 + ((g - g1) * .587)^2 + ((b - b1) * .114)^2)
(based on an answer here: RGB to closest predefined color)
It's not very accurate. What should I swap that color distance formula with so it calculates accurate color distance (to the human eye)?
Interesting.
The first problem is: "What is the dominant colour of an image?" Maybe the one most pixels have. What do you do with similar shades of the same colour? Would you cluster around similar colours?
I would implement it this way:
Grab all images inside your search paths. Cluster the colors used in each of them and the biggest cluster is the dominant color. You will have to play around a bit with cluster sizes and number of clusters. If this color is within a certain range of hue, saturation and brightness of your searched color it is a match.
Firstly, I wonder how can you crawl over the sites/directories to search for a particular image color, unless you have a big list of websites. If it isn't related to your question then just ignore it.
Back to your question, I personally think this is an interesting question as well. Since it requires quite a few research, I just want to point out some ideas for you to reference.
What you need to do is to get user-specified hex colors and convert them into RGB colors, because most of the image functions in PHP that I know only work with RGB. Now, if you have a list of directories that you can search for, then just crawl over them and use some basic functions to get hold of the desired webpage' contents (e.g. file_get_contents, or cURL). Once you have the contents of a specific page, you will need to use DOM functions to get images' URLs from that page (you can work it out yourself, using: getElementsByTagName() and getAttribute()). Now assuming that you are holding a list of image URLs, now you need to get their colors and try to match them with your user-specified colors (remember to convert everything into RGB).
In PHP we have a very convenient GD library that works with images. If your server support GD2 then you can have a look at imagecolorclosest(). This function "Returns the index of the color in the palette of the image which is "closest" to the specified RGB value". Note that the function only returns the closest match (not exactly match), so you have to do some comparisons to choose the right images (I believe this is easy because you now have RGB colors with very handy values to work with, say, using some subtraction and adjustment method).
Moreover, not only the images, when you have a specific page content, you can try to search for the color scheme of that page (by getting its "background-color" value), there are quite a few details that you can get and play around with :) Of course, an image's color is somehow related to its page's styling scheme colors, think logically wider.
If I'm saying something not clear, don't hesitate to comment on my reply :)
Happy coding.
I'm trying to find something, preferably F/OSS, that can generate a Google Maps overlay from KML and/or KMZ data.
We've got an event site we're working on that needed to accommodate ~16,000 place markers last year and will likely have at least that many again this year. Last year, the company that had done the site just fed the KML data directly to the gMaps API and let it place all of the markers client side. Obviously, that became a performance nightmare and tended to make older browsers "freeze" (or at least appear frozen for several minutes at a time).
Ideally this server side script would take the KML, the map's lat/lon center, and the map zoom level and appropriately merge all of the visible place markers into a single GIF or PNG overlay.
Any guidance or recommendations on this would be greatly appreciated.
UPDATE 10/8/2008 - Most of the information I've come across here and other places would seem to indicate that lessening the number of points on the map is the way to go (i.e. using one marker to represent several when viewing from a higher altitude/zoom level). While that's probably a good approach in some cases, it won't work here. We're looking for the visual impact of a US map with many thousand markers on it. One option I've explored is a service called PushPin, which when fed (presumably) KML will create, server side, an overlay that has all of the visible points (based on center lat/lon and zoom level) rendered onto a single image, so instead of performing several thousand DOM manipulations client side, we merge all of those markers into a single image server side and do a single DOM manipulation on the client end. The PushPin service is really slick and would definitely work if not for the associated costs. We're really looking for something F/OSS that we could run server side to generate that overlay ourselves.
You may want to look into something like Geoserver or Mapserver. They are Google map clones, and a lot more.
You could generate an overlay that you like, and Geoserver(I think mapserver does as well) can give you KML, PDF, png, and other output to mix your maps, or you could generate the whole map by yourself, but that takes time.
Not sure why you want to go to a GIF/PNG overlay, you can do this directly in KML. I'm assuming that most of your performance problem was being caused by points outside the user's current view, i.e. the user is looking at New York but you have points in Los Angeles that are wasting memory because they aren't visible. If you really have 16,000 points that are all visible at once for a typical then yes you'll need to pursue a different strategy.
If the above applies, the procedure would be as follows:
Determine the center & extent of the map
Given that you should be able to calculate the lat/long of the upper left and lower right corners of the map.
Iterate through your database of points and check each location against the two corners. Longitude needs to be greater (signed!) than the upper left longitude and less than the lower right longitude. Latitude needs to be less than the upper left latitude (signed!) and greater than the lower right latitude. Just simple comparisons, no fancy calculations required here.
Output the matching points to a temporary KML for the user.
You can feed KML directly into Google Maps and let it map it, or you can use the Javascript maps API to load the points via KML.
It might not solve your exact problem here, but for related issues you might also look into the Google Static Maps API. This allows you to create a static image file with placemarkers on it that will load very quickly, but won't have the interactivity of a regular Google map. Because of the way the API is designed, however, it can't handle anywhere near 16,000 points either so you'd still have to filter down to the view.
I don't know how fare you are with your project but maybe you can take a look at GeoDjango? This modified Django release includes all kinds of tools to store locations; convert coordinates and display maps, the easy way. Offcourse you need some Python experience and a server to run it on, but once you've got the hang of Django it works fast and good.
If you just want a solution for your problem try grouping your results at lower zoom levels, a good example of this implementation can be found here.
This is a tough one. You can use custom tilesets with Google Maps, but you still need some way to generate the tiles (other than manually).
I'm afraid that's all I've got =/
OpenLayers is a great javascript frontend to multiple mapping services or your own map servers. Version 2.7 was just released, which adds some pretty amazing features and controls.