From: phil r. <phi...@ya...> - 2012-09-13 10:54:02
|
Hi all I was just wondering what the format of the plPlot map files is? The maps included in plPlot are rather low resolution so wondered if it was possible for me to download more detailed ones form somewhere? Phil |
From: phil r. <phi...@ya...> - 2012-09-13 15:05:25
|
Unfortunately after a significant amount of searching i've only been able to find ascii versions of the CIA maps (which were on the page you suggested Andrew). The maps with plPlot are binary so these don't work. If anyone has copies of more detailed maps then I'd appreciate it if you'd let me know. At the moment I'm going to have to read in and plot the ascii maps as a line plot, but I won't end up with the useful features of the plmaps routine. Cheers Phil ________________________________ From: Andrew Roach <aro...@ya...> To: phil rosenberg <phi...@ya...> Sent: Thursday, 13 September 2012, 12:13 Subject: Re: [Plplot-devel] map resolution At 03:53 AM 13/09/2012 -0700, you wrote: > Hi all > I was just wondering what the format of the plPlot map files is? The maps included in plPlot are rather low resolution so wondered if it was possible for me to download more detailed ones form somewhere? > > Phil It was the CIA World DataBank map format. Many years ago I did use higher res versions for something or other - they are out there if you look. http://www.evl.uic.edu/pape/data/WDB/ might be some from what I can see. -Andrew |
From: phil r. <phi...@ya...> - 2012-09-13 21:31:34
|
Hi again I've just been through the source code to work out the file format. It actually turned out to be rather simple - just a series of segments made up of 2 byte numbers. Each starts with the number of points in the segment followed by the lons then the lats for that segment. I've generated high res binary files based on the coastline files from the ascii CIA files. If anyone else would like the files then let me know. Andrew - I think that although the data may have come from the CIA files, I don't think plPlot uses the original format. The ascii files have a much higher resolution than the two byte plPlot files which results in some rather unpleasant aliasing. I've put an example at http://homepages.see.leeds.ac.uk/~earpros/plplottest/trackplot.png showing the SE of the UK. It is still much better than the previous results, but maybe if the devs would consider allowing a 3 or 4 byte per point format the results would be much improved. Phil ________________________________ From: phil rosenberg <phi...@ya...> To: Andrew Roach <aro...@ya...> Sent: Thursday, 13 September 2012, 16:04 Subject: Re: [Plplot-devel] map resolution Unfortunately after a significant amount of searching i've only been able to find ascii versions of the CIA maps (which were on the page you suggested Andrew). The maps with plPlot are binary so these don't work. If anyone has copies of more detailed maps then I'd appreciate it if you'd let me know. At the moment I'm going to have to read in and plot the ascii maps as a line plot, but I won't end up with the useful features of the plmaps routine. Cheers Phil ________________________________ From: Andrew Roach <aro...@ya...> To: phil rosenberg <phi...@ya...> Sent: Thursday, 13 September 2012, 12:13 Subject: Re: [Plplot-devel] map resolution At 03:53 AM 13/09/2012 -0700, you wrote: > Hi all > I was just wondering what the format of the plPlot map files is? The maps included in plPlot are rather low resolution so wondered if it was possible for me to download more detailed ones form somewhere? > > Phil It was the CIA World DataBank map format. Many years ago I did use higher res versions for something or other - they are out there if you look. http://www.evl.uic.edu/pape/data/WDB/ might be some from what I can see. -Andrew |
From: Andrew R. <and...@us...> - 2012-09-21 09:24:45
|
Phil, I appreciate your problems Phil. The mapping functions are a bit of a half way house. Plplot doesn't (and I think shouldn't) provide full mapping tools. That's a different job. Get a GIS package if that is what you need. On the other hand, basic outline maps are very useful for scientific applications. You can do all this yourself with the generic API, but the mapping functions have some useful additional functionality in terms of projections / transforms etc. As a non-US resident I've always been slightly irked that we only have global and US maps. For this reason (as well as for getting better resolution maps) it would also be good to allow users to easily add their own map data. Currently the format is undocumented so any change in format would be best implemented before we write the documentation and make it a public API! I would also think carefully about data format. Better resolution would be beneficial as you say. Might also be worth considering some standard format to make obtaining new maps easier. Of course one might argue that high resolution only really matters when you are looking at a small area zoomed in, at which point many of the benefits of the mapping functions in terms of projections / transformations don't really matter so much anyway as it is close to being a flat cartesian surface. Just my random thoughts. Andrew On Thu, Sep 13, 2012 at 02:31:27PM -0700, phil rosenberg wrote: > Hi again > I've just been through the source code to work out the file format. It actually turned out to be rather simple - just a series of segments made up of?2 byte numbers. Each starts with the number of points in the segment followed by the lons then the lats for that segment. I've generated high res binary files based on the coastline files from the ascii CIA files. If anyone else would like the files then let me know. > Andrew - I think that although the data may have come from the CIA files, I don't think plPlot uses the original format. The ascii files have a much higher resolution than the two byte plPlot files?which results in some rather unpleasant aliasing. I've put an example at http://homepages.see.leeds.ac.uk/~earpros/plplottest/trackplot.png showing the SE of the UK.?It is still much better than the previous results, but maybe if the devs would consider allowing a 3 or 4 byte per point format the results would be much improved. > Phil > > > > ________________________________ > From: phil rosenberg <phi...@ya...> > To: Andrew Roach <aro...@ya...> > Sent: Thursday, 13 September 2012, 16:04 > Subject: Re: [Plplot-devel] map resolution > > > Unfortunately after a significant amount of searching i've only been able to find ascii versions of the CIA maps (which were on the page you suggested Andrew). The maps with plPlot are binary so these don't work. > ? > If anyone has copies of more detailed maps then I'd appreciate it if you'd let me know. At the moment I'm going to have to read in and plot the ascii maps as a line plot, but I won't end up with the useful features of the plmaps routine. > ? > Cheers > ? > Phil > > > ________________________________ > From: Andrew Roach <aro...@ya...> > To: phil rosenberg <phi...@ya...> > Sent: Thursday, 13 September 2012, 12:13 > Subject: Re: [Plplot-devel] map resolution > > At 03:53 AM 13/09/2012 -0700, you wrote: > > > Hi all > > I was just wondering what the format of the plPlot map files is? The maps included in plPlot are rather low resolution so wondered if it was possible for me to download more detailed ones form somewhere? > > > > Phil > > It was the CIA World DataBank map format. Many years ago I did use higher res versions for something or other - they are out there if you look. http://www.evl.uic.edu/pape/data/WDB/ might be some from what I can see. > > -Andrew > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: phil r. <phi...@ya...> - 2012-09-21 12:14:37
|
In many respects I agree. Plplot isn't a mapping tool and I could just get some outline data and plot it as a series of lines. As you say, when zoomed in the map projections make little difference. The stuff I'm doing at the moment is zoomed right in on Southern UK so projections aren't an issue, but if I were looking at northern Europe for example then I think I'd want something more detailed than the current maps and the projections would probably be useful then. I imagine that also there would be many lines needed to simply plot the outlines as a line chart. If we wanted to adopt an existing file format then shapefiles seem quite common and have essentially an open specification. The format is relatively straightforward, having a file header followed by a number of records each with a header followed by data. See http://en.wikipedia.org/wiki/Shapefile. There is a C library for reading/writing them at http://shapelib.maptools.org/ - this does add an extra dependency though with the extra complexity in the build stage or some relatively straightforward code could be added to Plplot to read basic shapefiles. Or if this is overkill for the needs of plplot a map file could begin with a header something like { char newversionflag; //always zero to identify new versions vs current version char versionnumber; //for future proofing char datatypeflag; //flag whether the data is big/little endian integers or ieee floats char nbytesperpoint; //number of bytes for each lat/lon value } followed by a series of records each beginning with a number which specifies the number of lat/lon values in the record like the current version. This would give most users the flexibility to generate the maps or any additional surface features they want in a pretty straightforward way or a number of different maps at different resolutions could be provided with plplot. Like Andrew says - just my random thoughts Phil ________________________________ From: Andrew Ross <and...@us...> To: phil rosenberg <phi...@ya...> Cc: "plp...@li..." <plp...@li...> Sent: Friday, 21 September 2012, 10:24 Subject: Re: [Plplot-devel] map resolution Phil, I appreciate your problems Phil. The mapping functions are a bit of a half way house. Plplot doesn't (and I think shouldn't) provide full mapping tools. That's a different job. Get a GIS package if that is what you need. On the other hand, basic outline maps are very useful for scientific applications. You can do all this yourself with the generic API, but the mapping functions have some useful additional functionality in terms of projections / transforms etc. As a non-US resident I've always been slightly irked that we only have global and US maps. For this reason (as well as for getting better resolution maps) it would also be good to allow users to easily add their own map data. Currently the format is undocumented so any change in format would be best implemented before we write the documentation and make it a public API! I would also think carefully about data format. Better resolution would be beneficial as you say. Might also be worth considering some standard format to make obtaining new maps easier. Of course one might argue that high resolution only really matters when you are looking at a small area zoomed in, at which point many of the benefits of the mapping functions in terms of projections / transformations don't really matter so much anyway as it is close to being a flat cartesian surface. Just my random thoughts. Andrew On Thu, Sep 13, 2012 at 02:31:27PM -0700, phil rosenberg wrote: > Hi again > I've just been through the source code to work out the file format. It actually turned out to be rather simple - just a series of segments made up of?2 byte numbers. Each starts with the number of points in the segment followed by the lons then the lats for that segment. I've generated high res binary files based on the coastline files from the ascii CIA files. If anyone else would like the files then let me know. > Andrew - I think that although the data may have come from the CIA files, I don't think plPlot uses the original format. The ascii files have a much higher resolution than the two byte plPlot files?which results in some rather unpleasant aliasing. I've put an example at http://homepages.see.leeds.ac.uk/~earpros/plplottest/trackplot.png showing the SE of the UK.?It is still much better than the previous results, but maybe if the devs would consider allowing a 3 or 4 byte per point format the results would be much improved. > Phil > > > > ________________________________ > From: phil rosenberg <phi...@ya...> > To: Andrew Roach <aro...@ya...> > Sent: Thursday, 13 September 2012, 16:04 > Subject: Re: [Plplot-devel] map resolution > > > Unfortunately after a significant amount of searching i've only been able to find ascii versions of the CIA maps (which were on the page you suggested Andrew). The maps with plPlot are binary so these don't work. > ? > If anyone has copies of more detailed maps then I'd appreciate it if you'd let me know. At the moment I'm going to have to read in and plot the ascii maps as a line plot, but I won't end up with the useful features of the plmaps routine. > ? > Cheers > ? > Phil > > > ________________________________ > From: Andrew Roach <aro...@ya...> > To: phil rosenberg <phi...@ya...> > Sent: Thursday, 13 September 2012, 12:13 > Subject: Re: [Plplot-devel] map resolution > > At 03:53 AM 13/09/2012 -0700, you wrote: > > > Hi all > > I was just wondering what the format of the plPlot map files is? The maps included in plPlot are rather low resolution so wondered if it was possible for me to download more detailed ones form somewhere? > > > > Phil > > It was the CIA World DataBank map format. Many years ago I did use higher res versions for something or other - they are out there if you look. http://www.evl.uic.edu/pape/data/WDB/ might be some from what I can see. > > -Andrew > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel |
From: Andrew R. <and...@us...> - 2012-09-26 14:53:13
|
On Fri, Sep 21, 2012 at 05:14:30AM -0700, phil rosenberg wrote: > In many respects I agree. Plplot isn't a mapping tool and I could just get some outline data and plot it as a series of lines. As you say, when zoomed in the map projections make little difference. > > The stuff I'm doing at the moment is zoomed right in on Southern UK so projections aren't an issue, but if I were looking at northern Europe for example then I think I'd want something more detailed than the current maps and the projections would probably be useful then. I imagine that also there would be many lines needed to simply plot the outlines as a line chart. > > If we wanted to adopt an existing file format then shapefiles seem quite common and have essentially an open specification. The format is relatively straightforward, having a file header followed by a number of records each with a header followed by data. See http://en.wikipedia.org/wiki/Shapefile. There is a C library for reading/writing them at http://shapelib.maptools.org/ - this does add an extra dependency though with the extra complexity in the build stage or some relatively straightforward code could be added to Plplot to read basic shapefiles. > > Or if this is overkill for the needs of plplot a map file could begin with a header something like > > { > ??? char newversionflag; //always zero to identify new versions vs current version > ??? char versionnumber; //for future proofing > ??? char datatypeflag; //flag whether the data is big/little endian integers or ieee floats > ??? char nbytesperpoint; //number of bytes for each lat/lon value > } > followed by a series of records each beginning with a number which specifies the number of lat/lon values in the record like the current version. > > This would give most users the flexibility to generate the maps or any additional surface features they want in a pretty straightforward way or a number of different maps at different resolutions could be provided with plplot. > > > Like Andrew says - just my random thoughts Phil, I took a look at the shapefile format. My personal take is that this might be a little over the top. Strictly it requires 3 files including information like projections etc. Seems more than we need. I think a simple binary format such as you suggest may suffice and could easily be made backwards compatible with the current file format. Not sure I'd bother with supporting both big and little endian formats. Would you be willing to try this out and produce a patch + documentation? If so, I think it could be a useful addition, particularly if we can also generate some better data files as examples. Regards Andrew |
From: Arjen M. <arj...@de...> - 2012-09-27 11:12:54
|
Hi Andrew, Phil, On 2012-09-26 16:52, Andrew Ross wrote: > > I took a look at the shapefile format. My personal take is that this > might be a little over the top. Strictly it requires 3 files including > information like projections etc. Seems more than we need. > On the other hand, the shape file format is a very commonly used format and there are plenty tools around to handle them. Isn't there a thrid-party library that we can use? Not to mimick a GIS system but to make it easier for people to use geographical information without having to convert the files. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Andrew R. <and...@us...> - 2012-09-27 11:35:21
|
There are such libraries (Phil mentioned one). We could use these, it just introduces another dependency on the core of plplot for what is a relatively minor feature. Currently the plplot core and some basic drivers can be compiled with almost no dependencies. For testing, porting to new systems and potentially embedded systems this is a very useful thing and worth preserving. Of course we could keep the current code as well and only enable shapefile support if the library is present. Shapefile support would be convenient for users. Andrew On Thu, Sep 27, 2012 at 01:12:40PM +0200, Arjen Markus wrote: > Hi Andrew, Phil, > > On 2012-09-26 16:52, Andrew Ross wrote: > > > > > I took a look at the shapefile format. My personal take is that this > > might be a little over the top. Strictly it requires 3 files including > > information like projections etc. Seems more than we need. > > > > On the other hand, the shape file format is a very commonly used format > and there are plenty tools around to handle them. Isn't there a > thrid-party library that we can use? Not to mimick a GIS system but > to make it easier for people to use geographical information without > having to convert the files. > > Regards, > > Arjen > > > > DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. > The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. > > > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Arjen M. <arj...@de...> - 2012-09-27 11:37:07
|
HI andrew, On 2012-09-27 13:35, Andrew Ross wrote: > There are such libraries (Phil mentioned one). We could use these, it > just introduces another dependency on the core of plplot for what is > a relatively minor feature. Currently the plplot core and some basic > drivers can be compiled with almost no dependencies. For testing, > porting to new systems and potentially embedded systems this is a very > useful thing and worth preserving. > > Of course we could keep the current code as well and only enable > shapefile support if the library is present. Shapefile support would > be convenient for users. > Actually, that is what I had in mind. Regards, Arjen DISCLAIMER: This message is intended exclusively for the addressee(s) and may contain confidential and privileged information. If you are not the intended recipient please notify the sender immediately and destroy this message. Unauthorized use, disclosure or copying of this message is strictly prohibited. The foundation 'Stichting Deltares', which has its seat at Delft, The Netherlands, Commercial Registration Number 41146461, is not liable in any way whatsoever for consequences and/or damages resulting from the improper, incomplete and untimely dispatch, receipt and/or content of this e-mail. |
From: Alan W. I. <ir...@be...> - 2012-09-27 16:37:42
|
On 2012-09-27 13:36+0200 Arjen Markus wrote: > On 2012-09-27 13:35, Andrew Ross wrote: >> >> Of course we could keep the current code as well and only enable >> shapefile support if the library is present. Shapefile support would >> be convenient for users. >> > > Actually, that is what I had in mind. I think that this (only enable support if the dependent library is present) is a good general approach. So we could start with using shapelib (if present) to interpret shapefile data. But in the long term I don't think we should stop there. I have mentioned the MIT-licensed OGR and GDAL possibilities before, but let me do it again since they are so relevant to this discussion and they are both more comprehensive now (more formats supported) than when I mentioned them before. The OGR library (http://www.gdal.org/ogr/index.html) translates between many vector formats for maps (see http://www.gdal.org/ogr/ogr_formats.html for the full list) including ESRI Shapefile format. The GDAL library (http://www.gdal.org/) similarly translates between many raster formats for maps (see http://www.gdal.org/formats_list.html for the full list). I think our long-term goal should be to interface our core library to both the OGR and GDAL libraries (again, only if those libraries are present). This would give PLplot users the powerful capability of being able to translate most available map formats into either a standard internal vector form (probably shapefile according to this current thread) or standard internal raster form (probably PNM following what we do with the "Lena" image) and modify that internal form with extra decorations and transformations as in example 19. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <and...@us...> - 2012-09-27 16:54:48
|
On Thu, Sep 27, 2012 at 09:37:34AM -0700, Alan Irwin wrote: > On 2012-09-27 13:36+0200 Arjen Markus wrote: > > > On 2012-09-27 13:35, Andrew Ross wrote: > >> > >> Of course we could keep the current code as well and only enable > >> shapefile support if the library is present. Shapefile support would > >> be convenient for users. > >> > > > > Actually, that is what I had in mind. > > I think that this (only enable support if the dependent library is > present) is a good general approach. > So we could start with using shapelib (if present) to interpret > shapefile data. But in the long term I don't think we should stop there. > > I have mentioned the MIT-licensed OGR and GDAL possibilities before, > but let me do it again since they are so relevant to this discussion > and they are both more comprehensive now (more formats supported) > than when I mentioned them before. > > The OGR library (http://www.gdal.org/ogr/index.html) translates > between many vector formats for maps (see > http://www.gdal.org/ogr/ogr_formats.html for the full list) including > ESRI Shapefile format. > > The GDAL library (http://www.gdal.org/) similarly translates between > many raster formats for maps (see > http://www.gdal.org/formats_list.html for the full list). > > I think our long-term goal should be to interface our core library to > both the OGR and GDAL libraries (again, only if those libraries are > present). This would give PLplot users the powerful capability of > being able to translate most available map formats into either a > standard internal vector form (probably shapefile according to this > current thread) or standard internal raster form (probably PNM > following what we do with the "Lena" image) and modify that internal > form with extra decorations and transformations as in example 19. I'd support the use of OGR / GDAL. I've had some experience of their utilities and they also form the basis of file import / export for free GIS software such as Grass. As such they are pretty widely ported and packaged. Andrew |