|
From: Daniel J S. <dan...@ie...> - 2015-10-23 15:45:48
|
On 10/23/2015 06:13 AM, Juhász Péter wrote: > On Thu, 2015-10-22 at 12:37 -0700, Ethan A Merritt wrote: >> On Thursday, 22 October, 2015 20:47:37 Juhász Péter wrote: >>> On Thu, 2015-10-22 at 00:17 -0500, Daniel J Sebald wrote: >>>> >>>> Although it isn't a type of plot I'd use in my field, it would be a >>>> really nice feature given how common this type of geographical "plot" >>>> with data points is today. A command syntax is going to be the >>>> difficult part. Defining the maps is another issue. What if boundaries >>>> change? Is there some type of universally accepted data format or >>>> descriptive language for map boundaries these days? >>>> >>>> Dan >>>> >>> >>> Two more issues that count against including high-resolution map data >>> into gnuplot itself: >>> >>> - licensing >>> - data size >> >> You may be responding to a message I haven't seen yet, but... >> I don't think Dan's comment implied incorporating the map data itself >> into gnuplot. The idea, I think, is that if there are standard formats >> for map data we might provide support for these to make it easier to >> read from external files. Analogous to the way we handle image formats: >> plot 'foo.png' binary filetype=png >> >> I don't know whether this would be useful or not. The external files >> might require so much pre-processing that the syntax of the final plot >> command is not an issue. >> >> Ethan >> > > Well, he didn't imply that, however, the OP wanted a simple way to > produce geographical plots that include country borders. To do that > reliably, you have to have a proven, known dataset. What you are saying > (adding support for one or more of the de facto standard GIS formats) is > only halfway there - and even that raises the question of which > format(s) to support, and to what extent. > > IMHO that alone doesn't worth the effort, as it doesn't provide real > benefits compared to the situation that we have now, that is, if you > want to produce nice, detailed maps, you get the data from wherever you > can, in any format you can, you convert it with some external tools to a > format that gnuplot can use, then plot it yourself. > > We might turn to systems such as R for inspiration: there the creation > of maps is supported in the form of add-on packages, e.g. > https://cran.r-project.org/web/packages/maps/index.html > https://cran.r-project.org/web/packages/mapdata/index.html > > However, gnuplot does not support add-on packages like that and I think > that's a can of worms we don't want to open right now. There is an R manual associated with the package: https://cran.r-project.org/web/packages/maps/maps.pdf but I'm not going to take the time to read it right now. But this R package has gone all out as far as databases with intriguing names like "spacetime", etc. As I see it, gnuplot should bring the benefit of easily overlaying data on a geospatial map in order to convey statistical, survey, or other types of data. For example, someone may want to use the size of a dot (which gnuplot has) to illustrate the number of museums in major U.S. cities. Or perhaps the user wants to show registered voters by state using color variation to illustrate party affiliation. That sort of thing. I could imagine a special plot mode "geospatial" akin to something like "polar" that changes the underlying coordinate system to, say, latitude and longitude or whatever. Given a database, gnuplot might figure out the lat/long data or vector boundary data behind the scenes, making the task of plotting easy for the user. So it might be: (Data I'm making up...) set geospatial bigdatabasefile.esri plot '-' using 1:2 with filledcircles title "Museum Count" "Los Angeles" 123 "New York" 217 "Philadelphia" 132 "Chicago" 194 "Washington D.C." 732 end Dan |